Guest blog by Beth Hurford, Senior Optimisation and Transformation Consultant, Logiq
Picture this. You’re in a requirements workshop. There’s a business analyst (BA), a developer, maybe a systems engineer, and you, the product owner (PO). Security isn’t there. Someone decided it was “too early”, that involving them now would mean “too many cooks” and that security can review things later. By the time security is invited in, the decisions have already been made.
Security failures don’t start in code. They start in product decisions.
After a few workshops, the backlog starts to take shape. Security is then brought in to review the decisions that have already been made and identify any missing security controls. This assumes security is a technical concern to be handled later by specialists. On the other hand, you may loop security in after development to sign off on decisions they had no part in making. The result is predictable: more meetings, more reviews, and stakeholders revisiting decisions they should have been part of from the start. If security concerns appear late, the cycle starts again: BAs rewriting user stories and developers reworking code. The result is siloed workstreams, where security becomes “someone else’s responsibility”.
When security does eventually get brought into the conversation, the dynamic is already broken. They raise concerns on decisions that feel settled, which makes them appear as blockers rather than enablers. That reputation sticks, and it becomes the justification for excluding them early next time. It’s a vicious cycle.
The product owner is uniquely positioned to champion security from the start. POs sit across every workstream – business, delivery, design, engineering – bringing together stakeholders that rarely share the same room. They guide teams by balancing commercial goals, technical constraints, user needs, and security risk – managing that balance iteratively as the product evolves. Nobody else has that vantage point. That makes you either the person who accidentally keeps security siloed, or the person who finally connects it to everything else. Product owners don’t need to be security experts, but POs and BAs can learn enough from security specialists to ask the right questions early.
This is what secure by design actually means in practice. It starts with who is in the room. Rather than treating security as a separate function you consult after requirements are agreed, security should be part of the delivery team – present during discovery, refinement, and planning. They don’t necessarily have to be in every meeting, but they should be involved from the outset so that their input shapes decisions rather than reviewing them after the fact. When knowledge is shared consistently over time, POs and BAs begin to internalise security thinking and learn to write requirements with security in mind, reducing the dependency on security being in every room.
This is where the questions you ask as a PO start to change. For example, when discussing user account types, are you considering least privilege – ensuring each role only accesses what it genuinely needs? When building a login feature, are password rules defined in the requirements, or left for a developer to make a judgment call on? When you’re scoping a feature that relates to storing user data, are you defining how long it needs to be retained and why? Or is that question never asked at all? Some of these requirements come from legislation and regulation. GDPR, for example, directly shapes decisions around data retention. Considering them after requirements are already written leads to designs that are more complex and harder to secure than if they’d been factored in from the beginning. These are the kinds of questions a PO or BA can ask without needing a security consultant in the room.They’re product questions, and they belong in your requirements workshops.
The output of this thinking lives in your user stories. If security is a requirement, it should appear where requirements live – the backlog. Not hidden in a separate ticket. Not reviewed after the fact, but written in from the start as part of your Definition of Ready and Definition of Done. The mindset should be that if a story isn’t secure, it isn’t done. That shift in how you write and approve stories changes the entire conversation around what ‘done’ means.
Security requirements belong in the backlog alongside every other requirement – prioritised, visible, and non-negotiable. A PO who controls the backlog controls what the team treats as important. If security is consistently prioritised, the team’s behaviour follows.
Testing follows the same logic. Testing validates whether the secure-by-design decisions actually worked. Security testing should happen alongside functional testing from the start, not added later as an afterthought. When a security issue is found, it should be raised and resolved within the same sprint, treated as a bug rather than deferred to a separate remediation backlog. This keeps security testing as a constant thread throughout the software development lifecycle rather than a gate at the end. There’s no big reveal because the risks have already been addressed.
None of this happens overnight. Embedding security into your process is itself an iterative journey. You won’t get it right the first time. The goal isn’t perfection, it’s progress. Each sprint is an opportunity to reassess your security risk profile, address what’s emerged, and improve. Aim to identify opportunities to iterate rather than failures to hide from.
The cumulative effect of all of this is that security stops being a bottleneck and starts being a capability. The perceived overhead of involving security disappears because the knowledge is distributed across the team rather than concentrated in a single function that everyone has to wait for. That shift starts with a product owner who treats security as a product decision, not a technical afterthought.
About Logiq:
Logiq is a NCSC-assured cyber security consultancy and secure solutions provider focused on safeguarding critical organisational data. Our clients are amongst the most demanding in the world and have some of the most stringent and complex security needs. We help to design and develop innovative solutions that enable them to focus on delivering their business securely.
