Safeguard
Compliance•

ISO 27001 documents: the policies and records you actually need

A checklist of the documented information ISO 27001 requires, which items are policies and which are records, and the topic policies auditors expect.

Safeguard Security Team
4 min read

ISO 27001 requires a short list of documented information: scope, information security policy, risk assessment and treatment process and results, a Statement of Applicability, objectives, competence records, internal audit and management review results, and corrective actions. Annex A controls then add topic policies, such as access control, only where you apply them.

Clause numbers below follow ISO/IEC 27001:2022. The ISO page returned HTTP 403 when we fetched it and the standard is paid, so check clause references against your licensed copy. The structure is stable and widely documented: clauses 4 to 10 are mandatory, and Annex A lists 93 controls in four themes (organizational, people, physical, technological).

Which documents does the standard itself require?

  • Scope of the ISMS: 4.3; Document
  • Information security policy: 5.2; Policy
  • Risk assessment process: 6.1.2; Procedure
  • Risk treatment process: 6.1.3; Procedure
  • Statement of Applicability: 6.1.3; Document
  • Information security objectives: 6.2; Document
  • Evidence of competence: 7.2; Record
  • Other documented information you decide you need: 7.5.1; Varies
  • Operational planning and control: 8.1; Document or record
  • Risk assessment results: 8.2; Record
  • Risk treatment results: 8.3; Record
  • Monitoring and measurement results: 9.1; Record
  • Internal audit programme and results: 9.2; Record
  • Management review results: 9.3; Record
  • Nonconformities and corrective actions: 10.2; Record

Notice that most items are records produced by doing the work, not policies. A tidy policy folder with no records fails an audit.

What does Annex A add?

Annex A is a reference list. You decide which controls apply through your risk assessment and record that in the Statement of Applicability, with a reason for each exclusion. Applicable controls typically need a written rule and proof it operates. Common topic policies teams write:

  • Access control, including joiner, mover and leaver steps.
  • Acceptable use of information and assets.
  • Information classification and handling.
  • Supplier and cloud service security.
  • Incident management.
  • Business continuity and backup.
  • Secure development and change management.
  • Cryptography and key management.
  • Logging and monitoring.

Combine topics when your organization is small. Three clear pages beat nine copied templates nobody reads.

How do you keep documents honest?

  • Give each a version, owner, approval date and review date.
  • Write what you do, not what you wish. If the policy says quarterly access reviews, a dated review must exist each quarter.
  • Link each Statement of Applicability row to the policy and to a recent record.
  • Avoid copying template text that mentions systems you do not run.

What to do

  1. Write the scope statement first, naming locations, services and exclusions.
  2. Draft the information security policy with management, and approve it formally.
  3. Define the risk method (scales, acceptance threshold) before scoring any risk.
  4. Run the assessment and produce the risk treatment plan.
  5. Build the Statement of Applicability from that plan.
  6. Write only the topic policies your applicable controls need.
  7. Set a calendar for internal audit and management review, then hold both.

Quick check

How many policies does ISO 27001 require?

Only one policy is named in the main clauses: the information security policy. Other policies depend on which Annex A controls you apply.

Is the Statement of Applicability optional?

No. It is a required document listing controls, whether each applies, whether it is implemented and the reasons for exclusions.

How Safeguard helps automate this

Documents describe intent, and auditors test whether reality matches. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. That gives you time for the policy writing only people can do. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies, off by default with every category on Manual until you choose. Certification is granted by an independent certification body, not by Safeguard. Book a call to see it.

Sources

  • ISO: ISO/IEC 27001 (HTTP 403 on fetch; standard is paid)
  • Widely published summaries of the standard's clause structure, not independently confirmed from a fetched primary page

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.