Security & Privacy: SFIA levels and developer seniority
Fennec team · 6 Apr 2026 · 4 min read
Security is the discipline where a good outcome is invisible: nothing happens. That makes it easy to underrate, since you mostly notice it when it fails. Good security work means finding problems before an attacker does, and building systems where the safe way to do something is also the easy way.
SFIA levels here move from treating the OWASP Top 10 as a checklist, to defining what "secure enough" actually means for an entire organisation.
1
Level 1: Follow
“I know what the OWASP Top 10 is and follow basic security practices in my work. I escalate potential security issues to others.”
Evidence here is about attentiveness: a code review comment about a security issue that you acted on, notes from OWASP Top 10 training, or a security concern you escalated to someone more senior instead of shipping around it.
Read the OWASP Top 10 properly rather than skimming the list of names, it's short enough to actually understand. Ask a senior engineer to show you a real vulnerability they found and how, and practice spotting one class of bug, SQL injection is a good first target, in code review.
2
Level 2: Assist
“I implement basic security controls, validate inputs, handle authentication following patterns, and flag security risks in code review.”
The evidence shifts toward implementation: input validation or authentication code you built following an existing pattern, a security risk you flagged in someone else's pull request, or basic security controls you implemented as part of a feature rather than an afterthought.
Implement an authentication or authorisation flow yourself instead of only calling an existing one, understanding it from the inside changes how you review it later. Flag one real risk in review this month, and learn how one OWASP category actually gets exploited, not just its name.
3
Level 3: Apply
“I proactively find and fix security issues, implement auth and authorisation correctly, and catch security anti-patterns in code review. I don't need to be told, I look for this naturally.”
This is where proactive work becomes the evidence: a vulnerability you found and fixed without being asked to look, authentication or authorisation logic you built and got right the first time, or a security anti-pattern you caught in review before it shipped.
Run a lightweight threat model on a feature you own, even an informal one. Go looking for a security issue instead of waiting for a scanner to find it, and pair with your security team on a review, it's a fast way to pick up the instincts that are hard to learn alone.
4
Level 4: Enable
“I design threat models, run security reviews for major systems, and set the security standards my team follows. I'm the person who defines what 'secure enough' means for our products.”
By now the evidence is standards you set: a threat model or security review you led for a major system, or a security standard your team adopted because you introduced it and made the case for it.
Write and run a threat-modelling session for your team rather than leaving it informal, and define what 'secure enough' means for one product area in writing, so the standard exists independent of you. Owning a system's security posture end to end is usually what marks this level from the outside.
5
Level 5: Ensure & Advise
“I define the security architecture and governance framework for the organisation. I lead audit and compliance programmes and build security culture.”
The evidence spans the organisation now: a security architecture or governance framework you defined, an audit or compliance programme you led, or a security culture initiative, training or review processes, that exists because you built it.
Write a security architecture standard spanning multiple teams, and lead an audit or compliance initiative rather than just supporting one. Building security culture through training and enablement, not just gates, is usually what separates this level from simply having more authority to block things.
6
Level 6: Initiate & Influence
“I set security and privacy strategy at an organisational or industry level.”
At the top, the evidence is external as much as internal: an organisation-wide security strategy you set, published research, talks, or responsibly disclosed findings, or security direction that shaped decisions well outside your own team.
From here, publish security research or standards externally, set security strategy at the organisation level, and expect to represent security at the leadership table more often than you review a specific pull request.
Go deeper
The open reference for application security risks and defences.
True stories from the world of hacking and cybercrime.
A long-running security news podcast.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log security & privacy evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.