Implementation of solutions

ISO 22301 Clause 8.3.5 requires you to put your selected business continuity strategies and solutions into real operation, not just approve them on paper. You must deploy them, integrate them into day-to-day processes, and prove they can meet your recovery objectives through implemented capabilities, trained ownership, and retained evidence. ¹

Key takeaways:

• Implementation means “operationally deployed and usable,” not “documented and planned.” ¹
• Treat each solution like a deliverable: owner, build/configure, integrate, train, test, and evidence package. ¹
• Auditors look for traceability from strategy selection to working capability that meets stated recovery objectives. ¹

Clause 8.3.5 is the point where business continuity stops being a set of intentions and becomes an operating capability. Your organization has already selected business continuity strategies and solutions under the earlier parts of ISO 22301 Clause 8.3. The requirement here is straightforward: implement what you selected. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is governance and proof. Implementation work is usually owned by IT, Security, Facilities, Operations, and business unit leaders, but you are accountable for making the program auditable: clear scope, assigned ownership, measurable acceptance criteria tied to recovery objectives, and evidence that demonstrates solutions exist and work as intended. ¹

This page translates Clause 8.3.5 into a requirement-level checklist you can run as an execution plan. It also includes the artifacts to retain and the exam-style questions you should be able to answer without scrambling.

Regulatory text

Text (verbatim): “The organization shall implement the selected business continuity strategies and solutions.” ¹

Operator interpretation: You need to (1) take the strategies/solutions you already selected and (2) build, configure, deploy, and embed them so they are available during disruption and aligned to your recovery objectives. A strategy that is “approved” but not deployed, funded, owned, trained, and tested is not implemented. ¹

Plain-English meaning

• If you selected alternate site working, you must have the site(s), access procedures, capacity assumptions, communications methods, and leadership roles in place.
• If you selected technology resilience (backup, replication, failover), it must be configured, monitored, accessible in an incident, and operated by trained staff.
• If you selected manual workarounds, the materials, forms, job aids, and training must exist and be reachable when core systems are down.

Clause 8.3.5 is satisfied by implemented capabilities plus evidence that they are operational and maintained under your management system. ¹

Who it applies to

Entity scope: Any organization implementing an ISO 22301 business continuity management system. ¹

Operational context: This requirement lands across multiple teams:

• Business owners who must adopt continuity procedures and staffing models.
• IT/Security teams responsible for resilience engineering, identity/access in emergencies, backups, replication, and system recovery runbooks.
• Facilities/Workplace teams responsible for alternate workspace arrangements and physical access.
• Third parties where solutions depend on external services (cloud providers, telecom, payroll processors, critical suppliers). You must implement the parts you control and contractually secure the parts they control.

Where audits focus: Auditors typically sample a small set of critical processes and trace end-to-end: selected solution → implemented capability → evidence → ability to meet recovery objectives. ¹

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

1) Build an “implementation register” that ties strategies to deliverables

Create a register (spreadsheet, GRC workflow, or a tool like Daydream) that lists each selected strategy/solution and the concrete deliverables required to make it real. Include:

• Solution description and scope boundary
• Process/system(s) supported
• Assigned executive sponsor and operational owner
• Dependencies (people, facilities, IT, third party services)
• Acceptance criteria tied to your recovery objectives (use your organization’s RTO/RPO/MAO language as defined internally)
• Evidence expected (see below)

This register becomes your audit map for Clause 8.3.5. ¹

2) Convert each solution into an implementation work package

For each solution, define:

• Design decisions (what you built and why, aligned to the selected strategy)
• Build/configuration tasks (technical controls, process changes, documentation)
• Integration points (how it fits into business-as-usual operations and incident response)
• Operational readiness (training, on-call coverage, access, communications)
• Validation method (exercise, technical test, walkthrough, failover proof)

A common control gap: solutions are implemented in technology but not integrated into business operations (for example, backups exist but restore access is unclear during an incident). Clause 8.3.5 expects both. ¹

3) Implement access, authority, and “break-glass” operation for disruptions

Many continuity solutions fail because teams cannot execute them under stress:

• Ensure named roles have the authority to declare continuity mode, initiate failover, and spend emergency funds within defined guardrails.
• Pre-stage emergency access paths (for example, alternate communication channels and emergency contact trees).
• Ensure third party escalation paths are documented and tested (account teams, premium support, emergency numbers).

This is implementation work, not policy writing. ¹

4) Train owners and operators, then embed into routine operations

Implementation is incomplete if only one person knows how the solution works. Build:

• Role-based training (operators vs approvers vs business users)
• Quick-reference job aids for disruption conditions
• Routine checks where feasible (monitoring, periodic restore checks, call tree validation)

Training records and job aids are part of the evidence set because they show the solution can be executed. ¹

5) Validate with exercises/tests that match the solution type

Pick validation methods that create credible proof:

• Technical solutions: controlled failover, restore, or recovery run-through with logs.
• Process solutions: tabletop exercises plus a timed walkthrough of key steps, including communications.
• Third party dependencies: joint exercise or documented evidence of the third party’s capability plus your internal execution steps.

Your goal is to show the implemented solution can meet recovery objectives “within defined timeframes” as established by your program, and that your organization can execute it repeatedly. ¹

6) Close the loop with change management and continuous ownership

After implementation:

• Put solutions under change control (system changes, vendor changes, org changes).
• Update continuity plans, runbooks, and training triggers.
• Capture lessons learned from tests and disruptions and feed corrective actions into your management system.

This prevents “implemented once, then drifted” failure modes that auditors spot quickly. ¹

Required evidence and artifacts to retain

Retain evidence that proves operational implementation, not just intent:

Governance and traceability

• Strategy/solution selection record and approval
• Implementation register with owners, status, and acceptance criteria
• Risk acceptance memos for any partial implementation or deferred scope

Technical and operational artifacts

• Architecture diagrams, configuration baselines, runbooks, and operating procedures
• Backup/restore or failover procedures and access requirements
• Inventory of required tools, devices, or alternate workspace resources
• Third party contracts/SLAs and escalation paths relevant to continuity

Readiness and validation

• Training materials and completion records for key roles
• Exercise/test plans, results, logs, issues, and corrective action tracking
• Evidence of remediation completion (tickets, change records, updated runbooks)

Daydream can help by structuring the implementation register, attaching evidence directly to each solution, and keeping an auditable chain from strategy decision to validated capability. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me one critical process and walk me from selected strategy to implemented solution to test evidence.” ¹
• “Who owns execution during an incident, and what proves they are trained and have access?” ¹
• “What third parties are required for recovery, and how do you know they will perform under disruption?” ¹
• “What changed since the last test, and how did you ensure continuity controls still work?” ¹

Hangups that slow audits:

• Solutions implemented for some systems but not for the “supporting plumbing” (identity, DNS, telecom, endpoints, privileged access).
• Evidence scattered across ticketing systems with no mapping to the selected solution.
• Overreliance on third party assurances without internal execution procedures.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating documentation as implementation.
   Fix: Require objective proof (configured systems, trained people, test output, accessible runbooks). ¹

2. Mistake: Building a solution that can’t be executed under incident conditions.
   Fix: Pre-stage access, communications, and authority. Validate with realistic exercises. ¹

3. Mistake: Leaving third party dependencies implicit.
   Fix: Identify third party dependencies per solution, record escalation paths, and confirm contract terms support your recovery approach. ¹

4. Mistake: No acceptance criteria tied to recovery objectives.
   Fix: Define “done” in operational terms: what must be available, who does what, and what evidence demonstrates readiness against your objectives. ¹

Enforcement context and risk implications

ISO 22301 is a standard, not a regulator, so “enforcement” typically occurs through certification audits, customer due diligence, contractual commitments, and internal governance. The risk of weak implementation is operational: strategies that look strong in committee fail during an outage, which creates business interruption, customer harm, and downstream regulatory exposure under other regimes that expect operational resilience. Keep your claims accurate: if a solution is partially implemented, document the limitation and treat it as a risk decision, not a marketing statement. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize governance and scope)

• Build the implementation register for all selected strategies/solutions, including owners and dependencies. ¹
• Define acceptance criteria per solution tied to your recovery objectives and decision records. ¹
• Identify the highest-risk gaps: missing owners, unfunded work, third party blockers, or unclear execution authority. ¹

Days 31–60 (implement and integrate)

• Convert each solution into work packages and push them through delivery teams (IT, Ops, Facilities, Security). ¹
• Draft or update runbooks and embed procedures into BAU operations (on-call, monitoring, access management, communications). ¹
• Stand up evidence capture: a single place to store artifacts mapped to each solution (Daydream, a GRC repository, or controlled folders with clear indexing). ¹

Days 61–90 (validate and harden)

• Run solution-level validation (technical tests, exercises, walkthroughs) with recorded outcomes and issues. ¹
• Close corrective actions that block recovery objectives; document risk acceptance where remediation cannot be completed yet. ¹
• Prepare an audit-ready narrative for sampled processes: strategy → solution → implementation → test evidence → ownership. ¹

Frequently Asked Questions

What counts as “implemented” for ISO 22301 Clause 8.3.5?

Implemented means the solution exists in operational form: built/configured, owned, integrated into procedures, and executable during a disruption with evidence to prove it. A proposal, design, or policy alone does not meet the clause. ¹

Do we need to test every solution to claim it’s implemented?

Clause 8.3.5 focuses on implementation, but in practice you need validation evidence to prove the implemented solution works and supports recovery objectives. Choose validation proportional to the solution type and risk. ¹

How should we handle third party dependencies in continuity solutions?

Document where you rely on third parties, ensure contracts and escalation paths support your recovery approach, and retain evidence of coordination or assurance. Also document your internal steps to invoke third party support during an incident. ¹

Our strategy is selected, but funding is pending. Are we nonconformant?

If the solution is not implemented, you have a gap against Clause 8.3.5. Record it transparently in your implementation register, assign ownership, and treat it as a management decision with tracked actions and risk acceptance where applicable. ¹

What evidence is most persuasive to an auditor?

Traceable evidence: an implementation register mapped to each solution, current runbooks/procedures, training records for operators, and test or exercise outputs that show the solution works under defined recovery objectives. ¹

How can a GRC team operationalize this without owning the technical work?

Run governance: define acceptance criteria, assign accountable owners, track delivery status, and collect evidence in an auditable structure. Tools like Daydream help by tying tasks and artifacts to each solution and making audit sampling fast. ¹

Footnotes

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