ISO 27001 Clause 7.5.2: Creating and Updating

Clause 7.5.2 defines how your organization creates and updates the documented information in your ISMS. While Clause 7.5.1 determines what documents you need and Clause 7.5.3 covers how you control them, 7.5.2 focuses on the mechanics: how documents are identified, what format they use, and how they get reviewed and approved. Get this right and your documentation stays consistent, findable, and trustworthy.

What the clause requires

ISO 27001:2022 Clause 7.5.2 states that when creating and updating documented information, the organization shall ensure appropriate:

• a) Identification and description - title, date, author, reference number, or other identifiers
• b) Format - language, software version, graphics - and media (paper, electronic, etc.)
• c) Review and approval - for suitability and adequacy

These three requirements apply every time you create a new ISMS document or update an existing one. The standard does not prescribe a specific document management system or template - it requires that your approach to identification, format, and approval is consistent and controlled.

How to implement document creation and updating

Identification and description

Every ISMS document should be identifiable without ambiguity. In practice, this means each document includes:

• Title - clear and descriptive (e.g., “Access Control Policy” not “Policy 7”)
• Document ID or reference number - a unique identifier for version tracking (e.g., ISMS-POL-004)
• Version number - so people know which version is current (e.g., v2.1)
• Date - when the document was created or last updated
• Author - who wrote or owns the document
• Approval authority - who approved the current version
• Review date - when the document is next due for review

For a small SaaS company, a simple document header or metadata block on each document covers this. If you use a compliance platform like Vanta or Eramba, document metadata is usually built in. If you use Confluence, Notion, or Google Docs, add a metadata table at the top of each document.

A practical naming convention helps too. Something like ISMS-[TYPE]-[NUMBER] works well:

• ISMS-POL-001 - Information Security Policy
• ISMS-POL-002 - Access Control Policy
• ISMS-PRO-001 - Incident Response Procedure
• ISMS-REC-001 - Risk Assessment Results (2025)

The specific scheme does not matter as long as it is consistent and everyone can find documents by their identifier.

Format and media

The standard requires you to consider format - language, software, and how documents are presented. For most organizations, this comes down to practical decisions:

• Language - use the working language of the organization. If your team works in English, write in English. If you have multi-language teams, determine which language is authoritative.
• Software and accessibility - choose formats people can actually open and edit. Storing policies as Word documents when everyone uses Google Workspace creates friction. Use the tools your team already uses.
• Templates - create a standard template for policies and procedures. This ensures consistent formatting across the ISMS and makes it obvious when a document is part of the ISMS versus an informal draft.
• Media - almost all ISMS documentation is electronic today. If you have paper records (physical access logs, signed acknowledgments), determine how they integrate with your electronic document system.

The key principle is that documents should be accessible to the people who need them, in formats they can work with, and distinguishable from informal or draft content.

Review and approval

Every ISMS document needs to go through a review and approval process before it becomes active. This ensures documents are technically accurate, fit for purpose, and authorized by someone with appropriate authority.

For a 20-person organization, a simple two-step process works:

1. Review - a subject matter expert checks the document for accuracy and completeness. For a technical procedure, this might be a senior engineer. For a policy, this might be the ISMS manager.
2. Approval - someone with authority approves the document for use. For policies, this is typically top management or the person leadership has delegated this responsibility to. For procedures, the process owner or ISMS manager usually approves.

Document the approval - a signature, an email confirmation, or an approval workflow in your document platform. The mechanism does not matter, but the evidence does.

For updates, the same review and approval process applies. When a document changes, it should go through review, receive updated version numbering, and be approved before the new version replaces the old one. Maintain a brief change log or revision history so people can see what changed and why.

Connecting 7.5.2 to the rest of your ISMS

Clause 7.5.1 connection. Clause 7.5.1 defines what documents your ISMS needs. Clause 7.5.2 tells you how to create and maintain them. If 7.5.1 says you need a risk assessment process document, 7.5.2 says that document needs proper identification, formatting, and approval.

Clause 7.5.3 connection. Clause 7.5.3 covers the lifecycle after creation - storage, access, retention, and disposal. Together, 7.5.1, 7.5.2, and 7.5.3 form a complete documentation management framework.

Clause 6.3 connection. When the ISMS itself changes under Clause 6.3, affected documents need updating. The 7.5.2 process ensures those updates are identified, reviewed, and approved before taking effect.

Clause 9.2 connection. Internal auditors check whether document creation and update processes are followed. Audit findings may require document updates - and those updates must follow the 7.5.2 process.

What auditors check

Auditors assess Clause 7.5.2 by examining the documents themselves and the process that produced them.

Document metadata consistency. Auditors sample ISMS documents and check whether they are consistently identified - titles, version numbers, dates, authors, and approval records. If some documents have metadata and others do not, that signals an inconsistent process.

Version control. Auditors check whether current versions are clearly identifiable and whether previous versions are either archived or removed from circulation. Finding two versions of the same policy in active use - with conflicting content - is a common finding.

Approval evidence. For each document, auditors ask: who approved this and when? If there is no record of approval, the document’s authority is questionable. Approval evidence can be a signature, an email trail, or a workflow record - but it needs to exist.

Update process. When auditors find a document that was recently updated, they check whether the update followed the defined process. Was it reviewed? Was it approved? Was the version number incremented? Was the change communicated to affected parties?

Template usage. While not strictly required, auditors notice when documents follow a consistent template. It signals a mature document management process. Conversely, ISMS documents with wildly different formats suggest an ad hoc approach.

Common mistakes to avoid

No version control. The most common issue. Documents get updated but the version number does not change, old versions remain accessible alongside new ones, and nobody can tell which is current. Use version numbers consistently and archive or delete superseded versions.

Approval by default. Some organizations treat documents as approved simply because the ISMS manager wrote them. The standard requires explicit review and approval. Even if the same person writes and approves, there should be a conscious approval step - not just “I wrote it, so it is approved.”

Over-engineering the process. A 15-person startup does not need a formal document management system with multi-stage approval workflows. A shared drive with a naming convention, a metadata block on each document, and email-based approval is enough. Match the process to your organization’s size.

Forgetting records. Records (evidence of activities like risk assessments, audit results, training logs) need the same identification and version discipline as policies and procedures. Many organizations carefully manage their policies but treat records as informal files with no version control or identification.

Not linking updates to triggers. Documents should be updated when something changes - a new risk, a policy revision, an organizational restructure, an audit finding. If your documents have not changed in two years but the organization has evolved significantly, auditors will question whether the documentation reflects reality.

How 27kay can help

We help organizations set up documentation processes that work - consistent, auditable, and proportionate to the organization’s size. As part of ISO 27001 implementation, we provide document templates, establish the naming convention and approval workflow, and ensure every ISMS document meets 7.5.2 requirements. For the full picture, see our ISO 27001 knowledge hub.

Need help getting your ISMS documentation under control? Get in touch - we will review what you have and set up a process that auditors will accept.