ISO 27001 for developers: mapping Annex A to your repo
By the Zairen team · · 7 min read
If you're an engineer who's been handed an ISO 27001 Annex A checklist for the first time, it probably reads like it was translated twice from a language you don't speak. That's not you being dense. Annex A is written for auditors and risk managers, and almost none of it maps obviously to a pull request.
Start by grouping controls by what actually touches code
Not every Annex A control lives in your repo. Some are organizational: policies, training records, supplier contracts. But a meaningful chunk, things like A.8.24 (use of cryptography), A.8.9 (configuration management), A.5.15 (access control) do have a direct code-level answer. The first useful thing you can do is separate "this is a document problem" from "this is a code problem," because they need completely different owners.
A.8.24, encryption, as a worked example
The control says data should be protected using cryptography according to a documented policy. In practice, that turns into concrete, checkable things: are secrets ever logged in plaintext, is TLS enforced on every external endpoint, are passwords hashed with something modern instead of MD5 from 2011. Static analysis can check most of that directly against your codebase, which turns a vague policy statement into a pass or fail you can actually act on.
Why the ISMS keeps drifting out of date
Most teams build their Statement of Applicability once, screenshot some evidence, and then the codebase moves on without anyone updating the paper trail. Six months later, the "evidence" describes a system that no longer exists. This is the single most common thing we see going into a recert audit: not that the controls are missing, but that the evidence is stale.
Mapping to more than one clause at once
A single piece of evidence, say, a passing check that all API routes require authentication, can satisfy more than one Annex A control at the same time, and often overlaps with SOC 2's CC6 criteria too. Keeping one control library instead of three separate spreadsheets means you're not doing the same evidence-gathering work three times for three frameworks that are asking a version of the same question.
What this looks like day to day
In practice, the least painful version of ISO 27001 is one where your CI pipeline is already producing the evidence as a side effect of normal development, and the ISMS just points at it, instead of your team stopping what they're building to go screenshot proof that it's secure.
Our ISO 27001 page covers how Zairen keeps that mapping current automatically, or book a demo to see it against your own Annex A scope.