ISO 27001 checklist for IT and software companies

This checklist splits an ISO 27001 project for an IT or software company into five phases, with the clause or Annex A control from the 2022 version noted after each point. Clauses 4 to 10 are mandatory. The Annex A points are examples that often come out of the risk assessment at software companies, not a fixed list.

The numbers refer to the standard; the descriptions are in our own words. Keep the standard itself at hand when you tick a point off.

Phase 1: foundation

1. Context recorded. Internal and external issues that affect your security, such as dependence on a single hosting provider or growth into the healthcare market. Also consider whether climate change is relevant. (4.1)
2. Interested parties and their requirements. Customers, data processing agreements, regulators, customers' certification requirements. (4.2)
3. Scope set. Which services, systems, teams and locations, what is deliberately out of scope, and the interfaces with the outside. (4.3)
4. Management on board. A board member who owns it and frees up time and budget. (5.1)
5. Information security policy approved. Short, signed off by management and communicated. (5.2)
6. Roles assigned. ISMS owner, risk owners, who handles incidents. (5.3, A 5.2)

Phase 2: risks and choices

7. Risk assessment method. How you estimate likelihood and impact, and when a risk is acceptable. (6.1.2)
8. Risks assessed. In business language, with an owner for each risk. Think of customer data in production, a leaked API key, an outage of the cloud region, a vulnerable dependency. (6.1.2, 8.2)
9. Risk treatment plan. For each risk: reduce, avoid, transfer or accept, approved by the risk owner. (6.1.3, 8.3)
10. Statement of Applicability. All 93 Annex A controls reviewed, with for each one apply or exclude, the reason and the status. (6.1.3)
11. Objectives. A few measurable goals, for example "critical vulnerabilities fixed within an agreed period". (6.2)
12. Changes planned. How you plan changes to the ISMS itself, such as a new office or a second product entering the scope. (6.3)

Phase 3: implementation

People and organisation

13. Competence and training. Security training at onboarding and periodically, with evidence of completion. (7.2, 7.3, A 6.3)
14. Screening and confidentiality. Arrangements when people join and leave. (A 6.1, 6.2, 6.5, 6.6)
15. Document control. Versions, owner, approval and a fixed location. (7.5)
16. Communication. Who reports what to whom, internally and to customers. (7.4)

Suppliers and cloud

17. Supplier register. Hosting, sub-processors, SaaS tools, with assessment and contractual arrangements. (A 5.19 to 5.22)
18. Cloud services. How you select, configure, monitor and exit cloud services. (A 5.23)

Access

19. Access policy and access reviews. Who can access what, with periodic checks and prompt removal when people leave. (A 5.15 to 5.18)
20. Privileged access and authentication. Minimal admin rights and strong authentication on production and source code. (A 8.2, 8.5)

Development and operations

21. Secure development. Security requirements, code reviews, secure coding and testing in the development pipeline. (A 8.25 to 8.29)
22. Separate environments and change management. Development, test and production kept apart, changes through a set process, no real customer data in test without safeguards. (A 8.31 to 8.33)
23. Vulnerabilities and configuration. Dependencies and systems kept up to date, configurations recorded. (A 8.8, 8.9)
24. Logging and monitoring. What you log, for how long, and who looks at it. (A 8.15, 8.16)
25. Backups. Made, encrypted where needed and periodically restored as a test. (A 8.13)
26. Endpoints and remote working. Laptops managed and encrypted, agreements on working remotely. (A 8.1, 6.7)

Incidents and continuity

27. Incident process. Reporting, assessing, responding, learning and preserving evidence, including notification duties towards customers and regulators. (A 5.24 to 5.28, 6.8)
28. Continuity. How your platform and services keep running during an outage, and whether that has been tested. (A 5.29, 5.30)
29. Laws and regulations. An overview of legal and contractual requirements, including the GDPR. (A 5.31, 5.34)

Phase 4: evaluation

30. Measuring. What you measure to know whether the ISMS works, and who reviews the results. (9.1)
31. Internal audit. A programme that covers the whole ISMS over time, carried out by someone who is not auditing their own work. (9.2)
32. Management review. Fixed topics, recorded decisions and actions. (9.3)
33. Nonconformities followed up. Cause, correction and a check that it worked. (10.2)

Phase 5: certification and upkeep

34. Certification body chosen. Accredited for ISO/IEC 27001, quotes compared across the whole cycle.
35. Stage 1 audit prepared. Scope, policy, risk assessment, Statement of Applicability, internal audit and management review ready.
36. Stage 2 audit prepared. Evidence per control easy to find, the right people available for interviews.
37. Annual cycle planned. Risk review, internal audit, management review and improvement, ahead of every surveillance audit. (10.1)

How to use the checklist

Work through the phases in order, but expect to go back. An internal audit in phase 4 almost always produces points to adjust in phase 3, and that is exactly what an auditor wants to see. Only tick a point off when there is evidence: an approved document, a completed register or a test carried out, with a date.

An explanation of the standard is in the article on ISO 27001, and the course of the audit in the article on certification.