ISO 27001 Clause 7.5.1: Documented Information

Clause 7.5.1 defines what documented information your ISMS must include - both the documents explicitly required by ISO 27001 and any additional documentation your organization determines is necessary. This is the clause that sets the scope of your ISMS documentation. Clauses 7.5.2 and 7.5.3 then cover how you create, update, and control that documentation.

What the clause requires

Clause 7.5.1 states that the organization’s ISMS shall include:

a) Documented information required by this document - the standard itself mandates specific documents and records throughout clauses 4-10.

b) Documented information determined by the organization as being necessary for the effectiveness of the ISMS - anything else you need to make your ISMS work in practice.

The clause also notes that the extent of documented information can differ between organizations based on three factors:

• Size of the organization and its type of activities, processes, products, and services
• Complexity of processes and their interactions
• Competence of persons working within the ISMS

This last point is often misunderstood. It does not mean less competent teams need more documentation. It means that documentation should be proportionate - a 15-person startup with experienced engineers needs different documentation than a 500-person organization with high staff turnover.

What ISO 27001 explicitly requires you to document

Scattered across clauses 4 through 10, the standard mandates documented information for specific items. Here is what you actually need:

Mandatory documents (policies, procedures, plans)

• ISMS scope (Clause 4.3) - what is inside and outside the boundaries of your ISMS
• Information security policy (Clause 5.2) - the top-level security policy approved by leadership
• Risk assessment process (Clause 6.1.2) - how you identify, analyze, and evaluate information security risks
• Risk treatment plan (Clause 6.1.3) - what you are doing about the risks you identified
• Statement of Applicability (Clause 6.1.3d) - the SoA mapping Annex A controls to your organization
• Information security objectives (Clause 6.2) - measurable objectives and plans to achieve them

Mandatory records (evidence of activities performed)

• Competence evidence (Clause 7.2) - training records, certifications, CVs showing competence
• Risk assessment results (Clause 8.2) - the output of each risk assessment cycle
• Risk treatment results (Clause 8.3) - evidence that treatment plans are being executed
• Monitoring and measurement results (Clause 9.1) - performance data showing the ISMS is working
• Internal audit program and results (Clause 9.2) - audit plans, findings, and corrective actions
• Management review results (Clause 9.3) - minutes or records from management review meetings
• Nonconformities and corrective actions (Clause 10.1) - what went wrong and what you did about it

This list gives you roughly 12-15 core documents and records. In practice, most organizations also document additional items to make the ISMS operational.

Additional documentation most organizations need

Beyond the mandatory minimum, Clause 7.5.1(b) recognizes that you will likely need more documentation for the ISMS to function effectively. For a typical 20-30 person SaaS company, these commonly include:

• Acceptable use policy - rules for how employees use company systems and data
• Access control policy - who gets access to what, and how access is granted and revoked
• Incident response procedure - steps for detecting, reporting, and responding to security incidents
• Business continuity plan - how the organization recovers from significant disruptions
• Supplier security policy - security expectations for third-party vendors and service providers
• Change management procedure - how changes to systems, infrastructure, and the ISMS are managed (connects to Clause 6.3)
• Asset inventory - list of information assets and their owners

The exact set depends on your risk assessment results and which Annex A controls you have declared applicable in your SoA. If your SoA says control A.8.9 (configuration management) is applicable, you need a documented process for it - even if the standard does not explicitly mandate that specific document.

Connecting 7.5.1 to the rest of your ISMS

Clause 7.5.1 is the first of three sub-clauses on documented information. Together they form a complete documentation management framework.

Clause 7.5.2 connection. Once you know what documents you need (7.5.1), Clause 7.5.2 covers how to create and update them - identification, format, review, and approval. This ensures documents are consistent and controlled.

Clause 7.5.3 connection. Clause 7.5.3 covers access, storage, protection, retention, and disposal of documented information. This ensures the right people can find the right documents, and that outdated versions do not cause confusion.

Clause 7.4 connection. Your communication plan determines how documented information is distributed. Policy updates, incident reports, and management review outcomes all need to reach the right people.

Every other clause. Unlike most clauses, 7.5.1 touches everything. Every requirement in the standard that says “the organization shall retain documented information as evidence of…” or “the organization shall document…” flows back to 7.5.1 as the foundational requirement that your ISMS documentation must be complete.

What auditors check

Auditors use Clause 7.5.1 as a cross-reference throughout the entire audit. Every time they assess a specific clause, they check whether the required documented information exists.

Completeness of mandatory documents. Auditors work through the list of explicitly required documents and records. Missing an entire document - like having no Statement of Applicability or no management review records - is a major nonconformity. This is one of the most common findings during Stage 1 audits.

Proportionality. Auditors assess whether your documentation is proportionate to your organization’s size and complexity. A 15-person startup with a 200-page ISMS manual raises questions about whether anyone actually reads it. Equally, a 200-person organization with a single one-page policy is likely under-documented.

Alignment between SoA and supporting documentation. If your Statement of Applicability declares a control applicable, auditors check whether supporting documentation exists. Declaring A.5.23 (information security for cloud services) applicable but having no documented cloud security procedures is a gap.

Currency and relevance. Auditors check whether documents are current. An incident response procedure last updated three years ago, referencing tools the organization no longer uses, suggests the documentation is not maintained. Review dates, version histories, and approval records all signal whether documentation is actively managed.

Accessibility. Documents exist but nobody can find them? That is a 7.5.1 issue. Auditors ask random employees where to find the security policy or the incident reporting procedure. If people cannot locate key documents, the documentation is not serving its purpose.

Common mistakes to avoid

Documenting for the auditor, not for the organization. If your documentation exists only to satisfy audit requirements and nobody uses it day to day, it will drift from reality. Write documents that people actually reference - concise, practical, and in the language your team uses.

Under-documenting and hoping for the best. Some organizations try to minimize documentation to reduce overhead. While proportionality is important, skipping mandatory documents or leaving out procedures for applicable controls creates audit findings. Know the mandatory minimum and cover it.

Over-documenting everything. The opposite problem - creating detailed procedures for every possible scenario. This creates a maintenance burden that is unsustainable, especially for small teams. A 15-person SaaS company typically needs 15-25 documents total, not 100. More documentation means more documents to keep current.

No single source of truth. ISMS documents scattered across Google Drive, Confluence, SharePoint, and email attachments create version control problems. Pick one platform as your document repository and direct everyone there.

Treating documentation as static. Your ISMS documentation should evolve with the organization. When processes change, infrastructure changes, or new risks emerge, documentation should update accordingly. Build document review into your management review cycle and review all core documents at least annually.

How 27kay can help

We help organizations build ISMS documentation that is complete enough to satisfy auditors and practical enough for daily use - without drowning in paperwork. As part of ISO 27001 implementation, we provide document templates, set up the documentation structure, and ensure every mandatory document is covered. For the full picture, see our ISO 27001 knowledge hub.

Not sure whether your ISMS documentation is complete? Get in touch - we will assess what you have, identify what is missing, and help you close the gaps.