Security ownership beyond the central team
How delivery squads absorbed security ownership, and what mergers and reorganisation did to standardisation.
In this recap
The room
Three practitioners, which made this less a panel and more a conversation. An engineering manager from payments inside a large retail bank, an engineering manager at a national online marketplace, and a founder and chief technology officer who previously ran technology at a European payments processor and now advises early-stage companies. Three further participants from the technology supplier side completed the table.
The session ran under Chatham House convention. Everything below is reported without names or organisations. With a table this small that matters more, not less, because nobody could hide in the group.
The record for this session carries a caveat worth stating. The recording came back without speaker separation, so attribution was reconstructed from the introduction round and from passages where the speaker was unambiguous. Where a contribution could not be tied to a person with confidence, it sits with the themes rather than being given a name.
When the central security team stops scaling
This was the spine of the morning, and the framing everyone accepted before they started disagreeing about the shape of the answer.
A central security function cannot cover thousands of developers. One example put to the room was five security people against three thousand engineers, with the observation that this is not a new problem: the same advice was being given out fifteen years ago.
The practitioner numbers made it concrete. One organisation described a security team that had shrunk from around twelve people to five or six, serving an estate with millions of customers behind it. Developer security training in that organisation runs once a year for two days, and the person describing it said plainly that this is not enough.
Five security people cannot serve three thousand developers. The understanding has to move into the teams that own the code.
A position argued in the room, reported without attribution.
Two working models were described, and they are meaningfully different.
A named person per team
One engineer in each team holds the security champion role and reviews code. Over several years this became a hard gate: going to production without the champion's approval stopped being allowed.
The strength is clarity. There is a name against the responsibility and an enforcement point in the pipeline.
A capability the squad holds
Rather than one champion, the squad carries a passport: a checklist of skills and activities the team has to hold, covering monitoring, security and infrastructure alongside ordinary delivery practice.
The strength is that it does not create a single point of failure, and it survives the champion leaving.
The third organisation at the table had neither, and said so. Ownership there was described as going in the wrong direction, with a separate and now smaller security team running scans and raising tickets into teams that did not have the context to action them well.
Where should security expertise actually sit: with a named person inside each delivery team, or as a capability the whole squad is measured against?
Both models were defended by people running them at scale, and the disagreement was about shape rather than direction. What the room did not resolve is what happens when the named champion leaves, or how you assess a squad-level checklist honestly when the squad marks its own work.
What a merger does to ownership
The most uncomfortable material of the session, and the most useful, because it was described as it actually is rather than as a case study.
One participant had inherited systems from central teams without the original ownership or the knowledge that went with them. A push-notification service arrived running on a decade-old framework and runtime, needing constant rework. His own assessment was that building new might have been easier than inheriting and refactoring.
Alongside that sat a quality gap between software built by his own team and software inherited from a team in another country, a forced migration between cloud providers, and mandated technology choices that did not fit the data model, which in turn made cost control difficult. Deadlines had compressed too: a shipping method that would previously have taken a quarter was cut to about a month.
The counter-example came from someone who had run technology through a series of acquisitions at a payments processor. The approach there was to bring acquired platforms up to a baseline while allowing autonomy, tolerating multiple clouds rather than forcing consolidation, and leaving data where it sat with data champions attached to it rather than driving everything into one lake.
It might have been easier to build it new than to inherit it and refactor.
A position argued in the room, reported without attribution.
The unresolved question underneath both accounts is how you raise the less mature teams without slowing down the capable ones. Nobody claimed to have solved it.
From trust to evidence
The facilitator framed the theme as a shift from a trust-based supply chain to an evidence-based one, where anything you trust can be evidenced in the pipeline: where a component came from, its provenance, and who touched it.
The analogy that carried the room was a simple one. A bottle of water lists its ingredients. Software has historically shipped with none. A software bill of materials is the ingredient list, and the follow-on is a batch number, so that when a component turns out to be from a bad batch you can trace where it went.
The most concrete control described was a package gateway. Very young packages, for example anything published in the last seven days, are blocked at the gateway, as are known-malicious ones. The part that makes it workable is what happens next: rather than failing the developer's request, the gateway serves the next compliant version. The policy holds and the developer is not stopped.
Regulation was named as the force pushing this from good practice towards expectation, with the direction of travel described as an automated packaging factory for software.
Governing AI rather than banning it
AI ran through every part of the conversation, and the starting position was shared: developers will use it regardless, so the work is guard rails rather than prohibition.
What people wanted the guard rails to do was specific. Keep code and intellectual property inside the organisation. Govern not just the models but the surrounding machinery, the connectors and the skills attached to them. Use smaller domain-specific models in place of a general one where the task allows it.
The dissenting note was about pace rather than principle. One participant, advising early-stage companies, said the tooling landscape changes almost monthly and that a small company cannot re-platform at that rate, so his advice is to choose technology likely to still be there in a year or two. He also described pushing a young company to think about production, security and compliance from day one while using AI assistants heavily, and reported a roughly fivefold productivity gain from that combination. That figure was offered as one company's experience, not as a benchmark.
Shift left, or test at the right point
The room was sceptical of shift-left as it is usually sold.
The cost argument for it is real and nobody disputed it: a penetration test months after the code was written arrives when the developer no longer remembers the context, which makes remediation slower and worse. The objection was to the conclusion drawn from it. Pushing every check into the development environment overloads the developer, and an overloaded developer starts ignoring output.
The alternative argued was testing at the right point across the whole lifecycle rather than as early as possible by default, with the practice maturing over time. One account described exactly that trajectory: penetration testing moved from quarterly to half-yearly as in-pipeline controls improved, because the pipeline was catching earlier what the test used to find.
On what makes an organisation start at all, the answer offered was blunt.
What actually makes an organisation start taking secure development seriously?
An incident, either your own or one at a close competitor. External pressure, meaning regulation or a customer demanding a secure lifecycle as a condition of doing business. Or, described as the rare case, someone senior simply deciding to do the right thing. A widely reported manufacturing incident was cited as a recent example of the first kind, and of customers going away to scrutinise their own pipelines afterwards.
Where the room pulled in different directions
A table of three produces fewer camps than a table of twelve, but the tensions were sharp and none of them closed.
Whether security ownership belongs to a named person in each team or to the squad as a measured capability. Both models were being run successfully by the people describing them.
Whether an acquiring organisation should standardise its inherited estate or bring it to a baseline and leave the autonomy alone. The two accounts at the table came out on opposite sides, and both had the scars to justify their position.
Whether shift-left genuinely reduces cost or simply relocates the burden onto developers who are already carrying too much.
Whether to move quickly on AI tooling while the advantage is available, or deliberately choose a slower-moving stack because a small organisation cannot re-platform every few months.