7.5.3 — Control of documented information

A correct, approved document that nobody can find, or that three people are editing three different versions of, is not actually controlled.

Mandatory requirement · Documented information required: no

In plain language

7.5.3 requires that, once a document exists, it stays available to the people who need it, protected from unauthorized access or loss, and properly managed through distribution, storage, version control, and eventual disposal.

Why this requirement exists

A well-written, properly approved document that lives on someone’s personal laptop, in an outdated shared drive folder, or with no access restrictions on sensitive content is functionally broken even though 7.5.2 was satisfied at the moment of creation. This requirement covers the document’s entire life after that point.

Scenario: an auditor asks to see the current risk treatment plan and receives three different versions from three different people, none of them dated or clearly marked as the authoritative copy. The content might even be identical, but the lack of version control is itself the nonconformity—the organization cannot demonstrate it controls its own documented information.

What the standard expects

The standard expects documented information required by the ISMS and by this standard to be controlled so that it is available and suitable for use where and when needed, and adequately protected—for example from loss of confidentiality, improper use, or loss of integrity. As applicable, the organization must address distribution, access, retrieval and use; storage and preservation, including legibility; control of changes such as version control; and retention and disposition. Documented information of external origin that the organization determines is necessary for the ISMS must also be identified as appropriate and controlled.

In practice

• Store ISMS documents in a single system of record—not scattered across personal drives, email attachments, and multiple shared folders.
• Restrict access to sensitive documents (the risk register, incident details) on a need-to-know basis, and log who can see what.
• Enforce simple version control—a single current version, clearly dated, with prior versions archived rather than deleted.
• Set retention periods appropriate to each document type, and actually dispose of documents once retention expires, rather than keeping everything forever by default.
• Track external documents you rely on (a vendor’s SOC 2 report, a regulatory guidance document) the same way you track internal ones.

Evidence the auditor will ask for

• A single, identifiable current version for any document requested, with clear version history.
• Access control records or permissions showing sensitive documents are appropriately restricted.
• A retention schedule and evidence it is actually followed.

Common pitfalls

• Multiple copies of the "same" document circulating with no clear authoritative version.
• Sensitive documents (the risk register, incident reports) stored with the same broad access as routine files.
• No retention or disposal practice at all—everything accumulates indefinitely, including outdated drafts that could confuse an audit.

Related requirements

• 7.5.2 Creating and updating—how a document is made, before this sub-clause takes over managing it.
• 6.1.3 Risk treatment—the SoA is exactly the kind of high-stakes document this sub-clause is designed to protect.
• Parent clause: 7.5 Documented information.