Documentation & SoA

Mandatory Documents and Records in ISO 27001:2022

Alex Fuerst

25 Nov 2025 — 8 min read

Every certification audit I conduct follows the same pattern in its opening hours: I request documentation. Not because I enjoy watching management representatives scramble through SharePoint folders and email archives, but because documentation tells me everything about whether an ISMS is real or theater. The difference between organizations that sail through audits and those that stumble often comes down to one fundamental question: did they understand what ISO 27001:2022 actually requires them to document, or did they just download templates and hope for the best?

The 2022 revision brought welcome clarity to documentation requirements while simultaneously confusing organizations that had finally figured out the 2013 version. Let me cut through that confusion with what you actually need, why you need it, and how to avoid the documentation traps that derail certification efforts.

Understanding the Documentation Framework

ISO 27001:2022 distinguishes between two types of documentation: documented information that the standard explicitly requires, and documented information that your organization determines is necessary for ISMS effectiveness. The first category is non-negotiable. Miss any of it, and you're looking at a nonconformity. The second category is where judgment matters—and where I've seen organizations both over-engineer themselves into paralysis and under-document themselves into chaos.

The standard uses careful language: "shall maintain documented information" means you need a document (think policies, procedures, processes). "Shall retain documented information" means you need records (think evidence that something happened). This distinction matters because it drives how you manage, update, and protect different types of documentation.

Before we dive into specifics, understand this: documentation exists to ensure consistency, enable knowledge transfer, provide audit evidence, and support continual improvement. If your documentation doesn't serve at least one of these purposes, question why it exists.

Mandatory Documents Required by the Standard

Let's be precise about what ISO 27001:2022 explicitly requires. These aren't suggestions—auditors will issue nonconformities for missing any of these.

Scope of the ISMS [Clause 4.3]

Your scope document must define the boundaries and applicability of your ISMS. This sounds simple until you realize how many organizations get it wrong. I audited a software company last year whose scope said "all company operations" while their Statement of Applicability excluded physical security controls because they "only do cloud stuff." That contradiction earned them a major nonconformity before we finished day one.

Your scope needs to reference the internal and external issues from Clause 4.1, the interested party requirements from Clause 4.2, and clearly identify interfaces and dependencies with activities performed by other organizations. Be specific about locations, business units, products, services, and processes included. If you're using cloud services, consider integrating guidance from ISO 27017 for cloud-specific considerations.

Information Security Policy [Clause 5.2]

The top-level policy must be appropriate to your organization's purpose, include a commitment to satisfying applicable requirements, and commit to continual improvement. It needs to be communicated within the organization and available to interested parties as appropriate.

I've seen organizations confuse this with a comprehensive security policy document covering everything from password requirements to incident response. That's not what this clause requires. The Clause 5.2 policy is a strategic, high-level statement of intent. Your detailed operational policies flow from Annex A controls and your risk treatment decisions.

Information Security Objectives [Clause 6.2]

You must document your information security objectives. These need to be consistent with your policy, measurable where practicable, take into account applicable requirements and risk assessment results, be monitored, communicated, and updated as appropriate.

The common failure here is creating objectives that can't actually be measured. "Improve security awareness" isn't an objective—it's a wish. "Reduce successful phishing simulations by 25% by Q4" is an objective. Document what you'll measure, how you'll measure it, who's responsible, and when you'll evaluate progress.

Risk Assessment Process and Methodology [Clause 6.1.2]

You need documented criteria for performing information security risk assessments, including risk acceptance criteria and criteria for performing assessments. The process must produce consistent, valid, and comparable results.

This document should explain your risk methodology—how you identify risks, how you analyze them (likelihood and impact scales), and how you evaluate them against acceptance criteria. If you're using ISO 31000 as your risk management framework, reference it here. For organizations handling personal data, consider how ISO 27018 privacy controls integrate with your risk assessment approach.

Risk Treatment Process [Clause 6.1.3]

You need a documented process for treating information security risks. This should define how you select and implement risk treatment options, create risk treatment plans, and obtain approval for residual risks and the risk treatment plan.

Statement of Applicability [Clause 6.1.3(d)]

The SoA is where many organizations stumble. It must include the necessary controls (whether from Annex A or elsewhere), justification for their inclusion, whether they're implemented, and justification for excluding any Annex A controls.

I've audited organizations with SoAs that read like shopping lists: "Control 5.1 - Yes, Control 5.2 - Yes..." without any meaningful justification. That's documentation for documentation's sake. Each entry should reference your risk assessment, legal requirements, or business needs that justify its inclusion or exclusion.

Mandatory Records Required by the Standard

Records demonstrate that your ISMS isn't just designed well—it actually works. Here's what you must retain:

Evidence of Monitoring and Measurement Results [Clause 9.1]

You need records showing what you monitored, when, who did it, and what the results were. This isn't just technical monitoring—it includes monitoring of procedures, controls effectiveness, and objective achievement.

Internal Audit Program and Results [Clause 9.2]

Maintain records of your audit program, individual audit plans, audit findings, and corrective actions. I look for evidence that audits actually evaluate ISMS effectiveness, not just check boxes. Your audit records should show progression—what you found, what you fixed, and whether the fixes worked.

Management Review Records [Clause 9.3]

Document the inputs, discussions, decisions, and actions from management reviews. I've seen organizations where management review "minutes" are three bullet points. That's not sufficient. I need to see evidence that management actually reviewed ISMS performance, considered changing circumstances, and made informed decisions about improvements.

Nonconformities and Corrective Actions [Clause 10.1]

Maintain records of nonconformities, corrective actions taken, and their results. This includes both internal findings and external observations. The record should show the root cause analysis process, not just the symptom fix.

Evidence of Training and Awareness [Clause 7.2]

Document what training was provided, to whom, when, and how effectiveness was evaluated. If Control 6.3 (Information security awareness, education and training) applies to you, you'll need additional records showing awareness activities and their effectiveness measurement.

Control-Specific Documentation Requirements

Beyond the main standard's requirements, your selected Annex A controls will drive additional documentation needs. Here are the most commonly applicable ones:

Access Control Documentation

If you've selected Control 5.15 (Access control), you'll need an access control policy. Control 5.16 (Identity management) requires documentation of user identity lifecycle management. Control 5.18 (Access rights) demands documented procedures for granting, reviewing, and revoking access rights.

Cryptography Documentation

Control 5.14 (Information transfer) often requires documented cryptographic policies and procedures. If you implement Control 8.24 (Use of cryptography), you'll need a crypto policy defining usage principles, key management procedures, and implementation standards.

Incident Management Documentation

Control 5.24 (Information security incident management planning and preparation) requires documented incident response procedures. Control 5.25 (Assessment and decision on information security events) needs procedures for evaluating and escalating events. Control 5.27 (Learning from information security incidents) requires documented lessons learned processes.

Supplier Relationship Documentation

Control 5.19 (Information security in supplier relationships) requires documented procedures for managing security in supplier agreements. If you're dealing with cloud suppliers, consider how ISO 27036 supplier security guidance enhances your documentation approach.

What Auditors Look for in Documentation

After fifteen years of conducting audits, here's what I actually examine when reviewing your documentation:

Evidence of Use

Documents that show signs of actual use. I look for version controls that indicate updates based on experience, references to the documents in meeting minutes, and evidence that people actually follow documented procedures. A pristine document that looks like it was created yesterday for a three-year-old ISMS raises red flags.

Consistency Across the ISMS

Your documents should tell a coherent story. If your risk assessment identifies email security as a high risk, but your SoA excludes anti-malware controls without justification, we have a problem. If your objectives include reducing incidents, but your incident management procedure is two paragraphs long, that's another red flag.

Measurable Outcomes

For procedures and processes, I look for evidence that you can measure whether they're working. Can you demonstrate that your access review procedure actually catches inappropriate access? Can you show that your awareness training improves behavior? Good documentation includes measurement criteria.

Proper Authorization and Approval

Documents should show appropriate approval for their level of importance. Your top-level policy needs top-level approval. Detailed procedures might be approved by functional managers. But there should be evidence that someone with appropriate authority has reviewed and approved each document.

Auditor's Perspective: I don't count pages. I don't care if your incident response procedure is two pages or twenty. What matters is whether it covers the essential elements, provides clear guidance to your people, and shows evidence of practical use. A two-page procedure that everyone follows beats a twenty-page procedure that sits on the shelf.

Common Documentation Pitfalls

Let me share the most frequent documentation failures I encounter:

Template Addiction

Organizations download generic templates and fill in blanks without thinking about their specific context. Last month, I audited a law firm whose risk assessment used manufacturing examples from a template. Their risk register included "production line failures" and "raw material contamination." They weren't even trying to customize it.

Documentation Overload

The opposite extreme: creating documents for everything. I've seen organizations with separate procedures for "Procedure Review Procedures" and "Document Approval Document Approval Procedures." This isn't thoroughness—it's paralysis through paperwork.

Orphaned Documentation

Documents that exist in isolation, unconnected to your actual ISMS. The most common example is creating an information security policy that never gets referenced in any other document, never gets communicated to staff, and never influences any decision.

Version Control Nightmares

Multiple versions floating around with no clear indication of which is current. I've audited organizations where different departments were following different versions of the same procedure, leading to inconsistent implementations and confused staff.

Practical Implementation Guidance

Here's how to approach documentation pragmatically:

Start with What You Have

Most organizations already have some of the required documentation. Before creating new documents, audit what exists. Your employee handbook might already cover acceptable use policies. Your IT procedures might already include access control elements. Build on existing foundations rather than starting from scratch.

Document for Your Audience

Consider who will actually use each document. Your information security policy needs to be understandable by all staff. Your technical procedures can use technical language for technical audiences. Match the complexity to the user.

Plan for Maintenance

Every document you create needs ongoing maintenance. Before creating a document, identify who's responsible for keeping it current, how often it needs review, and what triggers updates. Build maintenance into your document lifecycle from the beginning.

Integrate with Existing Systems

Don't create a parallel document management system for ISO 27001. Use your existing document management tools, workflows, and approval processes. The ISMS should integrate with how you already work, not create additional overhead.

Managing Documentation Effectively

Once you have the right documents, you need to manage them properly. This means implementing Control 5.12 (Classification of information) for your documentation, ensuring appropriate protection based on sensitivity. Your risk assessment methodology, for example, might be more sensitive than your general information security policy.

Consider implementing Control 5.13 (Labelling of information) to ensure all ISMS documents are properly identified and classified. This helps with document control and ensures appropriate handling.

For organizations using cloud-based document management systems, review how cloud compliance requirements affect your documentation storage and access controls.

The key is creating a sustainable documentation framework that serves your organization rather than burdening it. Good documentation enhances your ISMS effectiveness, provides clear guidance to your people, and demonstrates your commitment to information security management.

Remember: auditors don't award points for volume. We look for evidence that your documentation actually supports effective information security management in your specific context.

Need guidance on implementing these documentation requirements in your specific context? The IX ISO 27001 Info Hub provides practical implementation guidance, or consider a consultation to review your documentation approach against audit expectations.

Need personalized guidance? Reach our team at ix@isegrim-x.com.