ISO 27001:2022 requires two kinds of documented information: information the standard explicitly calls for, and information your organisation determines is necessary for an effective ISMS. It also requires certain retained evidence to show that processes occurred and produced results. The practical goal is not to build a large policy library; it is to keep required and useful information controlled. Current, available, protected, and proportionate.
What “documented information” means in ISO 27001
ISO/IEC 27000 defines documented information as information an organisation needs to control and maintain, together with the medium containing it. It can be in any format, on any medium, and from any source, including ISMS process information, operating documentation, and evidence of results such as records (ISO/IEC 27000:2023).
In practice, documented information can include:
- policies, procedures, plans, and standards
- risk registers, Statements of Applicability, and treatment plans
- logs, reports, approvals, tickets, review records, and audit evidence
- externally originated information, where needed for planning and operating the ISMS
The thing is, that last point matters: “documented information” is broader than formal documents. A risk treatment approval in a controlled workflow may be documented information. So may a training record, internal audit report, management review output, or monitoring result.
A useful distinction is:
- Maintained information: information kept current for ongoing use, such as the ISMS scope or information security policy.
- Retained evidence: information kept to prove something happened or produced results, such as competence evidence, audit results, or corrective-action records.
- Organisation-determined documentation: additional information the organisation decides is necessary for ISMS effectiveness.
ISO 27001 does not require a standalone policy, procedure, or record for every activity.
Required vs recommended: what actually has to be documented?
ISO 27001:2022 requires documented information in specific clauses, Clause 7.5.1 also says the ISMS must include documented information the organisation determines is necessary for effectiveness. The appropriate extent can vary with the organisation’s size, activities, process complexity, and personnel competence (IS/ISO/IEC 27001:2022).
Use three labels when building your documentation set:
- Required by ISO 27001: explicitly required to be available as documented information.
- Required as retained evidence: required to demonstrate results or process operation.
- Recommended where needed: useful if it improves consistency, accountability, or evidence, but not automatically ISO-mandated.
Annex A should be handled carefully. It is used in the risk-treatment process: organisations determine necessary controls, compare them with Annex A, and record treatment decisions in the Statement of Applicability. Annex A is not a universal “one document per control” library, but selected control wording may call for documented rules, procedures, or other information where applicable (IS/ISO/IEC 27001:2022).
| Clause | Required information or record | Example artefact | Typical owner | Control expectation | Audit evidence |
|---|---|---|---|---|---|
| 4.3 | ISMS scope available as documented information | ISMS scope statement | ISMS owner | Approved, current, and clear on boundaries | Approved scope, version history, review record |
| 5.2 | Information security policy available as documented information | Information security policy | Senior management / CISO | Approved, communicated, available as appropriate | Approved policy, publication location, acknowledgement or communication record |
| 6.1.2 | Retained documented information on the risk-assessment process | Risk assessment methodology | Risk owner / ISMS manager | Defined and controlled method for assessing risk | Approved methodology, change history |
| 6.1.3 | Retained documented information on the risk-treatment process, including Statement of Applicability and risk-treatment plan outputs | SoA and risk treatment plan | Risk owner / control owners | Treatment decisions recorded and controlled | SoA approval, treatment plan, control owner updates |
| 6.2 | Information security objectives available as documented information; retained documented information on objectives | Security objectives and measurement plan | Leadership / ISMS owner | Objectives documented, measurable where applicable, and reviewed | Objectives register, progress review, updates |
| 7.2 | Appropriate documented information as evidence of competence | Training record, role competence evidence | HR / team leads | Evidence retained for relevant competence | Training records, certifications, role assessments |
| 7.5 | Required and organisation-determined ISMS documented information, controlled | Documented information register or controlled repository | ISMS manager | Identification, approval, access, change, retention, and disposition controlled where applicable | Register, repository permissions, approval and version records |
| 8.1 | Documented information to the extent necessary to have confidence that processes occurred as planned | Operational procedure evidence, workflow records | Process owners | Evidence proportionate to process criticality | Completed workflow, ticket trail, operational log |
| 8.2 | Retained documented information on risk-assessment results | Risk register | Risk owner | Assessment results retained and traceable | Risk register snapshot, review history |
| 8.3 | Retained documented information on risk-treatment results | Treatment progress record | Control owners | Treatment implementation and results retained | Status updates, implementation evidence, approvals |
| 9.1 | Documented information available as evidence of monitoring, measurement, analysis, and evaluation results | KPI report, control monitoring output | ISMS owner / control owners | Results retained and reviewable | Monitoring report, dashboard export, review notes |
| 9.2 | Documented information available as evidence of audit-programme implementation and audit results | Internal audit programme and reports | Internal audit owner | Audit programme and results retained | Audit plan, audit report, findings log |
| 9.3 | Documented information available as evidence of management-review results | Management review minutes and actions | Senior management / ISMS owner | Review outputs retained and actioned | Meeting record, decisions, action tracker |
| 10.2 | Documented information available as evidence of nonconformities, actions, and corrective-action results | Corrective action record | ISMS owner / process owner | Nonconformities and action results retained | NCR, root-cause analysis, closure evidence |
This matrix is not a prescribed set of standalone documents. For example, one controlled risk management record may cover methodology, assessment results, treatment decisions, and review history if it remains suitable, protected, available, and auditable.
How Clauses 7.5.1, 7.5.2, and 7.5.3 differ
Clause 7.5 is the control model for documented information. It explains not just what the ISMS includes, but how that information should be created, updated, and controlled (IS/ISO/IEC 27001:2022).
Clause 7.5.1: what the ISMS must include
Clause 7.5.1 requires the ISMS to include:
- documented information required by ISO 27001
- documented information the organisation determines is necessary for ISMS effectiveness
This is the basis for proportionate documentation. Or, more accurately, it is one of the main parts of that basis. A small organisation with simple processes may need fewer procedural documents than a larger organisation with distributed teams, complicated suppliers, or high-risk operations. The test is not “how many documents do we have?” but “can we operate and evidence the ISMS effectively?”
Clause 7.5.2: creation and updating
Clause 7.5.2 applies when documented information is created or updated. It requires suitable:
- identification and description, such as title, date, author, owner, or reference number
- format and media, such as document, spreadsheet, ticket, wiki page, or workflow record
- review and approval for suitability and adequacy
For example, a risk treatment plan should show enough metadata for users and auditors to know which version is current, who owns it, who approved it, and when it should be reviewed.
Clause 7.5.3: ongoing control
Clause 7.5.3 is about keeping documented information controlled after it exists. It must be available and suitable for use where and when needed, and adequately protected. Where applicable, controls should cover distribution, access, retrieval, use, storage, preservation, change control, retention, and disposition.
This is where many ISMS documentation sets fail. A policy may exist, but if an outdated copy is still being used, approvals are missing, or access permissions are uncontrolled, the information is not well controlled.
Externally originated documented information should also be identified and controlled when the organisation determines it is necessary for planning and operating the ISMS. Examples may include contractual security requirements, supplier documentation, or regulatory material; not every external document needs to be registered by default.
A lean documented information register: fields to include
ISO 27001 does not require a documented information register. It requires controlled documented information. A register is simply a controlled way to show what exists, who owns it, where it lives, and how it is controlled.
Possible fields include:
| Field | Why it helps |
|---|---|
| Title | Identifies the documented information clearly |
| ID/reference | Provides a stable reference for audits, links, and change control |
| Owner | Assigns accountability for accuracy and review |
| Version | Shows which copy is current |
| Approval status | Distinguishes drafts from approved information |
| Approver | Shows authority for release or use |
| Review date | Supports periodic review and currency |
| Location | Points users and auditors to the controlled source |
| Access group | Shows who can view or change the information |
| Classification | Helps determine protection requirements |
| Retention period | Defines how long evidence or records should be kept |
| Disposal method | Supports controlled disposition where applicable |
| Related control/process | Links information to ISMS processes or Annex A controls |
The register can be lightweight. A controlled repository, spreadsheet, wiki, document management system, or GRC environment can work if it can demonstrate the applicable Clause 7.5 controls: ownership, approval, access, versioning, retention, and change history where needed.
Avoid turning the register into a second document library. It should point to the controlled source, not duplicate the content.
What audit-ready document control looks like
Audit-ready document control means you can demonstrate that documented information is approved, current, available to the right people, protected from unintended changes, retained where needed, and disposed of appropriately.
Examples of evidence that can help demonstrate control include:
- approval records for policies, scope, objectives, methodologies, or plans
- version history showing changes and current status
- review logs or review dates
- access permissions for repositories or records
- repository location showing the controlled source
- retention settings or retention records
- change requests, tickets, or workflow approvals
- disposal records, where disposition is applicable
The suitable level of evidence depends on the ISMS, document type, risk, and audit scope. A high-risk operational procedure may need tighter approval and change control than a low-risk internal guidance note.
Common document-control issues include:
- outdated policies still available for use
- missing approval or review evidence
- unclear document owners
- uncontrolled copies in personal drives or chat threads
- access that is too broad or too restrictive
- retained evidence with no defined retention period
- recommended documents being treated as if ISO requires them
The last issue creates avoidable maintenance burden. If you create a procedure, register, or policy, you also create an obligation to keep it accurate and controlled, and someone has to keep doing that work.
How much ISO 27001 documentation is enough?
Enough documentation is the smallest controlled set that satisfies ISO 27001 requirements, demonstrates required results, and helps the ISMS operate consistently.
Use these decision rules before creating another document:
- Is it explicitly required by ISO 27001? If yes, document or retain it.
- Is it needed to show evidence of a required process or result? If yes, retain suitable evidence.
- Is it necessary for consistent ISMS operation? If yes, document the process, rule, or responsibility at the level users need.
- Would the absence of documentation create ambiguity, control failure, or audit friction? If yes, document the decision or process.
- Can existing evidence serve more than one requirement? If yes, consolidate rather than duplicate.
Lean does not mean informal. It just means documented information is controlled, current, useful, and proportionate. Extra documents add maintenance obligations; if they are not kept current and controlled, they can create inconsistency with actual practice.
Turning documented information into an operating practice
ISO 27001 documented information is not a one-time document project. It needs ownership, review cadence, access control, evidence retention, and change control to stay aligned with how the organisation actually works.
Start by mapping required documented information, then add only the organisation-determined documentation needed for effective operation. Keep the register simple, maintain a controlled source of truth, and make review and approval part of normal ISMS work.
For teams managing recurring audits, distributed control owners, or multiple compliance obligations, tools such as Ciphrix can support a more operational approach to ownership, evidence, and control maintenance. The important point is the operating model: documentation should reflect real controls, not sit apart from them.