ISO/IEC 27001:2022 compliance: a practical implementation guide

ISO/IEC 27001 is a voluntary standard. No law in any major jurisdiction says "you must be certified". The pressure comes from the people who buy from you. In practice a cloud-native SaaS company meets one of four triggers:

• Enterprise procurement. Security questionnaires from customers with more than a few thousand staff routinely ask for an ISO 27001 certificate or a SOC 2 report, and outside North America ISO 27001 is the one they recognise. Without it, every deal gets a bespoke security review that can add weeks to the cycle.
• Acting as a processor for EU and UK customers. GDPR Article 32 requires "appropriate technical and organisational measures"; controllers who must evidence that their processors have them accept an accredited ISO 27001 certificate as a strong answer. See the GDPR guide for the legal side.
• Regulated and public-sector buyers. Banks, insurers, healthcare groups and government bodies frequently write ISO 27001 into their supplier security schedules as the minimum baseline, sometimes alongside sector add-ons.
• Partnerships and marketplaces. Integration partners and cloud marketplaces ask for it before listing or co-selling.

It also underpins related certifications. ISO/IEC 27017 (cloud security controls) and ISO/IEC 27018 (PII in public cloud) are audited as extensions of a 27001 certificate, and ISO/IEC 42001 (AI management) reuses the same management-system skeleton.

What happens if you ignore it. Nothing legal, but commercially real: deals stall at the security review, renewals get conditional on "certification within 12 months", and you spend engineering time answering the same 300 questions per prospect. One more point that matters today: the 2013 edition was retired on 31 October 2025. If you or a supplier still present a 2013 certificate it is no longer valid, and you should expect the certification body to treat you as a new applicant.

The standard is short (19 pages) and has two parts that are audited differently.

Clauses 4–10: the management system (all mandatory)

• 4 Context: internal and external issues, interested parties and their requirements, the scope statement (4.3), and the ISMS itself.
• 5 Leadership: top-management commitment, the information security policy, roles and authorities.
• 6 Planning: the risk assessment process (6.1.2), the risk treatment process and the Statement of Applicability (6.1.3), security objectives (6.2) and, new in 2022, planning of changes (6.3).
• 7 Support: resources, competence, awareness, communication and documented information.
• 8 Operation: running the processes you planned, performing risk assessments at planned intervals and implementing the treatment plan.
• 9 Performance evaluation: monitoring and measurement, internal audit (9.2) and management review (9.3).
• 10 Improvement: continual improvement and nonconformity and corrective action.

You cannot exclude anything in clauses 4–10. Internal audit and management review are not "nice to have"; a certification body will not issue a certificate until both have been performed at least once.

Annex A: 93 reference controls

Annex A lists 93 controls in four themes: Organisational (37), People (8), Physical (14) and Technological (34). It is a reference set, not a checklist. Clause 6.1.3 requires you to determine the controls you need from your risk assessment, compare them with Annex A to make sure nothing necessary has been omitted, and record the result in a Statement of Applicability (SoA): every control, whether it applies, why, and whether it is implemented. Exclusions are allowed with a justification. Implementation guidance for each control lives in ISO/IEC 27002:2022, which is not itself certifiable, and gives each control five attributes (control type, security property, cybersecurity concept, operational capability, security domain) that are handy for mapping to NIST CSF functions.

What changed from 2013 to 2022

The 2013 edition's 114 controls in 14 domains were consolidated into 93 controls in 4 themes, with 11 genuinely new controls: A.5.7 threat intelligence, A.5.23 use of cloud services, A.5.30 ICT readiness for business continuity, A.7.4 physical security monitoring, A.8.9 configuration management, A.8.10 information deletion, A.8.11 data masking, A.8.12 data leakage prevention, A.8.16 monitoring activities, A.8.23 web filtering and A.8.28 secure coding. Clause changes were smaller: 6.3 planning of changes, an explicit requirement to control externally provided processes in 8.1, and management review must now consider changes in the needs and expectations of interested parties.

Amendment 1:2024, published in February 2024, adds the harmonised climate-change text used across ISO management-system standards: clause 4.1 now requires you to determine whether climate change is a relevant issue, and 4.2 notes that interested parties can have climate-related requirements. Auditors check for a documented decision; a sentence in your context document is enough if your conclusion is "not relevant". The current normative text is therefore ISO/IEC 27001:2022 plus Amd 1:2024.

The transition is over

IAF MD 26:2023 set a 36-month transition: from 30 April 2024 all initial and recertification audits had to be against the 2022 edition, and all client transitions had to be complete by 31 October 2025, at which point every 2013 certificate expired or was withdrawn. Companion standards have since caught up too: ISO/IEC 27018:2025 (PII in public cloud, August 2025) and ISO/IEC 27017:2026 (cloud controls, July 2026), both built on the current ISO/IEC 27002 control set, and ISO/IEC 27701:2025 (privacy management, October 2025, now a standalone management-system standard; see the ISO 27701 guide).

Clause 4.3 asks for a scope that states boundaries and applicability, considering your context, your interested parties' requirements, and the interfaces and dependencies with other organisations. The scope statement is printed on the certificate, and procurement teams read it. A certificate that says "the ISMS supporting the Acme platform, delivered from AWS eu-west-1 and operated by Acme's engineering, support and corporate IT teams in London and remotely" closes deals. One that says "the information security management system of Acme Ltd" invites a follow-up questionnaire.

What a cloud-native SaaS should include

• The product or products customers buy, and every production cloud account, subscription or project that delivers them.
• The delivery pipeline: source control, CI/CD, artefact registries, the identity provider and the secrets store. Attackers do not respect your scope boundary.
• The people who can touch production or customer data: engineering, SRE, support, data, and the IT function that manages their endpoints, including remote workers (A.6.7).
• Non-production environments that ever hold copies of production data (A.8.33).
• External interfaces, named: the cloud provider, sub-processors, outsourced development, the managed SOC. They are outside the ISMS but inside your supplier controls (A.5.19 to A.5.22).

The scoping mistakes that cost the most

• Scoping to the security team. Engineering runs the controls that matter. If engineers are "out of scope", the auditor cannot sample change management or secure coding, and your certificate says nothing a customer cares about.
• Carving out laptops. Endpoints with production credentials are in scope whether or not you own the MDM.
• Everything in one go. A 300-person company with five products and three offices does not need all of them in the first certificate. Start with the product under commercial pressure and extend scope at a surveillance audit.
• Legal entity confusion. If the engineering subsidiary in another country does the work, it must be in scope, or the certificate must say the parent only.
• Forgetting shared services. HR onboarding, finance's procurement of suppliers and corporate IT sit in the parent but deliver People and Supplier controls. Include the processes even if the departments are not "sites".

The plan below assumes a 10–500-person company on AWS, Azure or GCP with a reasonable engineering culture but no formal ISMS. Compress it if you already hold a SOC 2 report; stretch it if logging and vulnerability management are starting from nothing.

Weeks 0–2: mobilise

• Name an executive sponsor and an ISMS owner. Agree a monthly 30-minute steering slot. Clause 5 is audited through what these people did, not what the policy says.
• Draft the scope statement and the context document (4.1, 4.2), including the climate-change decision from Amd 1.
• Run a gap assessment against clauses 4–10 and the 93 Annex A controls. Be honest about "not implemented".
• Choose the risk methodology (asset-based or scenario-based, a 5x5 matrix is fine) and the risk acceptance criteria.
• Shortlist accredited certification bodies and request quotes now; audit calendars often fill two to four months ahead.

Weeks 2–6: govern and assess risk

• Publish the information security policy and the topic policies you actually need (A.5.1): acceptable use, access control, cryptography, secure development, supplier security, incident management, business continuity, logging. Each with an owner and a review date.
• Assign roles (A.5.2): who approves access, who owns risks, who signs off changes.
• Build the asset inventory from the cloud, not a spreadsheet: export accounts, projects, data stores, repositories and SaaS tools, assign owners and classification (A.5.9, A.5.12).
• Hold risk workshops with engineering, product and operations. Output: a risk register with owners, scores, treatment decisions and a risk treatment plan with dates.
• Draft the SoA from the risk treatment plan. Every "applicable" control needs a justification that references a risk or a legal or contractual requirement.

Weeks 6–14: implement the technical and people controls

• Work the hard controls in the next section in priority order: logging and monitoring first (everything else produces evidence into it), then vulnerability and configuration management, cryptography, secure development and change management, then continuity testing.
• People controls: screening (A.6.1), contract clauses and NDAs, joiner-mover-leaver checklists, awareness training with completion tracking (A.6.3).
• Supplier register with risk tiering, contract review for security clauses and the provider assurance evidence you collected for the cloud (A.5.19–A.5.23).
• Incident management: a written process, severity levels, a tabletop exercise with minutes (A.5.24).

Weeks 14–18: operate and prove

• Let the system run. Quarterly access reviews, monthly vulnerability reports, change records and a restore test all need at least one cycle of real records before the audit.
• Internal audit (9.2) covering every clause and a sample of Annex A controls, performed by someone independent of the work audited. Record findings as nonconformities with corrective actions.
• Management review (9.3) with every required input (audit results, risk status, objectives, interested-party changes, feedback, nonconformities, improvement opportunities) and recorded decisions.

Weeks 18–26: certification

• Stage 1: documentation and readiness review. Close any gaps raised.
• Stage 2: effectiveness audit. Close nonconformities; the certificate follows the certification decision.

Ongoing

Monthly control checks, quarterly access reviews, annual risk review, annual internal audit and management review, and the surveillance audit each year. Treat the surveillance audit as a deadline for the annual cycle, not an event in itself.

Most of the 93 controls are paperwork plus a sensible process. These eight take real engineering time, and each is where auditors spend the longest. Links go to the control articles with full implementation notes.

A.5.7 Threat intelligence

You need a process that collects, analyses and acts on threat information, not a feed subscription. AWS: enable Amazon GuardDuty organisation-wide through a delegated administrator account in every region you use, route findings to Security Hub, and subscribe to AWS security bulletins. Azure: Microsoft Defender for Cloud plus threat analytics and intel profiles in the Defender portal for named-actor context (the standalone Microsoft Defender Threat Intelligence product reached end of life on 1 August 2026 and its capabilities now sit in the Defender portal). GCP: Security Command Center with Event Threat Detection; Google Threat Intelligence for the strategic layer. Done looks like: a documented list of sources, a monthly review note, and at least one ticket showing an advisory that changed a configuration or a patch priority.

A.5.23 Information security for use of cloud services

Auditors want a policy for acquiring, using, managing and exiting cloud services, a register of the services in use, and evidence you understand the shared-responsibility split. Download the providers' own ISO 27001, 27017 and 27018 certificates and SOC reports from AWS Artifact, the Microsoft Service Trust Portal and Google Cloud's Compliance Reports Manager, and file them against the supplier record. Enforce the boundary with organisation-level guardrails: AWS Organizations service control policies, Azure management groups with Azure Policy, GCP folders with Organization Policy constraints. Done looks like: each cloud service has an owner, a data classification, assurance evidence with a review date, and an exit plan.

A.5.30 ICT readiness for business continuity

Start from a business impact analysis that sets RTO and RPO per service, then prove you can meet them. AWS: AWS Backup with cross-account and cross-region vaults, multi-AZ data stores, AWS Elastic Disaster Recovery for anything stateful on EC2. Azure: Azure Backup with geo-redundant vaults, Azure Site Recovery, zone-redundant SKUs. GCP: Backup and DR Service, regional or multi-regional storage, Cloud SQL high availability. Done looks like: an annual restore test record with measured recovery time against the target, and backups covered by A.8.13 that are immutable and tested from a different account.

A.8.8 Management of technical vulnerabilities

The requirement is coverage, timeliness and accountability. AWS: Amazon Inspector for EC2, ECR images, Lambda functions and, since June 2025, connected code repositories; Systems Manager Patch Manager with patch baselines and compliance reporting. Azure: Microsoft Defender Vulnerability Management for VMs and container registries, Azure Update Manager for patch compliance. GCP: Security Command Center vulnerability findings, Artifact Analysis for images, VM Manager OS patch management. Done looks like: written remediation SLAs by severity, scanners covering every in-scope asset class, a monthly report showing SLA adherence, and documented risk acceptance for anything overdue.

A.8.9 Configuration management

Define baselines, enforce them, detect drift. Keep infrastructure in code and treat the repository as the baseline. AWS: AWS Config rules and conformance packs, Security Hub CSPM standards (Foundational Security Best Practices, CIS), service control policies for the things that must never happen. Azure: Azure Policy in deny and deployIfNotExists modes, Machine Configuration for guest settings, and the ISO/IEC 27001:2022 standard in Defender for Cloud, which can also assess connected AWS and GCP accounts. GCP: Organization Policy constraints, Security Health Analytics in Security Command Center (whose detectors map to ISO 27001:2022), OS Config for VM baselines. Done looks like: documented baselines per platform, drift alerts routed to a queue someone owns, and an exceptions register.

A.8.15 Logging and A.8.16 Monitoring activities

Logs must exist for every in-scope system, be protected from tampering, be retained for a defined period and actually be looked at. AWS: an organisation trail in CloudTrail delivered to a dedicated log-archive account, S3 Object Lock and log-file validation on, CloudWatch alarms for the events that matter, GuardDuty for detection, Security Lake if you want OCSF-normalised retention. Azure: activity log and resource diagnostic settings sent to a central Log Analytics workspace, immutable storage for the archive tier, Microsoft Sentinel for analytics rules. GCP: Cloud Audit Logs with Data Access logs switched on (they are off by default for most services), an organisation-level Log Router sink into a locked Cloud Logging bucket, Security Command Center for detections. Done looks like: a log-source inventory with retention periods, evidence that admins cannot delete logs, alert rules with runbooks, and a weekly review record with at least one investigated alert.

A.8.24 Use of cryptography

A cryptography policy that names approved algorithms and protocols, plus key management across the whole lifecycle. AWS: customer-managed KMS keys with rotation and restrictive key policies, encryption enforced on S3, EBS and RDS through Config rules, AWS Certificate Manager for TLS, CloudHSM only if a contract demands it. Azure: Key Vault or Managed HSM with customer-managed keys, minimum TLS 1.2 policies on storage and app services, encryption at host for VM disks (Azure Disk Encryption retires on 15 September 2028). GCP: Cloud KMS with customer-managed encryption keys on storage and databases, Cloud HSM for regulated workloads, Certificate Authority Service for internal PKI. Done looks like: a key inventory with owners and rotation evidence, and secret scanning in CI proving no plaintext credentials in repositories (see A.5.17).

A.8.28 Secure coding and A.8.32 Change management

These two are audited together because the pull request is the change record. Write a short secure-coding standard, enforce branch protection with mandatory review, and run SAST, dependency and secret scanning in CI. AWS: Amazon Inspector code security for GitHub and GitLab repositories (Amazon CodeGuru Reviewer has not accepted new repository associations since 7 November 2025, so do not build on it). Azure: GitHub Advanced Security or Defender for Cloud DevOps security. GCP: Cloud Build with Artifact Analysis and Binary Authorization so only scanned, signed images deploy. Separate development, test and production accounts or subscriptions (A.8.31) and write an emergency change path with after-the-fact review. Done looks like: any sampled production change traces to a pull request, a pipeline run, a reviewer and a deployment record.

Auditors sample. They pick a control, ask how it works, then ask for the record that proves it worked on a specific date. Organise evidence in four groups and you will not spend Stage 2 searching Slack.

1. Mandatory documented information (clauses 4–10)

• Scope statement (4.3) and context (4.1, 4.2, including the climate-change decision).
• Information security policy (5.2) and objectives (6.2).
• Risk assessment and risk treatment process descriptions (6.1.2, 6.1.3), the risk register and treatment plan, and the results of each assessment and treatment round (8.2, 8.3).
• The Statement of Applicability.
• Evidence of competence (7.2), operational planning records (8.1), monitoring and measurement results (9.1).
• Internal audit programme and reports (9.2), management review minutes (9.3), nonconformities and corrective actions (10.2).

2. Operational records

• Quarterly access reviews with reviewer, date and the removals that resulted (A.5.18).
• Joiner, mover and leaver checklists; screening confirmations; signed terms and NDAs; training completion.
• Supplier register, assessments and contract reviews; incident log and post-incident reviews; continuity test reports; risk review minutes.

3. Technical exports

• Logging configuration (CloudTrail, diagnostic settings, Audit Logs) and retention settings.
• Compliance reports from AWS Config or Security Hub CSPM, Defender for Cloud, Security Command Center.
• Vulnerability scan reports with ageing; patch compliance reports; key inventories; backup job history and restore test output; MFA enforcement reports from the identity provider; branch protection settings.

4. Tickets

Change tickets or pull requests, incident tickets, corrective action tickets, exception and risk acceptance records. Auditors like tickets because they carry timestamps and names.

Retention. The standard does not set a period; you do, under 7.5 and A.5.33, taking legal and contractual requirements into account. In practice keep ISMS records for at least one full three-year certification cycle, because the recertification audit can reach back to the start of it, and keep security logs for the period in your logging policy (twelve months online is a common customer contract term; check yours).

Who audits you

A certification body (CB) that is accredited to ISO/IEC 17021-1 and ISO/IEC 27006-1:2024 by a national accreditation body such as UKAS, ANAB or DAkkS. Those accreditation bodies are signatories to a multilateral arrangement that makes a certificate issued in one country recognised everywhere. Since 1 January 2026 that arrangement is the Global ACI MRA, which replaced the IAF MLA and ILAC MRA; existing accreditations and certificates remain recognised, and the IAF MLA mark stays on certificates during a transition period. Verify both the CB's accreditation and, later, your own certificate on the public IAF CertSearch database. Unaccredited certificates are cheaper and faster; they also carry no international recognition and are increasingly rejected by procurement teams who check the register.

The stages

1. Application and quote. Audit time is calculated by the CB from the number of people doing work under the ISMS, the number of sites and the complexity of the environment, following ISO/IEC 27006-1 and the accreditation rules. Headcount in scope is the biggest cost driver.
2. Stage 1. Documentation and readiness review, often remote. The auditor confirms scope, reviews the SoA, risk assessment, internal audit and management review, and reports areas of concern that would become nonconformities at Stage 2.
3. Stage 2. The effectiveness audit, on site or remote, typically a few weeks after Stage 1. Interviews with management, engineers, support and HR; sampling of Annex A controls against records; walkthroughs of the cloud consoles.
4. Findings. A major nonconformity (one that affects the ISMS's ability to achieve its intended results, such as a required process missing or a control not operating) blocks the certificate until closed and verified. Minor nonconformities need an accepted corrective action plan. Observations and opportunities for improvement are advisory.
5. Decision and certificate. An independent reviewer at the CB makes the decision. The certificate is valid for three years and shows the scope statement.
6. Surveillance. At least once a year, the first within twelve months of the certification decision, shorter than Stage 2 and focused on the mandatory clauses plus a rotating sample of controls.
7. Recertification. Before the three-year expiry, a full audit comparable to Stage 2. If the certificate lapses, ISO/IEC 17021-1 lets the CB restore it within six months of expiry once the outstanding recertification work is complete; after that you need at least a new Stage 2 audit.

Duration. From Stage 1 to certificate, six to twelve weeks is typical in our experience, dominated by how long nonconformities take to close. Cost drivers beyond headcount: additional sites, adding ISO/IEC 27017, 27018 or 27701 to the same audit, auditor travel, and scope extensions between cycles.

1. Treating Annex A as the checklist. Controls that do not trace to a risk or an obligation get "applicable" with no justification. Fix: build the SoA from the risk treatment plan; every applicable control cites the risk or requirement that needs it.
2. An SoA that says "implemented" everywhere. Stage 2 finds three controls that are not. Fix: mark them "partially implemented" or "planned" with a date; auditors accept honest plans and penalise false claims.
3. The internal audit is done by the person who built the ISMS. Fix: clause 9.2 requires objectivity and impartiality. Use someone from another team with a short training, or an external auditor, and keep the audit report separate from the gap assessment.
4. Management review by email. Fix: a meeting with minutes that show each 9.3 input, the decisions and who owns them. Top management must be in the room.
5. No operating history. Every policy is dated the fortnight before Stage 1 and there are no records. Fix: run at least one full cycle of access reviews, vulnerability reporting, change records and a restore test before the audit.
6. Logging gaps that only show up at Stage 2. A single-region CloudTrail, Azure resources without diagnostic settings, GCP Data Access logs never enabled. Fix: set logging at the organisation level with policy enforcement, and export a configuration report as evidence.
7. People controls left to HR without records. Screening happened but nobody can show it; leavers' access removal is undocumented (A.6.5). Fix: checklists in the ticketing system, with the identity provider's deprovisioning log as the proof.
8. Supplier controls stop at a spreadsheet. Fix: tier suppliers by access to data, collect assurance evidence for the top tier, and review it annually (A.5.22).
9. Skipping the 2024 amendment. Fix: one documented sentence deciding whether climate change is a relevant issue for the ISMS, and a note in the interested-parties table.
10. Choosing a certification body on price alone. Fix: confirm accreditation for ISO/IEC 27001 on the accreditation body's register before signing, and ask who the lead auditor will be.

iCompaas ships an ISO/IEC 27001:2022 ISMS template covering the documents the auditor asks for first: the scope statement, risk register, risk treatment plan, Statement of Applicability, internal audit schedule and management review minutes. Policy templates come with named owners and review cadences, so clause 7.5 document control and the annual policy review happen on a schedule rather than the week before the audit.

For the technical Annex A controls, iCompaas runs continuous checks across your connected cloud accounts on AWS, Azure, GCP and other providers, so controls such as A.5.7 threat intelligence, A.5.23 use of cloud services, A.8.16 monitoring activities and A.8.28 secure coding are evaluated against the live environment rather than a point-in-time screenshot. Findings are collected as evidence and can be exported for Stage 2 and surveillance audits. The control library on this site documents every one of the 93 Annex A controls with implementation and evidence notes, and for most of them shows the mapping to the other frameworks you may hold.