ISO 27001 Documentation Requirements: 7 Must-Have Records

Getting your ISO 27001 documentation requirements right is one of the biggest hurdles organisations face on the path to certification. Miss a single mandatory record, and your audit grinds to a halt. Yet the standard itself isn’t exactly a step-by-step guide; it tells you what to document but leaves the “how” frustratingly open to interpretation. That ambiguity trips up even experienced teams. At TrustedIA, our ISO 27001 Subject Matter Experts have guided dozens of organisations through successful implementation and certification, so we’ve seen first-hand where documentation gaps cause the most damage.

This article breaks down the seven mandatory records you need for ISO 27001:2022 compliance. No filler, no guesswork, just a clear checklist you can use to prepare for your audit with confidence. If a document is required, you’ll know exactly why and what auditors expect to see.

1. ISMS scope statement

The ISMS scope statement is the foundation of your entire Information Security Management System. It tells auditors which parts of your organisation, processes, and assets fall under your security controls, and which sit outside them. Without a well-defined scope, every other item on your ISO 27001 documentation requirements checklist becomes harder to validate and defend when questioned.

What it proves in an ISO 27001 audit

Your scope statement proves you deliberately defined what you’re protecting and why. Auditors use it as their starting point, cross-checking that your risk assessments, controls, and policies all align with what you’ve declared in scope. If any of those elements cover areas outside your stated scope, or miss areas inside it, you’re looking at a nonconformity.

What to include in a clear scope statement

A solid scope statement covers three core areas:

• Organisational boundaries: the departments, sites, and legal entities included
• Information types: the categories of data you process, store, or transmit
• Technology and systems: the platforms, applications, and infrastructure in scope, including any exclusions and the reasoning behind them

How to define boundaries for cloud, remote work, and suppliers

You must explicitly address cloud-hosted services, remote working arrangements, and any third-party suppliers that handle your data. If a supplier processes sensitive information on your behalf, they influence your scope boundary and must be acknowledged in this document. Vague references to “external providers” are not sufficient.

Leaving supplier relationships undefined in your scope is one of the most common reasons organisations receive nonconformities at the stage two audit.

Common scope mistakes that trigger nonconformities

Auditors frequently flag scopes that are too broad and generic (“all IT systems”) or that quietly exclude business-critical processes to make certification feel simpler. Both approaches backfire when auditors conduct interviews and find the operational reality doesn’t match what’s written.

How often to review and when to update

Review your scope at least annually as part of your management review cycle, and immediately after significant changes such as acquisitions, new cloud platforms, or shifts in your supplier base. Record each review outcome in writing, even when no changes are made, so that auditors can see your scope remains deliberate and current rather than a document you set once and forgot.

2. Information security policy and objectives

Your information security policy is the top-level commitment that underpins every control in your ISMS. Without it, there is no documented link between your organisation’s leadership intent and the security activities your team carries out day to day.

What auditors expect to see

Auditors want a policy signed off by top management and clearly dated. It must reference your ISMS scope and commit to meeting applicable requirements alongside continual improvement.

What to include in the policy so it drives action

Your policy must set a clear overall security direction and be short enough that staff can actually read and absorb it. A strong policy covers:

• Leadership commitment to security and continual improvement
• A direct reference to your security objectives
• The scope and who the policy applies to

Support it with lower-level procedural documents that give staff operational detail to act on.

How to set measurable information security objectives

Security objectives must be measurable, monitored, and reviewed whenever circumstances change. Tie each one to a specific metric or target, such as reducing phishing click rates or achieving a patch compliance threshold within a defined timeframe.

Vague objectives without measurable targets are among the most consistent findings in ISO 27001 audits.

How to align objectives to risks and business priorities

Each objective should map to a risk or business driver identified in your risk assessment. This connection proves that your ISO 27001 documentation requirements form a coherent system rather than a collection of disconnected documents.

Common pitfalls and how to avoid them

Two frequent mistakes are setting objectives once and never revisiting them, and having a policy that leadership cannot explain during an interview. Review both documents at least annually and retain evidence of every review on file.

3. Risk assessment and treatment methodology

Your risk assessment and treatment methodology is the documented procedure that explains how you identify, analyse, and decide what to do about information security risks. This is a mandatory document under ISO 27001:2022, and auditors will read it to verify that your risk process is repeatable and consistent across your organisation.

What this methodology must cover in ISO 27001:2022

The methodology must describe your complete risk process from identification through to treatment decisions. It must cover how you identify risks, evaluate them, and select treatment options, so you can apply the process consistently every time.

Without a documented methodology, auditors cannot verify that your risk assessments follow a consistent, defensible process.

How to define risk criteria and scoring

Set out your risk acceptance criteria and scoring approach, including how you measure likelihood and impact, and the threshold that determines whether a risk requires treatment. Keep the scoring model simple enough that risk owners across the business can apply it without specialist support.

How to identify assets, threats, vulnerabilities, and impacts

Your methodology must explain how you catalogue information assets and link each one to relevant threats and vulnerabilities. Include how you assess the potential business impact of each combination so that risk scores reflect real operational consequences rather than abstract ratings.

How to decide risk owners and approval points

Assign a named risk owner to each identified risk, and document who has the authority to approve treatment decisions. This satisfies one of the core iso 27001 documentation requirements around accountability and decision traceability.

Evidence to keep showing the method works in practice

Retain version-controlled copies of the methodology, along with records of every review. This proves the document is actively maintained and not simply a leftover from your initial implementation phase.

4. Risk assessment and risk treatment records

Your risk assessment results and risk treatment records are separate from your methodology document. While the methodology explains how you run the process, these records demonstrate that you actually ran it and made deliberate, documented decisions for every identified risk.

What must appear in the risk assessment results?

Your results document must list every identified risk, along with the associated asset, threat, vulnerability, and impact. Include the likelihood and impact scores, along with the resulting risk rating, so auditors can trace each risk through your scoring model without gaps.

What a risk treatment plan needs to contain

The treatment plan must state which treatment option you chose for each risk: mitigate, accept, avoid, or transfer. It must also name the specific controls selected and set target completion dates for any outstanding actions.

How to link risks to controls and owners

Map each risk directly to its chosen Annex A control or custom control, and assign a named owner responsible for its implementation. This linkage sits at the core of several ISO 27001 documentation requirements and helps keep your audit trail coherent.

How to show decisions for risk acceptance, avoidance, and transfer

Record the rationale behind each decision, not just the outcome. If you accepted a risk, document who approved it and on what basis.

Unsigned or undated risk acceptance decisions are one of the most consistent nonconformity triggers at stage two audits.

Common auditor findings and how to prevent them

Auditors frequently flag risks listed without named owners or treatment plans that reference controls never actually implemented. Keep your records updated after every review cycle and retain version history with dates so the audit trail stays complete.

5. Statement of applicability

The statement of applicability (SoA) is the document that connects your risk treatment decisions to the 93 controls in Annex A of ISO 27001:2022. It declares which controls you apply, which you exclude, and why. Auditors treat it as a core reference point throughout both stage one and stage two reviews.

What the statement of applicability needs to show

Your SoA must list every Annex A control and state clearly whether you have included or excluded it. For each included control, record its implementation status and the justification for selecting it.

How to justify the included and excluded Annex A controls

Every exclusion needs a written rationale explaining why the control does not apply. Excluding a control without justification is one of the most direct ways to collect a nonconformity under the iso 27001 documentation requirements for this document.

Auditors will test exclusions during interviews, so your justifications need to reflect operational reality, not wishful thinking.

How to map controls to risks and legal obligations

Link each included control to the risk or legal obligation that drove its selection. This mapping shows your controls are deliberate and risk-driven, not selected at random.

How to keep the statement of applicability consistent with reality

Review your SoA whenever your risk treatment plan changes or new controls are introduced. An SoA that describes controls your team has never implemented creates immediate audit findings.

Common statement of applicability mistakes auditors flag

The two most consistent issues are controls marked as implemented while still in progress and exclusions copied from templates without review. Both signal to auditors that your ISMS lacks active management oversight.

6. Competence and awareness records

Your competence and awareness records demonstrate that the people operating your ISMS have the right skills and knowledge to do so effectively. Auditors check these records to confirm that people who understand your security controls run them.

What counts as acceptable competence evidence

Acceptable evidence includes role-specific training certificates, recognised qualifications, or documented relevant experience. A job title alone does not satisfy this requirement under the ISO 27001 documentation requirements framework, so tie every record to a specific security responsibility.

What to record for training, skills, and qualifications

Record the course title, completion date, and outcome for every training activity. Link each record to the specific role it covers, so auditors can match competence to responsibilities without asking.

Missing links between training records and job roles is one of the most frequent findings at stage two audits.

How to prove awareness beyond attendance

Attendance registers alone do not prove awareness. Use follow-up assessments or short quizzes to show that staff understood the content, then retain those results as documented evidence alongside any attendance records you already hold.

How to handle contractors and third-party access

Apply the same record-keeping standard to contractors and third parties who access your systems. Document their induction, training completion, and any access restrictions so auditors can verify that external parties meet your security baseline without exception.

Retention, refresh cycles, and audit readiness

Set a defined refresh cycle for each training type, typically annual for general awareness training, and retain records for the full duration of your certification cycle. Keep everything in a single accessible location so you can produce any record quickly when an auditor requests it.

7. Performance and improvement records

Your performance and improvement records demonstrate that your ISMS is actively managed, not merely documented on paper. Auditors check these records to confirm you consistently monitor, measure, and act on your security programme.

Monitoring and measurement results to keep

Retain the results of every measurement activity you defined against your security objectives, including metric outputs, dates, and reviewers. These records form a core part of the iso 27001 documentation requirements for demonstrating ongoing effectiveness. Keep at a minimum:

• Metric results tied to each security objective
• Review dates and reviewer names
• Trend comparisons across review cycles

Internal audit programme and internal audit results

Your internal audit programme must show planned audit dates, scope, and the criteria used. Keep the resulting audit reports alongside any raised findings so auditors can trace each issue through to its resolution.

Management review minutes and outputs

Record every management review with dated minutes that capture inputs discussed and decisions made. Include the names of attendees and any approved changes to resources or objectives during the meeting.

Undated or unsigned management review minutes signal to auditors that leadership oversight of the ISMS is informal rather than structured.

Corrective actions and evidence of effectiveness

Log each corrective action with a root cause, the action taken, and a target closure date. Retain evidence of effectiveness, such as retest results or follow-up audit findings, to show the action genuinely resolved the underlying problem.

Security event logs and how to evidence control operation

Keep security event logs that show your controls triggered and were reviewed. Link each log entry to the relevant control owner so auditors can verify consistent operational oversight across your full review cycle.

Next steps to get audit-ready

These seven records cover every core ISO 27001 documentation requirement category that auditors will check during stage one and stage two reviews. Each document builds on the last, so gaps in your scope statement will surface as inconsistencies in your risk records, and weak competence evidence will undermine everything else you’ve built. The good news is that you now know exactly where to focus your preparation time.

Start by auditing what you already hold against each section in this checklist. Identify missing documents, outdated records, and broken or incomplete links between documents. Then prioritise the gaps that carry the highest nonconformity risk: scope, SoA, and risk treatment records.

If you want expert support to close those gaps faster, TrustedIA’s ISO 27001 consultancy services can guide you from your current position through to a successful certification audit, without the guesswork.