Guide
Required Documents for an ISMS (ISO 27001): Documented Information and Records, Organized
ISMS documentation is easier to plan when you split it into two layers: what the standard explicitly requires clause by clause, and what most organizations end up writing in order to operate the Annex A controls. The first layer is a countable list. The second grows or shrinks with your size and risk profile. Mixing the two is how small teams end up with a pile of policies nobody updates. This guide separates them into tables, then covers the difference between documents and records, how to structure the hierarchy, and the version and approval requirements that apply to the documents themselves.
Published: Last updated:
Think in two layers: required, and required in practice
Clauses 4 to 10 of ISO/IEC 27001:2022 state in specific places that information shall be available or retained as documented information. That is layer one: the documented information the standard explicitly requires. Its absence is something an audit can raise directly.
Layer two consists of the policies and procedures written to explain how Annex A controls actually run. The standard never names a specific policy, but if nothing defines how access rights are granted and reviewed, it is hard to show the control is operating. For the overall path to certification, see how ISO 27001 certification works.
Documented information the standard explicitly requires
Mapping items to clause numbers lets you check gaps mechanically. The names below are the wording of the standard; your own file names can differ. Combining several items into one file, or splitting one across several, is generally acceptable as long as the requirement is met.
| Clause | Documented information | Purpose and key points |
|---|---|---|
| 4.3 | Scope of the ISMS | Organizations, sites, activities and systems in scope, and the boundary with what is out |
| 5.2 | Information security policy | Approved by top management; frames objectives and commitment to improvement |
| 6.1.2 / 6.1.3 | Risk assessment and risk treatment process | Criteria for acceptance and performance, method, and ownership |
| 6.1.3 d) | Statement of Applicability (SoA) | Applicability of each Annex A control, justification for inclusion or exclusion, implementation status |
| 6.2 | Information security objectives | Measurable, with a plan naming who does what and by when |
| 7.2 | Evidence of competence | Training, qualifications and experience supporting each role |
| 7.5 | Documented information required by the standard and determined as necessary by the organization | Defines the set of documents under control |
| 8.1 | Documented information on operational planning and control | Kept to the extent needed for confidence that processes ran as planned |
| 8.2 | Results of risk assessments | The risk register and evaluation as of the assessment date |
| 8.3 | Results of risk treatment | Selected treatments and their implementation status |
| 9.1 | Results of monitoring, measurement, analysis and evaluation | What was measured, when, and by whom |
| 9.2 | Internal audit programme and audit results | Both the plan (frequency, scope, criteria) and the reports |
| 9.3 | Results of management review | How each input was handled, plus decisions and directions |
| 10.1 / 10.2 | Nature of nonconformities, actions taken, and results of corrective action | Event, immediate action, root cause, prevention, and effectiveness check |
The risk assessment process and its results usually take the longest to produce. That step is covered separately in ISMS risk assessment.
Policies and procedures commonly built around Annex A controls
The table below reflects what IT companies of up to roughly 100 people typically maintain. These need not be separate files; many organizations keep a single security management policy with chapters. The useful rule is to avoid putting things with different revision rhythms in the same file.
| Area | Typical policy or procedure | Matching records |
|---|---|---|
| Asset management | Asset management policy, acceptable use | Asset inventory, removal requests |
| Information classification | Classification and handling rules, labelling procedure | Reclassification records |
| Access control | Access control policy, privileged account procedure | Grant and revoke requests, access review records |
| Supplier management | Supplier and outsourcing policy | Supplier assessments, confidentiality agreements, annual reviews |
| Incident management | Incident response procedure, escalation paths | Incident records, response reports, retrospectives |
| Business continuity | Continuity and ICT readiness procedure | Exercise records, recovery test results |
| Change management | Change procedure, release approval criteria | Change requests and approvals |
| Secure development | Development standards, code review criteria, environment separation | Review records, test results, vulnerability handling |
| Logging | Rules for log capture, protection and retention | Monitoring output, alert handling records |
| Physical and people | Entry control, joiner and leaver procedures | Entry logs, agreements, asset return checklists |
Documents versus records
Older editions separated documents from records. ISO/IEC 27001:2022 uses the single term documented information for both. In day-to-day work, though, the distinction is still worth keeping.
- Documents (policies, procedures, forms) define what will be done; version control and approval dominate
- Records (requests, minutes, review results, audit reports) evidence what actually happened; protection against alteration dominates
- In the wording of the standard, the first roughly maps to maintain and the second to retain
- A blank form is a document; the same form once filled in is a record. That split keeps the register tidy
The hierarchy, and how to keep it small
The common structure is policy, then procedures, then work instructions, then forms and records. Higher levels change rarely and are approved at a senior level; lower levels sit close to the work and change often. When that relationship breaks, every minor operational tweak needs executive approval and updates stall.
- Keep a single top-level policy. Add topic policies only when the audience or approver genuinely differs
- Keep procedures at the level of who does what and how often; push screen-level steps down to work instructions
- Do not embed tool-specific steps in a policy, since they change every time the tool does
- Reference existing internal rules such as employment regulations instead of copying their text
- Do not commit to a frequency you cannot sustain, such as a full monthly inventory of every asset
Requirements on document control itself (7.5.2 and 7.5.3)
How you manage documents is itself a requirement. Clause 7.5.2 covers creation and update: identification such as title, date, author and reference number; format and media; and appropriate review and approval. Clause 7.5.3 covers control: availability where and when needed, and adequate protection.
| Aspect | What tends to be checked | Example practice |
|---|---|---|
| Identification | Title, document number and effective date are visible | Fix the number and effective date in the header |
| Version | The current version is unambiguous | Keep a revision table with version, date, reason and approver |
| Approval | An authorized person approved it | Define approver roles in the document control policy |
| Distribution and access | The right people can read it and others cannot | Set sharing permissions and re-check the audience periodically |
| Protection | Unintended change or deletion is prevented | Restrict edit rights on the master; publish a read-only copy |
| Obsolescence | Superseded versions cannot be used by mistake | Mark old versions as withdrawn and move them to a separate area |
Using templates, and the records auditors look at closely
Templates are a reasonable starting point, but they arrive full of assumptions. Role titles you do not have, meetings you do not hold and technologies you do not use tend to survive into the submitted version, where they surface as contradictions against your records. As a general practice, reviewing every stated frequency and role name against reality immediately after adopting a template saves rework later.
Auditors also spend more time on evidence that a document was followed than on the document itself. The records below are where gaps in coverage or blank approval fields tend to show up.
- Training and competence records: date, participants, content, and confirmation of understanding
- Access review records: systems covered, reviewer, and what was corrected
- Internal audit plans and reports, including how auditor independence was assured
- Management review minutes: how each input was handled, and the decisions taken
- Incident records, including minor events; a long run of zero often invites questions about detection
- Supplier assessment and periodic review records
Moving version control and approval into a tool
The list itself can live in a word processor or a spreadsheet. The load comes from tracking versions, approvals, review deadlines and the links between documents and records by hand. When documents, records, risks, controls and the Statement of Applicability sit in separate files, checking whether one revision propagated becomes a manual read-through.
Moving that bookkeeping into a tool leaves approval history and versions in place automatically and makes missed review dates easier to spot. If you first want to see which documents you are missing, the ISMS readiness self-check is a reasonable place to start.
Frequently asked questions
- What is the minimum number of documents for an ISMS?
- There is no fixed answer. The documented information the standard explicitly requires is a limited list, but how many files you split it into is up to you. IT companies of around 100 people often end up with one policy, a handful of procedures and a dozen or so forms, though scope and outsourcing change the picture.
- Is it acceptable to manage documents in a word processor or spreadsheet?
- The standard does not specify media or format, so the file type itself is generally not the issue. What is examined is whether the current version is unambiguous, whether approvals are recorded, and whether unauthorized change or deletion is prevented. If you put version numbers in file names, define how superseded files are handled.
- Is an ISMS manual mandatory?
- A single volume called a manual is not required by the current standard. What is required is the documented information named in each clause, and you may gather it into one book or keep it as separate documents. An overview document helps internal communication, but it is generally treated as optional.
- Are electronic approvals accepted?
- The standard does not restrict the method of approval, so electronic approval is generally not rejected. What matters is being able to show later who approved which version and when, and that the approver matches what your document control rules say. Whether to also require a seal or signature is an internal control decision.
- How often should documents be reviewed?
- No frequency is prescribed. Many organizations run an annual review and add ad hoc reviews after reorganizations, significant incidents, major system changes, or changes in legal and contractual requirements. Whatever you commit to should be a frequency your records can actually evidence.
Check where your ISMS stands in 5 questions
Answers are processed only in your browser and are never sent from this app.
Start the self-checkThis article is for general information only and does not guarantee any audit outcome or certification. Schemes and costs change, so confirm the latest details with certification bodies.
Related articles
The ISO 27001 (ISMS) Certification Process and Timeline: 8 Steps from Kickoff to Registration
ISO 27001 (ISMS) certification in eight steps from kickoff to registration, why it usually takes 6 to 12 months, and what Stage 1 and Stage 2 audits check.
How to Run an ISMS Risk Assessment: 6 Steps from Asset Inventory to the Statement of Applicability
A practical six-step ISO/IEC 27001 risk assessment: set risk criteria, inventory assets, analyse and evaluate risk, then treat it via the SoA.
ISO 27001:2022 Annex A Controls: All 93 Across 4 Themes, and What Changed from 2013
All 93 Annex A controls of ISO/IEC 27001:2022 by theme: 37 organizational, 8 people, 14 physical, 34 technological, plus the 11 new controls and SoA use.