Creating and updating

To meet ISO 22301 Clause 7.5.2, you must control how BCMS documented information is created and updated so every document is identifiable, in an appropriate format, and formally reviewed and approved before use. Operationalize this by standardizing document metadata, enforcing version control, and running a consistent review/approval workflow with retained evidence. ¹

Key takeaways:

• Standardize document identification (title, owner, date, version, unique reference) for every BCMS artifact.
• Control format and media (templates, repositories, access controls) so staff use the right, current documents.
• Require documented review and approval for suitability and adequacy, with auditable evidence of who approved what and when.

Clause 7.5.2 is a deceptively small requirement that frequently creates audit friction because it sits underneath everything else in the BCMS. Your BIA, risk assessment outputs, business continuity plans, exercise results, incident learnings, and corrective actions can be solid, but if you cannot prove documents are identified, controlled, reviewed, and approved, auditors will question whether the BCMS is managed or improvised.

For a Compliance Officer, CCO, or GRC lead, the practical goal is straightforward: create a repeatable “document control” operating model for business continuity documentation that works across teams and tools. That means deciding what counts as documented information, defining mandatory metadata, choosing where the source of truth lives, and establishing who can draft, who must review, and who approves. You also need evidence that these steps happen consistently, not only when an audit is near.

This page translates the requirement into a workflow you can implement quickly, with artifacts to retain and exam-style questions you should be able to answer on demand. ¹

Regulatory text

ISO 22301:2019 Clause 7.5.2 states: “When creating and updating documented information, ensure appropriate identification, format, and review and approval.” ¹

What the operator must do

You must implement document controls so that:

1. Identification: Each BCMS document is uniquely and clearly identified (for example: title, date, author/owner, and a reference number).
2. Format: The document is presented in an appropriate format and medium (for example: approved templates, controlled repository, readable/exportable form).
3. Review and approval: Updates and new documents go through a defined review and approval process for suitability and adequacy before being issued or used.
   All three must be demonstrable through retained records. ¹

Plain-English interpretation (requirement-level)

If someone asks, “Show me the current continuity plan for Process X,” you must be able to produce the current approved version quickly, show who approved it, and show that people are not using a stale copy. If someone updates a plan after an exercise, you must be able to show what changed, why it changed, who reviewed it, and who approved it.

This is not a “write a policy” requirement. It is an operational control over the full document lifecycle: draft → review → approve → publish → revise → retire.

Who it applies to

Entities

• Any organization operating a Business Continuity Management System (BCMS) aligned to ISO 22301. ¹

Operational context (where this shows up)

• Central GRC/BCMS function that owns the management system
• Business unit plan owners (operations, customer support, finance, etc.)
• IT/DR plan owners
• Teams producing records: exercises, incidents, corrective actions, management review outputs
• Third parties that create or host BCMS documentation (for example, an outsourced BC planning firm or a platform provider). Even if execution is outsourced, accountability for control stays internal.

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

Step 1: Define “documented information” scope for the BCMS

Create a BCMS Document Register that lists each controlled document type and key instances (or at least categories), such as:

• BCMS policy and objectives
• BIA methodology and results
• Risk assessment methodology and results
• Business continuity plans and IT disaster recovery plans
• Exercise and test plans, results, and after-action reports
• Incident learnings relevant to continuity
• Corrective actions and change logs
• Management review outputs

Outcome: you remove ambiguity about what must follow the control process. ¹

Step 2: Standardize identification metadata (make it non-optional)

Create a required metadata schema and enforce it through templates and repository fields.

Minimum fields to require

• Document title
• Document owner (role-based where possible)
• Unique reference number (or unique ID)
• Version number
• Effective date
• Approval date
• Approver(s)
• Classification/handling label (aligned to your internal scheme)
• Status (Draft / In Review / Approved / Retired)

Practical tip: if your repository cannot enforce fields, make the metadata part of the document header and require it in templates.

Step 3: Control format and medium (publish from a single source of truth)

Decide where “approved documents live” and block alternatives.

Operator decisions

• Repository: SharePoint, Confluence, a GRC tool, or a BCMS platform
• File formats: define acceptable editable vs published formats (for example: editable working docs vs locked PDFs for issued plans)
• Access controls: restrict edit rights; grant read rights broadly to relevant responders
• Offline availability: if you require offline copies for resilience, control how they are produced and refreshed so they do not become the de facto working version

The goal is not a perfect tool. The goal is a controlled issuance process so people can find the right document fast and you can prove it is current. ¹

Step 4: Implement a review and approval workflow (with clear RACI)

Define who drafts, who reviews, and who approves for each document type.

Example RACI (adjust to your org)

• Plan owner (Business Unit): Drafts and updates the plan
• BCMS manager / GRC: Reviews for BCMS requirements, structure, completeness
• IT/Security (as needed): Reviews technical recovery dependencies
• Approving authority: Business unit leader or delegated executive responsible for the process

Suitability and adequacy criteria Write down what reviewers check. Keep it short and testable:

• Document matches the approved template and includes required sections
• Roles and contact paths are current
• Recovery assumptions align to BIA outputs
• Dependencies and third-party contacts are listed
• Required approvals are present
• Links/attachments function and are accessible

Step 5: Control changes (updating discipline)

Define update triggers and how you record changes.

Common triggers

• Post-exercise improvements
• Organizational changes (roles, org structure)
• Material process changes (new systems, new sites)
• Third-party changes impacting recovery
• Incident learnings

Change control mechanics

• Maintain a revision history section (what changed, when, who, why)
• Keep prior versions retained and retrievable
• Ensure the same review/approval steps occur for updates, not only for net-new documents ¹

Step 6: Retire and prevent use of obsolete documents

Obsolete plans cause real operational harm during an event. Set a rule:

• Retired documents get a “Retired/Obsolete” watermark or status
• They move to an archive library with restricted access
• Links in runbooks point only to the current approved location
• Any printed binders have a controlled reprint process (owner + date) so they can be invalidated and replaced

Step 7: Make it auditable (evidence by design)

If you cannot produce evidence quickly, auditors will assume the process is informal. Build evidence capture into the workflow:

• repository versioning enabled
• approval captured via workflow tool, e-signature, or tracked decision record
• review comments retained or summarized with disposition

Daydream note (optional operational shortcut): teams often adopt Daydream to standardize document registers, approvals, and audit-ready evidence across programs without building a custom SharePoint workflow. Use it if your bottleneck is coordination and evidence retrieval rather than document drafting.

Required evidence and artifacts to retain

Keep these artifacts ready for sampling:

• Document Control Procedure / SOP for BCMS documented information (identification, format rules, review and approval steps)
• BCMS Document Register with owners, status, versions, and locations
• Templates with mandatory headers/metadata
• Approval records (workflow logs, e-signature record, email approval captured into the repository, or approval minutes)
• Version history and change logs for sampled documents
• Access control evidence (library permissions, role groups, or screenshots plus exportable permission lists)
• Archive/retention evidence showing obsolete docs are controlled and not in active circulation
  These map directly to identification, format, and review/approval expectations in Clause 7.5.2. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me the latest approved version of Plan X and the prior version. What changed and who approved it?”
• “How do you prevent staff from using locally saved copies?”
• “What metadata must appear on every BCMS document?”
• “How do you validate suitability and adequacy? Is there a checklist?”
• “Who has authority to approve updates to BIAs and continuity plans?”
• “Where is your document register and how do you keep it current?”

Common hangup: teams can show documents, but approvals live in email and are not linked to the document record. Fix this by requiring approvals to be recorded in the same system as the document.

Frequent implementation mistakes (and how to avoid them)

1. Relying on naming conventions alone
   Fix: enforce metadata in templates and maintain a register. Naming helps, but it is not evidence by itself.

2. Approvals that happen “in meetings” with no record
   Fix: capture approvals in meeting minutes with document IDs and versions, then store the minutes with the document or link them in the register.

3. No clear approver for each document type
   Fix: define approvers by role and include them in the register. Avoid “BC team approves everything” if the business owns the process.

4. Uncontrolled PDFs and binders
   Fix: treat issued PDFs as published outputs from a controlled source, and require a controlled refresh for offline copies.

5. Updates bypass review because they are “minor edits”
   Fix: define what counts as minor (for example, typos) versus substantive changes. Substantive changes must re-enter the workflow.

Risk implications (why operators should care)

Poor document control increases the chance that, during a disruption, teams execute the wrong steps, call the wrong contacts, or follow outdated recovery assumptions. That creates operational risk and can turn a manageable incident into a prolonged outage. From an assurance standpoint, weak evidence of review/approval undermines confidence in every other BCMS deliverable because auditors cannot verify governance over the system artifacts. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Appoint a BCMS document control owner (usually BCMS manager or GRC).
• Publish a one-page SOP: required metadata, where documents live, who approves what.
• Stand up the BCMS Document Register and populate top-tier documents first (policy, BIA outputs, critical plans).
• Freeze uncontrolled repositories by communicating “approved docs live here” and limiting edit rights.

Days 31–60 (operationalize workflow and evidence)

• Implement templates with mandatory headers and revision history.
• Configure repository versioning and an approval workflow (tool-based or controlled manual steps).
• Run a pilot: select a small set of plans, force an update through the workflow, and confirm evidence output is audit-ready.
• Train plan owners and reviewers using a short checklist that defines “suitable and adequate.”

Days 61–90 (scale and audit-proof)

• Expand coverage to remaining BCMS documents and records (exercise outputs, corrective actions, management review artifacts).
• Implement archive controls and retire obsolete docs formally.
• Perform an internal sampling review: pick documents and validate you can produce identification, format controls, and approval evidence fast.
• If coordination and evidence retrieval remain painful, consider consolidating the workflow and register in Daydream to reduce manual chasing and missing artifacts.

Frequently Asked Questions

What counts as “appropriate identification” under ISO 22301 Clause 7.5.2?

Treat it as mandatory document metadata: clear title, owner/author, date, version, and a unique reference number so you can distinguish drafts, approved versions, and obsolete copies. ¹

Can we approve BCMS documents by email?

Yes, but only if the approval is captured and linked to the controlled document record (for example, stored in the same repository with version reference). If you cannot produce the email trail reliably during an audit, move approvals into a workflow tool. ¹

Do minor edits require re-approval?

Define “minor” in your SOP. Typos may not need re-approval, but any change affecting roles, steps, dependencies, or recovery assumptions should re-enter review and approval because it impacts suitability and adequacy. ¹

How do we control offline copies without breaking resilience needs?

Issue offline copies as controlled outputs with a visible print/export date and version, and require periodic refresh by the document owner. Make the online repository the authoritative source so offline copies never become the working master. ¹

Who should be the approver for continuity plans, GRC or the business?

Approval should sit with the accountable business/process owner (or delegated leadership) because they own execution. GRC/BCMS should review for structure and governance and confirm the approval happened. ¹

What evidence is most persuasive to auditors for this clause?

A document register plus system-native version history and approval records tied to specific document versions. Auditors want to sample and trace from the document to its review and approval without guessing. ¹

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements