ISO 27001 Implementation: A Practical Guide for Tech Teams

Implementing ISO 27001 means building and running an information security management system (ISMS): a defined scope, a documented risk assessment, a Statement of Applicability that decides each of the 93 controls in Annex A of the 2022 edition, and evidence that the system operates, through internal audit and management review. An accredited certification body then audits it in two stages and certifies it for three years. For a software company, most technical controls already exist in the stack (SSO, code review, infrastructure as code, central logging). The real work is scoping tightly, writing the risk decisions down, and producing evidence continuously instead of in the month before the audit.

Key takeaways

• ISO 27001 certifies a management system, not a product. Clauses 4 to 10 are mandatory; Annex A is a reference list of controls you select from based on risk.
• The current edition is ISO/IEC 27001:2022. Its Annex A has 93 controls in four themes, and the transition period for 2013 certificates ended on 31 October 2025.
• Scope is the biggest lever on effort. Certify the product and the people and systems that build and run it, not the whole company on day one.
• The Statement of Applicability is the document auditors read most closely. A copied template with every control marked applicable is the fastest way to a bad Stage 1.
• Generate evidence from systems of record (Git, your identity provider, cloud audit logs, ticketing), so the audit is an export, not a project.
• Certification runs on a three-year cycle with surveillance audits in years one and two. The ISMS has to keep running between audits, or the surveillance audit finds out.

What ISO 27001 actually requires

The standard has two parts that people often blur together.

Clauses 4 to 10 are the requirements. Every one applies and none can be excluded. Together they describe a management system: understand your context, get leadership commitment, assess and treat risk, support the system with people and documentation, operate it, measure it, and improve it.

Annex A is the control catalog. You compare your risk treatment against it to check you have not missed anything, then record your decisions in the Statement of Applicability. Implementation guidance for each control lives in the companion standard, ISO/IEC 27002:2022.

Annex A in the 2022 edition

The 2022 revision consolidated the old 114 controls into 93 and regrouped them into four themes:

Eleven controls were new in 2022, and most are engineering topics: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28).

Two dates matter if you are reading older material. Certificates issued against ISO/IEC 27001:2013 had to move to the 2022 edition by 31 October 2025, so guidance built around the old 14 domains and 114 controls is out of date. And a 2024 amendment added climate change to clauses 4.1 and 4.2: you now determine whether climate change is a relevant issue for your ISMS. For most software companies that is a sentence, not a project, but auditors look for it.

Step 1: Scope it so you can actually run it

The scope statement (clause 4.3) defines what the certificate covers: which products, teams, locations and systems, and where your boundaries and interfaces sit. Customers read it. A certificate covering "the provision of the Acme platform" means something to a buyer. One covering "IT operations at the head office" does not.

A workable first scope for a SaaS company, kept as isms-scope.yaml in the compliance repository and reviewed at every management review:

scope_statement: >
  The information security management system supporting the design,
  development, operation and support of the Acme platform, including
  the customer data processed by it.
in_scope:
  products: [acme-web, acme-api, acme-mobile]
  teams: [engineering, sre, security, customer-support, people-ops]
  environments: [production, staging]   # staging holds no customer data but can deploy to prod
  locations: [remote-first, registered office]
  corporate_it: [laptops, identity-provider, email, chat, source-control, ci]
interfaces:
  cloud_provider: AWS (shared responsibility, see supplier register)
  payment_processor: Stripe (Acme stores no card data)
excluded:
  - internal R&D prototypes with no customer data
  - the marketing website (static, separate hosting, no customer data)

Three rules keep scope honest:

1. Anything that can change production is in scope. If staging can deploy to production, or a CI runner holds production credentials, it belongs inside the boundary.
2. Exclusions need a reason an auditor will accept. "Not ready yet" can justify excluding a newly acquired business unit. It cannot justify excluding the CI system.
3. Cloud providers are suppliers, not blank spaces. You inherit their physical controls through the shared responsibility model and evidence that through their certificates and reports under supplier management (controls 5.19 to 5.23).

Step 2: Run a risk assessment you would defend

Risk assessment (clause 6.1.2) is where ISO 27001 differs most from a checklist framework. You define a method, apply it, and the results drive which controls you need. The 2022 edition does not require an asset-based method. Scenario-based assessment is acceptable, and for software companies it is usually more useful.

The method has to define:

• How you identify risks (from assets, scenarios, or both)
• How you rate likelihood and impact, with definitions concrete enough that two people score the same risk the same way
• Your risk acceptance criteria: the level above which a risk must be treated
• Who owns each risk: a named person, not "Engineering"

Three-point and five-point scales both work. Vague definitions do not. "Major impact" should mean something like "customer data exposed for more than one customer, or production unavailable beyond the SLA", tied to commitments you actually made.

A risk register entry that survives an audit:

- id: R-014
  scenario: >
    A leaked long-lived cloud access key is used to read the bucket
    holding production database snapshots.
  assets: [aws-prod-account, s3://acme-db-snapshots]
  owner: head-of-platform
  likelihood: possible        # static keys still exist for two legacy integrations
  impact: severe              # all customer records, contractual breach notification
  inherent_risk: high
  treatment: mitigate
  controls: [A.5.17, A.8.2, A.8.5, A.8.15, A.8.24]
  actions:
    - Replace both static keys with OIDC role assumption (TICKET-311)
    - Block access key creation with an organization policy (TICKET-312)
    - Alert on snapshot reads from outside the backup role (TICKET-313)
  residual_risk: low
  accepted_by: cto
  review_by: 2027-04-01

What makes it useful: a specific scenario, a real owner, controls traced to Annex A, actions with tickets, and residual risk accepted by a named person. Clause 6.1.3 requires risk owners to approve the treatment plan and accept residual risk, and auditors check for that sign-off.

Good scenarios in a tech company come from your incidents and near misses, penetration test findings, cloud posture findings, dependency and CI exposure, and whatever your on-call engineers worry about at 3am. Ask them. They know where the weak spots are.

Step 3: Write a Statement of Applicability that reflects reality

The Statement of Applicability (SoA, clause 6.1.3 d) lists all 93 Annex A controls and records, for each one, whether it applies, why, and whether it is implemented. Auditors use it to plan Stage 2, so it should read like an index to your evidence.

Excluding a control needs a justification tied to scope or risk. "No offices" can justify some physical controls as not applicable. It cannot justify excluding 8.13, information backup.

Step 4: Map controls to what your stack already does

Most technological controls in Annex A are things a competent engineering team already does. The gap is usually consistency and proof. Map each control to a system of record so that evidence is an export.

Pull evidence with scripts, and keep the scripts in the compliance repository so every audit uses the same method. This one, evidence/branch-protection.sh, records default branch protection for every active repository:

#!/usr/bin/env bash
set -euo pipefail
ORG="acme"
OUT="evidence/$(date +%Y-%m-%d)-branch-protection.jsonl"
 
gh repo list "$ORG" --no-archived --limit 500 --json name,defaultBranchRef \
  --jq '.[] | "\(.name) \(.defaultBranchRef.name)"' |
while read -r repo branch; do
  gh api "repos/$ORG/$repo/branches/$branch/protection" 2>/dev/null \
    | jq -c --arg repo "$repo" '{repo: $repo,
        approvals: .required_pull_request_reviews.required_approving_review_count,
        dismiss_stale: .required_pull_request_reviews.dismiss_stale_reviews,
        enforce_admins: .enforce_admins.enabled}' \
    || echo "{\"repo\":\"$repo\",\"protection\":\"MISSING\"}"
done > "$OUT"
 
echo "Repositories without protection:"
grep MISSING "$OUT" || echo "none"

And this one lists people who left but still have an active identity provider account, from two CSV exports whose first column is the email address:

join -t, <(cut -d, -f1 hr_leavers.csv | sort) <(cut -d, -f1 idp_active.csv | sort)

The second check is crude on purpose. Joining the HR leaver list against active accounts is the single most useful check to run before an audit, because offboarding is where small companies find real exposure, not just paperwork gaps. For the infrastructure side, our guide to cloud security posture management covers continuous configuration checks, and the identity and access management guide covers the access model these controls assume.

GRC platforms (Vanta, Drata, Secureframe and similar) automate this kind of collection through API integrations and are worth evaluating once you have more than a handful of systems. They do not perform your risk assessment or write an SoA that matches your business. Treat their dashboards as monitoring, not as proof that a control works.

Step 5: Keep the documentation short and true

ISO 27001 requires specific documented information. It does not require a policy library the size of a novel. The mandatory items:

The Annex A controls you apply add more, such as documented operating procedures (5.37), an incident response procedure (5.24 to 5.28), and security clauses in supplier agreements (5.20).

Write policies that describe what you do. A ten-person company whose policies reference a CISO, a change advisory board and a data center it does not have will fail on the gap between the document and the evidence. Keep policies in Git as Markdown and change them through pull requests: the history becomes your document control evidence for clause 7.5.

Step 6: Internal audit and management review

Before a certification body will certify you, the ISMS must have run through its own checking loop at least once.

Internal audit (9.2) covers every clause and the applicable Annex A controls across the audit program. The auditor must be objective and impartial, which means they cannot audit their own work. In a small company that usually means an external consultant or a competent colleague from outside the security function. Each nonconformity gets a corrective action with a root cause, not just a fix.

Management review (9.3) is a minuted meeting where leadership looks at audit results, risk status, incidents, objectives, supplier issues and resourcing, and makes decisions. The minutes are evidence. A review where nobody decides anything reads exactly like what it is.

Step 7: The certification audit

Choose a certification body accredited by a national accreditation body that is a member of the IAF (UKAS, ANAB, DAkkS and others). Unaccredited certification exists, and enterprise buyers increasingly check. You can look up accredited certificates in IAF CertSearch.

The audit runs in two stages:

• Stage 1 reviews your documented ISMS: scope, risk method, SoA, policies, internal audit and management review. The auditor decides whether you are ready for Stage 2 and lists concerns to resolve first.
• Stage 2 tests implementation and effectiveness. Auditors interview staff, sample records and check that the controls in your SoA operate. Expect requests like "show me last quarter's access review for the production database" and "show me a production change and its approval".

Findings are graded as major or minor nonconformities. A major nonconformity (a clause requirement not met, or a control systematically not operating) blocks certification until it is closed and verified. Minor ones need an accepted corrective action plan. The certification body sets the deadlines.

After certification, the cycle is three years: surveillance audits in years one and two that sample parts of the ISMS, then a recertification audit before the certificate expires.

ISO 27001 or SOC 2 first?

Many companies end up with both. Which comes first depends on who is asking.

The control sets overlap heavily. Build the risk assessment and the evidence pipeline once and the second framework is mostly mapping. Our SOC 2 guide for startups covers the other side.

What goes wrong in production

These are the failure modes that cost companies a certification cycle or, worse, leave them certified and exposed.

• Scope creep in the wrong direction. Teams include everything to look thorough, then cannot produce evidence for half of it. Start narrow and widen at recertification.
• The template SoA. Every control marked applicable and implemented, justifications copied from a toolkit. Stage 1 auditors spot it quickly because the justifications never mention your systems.
• A risk register nobody owns. Risks assigned to teams, never reviewed, residual risk never accepted by a person.
• Evidence produced in a burst. All the quarterly access reviews dated the week before the audit. Auditors sample across the period and notice.
• Policies that contradict the code. The policy says every change is reviewed; branch protection is off on three repositories, including the one that deploys infrastructure. Run the branch protection script monthly, not yearly.
• Restores never tested. Backups run and nobody has ever restored one. The first real restore should not happen during an incident.
• A one-person ISMS. The security lead leaves and the system stops. Spread ownership: risk owners in engineering, evidence owned by the teams that run the systems.
• Treating the certificate as the goal. A certificate tells customers you manage security systematically. It does not stop a phished admin. Keep the operational controls honest between audits, because attackers do not wait for surveillance season.

Frequently Asked Questions

How long does ISO 27001 certification take?

For a software company with a cloud-native stack, plan in months rather than weeks. The elapsed time is driven less by writing documents than by running the ISMS long enough to produce evidence: at least one cycle of risk assessment, access reviews, an internal audit and a management review before Stage 2. Companies that already run SOC 2 or have strong engineering hygiene move faster because most technical controls already exist.

How many controls are in ISO 27001:2022 Annex A?

Annex A of ISO/IEC 27001:2022 contains 93 controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. The 2013 edition had 114 controls in 14 domains. Eleven controls were new in 2022, including cloud services security, configuration management, data leakage prevention and secure coding.

Do you have to implement all ISO 27001 Annex A controls?

No. You must consider all 93 and record each decision in the Statement of Applicability, with a justification for any control you exclude. Clauses 4 to 10 of the standard, by contrast, are all mandatory and cannot be excluded.

What is the difference between ISO 27001 and SOC 2?

ISO 27001 is a certifiable standard for an information security management system, audited by an accredited certification body and recognized internationally. SOC 2 is an attestation report issued by a licensed CPA firm against the AICPA Trust Services Criteria, most commonly requested by North American buyers. The controls overlap heavily, so evidence built for one can largely be reused for the other.

Is ISO 27001 certification mandatory?

ISO 27001 is voluntary; no general law requires certification. In practice it is often a contractual requirement from enterprise customers and public sector buyers, and some regulators accept it as evidence of appropriate security measures. Whether you need it depends on who you sell to.

Need help with ISO 27001?

We build and run production systems, so we approach ISO 27001 from the evidence side: a scope that matches how your platform actually works, controls wired into the tools your engineers already use, and evidence that comes out of systems of record. If we built it, we are on the pager for it, and we hold the controls to that standard.

• Cybersecurity and compliance
• Cloud architecture
• Talk to an engineer