ISO 27001:2022 Complete Implementation Checklist

By Het Mehta | Published: 2025-06-03 | Last Updated: 3/17/2026 | Standard: ISO/IEC 27001:2022

Important Note

ISO 27001 certification requires a formal audit by an accredited Certification Body (CB). Not all 93 Annex A controls are mandatory — organisations select applicable controls through a risk assessment and document inclusions and exclusions in the Statement of Applicability (SoA). Controls marked [NEW 2022] were introduced in the 2022 revision. The deadline to transition from ISO 27001:2013 certificates was 31 October 2025.

Introduction

This is the complete reference checklist for implementing and certifying an Information Security Management System (ISMS) against ISO/IEC 27001:2022. The 2022 revision restructured the standard from 114 controls across 14 domains to 93 controls across 4 themes — Organizational, People, Physical, and Technological — while adding 11 new controls to address modern threats including cloud security, threat intelligence, and data leakage prevention.

Use this checklist to track implementation progress, prepare for internal audits, and build your Statement of Applicability (SoA). Every checkbox state is saved in your browser so progress persists across sessions.

Overall Progress 0 / 118 complete

✅ Completed: 0 ⏳ Remaining: 118 📋 Annex A: 93 controls 🆕 New in 2022: 11

📋 Mandatory Clauses 4–10

These clauses form the core ISMS management framework and are mandatory for all organisations seeking certification. Unlike Annex A controls, no clause requirement can be excluded. Clauses 4–10 cover how you manage the ISMS; Annex A covers what controls you implement.

Clause 4 — Context of the Organisation

4.1 Understand the organisation and its contextProduce a documented Context of the Organisation analysis (e.g. PESTLE or SWOT) identifying internal factors (culture, capabilities, governance structure) and external factors (regulatory landscape, market, threat environment).

Auditor will ask: show me this document and confirm it was reviewed in the last 12 months. Evidence: signed context document with review date.
4.2 Understand the needs of interested partiesProduce an Interested Party Register listing each stakeholder (customers, regulators, shareholders, employees, suppliers), their relevant requirements (e.g. GDPR compliance, contractual SLAs, audit rights), and how each is addressed within the ISMS.

Auditor will ask: can you show me your interested party register and link each requirement to a control or procedure?
4.3 Determine the scope of the ISMSProduce a written ISMS Scope Statement that defines: which business units, locations, and information assets are in scope; which are explicitly excluded and why; interfaces with out-of-scope areas. The scope must be documented and approved.

Auditor will ask: is this scope realistic? Are any high-risk areas excluded without justification?
4.4 Establish and maintain the ISMSDemonstrate that all ISMS processes are implemented and interconnected — risk assessment feeds the SoA, which feeds controls, which are monitored and reviewed. Produce a process map or ISMS framework document. Auditor will look for gaps between documented processes and actual practice.

Clause 5 — Leadership

5.1 Leadership and commitmentEvidence includes:
(1) Management Review meeting minutes showing executive attendance and decisions made.
(2) ISMS budget approval records.
(3) Sign-off on the information security policy by the most senior accountable person (CEO, CTO, or CISO).
(4) ISMS listed as a standing agenda item in board or senior leadership meetings. Auditor will interview top management — expect questions on their knowledge of ISMS objectives and last audit findings.
5.2 Information security policyThe policy must be:
(1) Approved and signed by top management.
(2) Communicated to all staff (onboarding, annual refresh).
(3) Available to external parties on request.
(4) Reviewed at least annually or after significant incidents/changes. Minimum policy content: commitment to CIA, legal compliance, risk management, and continual improvement. Auditor will check version control, distribution records, and staff awareness. Evidence: policy document with approval signature, version history, distribution log.
5.3 Organisational roles, responsibilities, and authoritiesProduce a RACI matrix or role definition document assigning: ISMS owner (top management), Information Security Manager/CISO, Data Protection Officer (if required by GDPR), asset owners, process owners, and incident response roles. All role holders must be aware of their responsibilities. Auditor will ask each role holder what their specific ISMS responsibilities are.

Clause 6 — Planning

6.1.1 Actions to address risks and opportunities (General)Produce a documented Risk and Opportunity Register identifying ISMS-specific risks (e.g. a key ISMS role becoming vacant) and opportunities (e.g. cloud migration enabling stronger access controls). For each, document likelihood, impact, and the action planned. This is separate from the asset-based information security risk assessment under 6.1.2. Auditor will check this register exists and is maintained.
6.1.2 Information security risk assessmentProduce:
(1) A Risk Assessment Methodology document defining risk criteria, likelihood/impact scales, and the risk acceptance threshold.
(2) A Risk Register listing each risk (asset + threat + vulnerability), its inherent risk score, treatment decision, residual risk score, and risk owner sign-off. Assessment must be repeatable — two assessors must reach the same result. Methodology and results must be retained as documented information. Auditor will sample 5–10 risks and verify the methodology was applied correctly.
6.1.3 Information security risk treatmentProduce:
(1) A Risk Treatment Plan (RTP) showing selected treatment (mitigate/accept/transfer/avoid) for each risk, linked control(s), owner, and target date.
(2) A Statement of Applicability (SoA) — a document listing all 93 Annex A controls, stating whether each is applicable or not, justification for any exclusion, and current implementation status. The SoA is the single most audited document. Risk owners must sign the RTP. Auditor will check that every applicable control in the SoA has a corresponding implementation record.
6.2 Information security objectivesObjectives must be SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Examples: "Achieve 100% MFA enrolment for all privileged accounts by Q2", "Reduce mean time to patch critical CVEs to under 72 hours by end of year", "Complete all planned awareness training for 100% of staff annually". For each objective: document owner, measurement method, current baseline, and target.

Auditor will ask: how do you measure this? What is the current result?
6.3 Planning of changesChanges to the ISMS (scope changes, new processes, control updates, org restructuring) must go through a formal change management process — not just operational IT changes. Document: what changed, why, impact assessment, who approved it, and how the ISMS was updated accordingly. Auditor will ask about a significant recent change and verify it was handled through this process.

Clause 7 — Support

7.1 ResourcesDemonstrate that resource allocation decisions are documented: ISMS budget line (approved by management), headcount for information security function, tooling procurement records, and external support contracts (auditors, consultants).

Auditor will ask: was the ISMS budget approved by management? What was spent last year? Resource shortfalls that impact ISMS effectiveness are a nonconformity.
7.2 CompetenceProduce a Competence Matrix mapping each ISMS-relevant role to required competencies (e.g. CISM, ISO 27001 Lead Implementer, CISSP, GDPR practitioner). For each person in that role, show their current competence level and evidence (certificates, training records, CVs). Where gaps exist, show a training plan with completion dates. Auditor will ask for competence records for ISMS key roles.
7.3 AwarenessAll personnel must be able to demonstrate:
(1) Knowledge of the information security policy.
(2) Their personal role in the ISMS.
(3) Consequences of non-compliance. Evidence: (a) Annual security awareness training completion records for 100% of staff. (b) Phishing simulation results and remediation. (c) New-joiner onboarding security induction records. Auditor will spot-check 3–5 staff — including non-IT roles — and ask what they understand about the security policy.
7.4 CommunicationProduce a Communications Plan covering: what is communicated (policy updates, incident learnings, audit results, security bulletins), frequency, audience, channel (email, intranet, team meetings), and owner. Evidence of communication includes: email distribution records, intranet post dates, meeting minutes. Auditor will ask for evidence of the last security communication sent to all staff.
7.5 Documented informationMaintain a Document Register / Master List of ISMS Documents listing every required document with: title, reference number, version, owner, review date, and classification. All documents must have version control, approval records, and defined retention periods. Retention minimum: current version plus previous version; audit evidence typically 3 years. Auditor will verify the document register exists, is current, and that documents on it match what is actually in use.

Clause 8 — Operation

8.1 Operational planning and controlDemonstrate that security processes are actually operating as documented — not just written. Produce: process records, operational logs, and exception handling records. Changes to operations that affect information security must be planned and controlled. If outsourcing ISMS processes, show how control is maintained. Auditor will trace a sample of operational security events (e.g. an access request, a vulnerability scan, an incident) through the documented process.
8.2 Information security risk assessment (operational)Conduct formal risk assessments at planned intervals (minimum annually) and whenever significant changes occur — new system, merger, major new supplier, significant threat intelligence, or security incident. Each assessment must be documented with date, scope, methodology, results, and sign-off. Auditor will check: when was the last risk assessment? Was it triggered by this year's audit finding? What changed vs. the previous assessment?
8.3 Information security risk treatment (operational)Produce current Risk Treatment Plan (RTP) implementation evidence for every control in the SoA marked as applicable: policy documents, configuration screenshots, training records, penetration test reports, etc. The RTP must show current status (planned / in progress / implemented / accepted). Auditor will pick 10 controls from the SoA and ask for implementation evidence for each one.

Clause 9 — Performance Evaluation

9.1 Monitoring, measurement, analysis, and evaluationDefine security KPIs / metrics and produce a measurement report at least annually (ideally quarterly). Example metrics: MFA enrolment rate (%), mean time to patch critical CVEs (days), phishing simulation click rate (%), number of open high/critical findings from last audit, backup restoration test success rate (%), security incidents per quarter. For each metric: document baseline, target, measurement method, data source, and owner. Auditor will ask for the most recent metrics report and what management decisions it informed.
9.2 Internal auditProduce:
(1) An Annual Internal Audit Programme covering all ISMS clauses and all applicable Annex A controls over a defined cycle (typically 2–3 years).
(2) Individual Audit Reports for each completed audit including scope, criteria, findings (conformities, nonconformities, observations), and evidence.
(3) A Nonconformity and Corrective Action log tracking each finding to closure. Auditors must be independent of the area audited. Auditor (CB) will check: are internal auditors competent? Are all nonconformities tracked to closure? Is the audit programme risk-based?
9.3 Management reviewConduct a formal Management Review meeting at least annually (recommended 2x per year). Mandatory agenda inputs per the standard: audit results, risk assessment status, security objectives achievement, stakeholder feedback, legal compliance status, nonconformity status, and opportunities for improvement. Document Management Review Minutes with decisions made and actions assigned. Auditor will request last 2 management review records and verify all mandatory inputs were addressed.

Clause 10 — Improvement

10.1 Continual improvementDemonstrate a systematic improvement process: improvement actions are tracked in the Corrective Action log or a dedicated improvement register, each with a root cause, planned action, owner, target date, and verification of effectiveness. Improvements should arise from: audit findings, management review, incidents, metrics trends, and staff suggestions.

Auditor will ask: show me an improvement you made in the last 12 months and how you verified it was effective.
10.2 Nonconformity and corrective actionFor every nonconformity (from internal audit, external audit, incident, or management review):
(1) Contain and correct it immediately.
(2) Root cause analysis — identify why it happened (not just what happened).
(3) Corrective action plan with owner and due date.
(4) Effectiveness review — verify the root cause is eliminated, not just the symptom.
(5) Retain all records. Common failure: organisations close nonconformities without root cause analysis, leading to recurrence. Auditor will check closure evidence and follow up on prior audit findings.

🏢 Annex A.5 — Organisational Controls (37)

The governance layer of the ISMS — policies, asset management, access control, supplier relationships, incident management, and business continuity. These controls provide the administrative backbone that all technical controls build upon.

A.5.1–5.4 — Policies & Governance

A.5.1 Policies for information securityThe information security policy is the top-level document. Below it, produce topic-specific policies covering at minimum: Access Control, Acceptable Use, Data Classification, BYOD/Remote Working, Cryptography, Clear Desk/Screen, Supplier Security, Incident Management, Business Continuity, and Vulnerability Management. Each policy must state: purpose, scope, owner, review date, enforcement. Auditor will check version history, management approval signature, and evidence that policies were communicated to all staff.
A.5.2 Information security roles and responsibilitiesProduce a RACI matrix covering all ISMS processes and an Information Security Responsibilities document appended to job descriptions for all roles handling sensitive information. At minimum, define responsibilities for: ISMS owner, CISO/InfoSec manager, IT operations, HR (for joiner/mover/leaver), legal/compliance, data protection officer, and line managers. Auditor will interview 2–3 role holders and ask them to describe their specific ISMS responsibilities.
A.5.3 Segregation of dutiesDocument incompatible role combinations and controls in place. Classic examples: the person who requests access should not approve it; developers should not deploy to production; the person who runs backups should not be the sole person who verifies them; finance payment approval requires two authorisers. Evidence: documented role segregation policy, system access control configuration showing separated accounts, and approval workflow records.
A.5.4 Management responsibilitiesEvidence that managers actively enforce security policies — not just HR or IT. Required:
(1) Security included in performance objectives for managers.
(2) Line managers conduct and sign off security inductions for new joiners.
(3) Managers are the first escalation point for policy violations in their team.
(4) Managers report security concerns upward. Auditor will interview line managers outside IT to assess their security awareness and involvement.

A.5.5–5.8 — Contact, Threat Intelligence & Projects

A.5.5 Contact with authoritiesMaintain a Contacts Register listing: national CERT/CSIRT (e.g. NCSC in the UK, CISA in the US), data protection supervisory authority (e.g. ICO), law enforcement contact for cybercrime (e.g. Action Fraud), relevant sector regulator (FCA, CQC, Ofgem etc.), and local emergency services for physical security incidents. For each: contact details, purpose, and who in the organisation is the liaison. Review annually.

Auditor will ask: if you had a major incident tonight, who would you call and who is responsible for making that call?
A.5.6 Contact with special interest groupsDocument membership in relevant security communities: NCSC Early Warning programme, ISAC for your sector (FS-ISAC, H-ISAC etc.), vendor security advisories (Microsoft, Cisco, AWS etc.), OWASP, FIRST.org. Assign a named person responsible for monitoring and acting on intelligence from each source. Show evidence of intelligence being actioned — e.g. a threat bulletin that led to a patching decision.

Auditor will ask: show me a recent piece of threat intelligence you received and what you did with it.
A.5.7 [NEW 2022] Threat intelligenceEstablish a Threat Intelligence process:
(1) Define intelligence sources (OSINT, commercial feeds, ISACs, NCSC alerts, vendor advisories).
(2) Define intelligence format and storage (structured: STIX/TAXII preferred; at minimum, a documented threat log).
(3) Assign a named owner to triage incoming intelligence.
(4) Document how intelligence informs the risk assessment (new threats → reassess affected assets).
(5) Produce a Threat Intelligence report or summary at least quarterly for management review.

Auditor will ask: show me a recent threat intelligence item and trace how it affected your risk register or controls.
A.5.8 Information security in project managementAll projects above a defined threshold (e.g. processing personal data, new IT systems, changes to production environments) must include a Security Gate Review at each SDLC phase. Minimum gates: requirements (security requirements defined), design (threat model completed), pre-launch (pen test / security review passed), post-launch (production monitoring confirmed). Produce a project security checklist template. Auditor will pick a recent project and ask to see its security review records.

A.5.9–5.13 — Asset Management

A.5.9 Inventory of information and other associated assetsMaintain a formal Asset Register with at minimum these fields per asset: asset ID, name/description, type (hardware/software/data/service/people), owner (accountable individual, not just a team), custodian, classification, location, acquisition date, and disposal date. Cover: physical hardware, software licences, data assets (databases, file stores), cloud services, paper records, and intellectual property. Review at least annually and after every significant change. Auditor will sample 10 assets and ask for their owner, classification, and location.
A.5.10 Acceptable use of information and other associated assetsProduce an Acceptable Use Policy (AUP) covering: permitted and prohibited use of corporate IT, internet, email, removable media, personal devices, social media, AI tools, and cloud storage. All users must sign or digitally acknowledge the AUP at onboarding and annually thereafter. The AUP must reference disciplinary consequences (link to A.6.4). Auditor will ask to see a sample signed AUP, look for date of last acknowledgement, and ask what happens when someone violates it.
A.5.11 Return of assetsIntegrate asset return into the HR leaver process: hardware return checklist (laptop, phone, access card, tokens), software licence deactivation, and account deprovisioning — all within 24 hours of termination. For contractors: assets must be returned on last day of engagement. Produce evidence: completed asset return checklists with dates and signatures. Auditor will pick 3 recent leavers and verify their assets were returned and accounts disabled within the defined timescale.
A.5.12 Classification of informationDefine a classification taxonomy appropriate to your organisation. Typical tiers: Public — Internal — Confidential — Restricted. For each tier, define: description, examples, handling requirements (storage, transmission, disposal, sharing). Publish the scheme in the data classification policy. Auditor will pick a data asset (e.g. customer database) and ask: what is its classification, who classified it, and how is it handled accordingly?
A.5.13 Labelling of informationDefine labelling standards for each classification tier — digital documents (header/footer, metadata tags, DLP labels), email subject/body prefixes, and physical documents (stamp or cover sheet). Use Microsoft Purview Information Protection labels, Google Drive labels, or equivalent tooling. Ensure labels are applied consistently — spot-check via DLP reports. Auditor will ask to see a labelled document in each classification tier and verify the labelling matches the handling requirements.

A.5.14–5.18 — Access Control & Identity

A.5.14 Information transferProduce an Information Transfer Policy covering:
(1) Email — acceptable for what classification levels; must use TLS in transit for Confidential+.
(2) File sharing — approved platforms only (no personal cloud storage for Confidential+).
(3) Physical transfer — encrypted USB only (hardware-encrypted, e.g. IronKey), courier requirements, chain of custody for Restricted.
(4) Verbal — screen-sharing restrictions, no sensitive data in open offices. All file sharing agreements with third parties must require encryption and access controls.

Auditor will ask: how do you transfer customer PII to your payroll processor?
A.5.15 Access controlProduce an Access Control Policy defining the access model (role-based, attribute-based, or discretionary), the process for granting access (formal request → line manager approval → IT provisioning), the review cycle (quarterly for privileged access, annually for standard), and the default position (deny-all, grant only what is needed). Map roles to permissions for key systems. Auditor will pick a system and ask: how is access to this system requested, approved, provisioned, and revoked?
A.5.16 Identity managementEnsure every person and system has a unique, individual identity — no shared accounts, no generic service accounts without an owner. Maintain an identity lifecycle process:
(1) Joiner: provision on start date only after manager approval.
(2) Mover: adjust access within 24 hours of role change — remove old access, add new.
(3) Leaver: disable all accounts within 2 hours of departure, delete/archive within 30 days. Evidence: provisioning tickets with approval records, leaver process logs. Auditor will check for any active accounts belonging to leavers.
A.5.17 Authentication informationProduce a Password / Authentication Policy aligned with NIST SP 800-63B: minimum 12 characters (not 8), no mandatory periodic rotation unless compromise is suspected (forced rotation increases reuse), no complexity rules that reduce entropy (e.g. "must contain a symbol"), but screen against known-breached passwords (HaveIBeenPwned API or equivalent). Require MFA for all remote access and privileged accounts. Never transmit passwords in cleartext — hash with bcrypt, Argon2, or PBKDF2 (not MD5 or SHA-1). Prohibit password reuse (last 12). Mandate a corporate password manager. Auditor will ask to see the policy and verify it is technically enforced, not just documented.
A.5.18 Access rightsConduct formal access reviews on a defined schedule: privileged access quarterly, all other access annually. Reviews must be completed by the business owner of the system (not IT alone). Document: reviewer, date, decision per user (keep/remove/modify), and action taken. Produce completion evidence (signed review records or automated IGA reports). Auditor will request the last access review for a key system and verify that users who failed the review had their access removed.

A.5.19–5.23 — Supplier & Cloud Relationships

A.5.19 Information security in supplier relationshipsBefore onboarding a supplier with access to information assets:
(1) Complete a Supplier Security Assessment questionnaire commensurate with the risk tier.
(2) Classify suppliers by risk (e.g. Tier 1: access to sensitive data or critical systems; Tier 2: access to internal systems; Tier 3: no system access).
(3) Require security certification evidence (ISO 27001, SOC 2 Type II) from Tier 1 suppliers. Include a right-to-audit clause in all Tier 1 contracts. Auditor will ask for your supplier register and the security evidence held for your highest-risk supplier.
A.5.20 Addressing information security within supplier agreementsAll supplier contracts must include:
(1) Data protection obligations (Article 28 DPA if processing personal data).
(2) Security controls required (encryption, access control, incident notification within 24/72 hours).
(3) Right-to-audit / right-to-assess.
(4) Sub-processor restrictions.
(5) Data return / deletion on termination.
(6) Business continuity requirements. Use a standard security schedule / data processing agreement (DPA) template for all suppliers. Auditor will request a sample supplier contract and check for these clauses.
A.5.21 Managing information security in the ICT supply chainFor ICT products and services (hardware, software, cloud):
(1) Assess supply chain risk before procurement (e.g. country of origin, open-source dependencies).
(2) Require a Software Bill of Materials (SBOM) from critical software vendors.
(3) Monitor vendor security advisories and CVE feeds for products in use.
(4) Include supply chain security requirements in procurement RFPs.
(5) For critical components, assess alternatives to avoid single-vendor dependency.

Auditor will ask: what is your process if a critical supplier has a security breach or goes out of business?
A.5.22 Monitoring, review, and change management of supplier servicesConduct annual supplier reviews for all Tier 1 and Tier 2 suppliers: review SLA performance, security incidents reported, certification currency (check their ISO 27001 cert has not expired), and any changes to their sub-processors. For significant changes (new sub-processor, acquisition, data centre move), conduct a security impact assessment before approving. Document review outcomes and actions. Auditor will ask for evidence of the last review of your critical cloud provider.
A.5.23 [NEW 2022] Information security for use of cloud servicesProduce a Cloud Security Policy and a Cloud Services Register listing every sanctioned cloud service with: provider, data classification processed, shared responsibility matrix (what the provider secures vs. what you secure), applicable certifications (ISO 27001, SOC 2, CSA STAR, FedRAMP), data residency location, and exit/data portability plan. Address: configuration hardening (CIS Cloud Benchmarks), CSPM tooling, and encryption key management (customer-managed keys for Restricted data).

Auditor will ask: who approved the use of [cloud provider]? Where does your customer data sit? What happens if you need to exit?

A.5.24–5.28 — Incident Management

A.5.24 Information security incident management planning and preparationProduce a documented Incident Response Plan (IRP) including:
(1) Incident classification tiers (P1/Critical: active breach, ransomware; P2/High: data exposure, system compromise; P3/Medium; P4/Low).
(2) Response procedures per tier (escalation paths, communication templates, containment steps).
(3) Named CSIRT members with 24/7 contact details.
(4) Evidence preservation procedures (chain of custody).
(5) Regulatory notification triggers (GDPR: 72 hours to DPA; PCI DSS: immediate notification).
(6) Post-incident review template. Test the IRP via a tabletop exercise at least annually.

Auditor will ask: when was the last test? Walk me through P1 procedure.
A.5.25 Assessment and decision on information security eventsDefine a documented triage procedure with clear classification criteria. An "event" is any observable security occurrence; an "incident" is one that compromises or threatens CIA. Classification criteria must be objective — e.g. data exfiltration confirmed = P1 incident; malware detected and contained = P2; suspicious login blocked = event only. Assign a named triage officer role on every shift/on-call rotation. Log every event and every classification decision.

Auditor will ask: show me the last 5 security events logged and the classification decision made for each.
A.5.26 Response to information security incidentsFollow the PICERL model: Preparation (IRP ready, tools staged), Identification (confirmed incident, scope defined), Containment (isolate affected systems, block attacker access), Eradication (remove malware, close attack vector), Recovery (restore from clean backup, verify integrity), Lessons Learned (post-incident review within 5 business days). Document every action with timestamp and actor. For GDPR-notifiable incidents: notify supervisory authority within 72 hours. Auditor will ask for an incident record from the last 12 months and verify documentation quality.
A.5.27 Learning from information security incidentsConduct a formal post-incident review (PIR) for every P1 and P2 incident within 5 business days of closure. PIR output must include: root cause (using 5-Whys or fishbone), contributing factors, timeline, what worked/what failed in the response, and 3–5 specific improvement actions with owners and due dates. Feed PIR findings into: risk register (new risk identified?), control updates, training programme, and next management review. Auditor will ask for the PIR from your last significant incident.
A.5.28 Collection of evidenceProduce an Evidence Handling Procedure covering:
(1) Identification of potential evidence sources (SIEM logs, endpoint forensics, email headers, access logs, CCTV).
(2) Acquisition methods that preserve integrity (write blockers, forensic imaging, hash verification).
(3) Chain of custody documentation.
(4) Storage in a tamper-evident, access-controlled location.
(5) Retention period (minimum 12 months; 7 years if legal action is possible). Ensure logs cannot be modified by administrators — use immutable log storage or a SIEM with write-once storage.

Auditor will ask: if you needed to present evidence of a data breach to a court, could you demonstrate the evidence had not been tampered with?

A.5.29–5.37 — Business Continuity, Compliance & Operations

A.5.29 Information security during disruptionIntegrate information security requirements into the Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP). Security-specific BCP requirements: access controls remain enforced during failover; backup administrators have tested their credentials; all alternative processing sites have the same security controls as primary; incident response capability remains available during disruption. Test at least annually — a DR test that disables security controls is a finding. Auditor will check the last BCP/DR test record for security control validation.
A.5.30 [NEW 2022] ICT readiness for business continuityProduce a Business Impact Analysis (BIA) for all critical ICT services, defining RTO (Recovery Time Objective) and RPO (Recovery Point Objective) per service. Test recovery against these targets at least annually. Document test results — "we tested but did not meet RTO" is acceptable if there is an improvement plan. Map ICT dependencies: if Service A fails, what else fails?

Auditor will ask: what is the RTO for your CRM system? When was it last tested? What was the actual recovery time achieved?
A.5.31 Legal, statutory, regulatory, and contractual requirementsProduce a Legal Register listing every applicable law, regulation, and contractual clause affecting information security. For each: jurisdiction, specific requirement, who is responsible for compliance, how compliance is verified, and review date. Examples: GDPR (Articles 25, 28, 32, 33), NIS2 (if applicable), PCI DSS (if processing card data), sector-specific regulations (FCA SYSC, NHS DSPT, HIPAA). Review the register when laws change.

Auditor will ask: what laws apply to your processing of EU citizen data? Who is responsible for monitoring GDPR compliance?
A.5.32 Intellectual property rightsMaintain a Software Licence Register tracking: product name, vendor, licence type (per-user, per-device, per-core), number of licences owned, number deployed, renewal date, and cost. Conduct a Software Asset Management (SAM) audit at least annually — deploy deployed count vs. licences owned. Remove unlicensed software within 30 days.

Auditor will ask: are you compliant with all software licences? When did you last verify this?
A.5.33 Protection of recordsProduce a Records Retention Schedule defining retention periods for all ISMS-relevant record types: audit records (minimum 3 years), incident records (7 years if litigation possible), training records (duration of employment + 3 years), access logs (12 months minimum), management review minutes (3 years). Implement controls to prevent early deletion: restricted delete permissions, legal hold process, archive-to-immutable-storage for critical records.

Auditor will ask: where are your management review minutes from 3 years ago? Can you produce them?
A.5.34 Privacy and protection of PIIIf processing personal data:
(1) Maintain an Article 30 Record of Processing Activities (RoPA) per GDPR.
(2) Conduct Data Protection Impact Assessments (DPIAs) for high-risk processing.
(3) Appoint a DPO if required.
(4) Document lawful basis for each processing activity.
(5) Implement privacy-by-design in new systems.
(6) Enforce data minimisation — only collect what is necessary.
(7) Respond to Data Subject Requests (DSARs) within 30 days.

Auditor will ask: show me your RoPA. When did you last conduct a DPIA?
A.5.35 Independent review of information securityConduct at minimum one independent information security review per year — this can be an internal audit by an auditor independent of the ISMS operations team, an external consultant review, or a third-party penetration test. The reviewer must assess whether ISMS implementation matches documented controls. Produce a review report with findings. Auditor will check that the reviewer was genuinely independent and had the competence to assess the controls they reviewed.
A.5.36 Compliance with policies, rules, and standardsConduct technical compliance checks at least annually:
(1) Configuration audits against CIS Benchmarks or STIG for key platforms.
(2) Vulnerability scans to verify patch levels.
(3) Access rights reviews to verify policy compliance.
(4) DLP reports to verify data handling policies are followed. Report compliance status to management. Treat non-compliance as a nonconformity requiring corrective action.

Auditor will ask: how do you know your systems are configured securely? When was the last configuration audit?
A.5.37 Documented operating proceduresProduce Standard Operating Procedures (SOPs) for all critical information processing activities: backup and restoration, patch management, user account management, incident detection and response, change management, and vulnerability scanning. SOPs must specify: steps, responsible role, frequency, and expected output. Version-controlled and reviewed annually. Auditor will pick a critical process and ask to see the SOP, then verify the last few executions were documented.

👤 Annex A.6 — People Controls (8)

Controls focused on the human factor — consistently the most frequently exploited attack vector. Covers pre-employment screening, employment terms, security awareness training, discipline, post-employment responsibilities, NDAs, remote working, and incident reporting culture.

A.6.1 ScreeningDefine a tiered screening framework proportionate to role risk:
(1) All staff: identity verification, right-to-work check, reference check (2+ references).
(2) Roles with access to Confidential data: basic DBS/criminal record check.
(3) Roles with access to Restricted data, financial systems, or privileged IT access: enhanced DBS, financial check, credit check, 5-year employment history verification.
(4) Re-screen every 5 years or on material role change. Comply with local employment law — in many jurisdictions, certain checks require explicit consent.

Auditor will ask: what screening did your CISO and your database administrator undergo?
A.6.2 Terms and conditions of employmentEmployment contracts must explicitly reference information security obligations, not just via a generic HR policy. Specific clauses required:
(1) Acknowledgement of the information security policy.
(2) Confidentiality / NDA covering information accessed during and after employment.
(3) BYOD and acceptable use agreement.
(4) Data protection responsibilities.
(5) Obligation to report security incidents.
(6) Return of assets. Obtain signed acknowledgement at onboarding and re-sign when policy is materially updated. Auditor will request a sample employment contract and a contractor agreement.
A.6.3 Information security awareness, education, and trainingImplement a Security Awareness Programme including:
(1) Annual mandatory security training for all staff — test with assessment, require pass mark.
(2) New joiner security induction within first week.
(3) Quarterly phishing simulations with immediate training for those who click.
(4) Role-specific training for high-risk roles (IT, finance, HR, legal).
(5) Annual updated training when significant threats change (e.g. AI-enabled phishing, deepfakes). Track completion rates — 100% completion is the target. Produce a training completion report for management review. Auditor will ask for completion rates and the phishing simulation results for the last 12 months.
A.6.4 Disciplinary processThe disciplinary process for security policy violations must be:
(1) Documented in the HR disciplinary policy.
(2) Proportionate to the severity — ranging from a written warning (accidental minor breach) to immediate dismissal (deliberate data theft).
(3) Legally compliant with local employment law.
(4) Applied consistently — an engineer and a director who commit the same violation must face equivalent process.
(5) Triggerable by the information security function (CISO/InfoSec Manager can initiate referral to HR).

Auditor will ask: has the disciplinary process been used for a security policy violation? (They expect to hear "yes" at a mature organisation.)
A.6.5 Responsibilities after termination or change of employmentRun a formal leaver checklist — triggered by HR on resignation/termination. Mandatory steps:
(1) All accounts disabled on last working day (not "within 5 business days").
(2) Hardware, tokens, and access cards returned and logged.
(3) Privileged access removed within 2 hours of departure.
(4) Remind leaver of ongoing NDA obligations (verbal + written confirmation).
(5) For high-risk leavers (access to source code, financial systems, customer data): consider whether a gardening leave or escorted exit is appropriate.
(6) Remove from any distribution lists and system accounts within 24 hours. Auditor will pick 3 leavers from the last 6 months and verify account deprovisioning timestamps.
A.6.6 Confidentiality or non-disclosure agreementsMaintain a register of all active NDAs and confidentiality agreements: party, scope, duration, and review/renewal date. NDAs must cover: scope of confidential information, obligations during and after relationship, permitted use and disclosure, return/destruction obligations, consequences of breach. All employees, contractors, and third-party individuals with access to Confidential+ information must have a signed NDA on file before access is granted. Auditor will ask for the NDA register and sample a recent contractor engagement.
A.6.7 Remote workingProduce a Remote Working Policy and security standard covering:
(1) Approved devices only (corporate-managed or MAM-enrolled for BYOD).
(2) Mandatory use of corporate VPN for access to internal systems (or ZTNA if implemented). Note: split tunnelling should be disabled for privileged access — all traffic via corporate tunnel.
(3) Endpoint must pass compliance check (encrypted disk, updated AV, screen lock ≤5 minutes) before VPN connection is permitted.
(4) No use of public Wi-Fi without VPN.
(5) No processing of Restricted data in shared/public locations.
(6) Home router must be on a separate network from corporate devices (VLAN or separate guest Wi-Fi for IoT).

Auditor will ask: can someone connect from a personal, unmanaged device? Can they bypass the VPN?
A.6.8 Information security event reportingMake it effortless to report: a dedicated email alias (security@company.com), a button in the email client ("Report Phishing"), a Teams/Slack channel, and a physical poster with the reporting number in office areas. Acknowledge every report within 4 hours. Provide feedback to the reporter on the outcome. Run a metric: "number of user-reported events per quarter" — a rising trend indicates a healthy reporting culture. A zero-event organisation almost certainly has under-reporting.

Auditor will ask: how do you report a suspected phishing email? They will then walk to a random desk and ask the same question.

🏗️ Annex A.7 — Physical Controls (14)

Controls that protect tangible assets, facilities, and physical environments from unauthorised access, theft, natural disasters, and deliberate damage. Often underestimated but directly audited — auditors physically walk facilities during certification.

A.7.1–7.5 — Perimeter & Entry

A.7.1 Physical security perimeterDefine physical security zones (e.g. public, restricted, secure). For the secure zone (server room, data centre, comms rooms):
(1) No external windows without opaque film, or windows blocked.
(2) Reinforced walls and door (minimum 30-minute fire rating).
(3) Electronic access control with logging (card, PIN, or biometric).
(4) No shared entry with other tenants where possible.
(5) Perimeter breach detection (door open sensor, alarm). Auditor will physically inspect the server room — common findings: unlocked door, tailgating possible, shared key.
A.7.2 Physical entryImplement:
(1) Electronic access control with individual card/PIN/biometric — no master keys, no shared codes.
(2) Visitor register: full name, organisation, host, purpose, time in/out. Visitors must be escorted at all times in secure areas.
(3) Contractor register and site induction form.
(4) Tailgating prevention: turnstile or mantrap for high-security areas; signage and staff briefing for lower-security.
(5) Access logs retained for minimum 12 months. Auditor will request access logs and check for anomalous entries (weekend access by an unknown person, accounts of leavers still showing access).
A.7.3 Securing offices, rooms, and facilitiesConduct a physical security walk-through as part of your audit preparation. Common findings: post-it notes with passwords on monitors, unattended unlocked computers, whiteboards with confidential information, unlocked filing cabinets containing Confidential documents, server room door propped open. Implement: locked cabinet policy for all Confidential physical documents, auto-lock screensaver policy (enforced via GPO/MDM: 5-minute timeout), and regular physical security audits by someone independent of the team that works in that area.
A.7.4 [NEW 2022] Physical security monitoringImplement CCTV coverage of: entry/exit points to all secure areas, server room interior, reception area. Retain footage for minimum 30 days (90 days recommended). CCTV must comply with data protection law — post visible signage, register the CCTV system with the DPA/ICO, define the lawful basis. Conduct regular CCTV system health checks — a camera that has been offline for 2 months is a control failure. Also consider: motion-triggered alerts for out-of-hours access, or integration with the physical access control system (access event + CCTV timestamp correlation).

Auditor will ask: are all CCTV cameras working today? When did you last verify this?
A.7.5 Protecting against physical and environmental threatsProduce a Physical Risk Assessment for each facility identifying: flood risk (ground floor? near water?), fire risk (proximity to hazards, fire compartmentation), power failure risk (single or dual supply?, UPS coverage?), extreme temperature risk (HVAC redundancy?), and malicious physical attack risk. Implement mitigations proportionate to risk: smoke detection and suppression (FM200 / clean agent in server rooms), raised floors in flood zones, UPS and generator for critical systems, HVAC monitoring with alerts. Test fire suppression and UPS systems at least annually. Auditor will ask for maintenance records for fire suppression, UPS, and HVAC systems.

A.7.6–7.14 — Equipment & Environment

A.7.6 Working in secure areasImplement a Secure Area Working Procedure:
(1) No solo working in high-security areas without a buddy or CCTV coverage (lone worker risk).
(2) Visitors and contractors sign in and are escorted — they must not be left alone with systems.
(3) Cameras and recording devices prohibited in server rooms unless explicitly authorised and logged.
(4) Secure area access logs reviewed monthly for anomalies.
(5) Clean-up procedure before leaving secure area (no sensitive documentation left out). Auditor will check access logs for the server room and ask who was the last non-IT visitor.
A.7.7 Clear desk and clear screenEnforce via both policy and technical controls:
(1) GPO/MDM: screen locks after 5 minutes of inactivity, enforced for all endpoints.
(2) Clear desk policy: all Confidential documents locked in a cabinet at end of day, no printed PII left on desks.
(3) Whiteboards cleared at end of meeting.
(4) Paper shredders accessible in all areas where Confidential documents are handled. Conduct unannounced spot-checks (2–3 per year, documented) to verify compliance — post results to staff as a reminder. Auditor will walk the office after hours and look for unattended unlocked screens and paper on desks.
A.7.8 Equipment siting and protectionServer rooms must meet:
(1) Temperature 18–27°C with active monitoring and alerts.
(2) Humidity 40–60% with active monitoring.
(3) Raised floor or cable management to prevent trip hazards and facilitate airflow.
(4) Equipment not positioned near external walls or under water pipes.
(5) Hot aisle/cold aisle rack layout for data centres.
(6) No food or drink in server rooms. For office equipment: monitors angled to prevent shoulder surfing; printers/copiers in secure areas for high-sensitivity printing; print release authentication for Confidential documents.
A.7.9 Security of assets off-premisesProduce an Off-Premises Asset Policy:
(1) Full-disk encryption mandatory on all laptops and mobile devices (enforced via MDM compliance policy — non-compliant devices blocked from accessing corporate resources).
(2) Encrypted USB only (hardware-encrypted, e.g. IronKey, Kingston Ironkey).
(3) Screen privacy filters on laptops used in public.
(4) Never leave devices unattended in vehicles — especially in view.
(5) Report loss/theft within 1 hour to IT — enables remote wipe.
(6) Device tracking enabled (Find My / Microsoft Endpoint).

Auditor will ask: what happens if a laptop is stolen at an airport? How quickly would you know, and what data would be at risk?
A.7.10 Storage mediaImplement a Media Handling Procedure:
(1) All removable media in use must be logged in an asset register.
(2) Encryption required for all removable media containing Confidential+ data.
(3) Media containing Restricted data must not leave premises without management authorisation and chain-of-custody documentation.
(4) Secure disposal: overwrite with DoD 5220.22-M (3 passes) for HDDs, physical destruction or NIST 800-88 purge for SSDs, physical shredding for optical media. Obtain Certificate of Destruction (CoD) from approved disposal vendor.

Auditor will ask: how are old hard drives from decommissioned servers disposed of? Do you have a Certificate of Destruction?
A.7.11 Supporting utilitiesProduce a Utilities Risk Assessment and maintenance schedule:
(1) UPS: covers all critical systems, tested under load every 6 months, battery replacement on schedule (typically 3–5 years).
(2) Generator: automatic failover tested annually, fuel supply checked quarterly.
(3) HVAC: redundant cooling units for server rooms, maintenance contract in place, PM every 6 months.
(4) Dual power feeds from separate substations for critical facilities (verify with utility provider).
(5) Leak detection under raised floor. Auditor will ask for the last UPS test result and maintenance records.
A.7.12 Cabling securityImplement:
(1) All network cabling in conduits or cable trays — not loose on floors.
(2) Patch panels labelled and diagrammed — unknown cables are a security risk.
(3) Comms room / MDF/IDF locked and access controlled.
(4) Power cabling separated from data cabling to prevent interference.
(5) Fibre connections for cross-building runs to prevent copper eavesdropping.
(6) Decommissioned network ports disabled at the switch (not just physically unplugged).
(7) Network diagram kept current — an undocumented connection is an unknown risk.

Auditor will ask: is every network port in this building mapped? Are any active that should be decommissioned?
A.7.13 Equipment maintenanceMaintain a Maintenance Log for all critical equipment: date of maintenance, type (scheduled/unscheduled), performed by (internal/external), work done, and sign-off. Require maintenance personnel to sign in and be escorted. Before returning sensitive equipment from off-site repair:
(1) Verify it was not tampered with.
(2) Wipe data storage before sending for repair — use certified wipe tool.
(3) If wipe is not possible (failed drive), use an approved data destruction vendor instead of a repair vendor. Auditor will ask for the maintenance log for the server room UPS and check whether maintenance was performed by authorised personnel.
A.7.14 Secure disposal or reuse of equipmentNever dispose of hardware without certifying data destruction. Process:
(1) HDDs: overwrite using NIST 800-88 clear (DoD 5220.22-M) or degauss. Failed drives: physical shredding only.
(2) SSDs/Flash: NIST 800-88 purge via ATA Secure Erase or crypto erase (if self-encrypting). Physical shredding is the safest option for SSDs.
(3) Mobile devices: factory reset + MDM wipe.
(4) Obtain a signed Certificate of Destruction from your disposal vendor — retain for minimum 3 years.
(5) Maintain a disposal log.

Auditor will ask: show me the disposal records and Certificates of Destruction for your last batch of decommissioned servers.

💻 Annex A.8 — Technological Controls (34)

The largest and most technical section — 34 controls covering user endpoints, privileged access, secure authentication, malware defences, vulnerability management, logging, cryptography, network security, and secure development. This is where IT and security engineering teams will focus most of their implementation effort.

A.8.1–8.5 — Endpoints & Access Management

A.8.1 User endpoint devicesProduce an Endpoint Security Standard enforced via MDM (Microsoft Intune, Jamf, etc.) with technical controls — not just policy. Minimum requirements:
(1) Full-disk encryption (BitLocker on Windows with TPM, FileVault on macOS) — verified as enabled via MDM compliance report.
(2) AV/EDR agent installed and reporting to central console.
(3) OS and critical software patches applied within defined SLA.
(4) Screen lock after ≤5 minutes inactivity, enforced.
(5) Local admin rights removed from standard user accounts.
(6) Non-compliant devices blocked from accessing corporate resources via Conditional Access. Auditor will ask for your MDM compliance dashboard — how many endpoints are currently non-compliant?
A.8.2 Privileged access rightsApply the principle of least privilege rigorously:
(1) No standing domain admin or root access — use Just-In-Time (JIT) access via a PAM solution (CyberArk, BeyondTrust, HashiCorp Vault, Delinea).
(2) Separate accounts for privileged vs. standard tasks — admins must have two accounts.
(3) Privileged sessions recorded and retained (PAM session recording).
(4) Privileged access reviewed quarterly.
(5) No shared admin credentials — every admin action attributable to a named individual.
(6) Break-glass accounts for emergency access: sealed, monitored, and reviewed when used.

Auditor will ask: can you show me who has domain admin rights today? Were any of those accounts used in the last 30 days?
A.8.3 Information access restrictionImplement Role-Based Access Control (RBAC) on all systems containing Confidential+ data. Roles must reflect actual job functions — not convenience groupings. Produce a role-to-permission matrix for key systems. Access to production data should be denied by default for all non-production roles. For sensitive applications (HR, finance, payroll), implement application-level authorisation as well as network-level controls. Conduct a toxic combination review — identify and remediate any user who has both "create payment" and "approve payment" permissions.
A.8.4 Access to source codeImplement:
(1) Source code repositories (GitHub, GitLab, Bitbucket) with mandatory access review. No public repositories for proprietary code.
(2) Branch protection rules: force pull requests for main/production branches, require 2 reviewers.
(3) No credentials, API keys, or secrets in source code — enforce with pre-commit hooks (git-secrets, detect-secrets) and SAST tools.
(4) Separate read/write access — developers who write code should not be able to deploy to production.
(5) Audit log of all repository access retained 12 months.

Auditor will ask: show me who has write access to your production codebase. Has anyone ever committed a secret? How would you know?
A.8.5 Secure authenticationImplement per NIST SP 800-63B:
(1) Minimum 12-character passwords (not 8).
(2) Do not enforce periodic rotation unless compromise is suspected — forced rotation increases reuse and sticky notes.
(3) Screen passwords against known-breached lists (HaveIBeenPwned API or equivalent).
(4) No reuse of last 12 passwords.
(5) Account lockout after 10 failed attempts (with a cooldown, not permanent lockout — permanent lockout enables DoS).
(6) MFA mandatory for: all remote access (VPN/ZTNA), all cloud admin consoles, all privileged accounts, and all internet-facing applications handling Confidential+ data.
(7) Phishing-resistant MFA (FIDO2/WebAuthn) for privileged and admin accounts — TOTP/SMS are acceptable for standard users but not ideal. Auditor will ask to see the technical enforcement of these controls in your IdP/AD.

A.8.6–8.8 — Capacity, Malware & Vulnerabilities

A.8.6 Capacity managementProduce a Capacity Management Report covering CPU, memory, storage, and network utilisation for all critical systems, reviewed quarterly. Define thresholds: alert at 70% utilisation, remediate before reaching 85%. Maintain a capacity plan projecting growth for 12 months ahead. Cover cloud: monitor cloud spend and usage trends — unconstrained auto-scaling can also indicate a security event (cryptomining, DDoS amplification).

Auditor will ask: how do you know 90 days in advance that you need more storage?
A.8.7 Protection against malwareImplement defence-in-depth against malware:
(1) EDR on all managed endpoints (not just legacy AV — EDR provides behavioural detection and response capability).
(2) Email security gateway with attachment sandboxing and anti-phishing (Microsoft Defender for Office 365, Proofpoint, Mimecast).
(3) Web proxy with malware filtering for outbound web traffic.
(4) Network segmentation to limit lateral movement if malware executes.
(5) Application allowlisting on high-risk systems (servers, privileged workstations).
(6) Regular threat hunting in EDR telemetry. Confirm EDR agent health centrally — a laptop not reporting to the console for 30 days is effectively unprotected. Auditor will ask for an EDR coverage report and the last malware incident handled.
A.8.8 Management of technical vulnerabilitiesImplement a Vulnerability Management Programme:
(1) Authenticated vulnerability scans of all in-scope systems weekly for internet-facing, monthly for internal. Tools: Tenable Nessus, Qualys, Rapid7 InsightVM.
(2) Define patching SLAs by CVSS score: Critical (CVSS 9.0+): 24–72 hours; High (7.0–8.9): 7 days; Medium (4.0–6.9): 30 days; Low: 90 days.
(3) Track open vulnerabilities in a remediation register with owner and due date.
(4) Escalate overdue patches to management.
(5) Exceptions require formal risk acceptance signed by the asset owner.
(6) Subscribe to CISA KEV (Known Exploited Vulnerabilities) catalogue — actively exploited vulnerabilities require immediate attention regardless of CVSS.

Auditor will ask: how many critical vulnerabilities are open right now? How long have they been open?

A.8.9–8.11 — Configuration, Deletion & Masking (3 new controls)

A.8.9 [NEW 2022] Configuration managementImplement configuration management based on CIS Benchmarks (free, widely used) or DISA STIGs for your platform (Windows Server, Linux, cloud, network devices). Process:
(1) Define approved baseline configurations for each platform type.
(2) Deploy via automation (Ansible, Puppet, DSC, AWS Config rules).
(3) Detect configuration drift using a CSPM tool (Prisma Cloud, AWS Security Hub, Azure Defender for Cloud) or vulnerability scanner.
(4) Review and update baselines when new guidance is released.
(5) Maintain a Configuration Management Database (CMDB).

Auditor will ask: what is your configuration baseline for a Windows 11 endpoint? How do you verify it is applied?
A.8.10 [NEW 2022] Information deletionImplement a Data Deletion Standard:
(1) Automated deletion at end of retention period — do not rely on manual deletion.
(2) Verified deletion: for Confidential+ data, use a tool that confirms overwriting (DBAN, Eraser, or built-in secure erase).
(3) Cloud data: verify deletion actually removes data — use provider-certified deletion and test by attempting to retrieve deleted objects.
(4) Backups: purge backup sets containing expired data — most organisations forget to delete data from backups.
(5) Produce a quarterly deletion audit report.
(6) Log all deletion events for audit trail.

Auditor will ask: if a customer requests erasure under GDPR, can you confirm their data has been deleted from backups too?
A.8.11 [NEW 2022] Data maskingImplement data masking in non-production environments:
(1) Never copy production data with real PII into dev or test environments — use masked/synthetic data.
(2) Choose the appropriate technique: (a) Pseudonymisation: replace real data with tokens (reversible with key — use for test data that needs to maintain referential integrity). (b) Anonymisation: irreversible removal of identifying data (use for analytics). (c) Tokenisation: replace sensitive values with tokens stored in a secure vault (use for payment card data — PCI scope reduction).
(3) Verify masking quality — reidentification attack testing.
(4) Masking must be applied consistently across all fields that could be combined to identify an individual.

Auditor will ask: show me what customer data looks like in your development environment.

A.8.12–8.16 — DLP, Backups, Redundancy & Monitoring (1 new control)

A.8.12 [NEW 2022] Data leakage preventionImplement DLP controls at three layers:
(1) Endpoint DLP (Microsoft Purview, Symantec DLP): block or alert on sensitive data copied to USB, uploaded to unapproved cloud services, or printed.
(2) Network/proxy DLP: scan outbound web and email traffic for sensitive data patterns (credit card numbers, NI numbers, PII).
(3) Cloud DLP (CASB): monitor and restrict sensitive data in SaaS applications. Define DLP policies based on classification labels. Start with monitor-only mode, review false positive rate, then switch to block mode for high-confidence rules. Treat every DLP alert as an event requiring triage — log and respond.

Auditor will ask: how would you know if an employee emailed an unencrypted spreadsheet of customer data to their personal Gmail?
A.8.13 Information backupFollow the 3-2-1-1 backup rule: 3 copies of data, on 2 different media types, with 1 offsite copy, and 1 copy offline (air-gapped, to protect against ransomware). Define per-system: backup frequency (daily minimum for production systems), retention period (aligned to retention schedule), and RPO. Test restoration at least quarterly — not just "verify backup completed", but actually restore files to a test environment and confirm integrity. Produce restoration test records with timings (vs. RTO). Encrypt all backup data at rest and in transit. Restrict who can delete backups.

Auditor will ask: when did you last restore from backup? What was the result? Were you within your RTO?
A.8.14 Redundancy of information processing facilitiesMap each critical service to its availability requirement (RTO/RPO) from the BIA. For services requiring high availability:
(1) Multi-AZ or multi-region deployment for cloud workloads.
(2) Active-active or active-passive failover with automatic health check.
(3) Load balancing with health monitoring.
(4) No single points of failure in the critical path.
(5) Test failover at least annually — scheduled maintenance window or chaos engineering.

Auditor will ask: what is the RTO for your email system? How do you verify redundancy actually works?
A.8.15 LoggingDefine a Log Management Policy specifying:
(1) What to log: authentication events (success and failure), privileged account activity, user access to Confidential+ data, firewall allow/deny, DNS queries, system/application errors, and configuration changes.
(2) Retention: minimum 12 months online, 24 months archived (adjust to regulatory requirements — PCI DSS requires 12 months; NIS2 may require longer).
(3) Log integrity: logs must be protected from modification by administrators — use a SIEM with write-once storage or forward to an immutable log repository.
(4) Log coverage: 100% of in-scope systems must be logging to the SIEM — produce a coverage report.

Auditor will ask: if I asked you to produce all authentication events for a specific user account for the past 90 days, could you do that now?
A.8.16 Monitoring activitiesImplement centralised monitoring via SIEM (Splunk, Microsoft Sentinel, Elastic SIEM, IBM QRadar, etc.) with defined detection rules and alerting. Minimum detection use cases:
(1) Account lockout spike (potential brute force).
(2) Logon from impossible location (credential compromise).
(3) Large data download by a user account (insider threat / exfiltration).
(4) New admin account created outside change window.
(5) Malware detection by EDR. Define an SLA for alert response: Critical: 15 minutes; High: 1 hour; Medium: 4 hours. Conduct monthly SIEM rule tuning to reduce false positives.

Auditor will ask: show me the last 3 SIEM alerts. Walk me through how they were triaged and closed.

A.8.17–8.19 — Clocks, Utilities & Software Installation

A.8.17 Clock synchronisationConfigure all systems to use NTP with a trusted, accurate time source. Recommended hierarchy:
(1) Network devices and servers → NTP pool (pool.ntp.org) or a dedicated internal NTP server synced to GPS/atomic source.
(2) Internal NTP server → all endpoints and servers.
(3) Maximum acceptable drift: ±1 second for most systems; ±0.1 second for systems doing cryptographic operations or correlated log analysis. Verify synchronisation via monitoring — alert on systems with drift >5 seconds. Without accurate timestamps, forensic log correlation is unreliable.

Auditor will ask: if you had a security incident, could you correlate logs from your firewall, SIEM, and endpoint EDR with confidence in the timestamps?
A.8.18 Use of privileged utility programsDefine an approved list of privileged utility programs (e.g. netcat, nmap, Sysinternals, PsExec, PowerShell with WinRM, sqlcmd) and restrict execution to named administrators. Controls:
(1) Application control / allowlisting on servers — unapproved utilities cannot execute.
(2) All use of approved utilities logged via SIEM (Windows Event ID 4688 / Linux auditd).
(3) Utilities that are not routinely needed (e.g. packet capture tools) require a change request before use.
(4) Remove or disable utilities not in use — an attacker who gains access and finds nmap pre-installed is significantly more capable.

Auditor will ask: is PowerShell remoting enabled on all your servers? If yes, who can use it and is it logged?
A.8.19 Installation of software on operational systemsImplement application control on production servers and privileged workstations: Windows Defender Application Control (WDAC) or AppLocker in allowlist mode — only signed, approved applications can execute. For endpoints: MDM software deployment policy — standard users cannot install software; all installs go through IT service desk with manager approval. Produce a software installation log: every install recorded with requestor, approver, date. Shadow IT is a real risk — use CASB / web proxy to detect unsanctioned cloud applications being used by staff.

Auditor will ask: can a standard user install software on their laptop? Can they install browser extensions?

A.8.20–8.24 — Network Security

A.8.20 Networks securityProduce a network architecture diagram (current, not from 3 years ago) showing all network segments, firewalls, DMZ, and connections to external networks (internet, third parties, cloud). Implement:
(1) Stateful firewall at all network boundaries with default-deny rulesets.
(2) IDS/IPS with signature updates and tuning.
(3) Egress filtering — restrict outbound connections to known, needed destinations.
(4) Network Access Control (NAC) — only authenticated, compliant devices can join the corporate network.
(5) Separate VLAN for IoT, guest Wi-Fi, BYOD, OT/SCADA.
(6) Firewall rule review at least annually — remove unused rules. Auditor will ask for the firewall ruleset review records and the last change made to the firewall.
A.8.21 Security of network servicesFor every externally provided network service (internet, MPLS, SD-WAN, cloud connectivity):
(1) Include security SLAs in the service agreement: incident notification time, patching time, DDoS mitigation, availability.
(2) Verify provider's security certifications (ISO 27001, SOC 2).
(3) Confirm who is responsible for security at each layer (shared responsibility).
(4) Monitor service performance and security events — do not rely solely on the provider's reporting.
(5) Test failover to secondary connection annually.

Auditor will ask: what security commitments does your internet provider make? What is their RTO for a DDoS attack?
A.8.22 Segregation of networksImplement network segregation using:
(1) VLANs with inter-VLAN routing via firewall (not just a layer-2 switch).
(2) Separate segments for: corporate user traffic, servers/production, management (IPMI, ILO, iDRAC), guest Wi-Fi, BYOD, IoT/OT, and third-party/supplier access.
(3) Firewall rules between segments based on documented, justified business need — "any-to-any" between internal VLANs defeats segmentation.
(4) Audit firewall rules between VLANs annually.
(5) Verify that guest Wi-Fi cannot reach internal network resources — test by connecting and attempting to access internal IP. Auditor will ask to see the network diagram and the firewall rules between the user VLAN and the server VLAN.
A.8.23 Web filteringDeploy a Secure Web Gateway (SWG) or DNS filtering solution (Cisco Umbrella, Cloudflare Gateway, Zscaler Internet Access, Palo Alto URL filtering) enforcing policy for all internet-destined traffic, including from remote workers (tunnel all traffic through corporate proxy, or deploy a cloud-delivered SWG). Minimum blocking categories: known malware/C2 sites, phishing sites, anonymisers/proxies, file-sharing sites (for Confidential+ data), illegal content. Log all web traffic — use logs to detect anomalous exfiltration (large uploads to unfamiliar domains).

Auditor will ask: if an employee tries to access a known phishing site, what happens? Is remote workers' web traffic also filtered?
A.8.24 Use of cryptographyProduce a Cryptography Policy and Key Management Procedure specifying:
(1) Approved algorithms: AES-256 for symmetric encryption; RSA-2048 minimum (RSA-4096 preferred) or ECDSA P-256/P-384 for asymmetric; SHA-256 minimum (SHA-3 preferred) for hashing; TLS 1.2 minimum (TLS 1.3 preferred) for transport.
(2) Prohibited algorithms: DES, 3DES, RC4, MD5, SHA-1, TLS 1.0, TLS 1.1, SSL — verify these are disabled.
(3) Key lifecycle: generation (HSM or secure RNG), distribution, storage (KMS — AWS KMS, Azure Key Vault, HashiCorp Vault), rotation schedule (annually for long-lived keys), and destruction (documented, verified).
(4) Customer-managed keys for all Restricted data in cloud.

Auditor will ask: is TLS 1.0 disabled on all your public-facing services? Verify with testssl.sh.

A.8.25–8.31 — Secure Development

A.8.25 Secure development life cycleIntegrate security at every SDLC phase:
(1) Requirements: threat model created (STRIDE/DREAD/PASTA), security requirements defined.
(2) Design: architecture review with security input.
(3) Development: SAST in IDE (SonarLint, Semgrep) and CI pipeline (SonarQube, Checkmarx). Developer security training (OWASP, language-specific).
(4) Test: DAST (OWASP ZAP, Burp Enterprise), SCA for dependency CVEs (Snyk, Dependabot).
(5) Deployment: container image scanning (Trivy, Grype), infrastructure-as-code scanning (Checkov, tfsec).
(6) Operations: runtime monitoring, penetration testing. All security gates must pass before production deployment. Auditor will pick a recent release and ask for its security gate records.
A.8.26 Application security requirementsProduce a Security Requirements Template used for every application development or procurement. Base requirements on OWASP ASVS Level 2 (Application Security Verification Standard) as your minimum bar. Minimum requirements to define: authentication (MFA requirements), authorisation model (RBAC/ABAC), session management (timeout, invalidation), input validation (all untrusted input), cryptography (transport and at-rest), error handling (no sensitive data in error messages), logging (what must be logged), and third-party component policy (approved libraries only, CVE threshold).

Auditor will ask: show me the security requirements document for your customer portal.
A.8.27 Secure system architecture and engineering principlesDocument and apply security architecture principles:
(1) Least privilege at every layer (user, application, service, network).
(2) Defence in depth — multiple independent layers; compromise of one layer does not compromise the whole.
(3) Fail secure / fail closed — on error, deny access rather than grant.
(4) Separation of concerns — authentication, authorisation, and business logic are separate.
(5) Zero trust — no implicit trust from network location.
(6) Secure defaults — new instances are secure by default; insecurity requires explicit configuration. Produce an Architecture Decision Record (ADR) for significant design decisions documenting the security trade-offs considered.
A.8.28 [NEW 2022] Secure codingImplement a Secure Coding Standard referencing OWASP Top 10 and OWASP ASVS. Minimum controls:
(1) All developers complete secure coding training annually (OWASP, SANS, platform-specific).
(2) SAST integrated into CI pipeline — pipeline fails on high/critical findings.
(3) SCA (Software Composition Analysis) integrated into CI — pipeline fails on CVEs above defined severity.
(4) Mandatory peer code review with a security checklist.
(5) No secrets in source code — pre-commit hooks (detect-secrets, gitleaks) prevent commits with credentials.
(6) Input validation on all untrusted data — server-side, not just client-side.
(7) Parameterised queries / prepared statements — no string concatenation in SQL.

Auditor will ask: show me a code review where a security issue was caught. What tool found the last vulnerability in your CI pipeline?
A.8.29 Security testing in development and acceptanceImplement a Security Testing Programme:
(1) SAST: automated in CI pipeline on every commit.
(2) DAST: automated against a deployed instance in the staging environment (OWASP ZAP, Burp Enterprise).
(3) SCA: dependency scanning on every build (Snyk, Dependabot, OWASP Dependency-Check).
(4) Penetration test: external, scoped pen test by a qualified third party (CHECK-accredited in the UK, CREST-certified) at minimum annually, and after major releases or architecture changes.
(5) Results tracked in a remediation register; Critical findings block production deployment. Auditor will ask for the last penetration test report and the remediation status of its findings.
A.8.30 Outsourced developmentFor outsourced or third-party development:
(1) Include security requirements in the contract (OWASP ASVS Level 2 minimum, vulnerability disclosure obligations, code review rights).
(2) Conduct a code review of delivered code before accepting into your codebase (automated SAST + manual review for high-risk components).
(3) Require the vendor to provide an SBOM with the delivered software.
(4) Run SCA on all third-party code before deploying.
(5) Include right-to-audit and right-to-conduct-pen-test in the contract.
(6) Verify the vendor's own SDLC security practices before engagement.

Auditor will ask: when your outsourced development team delivers new code, what is your security review process before it goes live?
A.8.31 Separation of development, test, and production environmentsEnforce strict environment separation:
(1) Separate access credentials for each environment — no shared service accounts.
(2) Network segmentation: dev/test environments cannot initiate connections to production.
(3) No production data in dev or test — use synthetic or masked data only (link to A.8.11).
(4) Separate CI/CD pipelines with gates before promotion to production.
(5) No direct developer access to production — all changes go through the deployment pipeline.
(6) Production environment access list reviewed quarterly.

Auditor will ask: can a developer SSH directly into a production server? Is production data accessible in the development database?

A.8.32–8.34 — Change Management, Test Data & Audit (1 new control)

A.8.32 Change managementImplement a formal Change Management Process:
(1) All changes to production systems require a Change Request (CR) with: description, risk assessment, rollback plan, test results, and approver sign-off.
(2) Emergency changes (hotfixes) follow an expedited path — record first, approve within 24 hours.
(3) Change Advisory Board (CAB) or equivalent reviews and approves significant changes.
(4) Post-implementation review for major changes.
(5) Unauthorised changes are a nonconformity — your change management tool (ServiceNow, Jira, etc.) should detect and alert on changes without approved CRs. Auditor will pick a recent production deployment and ask for the Change Request record, approval, and rollback plan.
A.8.33 Test informationProduce a Test Data Management Policy:
(1) Production data must never be used in dev or test without explicit CISO approval and documented justification.
(2) Approved alternatives: (a) Synthetic data generated by tools (Faker, Mockaroo, custom scripts). (b) Masked production data — masked before export using an automated tool, verified to have removed all PII.
(3) Test environment access controls are equivalent to production for any unmasked data.
(4) Data generated during testing is deleted at the end of the test cycle.
(5) No test credentials in production. Auditor will ask to see what data is in the development database for your CRM application.
A.8.34 [NEW 2022] Protection of information systems during audit testingBefore allowing audit tools to run against production systems:
(1) Agree scope, methods, and schedule in writing — get formal written authorisation.
(2) Auditors use read-only accounts where possible — never provide a root/domain admin account to an auditor unless unavoidable and monitored.
(3) Define exclusions: systems that must not be scanned (production databases during business hours, ICS/OT systems).
(4) Ensure rollback plan exists if a scan causes disruption.
(5) All audit tool installations are temporary — remove after use.
(6) Audit activities are logged in the SIEM.
(7) Auditors must work under a rules of engagement (ROE) document.

Auditor will ask: show me the authorisation letter for the last penetration test. Was any production data accessed during the test?

📄 Download This Checklist

Your checkbox progress is included. In the print dialog, choose Save as PDF to get a clean, print-ready version.

📚 References & Further Reading

Conclusion

ISO 27001:2022 represents a mature, internationally recognised framework for managing information security risk. The shift to 93 controls across 4 themes makes the standard more manageable and better aligned with modern threats — particularly around cloud services, threat intelligence, and secure coding. Remember that the goal is not to tick every control, but to tick the right controls for your organisation's risk profile, and to document your justification for every inclusion and exclusion in your Statement of Applicability.