ISO 27001 Document Requirements: Complete Guide to Mandatory ISMS Documentation
Table of Contents
A policy says supplier access is reviewed every month. Fine. Where is last month's review, and what changed because of it? The answer tells you more about an ISO 27001 program than the policy's layout ever will.
Documentation is supposed to make those answers available to the people who need them. It is not a competition to see who can produce the largest folder. Below, I separate the material ISO 27001:2022 requires from the extra documents that tend to earn their keep.
What Is ISO 27001 and Why Documentation Matters
An ISMS is the complete system of policies, procedures, and controls an organization relies on to manage information security risk, and none of it means much if it can't be inspected by someone outside the organization. That's really the whole reason ISO 27001 insists on mandatory documents in the first place. A certification body needs to evaluate actual documented information rather than simply trust that an organization has its act together.
The standard replaced “documents and records” with “documented information” a few revisions ago. It gives organizations more flexibility in what counts as evidence. A wiki page can serve the same purpose as a PDF, as long as someone is responsible for keeping it current and changes are controlled. A good document management system helps keep that information accessible, organized, and up to date. The format was never really the point.
Plenty of ISO 27001 shops still keep a locked folder of PDFs nobody's opened since the last audit, which technically satisfies the letter of the requirement and does nothing for the spirit of it.
Mandatory Documents Required by ISO 27001:2022 (Clauses 4–10)
Organizations have to maintain certain mandatory documents and records across Clauses 4–10, such as the main parts of the ISMS, including its scope, information security policy, risk assessment and treatment, security objectives, internal audits, management reviews, and corrective actions.
Organizations can choose the format that works for them as long as the required information is documented, kept up to date, and available as evidence during an audit. This is where compliance automation can help, particularly when teams need to track updates, maintain evidence, and prepare for recurring reviews.
ISMS Scope Document: Defining Your Boundaries (Clause 4.3)
This is one of the most important and mandatory steps in data protection. Defining boundaries precisely determines what the organization protects and what remains outside the system.A cloud service may be in scope, but what about the office system its support team uses for the same customer data?
Sometimes an exclusion has a sound reason. Put that reason where the next reviewer can find it. An unexplained gap in the scope will come back as a question in the risk assessment.
Information Security Policy: Setting the Direction (Clause 5.2)
This is management's commitment, not an IT department's filing exercise. The policy should fit the organization, support its security objectives and commit to applicable requirements and continual improvement. It needs to be available and communicated.
Try asking a director what the policy changed. They needn't quote it, but they should be able to explain the priorities behind it. If the only answer is “we signed it for the audit,” the document needs another conversation with leadership.
Risk Assessment and Risk Treatment Plan Documentation (Clauses 6.1.2 & 6.1.3)
In this document, organizations identify, analyze, and evaluate risks before assigning them a score, while also defining how the results are compared. State what counts as acceptable and how results can be compared. Then retain the assessments carried out under Clause 8.2. Without common criteria, one reviewer's “high” may be another's “medium.”
The Risk Treatment Plan maps identified risks to specific controls and actions. Being aware of a risk isn't a treatment plan on its own. Knowing exactly who's fixing it and by when is what turns awareness into something an auditor can actually verify against the record.
Statement of Applicability: Linking Risks to Annex A Controls
The Statement of Applicability (SoA) is the mandatory document listing all 93 Annex A controls, with a justification for including or excluding each one. It also shows whether selected controls are implemented. Annex A controls are the catalog of 93 security controls, grouped into four themes, that organizations evaluate during risk treatment.
The risk assessment feeds the SoA. With the contractor example, you should be able to move from the access risk to the treatment decision, then to the selected controls.
Contracts and other requirements can influence that choice too. “N/A” is not a useful explanation for an exclusion; write down why the control does not apply.
Information Security Objectives and How to Document Them (Clause 6.2)
“Improve awareness” is closer to a slogan than an objective anyone can measure. Security objectives need to be measurable and reviewed on some kind of schedule, not vague aspirational sentences added right before the audit purely for appearances.
“Cut phishing click-through by 15% this year” gives you something concrete to document, track, and review.
Training records should show that training actually took place. An LMS completion log or sign-in sheet is usually enough to provide that evidence.
Operational documentation should show that controls work in practice. Auditors may check change logs, incident tickets, or vendor risk assessments to confirm that actual processes match the policy.
Competence, Awareness, and Communication Records (Clauses 7.2–7.4)
Under Clause 7.2, keep evidence that people doing security-relevant work can do it. A training certificate might help. For the person responsible for recovery, evidence of a completed restore can say more than an attendance sheet.
Awareness under Clause 7.3 concerns the policy and each person's part in the ISMS. Clause 7.4 concerns what must be communicated, by whom, to whom, when and how.
Induction notes and relevant notices may help show this happened. Neither clause means every organization needs a separate log for every message it sends.
Operational Planning and Control Documentation (Clause 8.1)
A change ticket can show approval and outcome; a calendar invitation shows only that a meeting was arranged. Under Clause 8.1, keep enough information to have confidence that planned processes ran.
Account for planned changes, unintended changes and relevant work done by external providers.
Clauses 8.2 and 8.3 also require retained results of risk assessment and treatment. If supplier access is meant to be checked monthly, keep the completed review and any follow-up. A recurring reminder does not show which accounts were removed.
Internal Audit Program and Records (Clause 9.2)
Organizations are expected to conduct internal audits regularly. It is crucial to verify whether the ISMS meets the requirements of the organization and the standards.
Good records management for compliance also makes it easier to retain the audit trail and retrieve evidence when it is needed.
I would compare the program with the scope before the next audit cycle. Does one department keep disappearing from the schedule? A tidy report from an easier area does not answer that question.
Management Review: What to Document (Clause 9.3)
Top management reviews the ISMS at planned intervals and retains the results. The discussion covers required inputs such as performance, monitoring and audit findings, changes affecting the ISMS, risks and opportunities for improvement. Record decisions, actions and owners.
Minutes do not need to reproduce the meeting.
They do need to answer a question six months later: what did management decide about the rise in supplier incidents? “Discussed” is rarely enough.
Corrective Action and Non-Conformity Records (Clause 10.2)
A non-conformity just means you failed to meet one of the standard's requirements, and it kicks off corrective action. Certification bodies dig into this part harder than almost anything else, because closing a non-conformity is where you find out if a company actually fixes things or just writes down that they will.
Some companies close the same one three times running. Honestly, that's worse than admitting the first fix didn't work and trying something else.
Annex A Documentation: Controls and ISO 27002 Implementation Guidance
Annex A groups its controls into organizational, people, physical and technological themes. Some selected controls require supporting information. An asset inventory, for example, may be needed to implement control A.5.9. Whether a particular procedure is necessary depends on the controls chosen and how they operate.
ISO/IEC 27002 provides implementation guidance for the Annex A controls; ISO 27001 remains the requirements standard used for certification. Use the guidance to design a workable process. One maintained access procedure can cover several related controls. Ninety-three separate procedures would give the team ninety-three documents to keep current.
Non-Mandatory Documents Worth Implementing
An incident runbook is valuable when someone needs a supplier contact at two in the morning. An asset inventory makes a risk conversation less abstract. A document register can prevent three versions of the same policy from circulating.
What auditors are ultimately checking for, across every clause, is consistency between what a policy claims and what the records actually show happened.
These are not all universal standalone requirements of Clauses 4–10. A selected Annex A control, contract or other obligation may still make the information necessary. My test is whether somebody will use the document and take responsibility for updating it.
ISO 27001:2022 vs. 2013: What Changed in Documentation Requirements
Annex A changed from 114 controls in 14 categories to 93 controls in four themes. Some were merged or renamed, and 11 new controls were introduced, including threat intelligence and security for cloud services. Clauses 4–10 changed much less.
A useful 2013-era document library does not need to be rebuilt simply because the numbering changed.
The 2022 arrangement can reduce duplicate documentation; it does not remove the need for evidence. Map old controls to the new SoA, consider the new controls against current risks and update documents where decisions or practices actually changed.
Preparing Your Documentation for Certification Audit
A certification body evaluates documented information and samples how work is done. Pick one meaningful risk and follow it through assessment, treatment, SoA, operating control and recent evidence. Then start at a control and trace the reasoning backwards. Where do you have to guess?
Ask a colleague who did not organize the files to find the current policy, last internal audit result and one closed corrective action. The point where they get stuck is often more useful than another afternoon spent polishing a template.
Why KORTO
KORTO offers searchable logs for record access and changes, granular permissions, and retention workflows. Retention schedules can be aligned with the ISMS scope, while access records make questions such as “who had access to this policy on this date?” a quick lookup rather than a project.
KORTO is also ISO 27001 certified, so it has been through the same type of audit its customers are preparing for.
Getting the documentation side of ISO 27001 right is easier with a system built around evidence and traceability from the start. Talk to KORTO about certification-ready document management for your ISMS, or check KORTO’s pricing to see how it fits your organization.
5-Second Summary
ISO 27001 documentation is essential for demonstrating that information security policies, risk management processes, and controls work in practice. Maintaining the required ISMS documents and reliable audit evidence helps organizations achieve compliance, improve accountability, and prepare for certification. A structured document management system makes it easier to keep records current, trace decisions, and demonstrate ongoing security improvements.