Engineering Practices

ISO 27001 Is Not for the Compliance Team. It Is for You.

Neil Sherman · June 2026

Engineers have a complicated relationship with ISO certification. By “complicated” I mean we mostly pretend it is not happening. Someone gets a certificate, the marketing team puts a small grey logo on the website, and the rest of us go back to whatever we were arguing about that week.

This is, I think, a missed opportunity, because the two standards most software businesses end up dealing with, namely ISO/IEC 27001 and ISO 9001, do far more than provide assurance to the compliance team. They are also, less obviously, documents that work in the engineering team’s favour, particularly for senior engineers who have spent half their careers losing the same handful of arguments and would quite like some help winning them.

The argument you have lost a hundred times

Pick a senior engineer at random and they will have a private list of things they have been gently advocating for, in various meetings, for years.

Rotate the secrets. Threat-model the auth flow before it ships, not after the penetration test report comes back highlighted in red. Stop putting credentials in the config file that gets checked into source control by the new starter on day three. Test the backup restore once in a while, just to confirm it does the thing it claims to do.

These arguments are correct. Everybody nods at them. Then everybody goes back to whatever they were actually doing, because being correct is, on its own, not a strategy. The roadmap is full. The risk feels theoretical. The argument resumes in roughly nine months when somebody else raises it as if for the first time, and the cycle continues.

Here is the trick. ISO 27001 does not make those arguments more correct. They were always correct. What it does is move them out of the bucket marked “engineering preference” and into the bucket marked “things the company has formally committed to doing.”

Different bucket. Different conversation. Much shorter conversation.

A small note before I go further, because the rest of this post is written in a register that finds the politics of certification mildly amusing. That register is the engineering perspective. It is not the whole picture. In any serious organisation, ISO 27001 and 9001 also underpin formal risk management, governance, and external assurance processes that are run with considerable rigour. I take certification seriously and so do the engineers I work with. What follows is the engineering side of the story, which usually does not get told because it is the side told over coffee rather than in board reports. Both stories are true. The board version is properly written elsewhere by people whose job it is to write it.

ISO 27001, read as if it were aimed at you

The current edition is ISO/IEC 27001:2022, which arrived in October 2022 and which most certified organisations are now operating under. Its Annex A contains 93 security controls. The marketing material tends to describe these as “comprehensive,” which is one of those words designed to discourage further questions.

You do not need to read all 93. About a dozen of them are written, in spirit if not in syntax, directly at software teams. Three are particularly worth knowing about by name, because if you can drop these into a conversation with a slightly weary expression you will sound enormously plausible.

A.8.25 Secure development life cycle says, in plain English, that you need a defined way of building software, and that security has to be part of every stage of it rather than something you sprinkle on at the end like seasoning. A.8.27 Secure systems architecture and engineering principles is the architect’s clause. It expects design decisions to take security seriously: zero trust, defence in depth, fail securely, least privilege. If you have ever drawn one of those phrases on a whiteboard and watched the room politely wait for you to finish so they could get back to the feature discussion, this is the clause that hands you back the marker. A.8.28 Secure coding is the developer’s clause. It requires documented coding standards aligned with recognised guidance such as the OWASP Secure Coding Practices or the SEI CERT coding standards, and expects you to actually use them, rather than write them down once and then never speak of them again.

There are others worth knowing. A.8.29 covers security testing. A.8.31 covers separation of dev, test and production environments, which sounds trivial until you remember how many organisations run a “staging environment” whose only meaningful difference from production is the word “staging” in the URL. A.8.13 requires that backups are not only made but tested. A.8.32 covers change management.

The point is not to memorise the numbers. The point is that taken together, this cluster of controls is essentially a written, externally-audited list of practices that senior engineers spend their careers asking for politely.

When the team lead says “we cannot ship that this sprint because the auth flow has not been threat-modelled,” there is a real difference between that being a personal opinion and that being the documented expectation of a standard the company has formally committed to. One of those gets debated in stand-up. The other gets a calendar invite.

How long the argument used to take

Picture a scenario every long-running engineering team has had at some point.

There is a service. Its secrets management is, charitably, vintage. Credentials sit in a config file checked in years ago by someone who has long since moved on. Rotating them properly would take a sprint. The argument has surfaced four or five times. Every time, the answer is that it is a nice-to-have, the roadmap is full, and the risk feels theoretical.

Now run the same argument three months into a serious certification effort.

It does not take a year. It does not take a quarter. It takes one meeting, and not a long one, because the question has changed shape. It is no longer “do we believe this is worth doing.” It is “can we evidence this when the auditor asks.” Those are extraordinarily different questions, and the second one has a much shorter answer, which is “no.”

This is the underrated payoff of certification for the engineering team. The clauses become a polite, neutral third party that everyone in the room can refer to. The argument stops being you against the delivery roadmap. It becomes the entire team against an external commitment that everyone has already signed up to. You did not pick the fight. You are pointing out, with regret, that it was picked on paper years ago.

A small analogy, because I cannot quite resist them. My eldest came home from school last term complaining that his teachers made everyone line up before assembly. “Why do we even need to line up?” Because forty children walking in as a queue arrive in the hall in the same shape they left the classroom. Forty children walking in as a free-for-all arrive as a different problem entirely.

The line is annoying. The line is not the point. The line is what makes the next bit possible.

ISO 27001 is the line.

ISO 9001 and the haunted codebase

ISO 9001 is the harder sell, because it is not a security standard, it is a quality management standard, and the prose has a faint whiff of factory floor about it. But if you persist past the language, several of its seven quality management principles translate cleanly to software work, in particular the process approach, evidence-based decision making, and continual improvement. The software-flavoured interpretation lives in ISO/IEC/IEEE 90003, in case you ever need to win an argument by citing a standard nobody else in the room has heard of.

Here is the engineering problem ISO 9001 quietly solves.

Every long-running codebase eventually becomes mildly haunted. The build pipeline has a step nobody can explain. Deployments do not happen on Fridays for reasons lost to history. One service has its own database while three others share, and the original justification is buried somewhere in a Slack message from 2019. The retry policy on the payments service is significantly more conservative than every other service in the estate, and the only person who knew why does not work there anymore.

This is the tribal knowledge problem, and it is one of the quieter killers of long-lived software. Every new joiner cheerfully reinvents the same wheels, hits the same potholes, and slowly rediscovers institutional reasons for things that were never written down because, at the time, everybody knew.

ISO 9001 is, at its core, an externally-enforced commitment to writing things down. Not in the bureaucratic sense of producing reams of policy documents nobody reads. In the more useful sense of the auditor being unable to certify your processes if those processes only exist in three senior engineers’ heads.

The version I have come to value is what I think of as “decisions, not procedures.” Documenting how a release is cut is fine, but procedural. Documenting why the release process looks the way it does, why the database engine was chosen, why a pattern was tried and abandoned, why the retry policy is what it is, that is the thing that stops new engineers from spending six months guessing. Architectural Decision Records are the format most teams settle on. ISO 9001 will not, by itself, make a team write them. It will, however, give the team a defensible reason to start, which in my experience is most of what good engineering practice ever needs.

What this is not

A few quick caveats before anyone accuses me of selling certification consulting.

ISO 27001 will not stop you writing insecure code. ISO 9001 will not make the resulting software good. The standards are scaffolding, not foundations. They make it harder to do certain bad things and easier to do certain good things, which is an underrated thing for any framework to achieve, but they do not write code or make architectural decisions for you. Certification amplifies whatever culture is already there. An organisation with strong engineering instincts will find these standards genuinely useful. The standards alone are not, and have never claimed to be, a substitute for engineering judgement, which is why no serious practitioner treats certification as the end of the conversation.

The audit, reframed

A good auditor asks, almost word for word, the same questions a good staff engineer asks. Show me how you decide what gets deployed. Show me what happens when a deployment fails. Show me how a developer who joined yesterday would know what your secure coding standards are. Show me where the threat model for this service lives. Show me the last time the backup restore was tested, and please do not say “in theory.”

If the honest answer to any of those is “it lives in someone’s head,” the auditor will look quietly disappointed.

So would any senior engineer doing a serious technical review.

The audit, properly understood, is an unusually structured form of external technical review. The crucial difference from internal review is that the third party has no political stake in your delivery roadmap. They are not going to be talked out of asking the awkward question. They are not going to defer it to next quarter. They are not going to be impressed by how busy you have been.

This is irritating in the moment and genuinely useful afterwards, particularly when the awkward question is one you have been trying to get somebody in your own organisation to take seriously for the last three years.

The business side, briefly

The commercial case for these standards has been written about exhaustively. Easier procurement. Faster security questionnaires. Larger contracts in regulated sectors. Better insurance premiums. All true. All important. All not what I find interesting, because they have been told to death.

What gets less airtime is the engineering side: that certification, done properly, makes the technical work easier. It removes about half the political friction from the engineering arguments worth having. It pushes good practice from “thing we keep meaning to do” into “thing we have already promised to do.” It turns the slow erosion of institutional knowledge into a written, version-controlled record. Those are the benefits engineers feel day to day, even if the case study on the corporate website is about winning the contract.

Both things are true at once. The business gets a sales tool. The engineers get cover. The smart organisations realise this and lean into the second one, because culture follows the path of least resistance, and the path of least resistance is suddenly the path the auditor is checking.

So what

Stop reading these standards as compliance documents. Start reading them as the engineering arguments you have been losing for the last decade, written down in language the rest of the business has already agreed to take seriously.

That is, in fact, exactly what they are.

External references

Views are my own and do not necessarily reflect those of my employer.