WHAT ARE THE MANDATORY ISO 27001 DOCUMENTS?

Exploring what's a must have and what's nice to have.

To comply with ISO 27001:2022, organisations must provide evidence of several mandatory documents. These documents are named in the various clauses and are not avoidable. You will need to be able to put your hands on copies of any of these documents as part of an audit and evidence that they are up to date and communicated.

Other documents (sub-policies, procedures, etc.) are at the organisation's discretion. 

However, the Statement of Applicability lays out so many controls that you need to ask yourself how you will address them, if not by creating additional supporting documentation.

The clauses are very open to interpretation. Therefore, one ISO consultant might have a different view on what the standard mandates. Some clauses, for example, don’t say you must have a policy, just ‘rules’. That means they could be procedure-based, system-based or policy-based.

Check out the documents I've created for you here.

Mandatory Documents

• Scope of the ISMS (Clause 4.3): This document defines the boundaries and applicability of the Information Security Management System.

  
  
  
  

• Information Security Policy (Clause 5.2): This high-level policy outlines the organisation's approach to information security.

• Defined Security Roles and Responsibilities (Clause 5.3): Organisations need to define and document roles and responsibilities related to information security.

• Risk Assessment and Treatment Methodology (Clause 6.1.2): This document specifies an organisation's method for performing information security risk assessments and deciding on risk treatment options.

• Statement of Applicability (Clause 6.1.3 d): This critical document lists all the ISO 27001 controls and whether they are applicable, along with a justification for their inclusion or exclusion.

• Risk Treatment Plan (Clause 6.1.3 e): This outlines how the organisation plans to address the risks identified in the risk assessment.

• Information Security Objectives (Clause 6.2): The objectives summarise the goals for the forthcoming period and must be documented and communicated.

• Records of Training, Skills, Experience, and Qualifications (Clause 7.2): Records demonstrating that employees have the necessary training, skills, experience, and qualifications.

• Risk Assessment Report (Clause 8.2): This report documents the results of the organisation's risk assessments.

• Monitoring & Measurement Results (Clause 9.1): Documented information must be available to demonstrate the effectiveness of security controls and the ISMS.

• Internal Audit Program and Results (Clause 9.2): This document includes the internal audit program, detailing the schedule, scope, and criteria for audits, as well as records of the results from internal audits of the ISMS.

• Management Review Minutes (Clause 9.3.3): This document includes the minutes from management reviews, which capture discussions, decisions, and actions related to the ISMS's performance and continual improvement.

• Nonconformities and Corrective Actions (Clause 10.1): This document records identified nonconformities and the actions taken to correct them and prevent their recurrence, ensuring continual improvement of the ISMS.

• Inventory of Assets (Clause A.5.9): This is an inventory of all assets within the scope of the ISMS.

• Acceptable Use Policy (Clause A.5.10): Describing how assets may be used within the organisation.

• Access Control Policy (Clause A.5.15): This document defines requirements for access control to physical and information assets according to the organisation's needs.

• Incident Management Procedure (Clause A.5.26): This procedure ensures a consistent and effective approach to managing information security incidents.

• Statutory, Regulatory, and Contractual Requirements (Clause A.5.31): This document identifies and documents all legal, statutory, regulatory, and contractual requirements relevant to the organisation's information security.

• Operating Procedures for IT Management (Clause A.5.37): These are documented procedures that ensure the correct and secure operation of information processing facilities.

• Security Configuration Records (Clause A.8.9): These records contain security configurations for software, hardware, and network services.

• Secure System Engineering Principles (Clause A.8.27): Principles that must be applied to system engineering processes.

• Supplier Security Policy (Clause A.15.1.1): Outlines how supplier dealings should handle information security.

• Business Continuity Procedures (Clause A.5.29 / A.5.30): These procedures help the organisation protect against, reduce the likelihood of, and ensure business continuity.

• Backup Policy(s) (Clause A.8.13): The organisation must maintain a ‘topic-specific’ policy or policies on backups.

It's important to note that these are the minimum requirements. Organisations may need additional documents based on their specific context, risks, and control implementation.

Documents that are Not Explicitly Mandatory but Often Considered

The distinction between mandatory and non-explicitly mandatory documents is based on the standard's requirements for specific documents versus requirements for processes or outcomes that may be documented in various ways at the organisation's discretion. 

The ISMS Manual

One document often used is the "Information Security Manual" or "ISMS Handbook." A manual is a helpful overview document for people getting to know your ISMS and how it applies the 27001 standard. They can benefit audits, new starters, or anyone just trying to get to grips with your ISMS. Again, it's not mandatory, but it is helpful. 

Here's a ISMS Manual template you can download.

Combining Documentation/Policies

Consolidating documentation where you think it naturally lends itself to doing so is fine. For example, 

A.8.24 : Use of Cryptography – This control stipulates you need to have ‘rules’ around the handling of cryptographic keys (SSL certificates, etc). This may be a very complex area for your organisation, demanding separate procedures and policies, or it might be something that isn’t crucial to your organisation, and you just put a section into your Information Security Policy saying all crypto keys need to be stored in a particular location.

The point is that you adapt the 27001 framework to your needs. You may need to explain why you’ve chosen a certain approach to an auditor, but if it’s justified to you and documented clearly, then I’m sure they will see it that way, too.

---

Important Notice

This document is provided for personal use only. Commercial or consultative use requires a licence. For detailed terms of use, please visit https://www.iseoblue.com/terms.