7.5.2 — Creating and updating

In plain language

In plain language: 7.5.2 requires that every time you create or update an ISMS document, you handle three things properly: label it clearly enough to identify it, format it appropriately for how it will be used, and have someone review and approve it before it counts as official.

Why this requirement exists

Without a defined creation process, documents accumulate informally — a draft policy gets emailed around, someone starts using it, and it becomes the de facto standard without anyone having actually reviewed it for accuracy or approved it for use. This sub-clause exists to put a gate in front of that drift.

Scenario: an incident response plan gets drafted, shared in a chat channel for feedback, and then referenced during a real incident six months later — except the version people are using was never formally approved, and a critical contact detail was fixed in a later draft that never got distributed. A defined review-and-approval step would have caught that before it mattered.

What the standard expects

The standard expects that, when creating and updating documented information, the organization ensures appropriate identification and description (such as a title, date, author, or reference number); appropriate format (such as language, software version, or graphics) and media (such as paper or electronic); and appropriate review and approval for suitability and adequacy.

In practice

• Use a consistent header or metadata block on every document: title, version number, date, author, and approver.
• Assign a named approver for each document type, and do not treat a draft as official until that approval is recorded.
• Pick a format appropriate to the audience — a technical procedure for engineers can look different from a policy meant for all staff.

Evidence the auditor will ask for

• Documents showing consistent identification metadata (title, version, date, author).
• Approval records — sign-off, an approval workflow, or meeting minutes — for key documents.

Common pitfalls

• A document in active use that was never formally approved by anyone.
• Inconsistent versioning across documents, making it unclear which one is current.

Related requirements

Parent link: 7.5 Documented information

Frequently asked questions