ISO/IEC 27001 documentation: the mandatory documents and records, and what you can leave out

The documented information ISO/IEC 27001:2022 names

Clause 7.5.1 gives documented information two sources: what the standard requires, and what you decide the ISMS needs to be effective. Its note ties the extent to your size, activities, process complexity and people's competence, so the second is your judgement. The first is fixed, and short:

The standard never calls the Statement of Applicability or the treatment plan "documented information"; it requires you to produce the first and formulate the second, so both become controlled documents the certification body will want to see. The requirements guide covers what each clause requires beyond paperwork.

What the Annex A controls you select add

Clauses 4 to 10 bind every certified organisation; an Annex A control applies when your risk treatment needs it and your Statement of Applicability includes it. Several then require something in writing:

• 5.1 Policies for information security: topic-specific policies beside the main one, approved by management, communicated, acknowledged by the people concerned and reviewed at planned intervals and on significant change.
• 5.9 Inventory of information and other associated assets: a maintained inventory, with owners.
• 5.10 Acceptable use of information and other associated assets: documented rules of use and handling procedures.
• 5.31 Legal, statutory, regulatory and contractual requirements: those requirements and your approach to them, documented and kept current.
• 5.37 Documented operating procedures: procedures for information processing facilities, available to those who need them.

The standard does not say which topics need their own policy. In a 50-person firm they are usually access control, acceptable use, supplier and cloud security, incident management, backup and remote working, plus secure development for software companies; the Annex A guide explains each theme.

Documents and records: the difference auditors test

The standard uses one term for both, so the split is made by purpose. A document states intent or method, such as the scope, a policy or a procedure, and is meant to change: each change is reviewed, approved and versioned, and the old version withdrawn. A record states what happened, such as a risk assessment result, an access review or an audit report, and is never edited; a mistake is corrected by a new, traceable entry.

Do not infer the category from the standard's verbs. The 2022 text asks you to "retain" information about your risk assessment process, a living document, and to make audit and review results "available as evidence", which are records.

Clauses 7.5.2 and 7.5.3 set the controls: identification, format and media, review and approval, availability where needed, protection of confidentiality and integrity, access, storage, version control, and retention and disposition. External documents the ISMS relies on are controlled too.

A minimal set for a 50-person company

Assume one office, cloud-based systems, a small IT team or managed service provider, and one scope. Owners are roles, often doubled up. Beyond planned intervals and significant change the standard fixes no calendar, so these cycles are defaults, not requirements.

Keep every item on one register with owner, version, date and next review; the certification body's Stage 1 readiness review then has one place to start. Right-sizing the rest is covered in ISO/IEC 27001 for small businesses and start-ups.

What you can leave out, and what to avoid

Clauses 4 to 10 ask for no ISMS manual and prescribe no set of procedures; the only processes they name for documenting are risk assessment and risk treatment. Four habits turn that freedom into findings:

• Copied manuals. A template pack written for another company describes firewalls, approval chains and data centres you may not have. Auditors test what you wrote against what they see, so each inherited sentence becomes a commitment to prove.
• Procedures nobody follows. If the leavers procedure promises same-day access removal and the identity platform shows accounts active weeks later, the document has created the nonconformity. Write down what people actually do, then improve it.
• The 60-page policy. Clause 5.2 asks the policy to suit your purpose, set or frame objectives, and commit to meeting applicable requirements and to continual improvement; two or three signed pages do that. Control 5.1 expects people to acknowledge the policies that bind them, and nobody meaningfully acknowledges 60 pages; put the detail in topic-specific policies.
• Evidence rebuilt for the audit. A ticket history, an exported access review or a backup job report is already a record if it is retrievable, protected from alteration and kept for a set period. Retyping it into spreadsheets before Stage 2 wastes effort and makes auditors ask when the work was really done.

How Effivity holds and version-controls it

Effivity keeps documents and records in one master repository. Documents pass single or multi-level approval before release; change requests are routed and tracked, and each controlled change takes the next version number automatically, with its history. Obsolete versions are archived, access follows user rights, external documents are registered with revision number and date, and forms and checklists carry retention and disposal rules.

ISMS records sit in the modules that produce them, such as Risk Management, Information Asset, Statement of Applicability, Incident Management, Internal Audit, MRM and Non-Conformance. Effivity is used in 50+ countries and is included with the engagement, at no additional cost; the Effivity guide covers each module.

ISO/IEC 27001 documentation: questions buyers ask