ISO 27001 checklist

Clause 4: Context of the organisation

• The internal and external issues that affect the ISMS are identified and recordedInclude a decision on whether climate change is a relevant issue: Amendment 1:2024 added that question to clause 4.1.
• Interested parties and their information security requirements are listed, with a decision on which ones the ISMS addressesCustomers, regulators, suppliers, staff and owners. Contracts and laws are the usual sources of requirements.
• The ISMS scope is written down, with its boundaries and its interfaces with other organisationsSee the requirements guide for what a scope statement covers.
• The processes that make up the ISMS, and how they connect, are defined

Clause 5: Leadership

• Top management takes an active part: it provides resources, sets direction and reviews resultsMinutes, decisions and budgets show this better than a statement of support.
• An information security policy suited to the organisation is approved by top managementIt sets objectives or a way to set them, commits to meeting requirements and to improving the ISMS, and is shared with staff and, where appropriate, with interested parties.
• Information security roles, responsibilities and authorities are assigned and communicatedIncluding who makes sure the ISMS meets the standard, and who reports on its performance to top management.

Clause 6: Planning

• Criteria for accepting risk and for carrying out risk assessments are defined
• A documented, repeatable risk assessment method has been applied to the whole scopeEach risk to confidentiality, integrity or availability has an owner, a rating for consequence and likelihood, and a priority. See the risk assessment guide.
• A treatment option is chosen for each risk that needs treatment, with the controls it requiresSee risk treatment.
• The chosen controls have been compared with Annex A to check that nothing necessary is missing
• A Statement of Applicability covers every Annex A control with its status and the reason for including or excluding itSee the Statement of Applicability.
• A risk treatment plan is approved by the risk owners, who have also accepted the residual risks
• Measurable information security objectives are set, with owners, resources, deadlines and a way to judge results
• Changes to the ISMS are planned before they are made

Clause 7: Support

• The people, time, tools and budget the ISMS needs are identified and provided
• The competence each security role needs is defined, and evidence of it is keptQualifications, training records or experience, and what was done to close any gap.
• Staff know the policy, how their work contributes to security, and the consequences of not following the ISMS
• Communication about information security is planned: topics, timing, audience and channel
• ISMS documents and records are controlled: identified, approved, versioned, protected and kept for a set period

Clause 8: Operation

• The ISMS processes run as planned, with criteria for each and records that show it
• Processes, products and services from outside the organisation that matter to the ISMS are identified and controlled
• Risk assessments are repeated at planned intervals and after significant change, and the results are kept
• The risk treatment plan is being carried out, and the results are recorded

Clause 9: Performance evaluation

• What is monitored and measured is decided, with the method, the schedule and who analyses the results
• Monitoring results are kept and used to judge how well the ISMS performs
• An internal audit programme covers the whole ISMS at planned intervals, with objective auditorsAuditors should not audit their own work. The programme sets frequency, methods, responsibilities and reporting.
• At least one internal audit has been completed, with findings reported to management and recorded
• Top management has reviewed the ISMS, and its decisions and actions are recordedSee performance evaluation for what the review considers.

Clause 10: Improvement

• Opportunities to improve the ISMS are identified and acted on
• Nonconformities are recorded and corrected, and their causes are addressedFix the immediate problem, find the cause, decide whether it could happen elsewhere, and act on that.
• Each corrective action is checked for effectiveness before it is closed

Annex A: Organisational controls

A sample from 5.1 to 5.37. Include each one that your risk assessment calls for.

• The information security policy and topic-specific policies are approved, published and reviewed (5.1)
• An inventory of information and associated assets exists, and each asset has an owner (5.9)For internet-facing names, compare the inventory with the hostnames in certificate transparency logs.Free tool: Subdomain finder
• Information transfer is protected, including email from your domains (5.14)SPF, DKIM and an enforced DMARC policy on sending domains, and rules for file sharing and other channels.Free tool: Email security checker
• Access is granted, reviewed and removed through a defined process (5.15 to 5.18)
• Security requirements are agreed with suppliers and their delivery is monitored (5.19 to 5.22)
• Cloud services are chosen, used and exited under defined security requirements (5.23)
• Incident handling is prepared: reporting, triage, response and lessons learned (5.24 to 5.27)
• Business continuity plans cover information security and the recovery of IT, and are tested (5.29, 5.30)
• Legal, regulatory and contractual requirements, including privacy, are listed with how each is met (5.31, 5.34)

Annex A: People controls

A sample from 6.1 to 6.8.

• Background checks are carried out before people join, in proportion to the role (6.1)
• Employment terms and confidentiality agreements cover information security (6.2, 6.6)
• Everyone receives security awareness training when they join and at regular intervals, and it is recorded (6.3)
• Remote working is covered by rules and technical protections (6.7)
• People know how to report a security event, and reports reach someone who acts on them (6.8)

Annex A: Physical controls

A sample from 7.1 to 7.14. Remote-first organisations still have equipment at home and on the move.

• Premises that hold information or equipment have defined perimeters and entry controls (7.1, 7.2)
• Clear desk and clear screen rules are in place and followed (7.7)
• Laptops, phones and other equipment used outside the office are protected (7.9)
• Storage media and equipment are wiped or destroyed securely before reuse or disposal (7.10, 7.14)

Annex A: Technological controls

A sample from 8.1 to 8.34. The free tools check the public side of some items; internal systems need your own evidence.

• User devices are managed, encrypted and protected against malware (8.1, 8.7)
• Privileged access is limited to named people, and multi-factor authentication protects important systems (8.2, 8.5)
• Technical vulnerabilities are tracked and fixed within set timescales, and no internet-facing system runs unsupported software (8.8)Free tool: End-of-life software checker
• Secure configuration baselines are defined and applied, including for public websites (8.9)For public sites, the baseline usually covers HTTP security headers, cookie flags and HTTPS redirects.Free tool: Website security checker
• Backups are taken to an agreed schedule and restores are tested (8.13)
• Logging and monitoring are in place, and alerts are reviewed and followed up (8.15, 8.16)
• Only the services that need to be reachable from the internet are reachable (8.20)The exposed services check works on domains you have verified.Free tool: Exposed services checker
• Cryptography rules are defined, and public services follow them for TLS versions, ciphers and certificates (8.24)Free tool: SSL/TLS checker
• Security requirements are set for each application, including the HTTP security headers it sends (8.26)Free tool: HTTP security headers checker
• Software is developed under a secure development life cycle, with secure coding, security testing and change control (8.25, 8.28, 8.29, 8.32)