Documented information

ISO/IEC 20000-1 Clause 7.5 requires you to define, maintain, and control the documented information your service management system (SMS) needs to run effectively, then protect it so it stays available, fit-for-purpose, and secure. Operationalize it by creating a controlled document set (what exists, who owns it, where it lives), enforcing lifecycle controls, and retaining objective evidence. (ISO/IEC 20000-1:2018 Information technology — Service management)

Key takeaways:

• You must keep both ISO-required SMS documentation and any additional documentation your organization needs for effective service management. (ISO/IEC 20000-1:2018 Information technology — Service management)
• “Control” means lifecycle governance: approve, version, publish, restrict access, review, retain, and dispose with traceable records.
• Auditors look for proof the right people can reliably find the right version, and that sensitive documentation is protected from unauthorized change or disclosure.

“Documented information” in ISO/IEC 20000-1 is not a paperwork exercise. It’s a requirement to make your SMS operable: people must be able to find the right instructions, standards, process flows, and records at the moment they need them, and those materials must be current and protected. Clause 7.5 is the control layer that makes everything else auditable. If your incident, change, and problem processes are solid but the procedures are scattered across wikis, shared drives, and chat threads with no ownership, approval, or versioning, you will struggle to demonstrate conformity.

This requirement page is written for Compliance Officers, CCOs, and GRC leads who need a fast path from “requirement text” to “what do we implement on Monday.” It focuses on the minimum set of practical controls that satisfy auditors: a documented information inventory, defined document owners, publication and change rules, access controls aligned to sensitivity, and retention of records that prove the controls run in practice.

If you manage third parties that contribute to service delivery (cloud providers, MSPs, SaaS platforms, call centers), Clause 7.5 also becomes your backbone for ensuring external documents and shared operating procedures are controlled the same way as internal documentation.

Regulatory text

Requirement (excerpt): “The organization's service management system shall include documented information required by this document and documented information determined by the organization as being necessary for the effectiveness of the service management system. Documented information shall be controlled to ensure it is available, suitable for use, and adequately protected.” (ISO/IEC 20000-1:2018 Information technology — Service management)

What the operator must do:

1. Identify what documentation and records your SMS needs (ISO-required plus your own “needed for effectiveness” set).
2. Put controls around that information so staff can access the correct version, it works for its intended purpose, and it is protected against loss, unauthorized access, and unauthorized changes. (ISO/IEC 20000-1:2018 Information technology — Service management)

Plain-English interpretation

Clause 7.5 means: “Write down what you need to run services consistently, then manage those documents and records like production assets.” You must be able to answer, quickly and with evidence:

• What SMS documents exist, and which are required?
• Who approves and owns each one?
• Where is the authoritative copy?
• How do you prevent outdated or unofficial versions from being used?
• How do you protect sensitive service documentation and records?

A practical interpretation that works well in audits: documented information is controlled if it is inventoried, owned, versioned, reviewable, access-controlled, retained, and recoverable.

Who it applies to (entity and operational context)

Applies to: service providers and any organization operating an ISO/IEC 20000-aligned SMS. (ISO/IEC 20000-1:2018 Information technology — Service management)

Operational contexts where it becomes “make or break”:

• Multi-team service delivery: NOC, SRE, service desk, app teams, and security each keep their own playbooks. Without a control layer, the SMS becomes inconsistent.
• Regulated services: finance, healthcare, and critical infrastructure teams often have higher expectations for access control and retention, even if those expectations come from other obligations. Clause 7.5 becomes your harmonization point.
• Third-party operated components: if a third party runs parts of your service, you still need controlled documentation that defines interfaces, responsibilities, escalation paths, and evidence retention expectations.

What you actually need to do (step-by-step)

Step 1: Define your “SMS documented information” scope

Create a written rule that answers:

• What counts as SMS documented information (policies, procedures, standards, templates, records, runbooks)?
• What systems are approved repositories (GRC tool, QMS, document management system, ticketing system, controlled wiki)?
• What is explicitly out of scope (drafts, personal notes), and how drafts become controlled documents.

Output: “Documented Information Standard” (or equivalent) that states your control rules. (ISO/IEC 20000-1:2018 Information technology — Service management)

Step 2: Build a documented information inventory (your audit map)

Create a register (spreadsheet is fine) with:

• Document/record name
• Type (policy/procedure/work instruction/record/template)
• Process area (incident, change, problem, request, service level, etc.)
• Owner (accountable role)
• Approver (role)
• Repository location (authoritative link)
• Version/date
• Classification (public/internal/confidential/restricted)
• Review cadence trigger (event-based or periodic)
• Retention requirement and disposal method

This is your single best audit accelerator because it ties together availability, suitability, and protection in one artifact.

Step 3: Implement lifecycle controls that auditors can test

Minimum control set:

• Creation & approval: define who can author, who must approve, and what “approved” means (e-signature, workflow, or ticket reference).
• Version control: every change produces a new version; old versions are archived and not presented as current.
• Publication control: staff access a single authoritative copy; prevent “shadow SOPs” in shared drives.
• Review & update: define when documents must be reviewed (triggered by major incidents, process changes, tool migrations, org changes, or audit findings).
• Retention & disposal: records are retained long enough to demonstrate operation of the SMS; disposal is deliberate and logged.
• Backup & recovery: repositories are backed up; you can restore documentation and critical records after an outage.

Tip that reduces audit friction: implement “document control” as a lightweight workflow tied to your ticketing system (change request or document change ticket). It creates traceable evidence without extra tooling.

Step 4: Align protection to sensitivity, not convenience

Clause 7.5 requires documented information to be “adequately protected.” (ISO/IEC 20000-1:2018 Information technology — Service management) Turn that into a simple classification scheme and controls:

• Restrict edit rights to owners and delegated maintainers.
• Restrict read rights for sensitive items (security procedures, privileged runbooks, architecture diagrams that expose attack paths, customer-specific operating procedures).
• Log access and changes where feasible (at least for restricted classes).
• Prevent uncontrolled export (where practical) for highly sensitive documents.

Step 5: Extend controls to third-party-provided documentation

Where a third party provides operational documentation (SaaS support runbooks, integration guides, escalation procedures), decide:

• Do you store a controlled copy, or reference the third party’s controlled location?
• How do you verify it stays current (e.g., contract notice clauses, periodic reviews, or change notifications)?
• How do you preserve evidence if the third party portal changes?

You’re not required to duplicate everything, but you must ensure availability and suitability for your SMS operations.

Step 6: Prove it works with objective evidence

Pick a small sample of documents and records across SMS processes and demonstrate:

• Current version is available to the right teams.
• Approval history exists.
• Changes are tracked.
• Access controls match classification.
• Records show processes ran (tickets, approvals, post-incident reviews, change logs).

Auditors test systems by sampling. Design your evidence so sampling is easy.

Required evidence and artifacts to retain

Keep these artifacts ready for audit sampling:

• Documented Information Standard / Document Control Procedure (defines lifecycle controls). (ISO/IEC 20000-1:2018 Information technology — Service management)
• Documented information register (inventory) with owners, versions, locations, classification, retention rules.
• Examples of controlled documents: incident procedure, change procedure, service catalog/service descriptions, SLAs/OLAs, continuity runbooks (whatever your SMS includes).
• Evidence of approval/version history (workflow logs, change tickets, e-signatures, repository history).
• Access control evidence for protected classes (permission screenshots/exports, role mapping).
• Retention/disposal evidence (retention schedule, deletion approvals/logs where applicable).
• Backup/recovery evidence for repositories (backup job logs or restore test evidence where available).

Common exam/audit questions and hangups

Auditors often ask:

• “Show me your list of SMS documented information, and where each item is controlled.”
• “How do you prevent outdated procedures from being used during an incident?”
• “Who approves changes to the change management procedure?”
• “How do you classify and protect sensitive runbooks?”
• “Show evidence that documented information is reviewed and updated when needed.”
• “How do you control documented information maintained by a third party that is required for your service operations?”

Hangups that slow audits:

• No single inventory; teams point to multiple repositories.
• Procedures exist, but there’s no proof of approval or version control.
• Wiki pages with “last updated” dates but no review/approval trail.
• Records exist (tickets), but they’re not clearly tied to SMS requirements or retention rules.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating “documents” and “records” the same.
   Avoid it: define both. Documents guide work (procedures, standards). Records prove work happened (tickets, approvals, reports).

2. Mistake: unmanaged wikis and shared drives as the “system of record.”
   Avoid it: you can use a wiki, but only if you enforce page ownership, approvals, versioning, and access controls.

3. Mistake: inventory built once for certification, then ignored.
   Avoid it: make the register part of onboarding for new processes and part of change management for process/tool changes.

4. Mistake: over-classifying everything as restricted.
   Avoid it: classify based on realistic harm. If no one can access procedures, availability fails.

5. Mistake: third-party documentation left to chance.
   Avoid it: define whether you mirror critical third-party docs, and require change notifications for operationally critical items.

Enforcement context and risk implications

ISO/IEC 20000-1 is a standard used for certification rather than a regulator-enforced rule. Your practical risk is certification failure, surveillance audit findings, and operational failures caused by outdated or inaccessible procedures. Clause 7.5 findings often cascade: if documented information is uncontrolled, auditors will question the effectiveness of incident, change, and problem management evidence because the “rules of the system” are not stable.

Practical 30/60/90-day execution plan

First 30 days: Stabilize and define control rules

• Assign an executive owner for document control (often SMS manager) and operational owners by process area.
• Publish a Documented Information Standard that defines repositories, approval, versioning, classification, and retention expectations. (ISO/IEC 20000-1:2018 Information technology — Service management)
• Pick the authoritative repositories and shut down “official” status for everything else (redirect links, add banners, lock editing where needed).
• Build the first cut of your documented information register, focusing on the most-audited processes (incident, change, problem, request, service level).

Next 60 days: Implement controls and clean up the highest-risk gaps

• Convert high-impact SOPs/runbooks into controlled documents with owners and approval history.
• Implement access controls for restricted documentation and validate that teams can still get what they need during operations.
• Define retention rules for key SMS records (tickets, approvals, PIRs) and confirm your systems can meet them.
• Establish a change mechanism for documentation (document change tickets) and run it for real changes.

Next 90 days: Prove operating effectiveness and scale

• Run an internal sampling test: pick documents and records from each major SMS process and verify lifecycle controls end-to-end.
• Train process owners and service leads on “how documentation changes happen here.”
• Extend the register to cover the full SMS scope, including third-party-provided operational documentation.
• If you need a workflow backbone, configure Daydream to manage the document inventory, ownership, review tasks, and evidence linking so audits become a retrieval exercise instead of a scavenger hunt.

Frequently Asked Questions

What counts as “documented information” under ISO/IEC 20000-1 Clause 7.5?

It includes ISO-required SMS documentation plus anything you determine is necessary for the SMS to be effective. Treat policies, procedures, standards, templates, and operational records as in scope once they govern or prove service management work. (ISO/IEC 20000-1:2018 Information technology — Service management)

Do we need a formal document management system to meet the documented information requirement?

No. You need controls that work: ownership, approval, version history, access control, and retrievability. A wiki or shared repository can pass if those controls are enforced consistently and you can show evidence. (ISO/IEC 20000-1:2018 Information technology — Service management)

How do auditors test “available and suitable for use”?

They sample documents and ask users to retrieve the current version, then check that it’s complete and workable for the task. If teams rely on tribal knowledge or conflicting copies, “availability” and “suitability” will fail in practice. (ISO/IEC 20000-1:2018 Information technology — Service management)

What’s the minimum evidence set we should have ready on audit day?

A documented information control procedure, a current inventory/register, and sample proof of versioning/approval/access control for several key SMS documents. Also be ready to show records (tickets, approvals, reviews) that demonstrate the SMS runs as documented. (ISO/IEC 20000-1:2018 Information technology — Service management)

How should we handle third-party documentation that we rely on for service delivery?

Decide whether to store a controlled copy or reference the third party’s controlled source, then define how you keep it current and available during outages. If the third party portal is your only source, plan for continuity and evidence preservation. (ISO/IEC 20000-1:2018 Information technology — Service management)

Our procedures change often. How do we stay compliant without slowing operations?

Tie document updates to the same workflow you already use for operational change (a change ticket or a documented approval flow). Keep the procedure lightweight, but require an owner, a version increment, and an approval record for every published change. (ISO/IEC 20000-1:2018 Information technology — Service management)