ISO 27001/27002
From ISO 27002 Controls to Engineering Requirements
July 2026 · 4 min read
An ISO 27002 control catalogue is deliberately written at the level of outcomes. It tells an organization that access should be managed, that changes should be controlled, that security-relevant events should be logged — and it stops there, because the standard cannot know your architecture, your team, or your deployment pipeline. That restraint is a strength of the standard and a persistent problem for engineering teams, who are left holding language that describes a destination without a route.
The failure mode I have seen most often is treating that gap as a documentation exercise: the control text gets paraphrased into a policy, the policy gets approved, and delivery continues unchanged until an audit forces a rushed retrofit. Compliance becomes a parallel process bolted onto engineering — satisfying the letter of each control while changing nothing about how software is actually built.
Having moved between security governance responsibilities and hands-on software engineering — including contributing to a platform whose whole purpose is helping organizations assess controls like these — I have come to treat every control as an input to the requirements process. What follows is the translation path I use, from control language to work an engineering team can estimate, build, and verify.
Read the control as a question, not an instruction
A control that says access to information should be restricted according to policy is not telling you what to build; it is asking questions you have not answered yet. Who owns this system and this data? What roles exist, and what does each genuinely need? How is access granted, and — the part teams forget — how and when is it revoked? The same move works across the catalogue: a logging control asks what a security-relevant event is in your system; a change-management control asks which changes need a documented approval trail before reaching production. Write the questions down. They are the raw material of requirements, and answering them early is dramatically cheaper than answering them mid-audit.
Give every answer an owner
Control language loves the passive voice: access shall be reviewed, incidents shall be reported. Software does not run in the passive voice. Every translated requirement needs a named owner — a person or a team, not a department — accountable for the mechanism existing and continuing to work. In practice this is the single highest-leverage translation step: most control failures I have seen were not missing mechanisms but orphaned ones, built once and owned by nobody after the engineer who wrote them moved on.
Turn intent into acceptance criteria
Once a control has become questions with owners, the answers become testable statements — the same acceptance criteria you would write for any feature:
- When a user’s role changes, access tied to the old role is revoked within a defined window, and the revocation is recorded.
- Every deployment to production is traceable to a reviewed, approved change with an identifiable approver.
- Security-relevant events — authentication, permission changes, data exports — are logged with actor, timestamp, and outcome, and the log itself is protected from modification.
- An emergency-access path exists, and using it triggers a review rather than a shrug.
Fold the control into delivery habits
The translation is complete only when it disappears into how the team already works. Access rules become part of code review — a reviewer asks who can call this endpoint the same way they ask about test coverage. Change control stops being a separate form and becomes your pull-request flow with approvals that are actually recorded. Logging decisions get made in design discussions, not discovered during incident response. When a control lives inside delivery habits, evidence accumulates as a by-product of normal work — which is exactly what an auditor hopes to find, and what a bolted-on process never produces.
None of this makes a team compliant by itself, and that is not the goal. The goal is that when the audit conversation happens, engineering can answer with artifacts instead of assurances — requirements, review records, logs — because the controls were treated as inputs to the work rather than paperwork after it. In my experience that team also ships better software, audit or not: ownership, traceability, and deliberate access design were never compliance ideas. They were always engineering ideas that a standard happened to write down.