ISO 27001 for Engineering Teams: The Controls That Actually Matter

Who this is for

This guide is written for engineering leaders, platform teams, and CTOs at companies where an enterprise customer or the board just said: "We need ISO 27001."

Most of the 93 Annex A controls map directly to things your engineering team already does or should be doing. The problem is nobody has written down that you do them. This is how to translate your actual security work into the evidence an auditor needs to sign off.

1. What ISO 27001 actually is

ISO 27001 is not a checklist. It is a schema for documenting an Information Security Management System (ISMS) — a set of policies, procedures, and controls that manage risk. Certification requires two audits four weeks apart (Stage 1 and Stage 2). Stage 1 is paperwork and intent. Stage 2 is a site visit where the auditor looks at the evidence that you actually follow the policies you wrote.

The 93 controls in Annex A of the current (2022) standard fall into four themes: organizational, people, physical, and technological. A.8 (Technical controls) and A.5 (Access control) will touch almost everything your team does. A certification body gets to choose which controls to audit. For a startup or mid-market company, expect coverage of 20–35 controls spread across access control, data classification, vulnerability management, incident handling, and change management. A bank will audit 80+.

Timeline: 6 months minimum. 12 months typical for a team that starts from scratch. The audits cost $8k–$25k. Your work to close gaps costs time, not money.

2. The controls that hit engineering hardest

A.8.5 (Access to source code repositories) and A.8.9 (Configuration management) will come up in every audit. A.8.15 (Secure development, testing, and change management) is the catch-all where the auditor reviews your CI/CD pipeline.

A.8.5 requires: MFA on every repository. GitHub organization settings show this. Branch protection rules that require code review before merge. Audit logs for access changes. A policy that names who can approve pushes to production.

A.8.9 requires: Documentation of your infrastructure as code. A change log (commits count). A policy on infrastructure testing before production. If you are running on Kubernetes, your Helm charts and overlay files are your "configuration management system." Name the repo, name the approval process, name who can merge.

A.8.15 requires: Evidence that you run security checks before code ships. SAST scans (static analysis) on every PR. Dependency scanning for known vulnerabilities (Dependabot, Snyk). A policy on how often you patch dependencies. Most auditors want to see this in CI — they expect your build to fail if a critical vulnerability is found.

What we see in the field: Almost every team has GitHub organization-wide settings that allow bypass of branch protection if you have admin permissions. The auditor will name this as a finding. Set a policy that requires branch protection even on unimportant repos. Use an IaC scanner (Checkov, tfsec) to catch misconfigurations before they reach production.

3. Cloud-specific controls

A.5.23 (Cloud service management) is short but powerful. It requires a policy on how you select cloud providers and review their security controls. You do not need to audit AWS yourself — you can reference AWS's SOC 2 Type II report. But you need to document that you made a decision based on evidence, not coincidence.

A.8.26 (Application development security requirements) says that security requirements must be part of the design process. This is not a security team alone — this is a shared responsibility. Requirements can be simple: "All API endpoints require authentication. All secrets are stored in the secret manager, never in config. All databases are encrypted at rest."

Keep these in a living document in your wiki. Link to your architecture decision records (ADRs) when you made the call to use AWS KMS instead of customer-managed encryption. Link to the PR that added authentication to the API endpoint. That is your evidence.

4. The audit gap: doing it vs. proving you do it

The largest finding we see is not "you are not doing the thing." It is "you are doing the thing but there is no evidence."

Example: Your team reviews every code change. You have a policy on it. But the policy says "code review required" and GitHub is configured to allow admins to override branch protection. The auditor will flag this as non-conformance. The fix: Enable "Dismiss stale reviews" on main. Require re-review after force push. Log and report any admin overrides quarterly to prove they are rare and documented.

Example: You rotate database credentials every 90 days. But nobody documented when the rotation happened or who did it. Add a ticket to your change log or audit table in your secret manager. Proof that the rotation happened is enough.

Example: You scan dependencies for vulnerabilities. But there is no policy on what happens when a scan finds a critical issue. Write the policy: "Critical issues must be triaged within 48 hours. Medium or lower can wait for the next sprint." Add the policy to your wiki. Link to 2–3 examples where the team followed it.

5. Building the evidence trail

Start here, today. Add observability to the controls the auditor will care about.

Access logs: Export GitHub organization audit logs monthly. Save them to S3 or a log archive. A year of logs proves that access reviews happened. Do not wait for the audit to start collecting.

Change logs: Your CI/CD pipeline is already a change log. Export a report of every deployment to production in the last 12 months: timestamp, commit hash, approver, what changed. You can build this from your CI system's API in 20 lines of code. Run it weekly. Put it in a shared drive or wiki page.

Vulnerability management: Export your SAST and dependency scanner results monthly. Keep a running sheet: tool name, date, critical/high/medium counts, what was fixed, what is accepted risk. The auditor needs to see that you trend down or stay flat over time, not that you spike to zero then back up.

Incident response: If you have had an incident, document it (even if it was internal). The documentation matters more than the incident itself. Timeline, root cause, what was done, what changed to prevent recurrence. Most teams that pass are not teams that never had an incident. They are teams that can prove what they learned.

6. The controls that earn their keep

Some controls exist only for compliance. A.14.1 (Information security incident management) is not one of them. Build a real incident response process because incidents will happen, not because the auditor will ask. The process you build for ISO 27001 is the same one that saves you 4 hours of chaos when something breaks at 2 AM.

A.8.9 (Configuration management) earns its keep. If all your infrastructure is defined in code, checked into a repository, reviewed before merge, and logged — you have both compliance and the ability to roll back to any known-good state in minutes. That is worth far more than a certification stamp.

A.5.1 (Access control policy) forces you to name roles and responsibilities. Once you have that clarity, you can build tooling around it: automated provisioning, deprovisioning on termination, periodic access reviews that take 20 minutes instead of 3 days. The compliance requirement becomes infrastructure.

Do not implement controls as if compliance is the only reason. Implement controls that improve your security posture first, then prove that you did it for the audit.

7. The timeline and effort

Month 1–2: Select an auditor. They will tell you which 20–35 controls they will audit. Write policy documents. Most teams write one master ISMS policy that references role-specific policies: development security, change management, incident response. Use a template. You are not inventing novel governance.

Month 2–3: Close technical gaps. If you have no SAST scanning, add it. If MFA is not required, turn it on. If there is no incident response runbook, write one in an afternoon. These are not hard.

Month 4: Evidence collection. Export logs. Build the change and incident reports. Ask the team for proof that they follow the policies. If they don't have proof, make a ticket to add it (logging, change tracking, approval comments in PRs).

Month 5: Internal audit. Walk through the checklist. Do the controls hold up? If not, update the policies to match what you actually do, or change what you do to match the policy. Do not try to fake evidence. The Stage 2 auditor will see through it.

Month 6: Stage 1 audit. The auditor visits, reviews the documents, interviews a few team members. Expect 5–10 minor findings. Close them in a month.

Month 7: Stage 2 audit. The auditor returns, runs through the controls in detail, looks at evidence. Expect 2–5 findings (non-conformances that prevent certification). Negotiate a timeline to close. Most get closed in 3 months.

Month 10: Certification. Repeat the internal audit annually. Expect to spend 20 hours per quarter keeping evidence current.

The pattern that shapes certification outcomes

The teams that get certified fastest are not the ones that start with perfect documentation. They are the ones that accept a simple truth: ISO 27001 is not a tool your security team uses in isolation. It is a forcing function that makes security a shared concern across the entire business. The moment your development team owns the change log and keeps it current, the moment your platform team instruments access logs because they need them operationally (not because an auditor asked), the moment your incident postmortems feed directly into a control improvement — certification stops being a project and becomes the normal way you work.

The teams that struggle are ones that try to build compliance as a parallel system. A separate security checklist. A separate change log. A separate access review. The moment you try that, you have twice the work and auditors can see the disconnect.

The short version

ISO 27001 is an ISMS certification that requires documented security policies, evidence that you follow them, and a two-stage audit (one paperwork, one on-site). Most of the controls hit access management (MFA, branch protection, role definitions), change management (code review, CI/CD scanning, logged deployments), and configuration management (infrastructure as code). Start by turning on technical controls you should have anyway: SAST scanning, dependency checks, audit logging. Build evidence trails now — GitHub audit logs, change reports, incident postmortems — so you have 12 months of history at audit time. Do not build compliance as a parallel system; fold the controls into your normal workflow (code review, change logs, access reviews). Expect 6–12 months and $8k–$25k in auditor fees. The work is procedural, not architectural.