ISO 27001 Annex A Controls: Implementation Checklist and Applicability Decisions
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most organizations fail their first ISO 27001 certification attempt not because of missing security controls but because of ISMS design issues: a scope statement that auditors cannot evaluate, a risk assessment methodology that does not produce actionable treatment decisions, or a Statement of Applicability that lists controls as 'applicable' without evidence of implementation. This guide covers the implementation steps that lead to a clean certification, including the documentation requirements that auditors check in Stage 1.
Defining the ISMS Scope
The scope statement defines what is inside the ISMS and what is outside. Auditors test the scope boundaries: if something inside the scope has a security issue, it is an ISMS finding; if something outside the scope has an issue, it is not. A poorly defined scope creates ambiguity that triggers audit findings.
Use the four-component scope structure
ISO 27001 requires the scope to include: (1) the organizational units included (departments, business units, legal entities); (2) the information assets within scope (data types, systems, services); (3) the physical locations included (offices, data centers, cloud regions); (4) the exclusions and their justification. Example: 'The ISMS covers the development, deployment, and operation of the SaaS Platform by the Engineering and Operations teams at the London headquarters and AWS eu-west-1 region. The HR Information System is excluded as it is managed by a third party under a separate ISMS.'
Start with a narrow scope for first certification
A narrow scope (one product, one team, one location) is easier to certify and demonstrates to customers that a specific product is ISO 27001 certified. Expand scope in subsequent certification cycles. Auditors prefer a narrow, well-controlled scope over a broad scope with gaps.
Document the context of the organization
ISO 27001 Clause 4 requires documenting internal context (strategy, culture, organizational structure) and external context (regulatory requirements, customer expectations, competitive environment) that affect the ISMS. This feeds directly into the risk assessment: the context determines what threats are relevant and what impact levels are appropriate.
Identify interested parties and their requirements
Clause 4.2: identify stakeholders who have requirements that the ISMS must satisfy (customers, regulators, employees, board) and document their specific requirements. Customer contracts often specify security requirements that become ISMS requirements. This documentation shows auditors the ISMS is driven by real requirements, not theoretical ones.
Risk Assessment Methodology
Clause 6 requires a documented risk assessment methodology. Auditors focus heavily on whether the methodology is consistent, repeatable, and produces defensible treatment decisions. A methodology that auditors reject will fail Stage 1.
Choose asset-based or scenario-based risk assessment
Asset-based: enumerate information assets, identify threats and vulnerabilities for each asset, calculate risk as Likelihood × Impact. Scenario-based: enumerate threat scenarios (e.g., 'ransomware encrypts production database'), estimate likelihood and impact for each. Either approach is acceptable; the choice must be documented in the methodology. Scenario-based tends to produce more actionable results for implementation teams.
Define your risk scoring scale and acceptance criteria
Document a 3×3, 4×4, or 5×5 likelihood-impact matrix with defined anchors for each level. Example 3×3: Low impact = loss of non-public data affecting one department; High impact = regulatory fine or customer-visible service outage. Define the risk acceptance threshold: risks scoring ≤4 are accepted, risks scoring 5+ require treatment. Auditors check that the threshold is consistently applied.
Document risk owners and treatment decisions
Every risk in the risk register must have a named risk owner (a person, not a team) and a treatment decision: Treat (implement control), Tolerate (accept with documented rationale), Transfer (insurance or contract), or Terminate (stop the activity). Auditors sample risk register entries and interview risk owners: the owner must be able to discuss their risks.
Create the Statement of Applicability
The Statement of Applicability (SoA) lists all 93 Annex A controls, whether each is applicable, if applicable the justification for inclusion (risk treatment, legal requirement, contractual obligation), the implementation status, and the evidence of implementation. Controls marked as not applicable require documented justification. This is one of the primary Stage 1 audit documents.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Required Documentation Set
ISO 27001 specifies mandatory documents (documented information required by the standard) and provides flexibility on format. Auditors check that all mandatory documents exist, are current, and are controlled (version-managed, reviewed, approved).
Mandatory policies and procedures
Information security policy (Clause 5.2), ISMS scope document, risk assessment methodology, risk register with treatment decisions, Statement of Applicability, risk treatment plan, security objectives and measures (Clause 6.2), evidence of competence and awareness (training records), and records of internal audits and management reviews. These 10 categories cover the minimum mandatory documented information.
Annex A control documentation
For each implemented Annex A control, document the control objective, implementation description, and where to find evidence. Auditors do not need a separate policy for every control, but they need to trace each SoA entry to evidence of implementation. A single security procedures document covering multiple controls is acceptable.
Internal audit program and results
ISO 27001 requires a documented internal audit program with audit criteria, scope, frequency, and methods. Internal audits must be conducted before Stage 2 by auditors who are independent from the areas being audited (in small organizations, this may require using a third party). Audit results are reviewed at management review and feed into continual improvement.
Management review records
At least one documented management review per year (Clause 9.3) that covers: ISMS performance metrics, audit results, risk status, resource adequacy, and continual improvement opportunities. The review record must show management input and decisions made. Auditors look for genuine management engagement rather than a rubber-stamp exercise.
Certification Audit Preparation
The certification process consists of Stage 1 (documentation review, typically remote or on-site) and Stage 2 (on-site implementation verification). Both are conducted by auditors from an accredited certification body (BSI, DNV, Bureau Veritas, etc.).
Stage 1 preparation
Provide auditors with: ISMS scope and policy, risk assessment and risk register, Statement of Applicability, risk treatment plan, internal audit report, and management review record. Stage 1 auditors check that documentation is complete, consistent, and demonstrates an ISMS that could be effective. Common Stage 1 findings: SoA controls marked implemented without evidence, risk register without consistent scoring, no formal management review record.
Stage 2 preparation
Stage 2 auditors interview employees across the scoped organization and test controls against the SoA. Prepare: a list of all employees who may be interviewed (technical staff, managers, risk owners), evidence packages for each SoA control, access to systems auditors may test (asset inventory, patch management, access control logs, incident management system). Coach employees: Stage 2 auditors ask 'can you show me how you do X?': employees must be able to demonstrate controls, not just describe them.
Common Stage 2 failure modes
The most common Stage 2 findings that delay certification: (1) controls documented in the SoA but not demonstrably implemented (particularly: vulnerability management, incident response testing, third-party supplier assessments); (2) asset inventory incomplete or not maintained; (3) access control reviews not conducted at the documented frequency; (4) security awareness training not tracked with completion records; (5) employees unaware of the information security policy they were supposed to have reviewed.
The bottom line
ISO 27001 certification fails most commonly not from missing security controls but from ISMS design gaps: a scope statement auditors cannot evaluate, a risk assessment without a documented methodology, and a Statement of Applicability listing controls as implemented without evidence. Invest first in the risk assessment methodology and SoA, because these are the documents Stage 1 auditors examine before anything else. A clean Stage 1 outcome means Stage 2 can focus on demonstrating the controls you have already built, rather than redesigning the ISMS architecture mid-engagement.
Frequently asked questions
What is the difference between ISO 27001 and SOC 2?
ISO 27001 is a management system standard certifying that an ISMS exists, is implemented, and is continually improved. It is audited by accredited certification bodies and results in a globally recognized certificate. SOC 2 is an assurance report (not a certification) produced by a licensed CPA firm assessing whether security controls meet the AICPA Trust Services Criteria over a specified period. ISO 27001 tends to be preferred in European markets and enterprise sales cycles; SOC 2 Type II is the dominant requirement in US SaaS sales. Most enterprise software companies pursue both. ISO 27001 is process-focused; SOC 2 is evidence-of-effectiveness-focused.
How long does ISO 27001 certification take?
For a first-time certification: 12-18 months is typical for a mid-size organization (50-500 employees) with a narrow scope. This includes: 1-2 months for scope and context definition, 2-3 months for risk assessment and SoA, 3-6 months for control implementation, 1-2 months for internal audit and gap remediation, and 2-3 months for the certification audit cycle. Smaller organizations with a narrow scope (one product, 10-20 people in scope) can achieve certification in 6-9 months. The critical path is risk assessment and SoA completion, which can stall if risk owners are not engaged.
How many controls do we actually have to implement?
ISO 27001:2022 Annex A has 93 controls. You do not need to implement all of them: you justify non-applicability in the Statement of Applicability. Common exclusions: physical security controls (Annex A 7.x) if using a colocation data center where physical security is the provider's responsibility, or controls related to media handling if your organization is cloud-only. In practice, most organizations implementing for cloud-based software products will implement 70-80 controls and justify 15-20 as not applicable.
Can we achieve ISO 27001 certification using existing SOC 2 documentation?
Yes, with significant restructuring. SOC 2 evidence (policies, procedures, control evidence) maps to many ISO 27001 Annex A controls. The primary gaps when transitioning from SOC 2 to ISO 27001: (1) ISO requires a formal risk assessment methodology and risk register: SOC 2 does not prescribe a specific risk process; (2) ISO requires a Statement of Applicability: SOC 2 does not; (3) ISO requires formal management reviews: SOC 2's evidence is often operational rather than management-level; (4) ISO 27001:2022 includes 11 new controls not covered in SOC 2 Trust Services Criteria. Expect 3-6 months of additional work to bridge a mature SOC 2 program to ISO 27001.
What are the new controls added in ISO 27001:2022?
The 11 new controls in Annex A of ISO 27001:2022 that were not in the 2013 version: A.5.7 Threat intelligence (collecting and analyzing threat intelligence), A.5.23 Information security for 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 (expanded from logging), A.8.23 Web filtering, A.8.28 Secure coding. Organizations certified to the 2013 standard must transition to 2022 by October 2025.
What does the surveillance audit require after initial certification?
ISO 27001 certification is valid for 3 years with annual surveillance audits in years 1 and 2 and a full recertification audit in year 3. Surveillance audits are shorter than the initial Stage 2 (typically 1-2 days) and focus on: whether the ISMS continues to operate, whether internal audits and management reviews have been conducted, whether previous non-conformities have been closed, and whether the risk register has been updated to reflect changes in the organization or its threat environment. The most common surveillance audit failure mode is an ISMS that passed certification but was not maintained: no internal audits conducted, risk register not updated, management reviews not held.
How do we justify the ROI of ISO 27001 certification to leadership?
The primary ROI drivers: (1) Sales acceleration: enterprise customers in the EU and APAC often require ISO 27001 certification as a security due diligence gate; quantify the pipeline value at risk from missing certification; (2) Cyber insurance: ISO 27001 certification often qualifies for better premium rates and higher coverage limits; (3) Regulatory alignment: ISO 27001 maps directly to NIS2, DORA, and GDPR Article 32 security obligations; certification provides documented evidence of compliance; (4) Internal security improvement: the risk assessment process identifies gaps that may have otherwise gone unaddressed; (5) Third-party risk reduction: ISO 27001 certification simplifies customer vendor risk assessments, reducing sales friction.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.