I messaged the head of operations. After a short discussion and an inspection, he turned off a production system that had gone live that day.
This was not a paved path response. As the lead of a small team building the security platform for our product teams, this meant reaching for an option I had kept strictly in reserve: putting the brakes on another team's delivery, forcing them to delay a launch. Not something to do lightly.
How did we get here?
As Engineering Security (Eng-Sec) lead, part of my job was to do a sense-check on new systems. Was the security guidance landing? Were the conversations we'd started changing how it was built? This post-launch check was a surprising and unusual no. It was collecting and holding customer data in a database that had never been moved off its defaults or locked down. It shouldn't run as a production system, and it couldn't. Six months into rolling out a new security standard, and this new way of working clearly hadn't reached every team.
So we took control back.
Just this team. Just this once.
That decision is what I want to talk about. Not the time we triggered it, but the work done so this was the only time in two years that we had to.
Pushing security conversations earlier, and providing clarity and support worked. Through this, teams took solid ownership of their own security and shrank and secured the estate. This one time we stopped a launch outright was an event. How we make this option so rare is worth walking through.
"You build it, you own it"
Our product teams held the wheel, control of their systems. And that included security. Not "we'll decide and let you feel involved", but "you are best positioned to make the right call". Every team knew their system, their users, their risk, far better than we ever would looking in from the side. If we wanted them to own security, they had to actually own it.
That power comes with a bill, and we'd worked hard to make that clear. On the front of our security standard was the comforting version: "With great power comes great responsibility". We'd named our standard The STAN. After Stan Lee, author of that quote. We want you to own your systems. But that means you need to own the security too.
There was no "do as I say". It would be well rude to say that from the sidelines. My team, Engineering Security, owned the authentication and authorisation stack - access control. Every rule we wrote, we operated under first.
Beyond that, as the lead in the Eng-Sec team, I, along with our head of operations, had a responsibility to be the backstop. This was new, and teams were learning. Cars built for driving lessons have an extra brake for the instructor, and sometimes, this was our seat.
Designing the system with safe defaults
Giving ownership doesn't mean betting on people not making mistakes. People make mistakes, not due to carelessness, but because they're human. Tired; moving fast; trusting the thing in front of them to catch what they miss. You don't fix that by asking for more care. Nor by sitting on that emergency brake pedal. You fix it by building a car where a mistake doesn't write the car off.
The sharpest bump we hit: nobody should be able to accidentally delete rows in a production database. Not "nobody should". Nobody should be able to, by accident. A fat-fingered command on a Tuesday should never be the only thing between a normal week and a very bad one. We learnt to put barriers in the way. A confirmation, a guard, a gap between the feet and the cliff edge.
This is a lot of the job, and it's a little unglamorous. Building and automating safe paths so they are also the low-friction option. And where we couldn't automate, we'd teach.
We had a rule for it, automate or educate, and a name for what we were after: pits of success, a system shaped so people fall into the right answer without trying.
We wanted to have confidence that we could keep the foot away from the brake. After all, we couldn't babysit every team, at all times. Trust, but verify is an old line, but useful. Measuring security is hard, so we measured what we could. Finding proxy measurements in known vulnerabilities, out-of-date libraries, the risky dependencies teams could be carrying.
Measuring mattered and guided the Eng-Sec team. Reporting mattered more. A problem nobody could see stayed nobody's job. The same problem on a shared report? Teams saw it, took ownership and fixed it. Visibility did the work policing would have done. But nobody had to be the police.
The five rules that meant we avoided the brakes
Good security is often invisible. A paved-path someone walks without noticing there was ever a harder, unsafe route. A fix that landed before it needed escalating. Design sessions that led to safe systems. The brakes, when needed, are the part people remember, because they are loud, obvious, and often too late in the build cycle.
This security scaffolding was guided by teams' five core rules.
With great power comes great responsibility. Enable teams to hold their security responsibility.
Automate or educate. Make the safe path the easy one.
Keep everyone one step from disaster. So a slip is never a fall.
Trust, but verify. Measure it, show it, let daylight do the work.
Use the brakes as a last resort. Be the final backstop to allow teams to learn a new job.
These allowed us to not become a new security police force, instead to educate, support and guide the organisation to a new way of operating, now with security included.
If you hold a veto or a gate late in the process, you control the brakes. Your key question shouldn't be: do you use it well? Instead ask: what would make it unnecessary? Perhaps borrow my rules, until you find your own.
[Cover Photo by Adhitya Sibikumar on Unsplash]
