ISMS Documentation: Which Documents You Actually Need (and Which You Don't)

Documentation in the ISMS: Mandatory, Optional, and Ballast

Anyone building an ISMS according to ISO 27001 quickly encounters a central question: which documents do I need to have, which should I have, and which can I skip? The answer is less straightforward than many consultants suggest. ISO 27001 explicitly names certain documents as mandatory but leaves room for others. And it's precisely in this room where typical mistakes occur: too little documentation leads to audit findings; too much leads to a paper tiger that nobody maintains.

This article gives you a complete overview. You'll learn which documents ISO 27001 strictly requires, which provide useful additions, and where you should deliberately hit the brakes. At the end, there's a concrete example: the document landscape of a mid-market company with approximately 100 employees.

What ISO 27001 Means by Documented Information

Before we get into the list, a brief look at the terminology is worthwhile. ISO 27001 consistently refers to "documented information." This term encompasses two categories:

Documents are prescriptive documents such as policies, procedures, and plans. They describe how something should be done. Example: the information security policy defines the principles by which the organization conducts information security.

Records are evidentiary documents. They prove that something was actually done. Example: the management review minutes prove that senior management regularly reviewed the ISMS.

The distinction is important because auditors check both types. A document alone is not enough. If the risk assessment methodology is described but no risk assessment exists as a record, the requirement is not met.

Mandatory Documents per ISO 27001: The Complete List

The following documents are explicitly required in ISO 27001:2022. Without them, certification is not possible. The clause references help you look up the requirement in the standard.

Context and Scope (Clause 4)

The scope is one of the most frequently examined documents in an audit. It must name the locations, business areas, processes, and technologies covered by the ISMS. Vague formulations like "all IT systems" are insufficient.

Leadership and Commitment (Clause 5)

The information security policy is the umbrella document for all other policies. It must be approved by management and communicated to all employees. A signed PDF in a SharePoint folder that nobody ever opens meets the requirement formally — but not substantively.

Planning (Clause 6)

The SoA is the centerpiece of ISO 27001 documentation. It lists all 93 Annex A controls and documents for each one whether it's applied, how it's implemented, and why it may be excluded. A poorly maintained SoA is one of the most common reasons for major nonconformities in audits.

Support (Clause 7)

Document control is essentially the meta-document: it describes how all other documents are managed. Without a functioning document control procedure, the entire ISMS is formally vulnerable.

Operation (Clause 8)

Performance Evaluation (Clause 9)

Improvement (Clause 10)

If you count all documents in this list, you arrive at approximately 20 to 25 individual documents and records. This is the mandatory minimum. Everything beyond is optional.

Recommended Documents: What Auditors Expect Even When Not Mandatory

Beyond the explicitly required documents, there's a range of documents that aren't literally demanded in the standard but are expected by most auditors. The reason: the mandatory documents implicitly presuppose their existence, or they're the logical implementation of an Annex A control.

Operational-Level Policies

The information security policy from Clause 5.2 is the umbrella document. For actual management, you need topic-specific policies:

• Password policy (A.5.17): Complexity, length, reuse, MFA
• Access control policy (A.5.15, A.5.18): Authorization concept, least privilege, recertification
• Mobile device and remote work policy (A.6.7, A.8.1): BYOD rules, VPN requirement, device encryption
• Backup policy (A.8.13): Backup strategy, retention periods, restore tests
• Information classification policy (A.5.12, A.5.13): Protection levels, labeling, handling
• Encryption policy (A.8.24): What data is encrypted how, key management
• Incident handling policy (A.5.24 to A.5.28): Detection, reporting, escalation, post-processing
• Supplier policy (A.5.19 to A.5.22): Assessment, contractual requirements, monitoring

Each of these policies addresses one or more Annex A controls. In the SoA, you reference these policies as implementation evidence.

Procedural Documents and Process Descriptions

• Incident response plan: Detailed sequence for security incidents with roles, communication channels, and escalation levels
• Business continuity plan: How business operations are maintained during an outage
• Recovery plan: Technical restoration of systems after an incident
• Change management procedure: How changes to systems are planned, approved, and executed
• Onboarding and offboarding process: Granting and revoking permissions on joining and leaving

Inventories and Registers

• Asset inventory: All information assets with owner, classification, and protection requirement
• Risk register: Central overview of all identified risks with assessment and treatment status
• Measure register: All ongoing and completed measures with responsible party, deadline, and status
• Supplier register: External service providers with security-relevant classification and contractual status

Additional Recommended Records

• Training plan: Annual planning of awareness and specialist training sessions
• Audit annual plan: Three-year audit planning across all ISMS areas
• Metrics dashboard: Regularly updated ISMS KPIs
• Incident reports: Structured post-processing of completed incidents

The recommended documents bring the total to approximately 40 to 50 individual documents. That sounds like a lot but is realistic for a functioning ISMS. What matters is not the quantity but the quality and timeliness.

What You DON'T Need: Recognizing and Avoiding Over-Engineering

Now for perhaps the most important part of this article. The temptation to over-document is in practice at least as great as the danger of having too little. Over-engineering in ISMS documentation has concrete causes and concrete costs.

Typical Forms of Over-Engineering

Policies for self-evident things. You don't need a separate "Policy for Responsible Use of Company Laptops" if the mobile device policy covers it. You don't need a separate "Workplace Security" document if physical security is in the access control policy. Every additional document generates maintenance effort and increases the likelihood of contradictions.

Process descriptions for trivial workflows. Not every IT operation needs a formal procedural document. If your team consists of three administrators who talk daily, a 15-page change management procedure with five approval levels is not just unnecessary — it's counterproductive. It won't be followed, and the auditor will notice.

Detail levels that add no value. A risk assessment must identify, evaluate, and prioritize risks. It doesn't need a two-page analysis with five subcategories for every risk if the assessment methodology doesn't call for it. A compact risk register with clear evaluation criteria beats a bloated risk handbook in practice.

Duplicate documentation. If the asset inventory contains the protection requirement and the risk register also lists the protection requirement, you're maintaining the same information in two places. At the next update, values will diverge, and the auditor will rightly ask which document is authoritative. Every piece of information should have exactly one authoritative source.

Templates without context. A common mistake with consultants and ready-made template packages: 80 documents are delivered that are generic and never adapted to the organization. The auditor spots this immediately when the password policy says "Company XY," the server policy describes Windows servers even though you only run Linux, or the access control policy regulates a data center you don't have.

Rule of Thumb for the Right Documentation Depth

Every document must be able to answer at least one of the following questions with yes:

1. Does the standard explicitly require this document?
2. Does an employee need this document to correctly perform their task?
3. Does the auditor need this document as evidence for the implementation of a control?
4. Does this document help in decision-making in a specific situation?

If none of these criteria applies, you don't need the document. Remove it before it costs you maintenance effort.

Document Structure: Order Instead of Chaos

A good document structure is the prerequisite for your ISMS documentation system to work. There are various approaches, but a proven model is the pyramid structure.

The Document Pyramid

Level 1: Policies These are the guiding documents: the information security policy and the topic-specific policies. They describe the "what" and "why." Policies are approved by management or the CISO and apply to the entire organization or clearly defined areas.

Level 2: Procedures and Processes These documents describe the "how." The incident response plan, the change management procedure, the onboarding process. They're directed at the people executing the process and are more detailed than policies.

Level 3: Work Instructions and Checklists Even more detailed instructions for specific activities: checklist for server hardening, instructions for creating a user in Active Directory, procedure for restore tests. Not every process needs work instructions — only where errors have serious consequences or the activity is rarely performed.

Level 4: Records and Evidence All results and proof: risk assessments, audit reports, training records, incident reports, management review minutes. These documents aren't created on a planned basis but emerge as the result of a process.

Folder Structure

A proven folder structure for ISMS documentation aligns with the standard's clauses:

ISMS/
├── 01_Context_and_Scope/
│   ├── ISMS-Scope.pdf
│   ├── Context_of_the_Organization.pdf
│   └── Interested_Parties.pdf
├── 02_Policies/
│   ├── Information_Security_Policy.pdf
│   ├── Password_Policy.pdf
│   ├── Access_Control_Policy.pdf
│   └── ...
├── 03_Risk_Management/
│   ├── Risk_Assessment_Methodology.pdf
│   ├── Risk_Register.xlsx
│   ├── Risk_Treatment_Plan.pdf
│   └── SoA.xlsx
├── 04_Procedures/
│   ├── Incident_Response_Plan.pdf
│   ├── Change_Management_Procedure.pdf
│   └── ...
├── 05_Inventories/
│   ├── Asset_Inventory.xlsx
│   ├── Supplier_Register.xlsx
│   └── ...
├── 06_Training/
│   ├── Training_Plan.pdf
│   ├── Training_Records/
│   └── ...
├── 07_Audit/
│   ├── Audit_Program.pdf
│   ├── Audit_Reports/
│   └── ...
├── 08_Management_Review/
│   ├── Review_2025-Q4.pdf
│   └── ...
└── 09_Improvement/
    ├── Measure_Register.xlsx
    └── Corrective_Actions/

This structure is a suggestion. More important than the exact organization is consistency: once you've decided on a structure, stick with it.

Naming Convention: No Document Without Rules

Without a consistent naming convention, every document management system ends in chaos. At the latest when the second auditor asks "Where is the current version of the password policy?" you'll regret not having one.

Recommended Naming Format

[Type]-[Topic]-[Version].[Format]

Examples:
POL-Information-Security-v2.1.pdf
POL-Password-v1.3.pdf
PRO-Incident-Response-v1.0.pdf
REC-Management-Review-2025-Q4.pdf
REG-Risk-Register-v3.2.xlsx
CHK-Server-Hardening-v1.1.pdf

Type Abbreviations

Versioning

Use simplified semantic versioning:

• Major version (v1.0, v2.0): Fundamental revision, new approval required
• Minor version (v1.1, v1.2): Small adjustments, review by CISO
• Draft: Mark drafts with "DRAFT" in the filename or as a watermark

Every document must contain a version history. This must include at minimum the version number, date, change description, and approved by whom. A brief three-liner in a table is sufficient.

Document Control: The Process Behind the Documents

Document control describes the entire lifecycle of an ISMS document: from creation through review and approval to archiving and deletion. Without a functioning document control procedure, the entire documentation is vulnerable.

Lifecycle of an ISMS Document

1. Creation: A new document is created, typically by the CISO or the process owner. The creator is responsible for the content and compliance with the naming convention and template.

2. Review: The document is reviewed by a professionally qualified person. For policies, this is often the CISO; for technical documents, the IT manager. The reviewer checks content accuracy, consistency with other documents, and practicality.

3. Approval: The formal authorization. Policies are approved by management; operational documents by the CISO or the respective owner. Approval must be demonstrable — whether through signature, digital signature, or a documented workflow.

4. Publication and communication: The document is stored at the defined location and communicated to affected persons. For policies that affect all employees, active communication is required — not just an upload to the file server.

5. Regular review: Every document has a review cycle. Policies typically annually; operational documents every one to two years. The review ensures the document is still current and matches actual practice.

6. Update: When changes occur, a new version is created that goes through the review and approval process again. The predecessor version is marked as "superseded" and archived.

7. Archiving and deletion: Superseded versions are archived for a defined period (typically at least through the certification cycle of three years), then deleted. At no point should it be unclear which is the current version.

Access and Distribution

Not every document needs to be accessible to everyone. A sensible access model:

• Policies: All employees (read access)
• Procedures: Involved departments (read access), process owners (write access)
• Work instructions: Affected teams (read access)
• Risk register, SoA: CISO, management, risk owners (read access), CISO (write access)
• Audit reports: CISO, management, audited area

Practical Example: Document Landscape of a 100-Employee Company

Enough theory. What does the document landscape of a mid-market IT service provider with 100 employees, three locations, and ISO 27001 certification actually look like? This example shows a realistic, audit-ready documentation without over-engineering.

Policies (11 Documents)

Eleven policies, each between three and eight pages. Compact, focused, and actually readable. No document that's 30 pages long and nobody reads to the end.

Procedures and Plans (8 Documents)

Inventories and Registers (5 Documents)

Templates (6 Documents)

Regularly Generated Records

These documents are created during ongoing operations:

• Quarterly: Updated risk register, measure progress, ISMS metrics
• Semi-annually: Internal audit reports (2 to 3 per year, rotating)
• Annually: Management review minutes, updated training plan, awareness training results
• Event-driven: Incident reports, corrective actions, change requests

Total Count

This yields approximately 30 actively maintained documents plus templates and ongoing records. For a 100-employee company, this is a realistic and manageable scope. Each document has a clear purpose and a defined maintenance cycle.

Frequently Asked Questions About ISMS Documentation

Do I have to create everything in a specific format? No. ISO 27001 doesn't prescribe a format. You can use Word, PDF, wiki systems, specialized ISMS tools, or a combination. What matters is that documents are findable, current, and protected against unauthorized changes.

How detailed do policies need to be? Detailed enough that an employee knows what to do and what not to do. Not so detailed that technical changes (such as a system switch) immediately require a policy update. Separate principles (policy, change-resistant) from technical details (work instruction, change-prone).

Can I combine multiple topics in one document? In principle yes, as long as the responsibilities and review cycles are compatible. A combined "Access Control and Password Policy" makes sense because both topics are closely related and have the same approver. A combined "Backup and Training Policy" would be nonsensical.

Do I need a dedicated document management system? Not necessarily. A well-structured file server or SharePoint with defined permissions can suffice. What matters is that document control actually works: versioning, approval, access protection, archiving. If you're maintaining more than 30 documents and multiple people are involved, a specialized system like ISMS Lite is worthwhile because it automates review cycle reminders, approval workflows, and audit trails. 500 Euro pro Jahr you get all modules without user limits, alternatively as a one-time purchase for 2.500 Euro.

What happens when a document is outdated? An outdated policy is worse in an audit than a missing one. If the auditor sees that the password policy hasn't been reviewed in three years and still contains requirements from a decommissioned system landscape, that's a clear nonconformity. Better to have fewer documents that are current than many outdated ones.

Finding the Right Balance

ISMS documentation is not an end in itself. It serves two goals: it gives employees orientation, and it demonstrates to auditors that the ISMS works. Anything that doesn't contribute to one of these goals is ballast.

The mandatory documents per ISO 27001 form the foundation. The recommended documents supplement it with practice-relevant policies and evidence. And then comes the point where you consciously decide: that's enough. Not every aspect needs its own document, not every document needs ten pages, and not every process needs to end in a formal procedural description.

Start with the mandatory documents. Add the policies relevant to your organization. Build the records during ongoing operations. And critically examine every new document: does someone actually need this, or am I writing it just because it's on a list?

An ISMS with 35 well-maintained documents is superior in every respect to an ISMS with 80 dusty documents. Your auditor will see it the same way.

Further Reading

• Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
• Creating a Statement of Applicability (SoA): Selecting and Justifying Controls
• Writing an Information Security Policy: Structure, Content, and Example
• Policy Lifecycle: From Creation to Retirement
• Conducting an Internal ISMS Audit: Planning, Checklist, and Report

The best documentation is the kind that's actually lived. It's better to consistently maintain 30 documents than to create 60 documents in advance and never touch them again. The review cycle is your best friend: it forces you to regularly check every document for timeliness and relevance. Whatever fails that check can be retired. That's not failure — that's continual improvement.