The posting, in Teya's own words
archived Oct 13, 2026Hello. We’re Teya. Teya was founded on a simple belief: local businesses deserve better. They are the cafés, restaurants, salons, shops and entrepreneurs that bring character to our high streets, create jobs and keep communities moving. Yet for too long, financial services has made life harder for them - with clunky tools, poor support and complexity that gets in the way of running a business. Teya exists to change that. We’re building a financial platform for local businesses across Europe - one built around simple tools, thoughtful design and real human support. Our Members rely on us to help them run their business with confidence, and that responsibility shapes the way we work. We move fast. We care about quality. We stay close to the detail. And we believe great performance and genuine hospitality should go hand in hand. If you want to build meaningful products, solve real problems and make a genuine difference for local businesses, we’d love to hear from you
About the role
We're a regulated payments fintech operating across multiple European markets, scaling into banking-licence territory. Security Engineering is being rebuilt around a joint operating model with our product, platform, and infrastructure teams. We're hiring a Principal Security Engineer to own the application security side of that model: how software gets designed, built, reviewed, and shipped safely across a growing engineering estate, and how security shows up as an accelerator rather than a toll gate. This is not a review-queue role, and it is not a role about counting findings. We're not looking for someone to triage scanner output, chase "critical" CVE counts, or sign off tickets. We want an engineer who changes how the company builds software: transforming our SDLC into a secure SDLC, placing controls where they deliver the most value for the least friction, and making the secure path the default path. The thread running through everything here is influence. You will spend as much time with engineers, product managers, designers, operations, and compliance colleagues as you do with code and tooling. The person who succeeds in this role is the person who can walk into any team, explain the risk in language that team actually uses, and leave them better equipped than when they arrived.
Read the full posting ↓
First 90 days
Understand how we actually build. Map our real delivery paths, from idea to production, across the teams that matter most. Find where security currently lands too late, too heavily, or not at all. Baseline the application estate. Establish a clear, honest view of coverage, risk, and the gaps between them. We would rather know the truth early than have a tidy dashboard. Start building relationships. Embed with engineering teams, run threat modelling with them rather than for them, and use those sessions to demonstrate what good looks like in practice. Identify high-leverage controls. Identify what changes to the SDLC would measurably reduce risk while making delivery faster.
First year
Secure SDLC transformation. Design and roll out the controls, patterns, and checkpoints that make up our SSDLC. Proportionate, evidence-based, and justified by impact, not by convention. Shift-left in practice, not as a slogan. Secure defaults in templates, libraries, and paved roads so that the easiest way to build something is also the safe way. Developers should hit guardrails rarely, and understand them when they do. Pipeline-embedded controls. Work with the platform team to extend policy-as-code and build upon existing pipeline security toolchain (SAST, SCA, secrets, or DAST for example). Checks that run in the pipeline and produce signal engineers trust, not noise they learn to ignore. Threat modelling as routine practice. Make design-stage security a normal part of how teams work, scaled through enablement and templates rather than through your calendar. Security champions and enablement. Build a champions network, run training that engineers actually want to attend, and create the material that lets teams self-serve on the common questions. Risk that reflects reality. Move us from severity labels towards exploitable attack paths: what an attacker could actually chain together in our environment, and what that would cost us.
The 18-month direction
The strategy is that security scales through leverage and culture, not headcount. Your job is to build the patterns, tooling, and shared understanding that other teams operate against, and to make security a capability the business associates with speed and confidence rather than delay. If a control needs to be applied a hundred times, you build the way it applies itself, and you make sure the hundred teams understand why it exists.