BIA and risk assessment — General

“BIA and risk assessment — General” is a deceptively short requirement that drives most of the real work in a business continuity management system (BCMS). ISO 22301:2019 Clause 8.2.1 does not ask for a one-time BIA slide deck or a risk register that lives in a separate GRC tool with no connection to continuity planning. It asks for a process that you establish, implement, maintain, and continually improve. That wording is operational: you must be able to show how the work is performed, how it stays current as the business changes, and how you make it better when you learn from incidents, exercises, audits, or near misses. ¹

If you are a Compliance Officer, CCO, or GRC lead, your fastest path is to define the “minimum viable BCMS analytics loop”: identify what must be protected (BIA), identify what can go wrong (risk assessment), decide what level of recovery is required, and feed that into continuity strategies, plans, and exercising. The rest is governance and evidence.

Regulatory text

ISO 22301:2019 Clause 8.2.1: “The organization shall establish, implement, maintain and continually improve a process for BIA and risk assessment.” ¹

What the operator must do (requirement-level interpretation):

• Establish: Define and approve a documented BIA and risk assessment process (scope, roles, method, criteria, outputs, and approval).
• Implement: Execute the process in practice across the BCMS scope, not as an ad hoc effort.
• Maintain: Keep results and the process current as your services, third parties, technology, locations, and operating model change.
• Continually improve: Measure effectiveness and make controlled updates based on lessons learned (incidents, exercises, internal audit findings, management review outcomes). ¹

Plain-English interpretation

You need a repeatable way to answer two questions, then keep that answer current:

1. BIA: “If this activity stops, what is the impact over time, and how fast must we recover?”
2. Risk assessment: “What scenarios could cause that stoppage, and what controls reduce likelihood or impact?”

Auditors will test whether your BIA and risk outputs actually drive decisions: recovery time targets, minimum service levels, dependency mapping (including critical third parties), and continuity/exercise priorities.

Who it applies to

Entity scope: Any organization operating (or aligning to) an ISO 22301 BCMS, across the defined BCMS scope. ¹

Operational context where it bites hardest:

• Multi-service organizations where “critical” is contested across business lines.
• Technology-dependent operations where recovery depends on systems, data, and identity services.
• Third-party-dependent services (payment processors, cloud platforms, MSPs, call centers, logistics providers). Treat third parties as dependencies in the BIA and as risk sources in the risk assessment.

Role coverage (typical):

• BCMS/Resilience owner (process owner)
• Business process owners (impact owners)
• IT/service owners (technical feasibility inputs)
• Third-party risk management (dependency and contract inputs)
• Compliance/GRC (governance, evidence, audit readiness)

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

1) Define the combined BIA + risk assessment process (document it)

Create a procedure that answers, at minimum:

• Scope: Which products/services, sites, teams, and supporting assets are in scope.
• Method: Workshop vs. questionnaire vs. system-of-record extraction; how you normalize scoring.
• Impact categories and rating criteria: Use the same definitions every cycle.
• Time-to-impact model: How impact changes over time, since recovery urgency depends on time.
• Risk scenario library: A starting set of plausible disruption scenarios, including third-party failures and cyber events.
• Triggers: What events force an out-of-cycle refresh (major system change, acquisition, new critical third party, material incident).
• Outputs: What documents/records must exist at the end (see “Evidence” below).
• Approvals: Who signs off on results and on changes to the method. ¹

Practical decision: Pick one scoring model you can defend and repeat. Consistency beats sophistication.

2) Build the inventory you will assess (the “what”)

You cannot run a credible BIA without a controlled list of:

• Business services / products in scope
• Key activities/processes supporting those services
• Dependencies: people/roles, applications, infrastructure, data, facilities, and critical third parties
• Upstream/downstream linkages (what breaks if this breaks)

If you already have CMDB/service catalogs and third-party inventories, reconcile naming and ownership so you can trace dependencies without manual translation.

3) Execute the BIA (impact and recovery requirements)

Run BIA sessions with accountable owners and capture:

• Critical activities and how interruption impacts customers, operations, compliance obligations, and finances (use your defined categories).
• Maximum tolerable disruption and recovery objectives (document your chosen terms and ensure they are used consistently).
• Minimum acceptable service levels during disruption (what “degraded but acceptable” means).
• Peak periods and seasonal constraints.
• Dependency confirmation: validate the real-world dependencies, including named third parties and single points of failure.

Operator tip: Force a choice on “what must be restored first.” Many BIAs fail because everything is rated “high.”

4) Execute the risk assessment (threats, vulnerabilities, controls)

For each critical activity/service (or group of similar services):

• Identify disruption scenarios (include internal failures, facility loss, cyber events, third-party outages, key person loss).
• Rate risk using your method (likelihood and impact, or equivalent).
• Map existing controls and planned treatments (mitigations, transfer, acceptance).
• Record risk owners and due dates for treatments.

Keep the risk assessment tied to continuity outcomes. If a risk is accepted, document what continuity capability still covers the residual exposure.

5) Convert BIA + risk outputs into BCMS requirements and work tickets

This is where audits are won or lost. Create traceability from:

• BIA recovery needs → continuity strategies (resourcing, alternate site, technology recovery, third-party contract requirements)
• Risk scenarios → preventive controls and response playbooks
• Priorities → exercise schedule and test objectives

If you use a platform such as Daydream, treat it as your system of record for: scope inventory, workshop records, scoring, approvals, and traceability links to continuity plans and third-party records. The point is not tooling; it is defensible evidence and repeatability.

6) “Maintain” through change management

Define and enforce refresh triggers, such as:

• New or changed critical service
• Material architecture change (identity, network, core app)
• New critical third party or material contract change
• Major incident or exercise failure

Make the trigger operational: integrate with change advisory boards, procurement/TPRM intake, and incident postmortems so BIA/risk refresh tasks get created and tracked.

7) “Continually improve” through measured feedback

Continual improvement needs a feedback loop:

• Track issues found during exercises and incidents.
• Track overdue risk treatments that undermine recovery assumptions.
• Update scoring criteria when it no longer reflects the business reality.
• Document method changes with rationale and approval. ¹

Required evidence and artifacts to retain

Auditors typically want to see a clean chain from method → execution → decisions.

Core artifacts (minimum set):

• Approved BIA and risk assessment procedure (version-controlled)
• BCMS scope statement and assessed inventory
• BIA worksheets/interview notes, including attendees and dates
• Impact rating criteria and time-to-impact definitions
• Risk assessment records (scenario list, scoring, controls, treatments, owners)
• Approval records (business owner sign-off and BCMS owner approval)
• Change log showing updates to results and method over time
• Traceability matrix: critical activities/services → recovery requirements → strategies/plans/exercises → third-party dependencies

Evidence quality tips:

• Timestamp everything.
• Record who made the decision, not just the score.
• Keep “why” notes when trade-offs occur (e.g., recovery target adjusted due to feasibility).

Common exam/audit questions and hangups

Use these to prep leadership and process owners:

1. “Show me your documented process.” Auditors will ask for the procedure, not just the outputs.
2. “How did you decide what’s in scope?” Expect scrutiny if a major revenue service is excluded.
3. “Prove that BIA results drove continuity plans.” They will sample one critical service and walk the chain.
4. “How do you keep this current?” They will test refresh triggers against real organizational changes.
5. “What changed since the last cycle?” If the answer is “nothing,” expect deeper probing.
6. “How are third parties reflected?” Weak dependency mapping is a frequent finding, especially where cloud and outsourced operations dominate.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating BIA as a one-time project	Violates “maintain” and “continually improve” expectations	Put a named owner on the process and define refresh triggers
Scores with no decision	Auditors want actionability	Require outputs: recovery requirements, priorities, and assigned work
“Everything is critical”	Makes recovery impossible to execute	Force ranking and define what “degraded acceptable” means
Ignoring third-party dependencies	Breaks recovery assumptions	Include third parties in dependency mapping and scenario analysis
Method changes without record	Looks like result manipulation	Version control criteria and document rationale/approval

Execution plan (30/60/90)

You asked for quick operationalization; this plan is outcome-based and avoids made-up time-on-task claims.

First 30 days (Immediate)

• Appoint a single process owner and backups.
• Draft and approve the BIA + risk assessment procedure (scope, method, triggers, outputs).
• Build the initial in-scope inventory (services, owners, key dependencies, critical third parties).
• Select a system of record for artifacts and approvals (spreadsheets can work short-term; Daydream fits well if you need workflow and traceability).

Next 60 days (Near-term)

• Run BIA sessions for the most critical services first (the ones with the highest customer impact or regulatory exposure).
• Run risk assessments for the same services using a standard scenario library.
• Produce the first traceability view from BIA/risk outputs to continuity strategy decisions and plan updates.
• Establish the refresh trigger workflow with Change Management, Procurement/TPRM, and Incident Management.

Next 90 days (Stabilize and improve)

• Expand coverage across the full BCMS scope.
• Run a management review of findings: top dependencies, top risks, and where recovery targets are infeasible.
• Update continuity exercises to test the highest-risk and highest-impact assumptions.
• Record method improvements (criteria tweaks, scenario library updates) and get approvals.

Frequently Asked Questions

Do I need separate documents for the BIA and the risk assessment?

ISO 22301 Clause 8.2.1 requires a process covering both, not a specific document structure. You can combine them, but keep outputs distinct enough that you can trace impacts to recovery requirements and risks to treatments. ¹

How do I prove “continual improvement” without inventing metrics?

Keep a change log that ties improvements to real inputs: incident learnings, exercise outcomes, audit findings, or leadership decisions. Version-control the method and show approvals for changes. ¹

What’s the minimum viable scope for a first pass?

Start with the services and activities inside your declared BCMS scope, prioritizing those with the highest operational and customer impact. Document the rationale for sequencing so auditors see intent and governance. ¹

Where do third parties fit in this requirement?

Treat critical third parties as dependencies in the BIA (what you cannot deliver without) and as disruption scenarios in the risk assessment (what can fail and why). Keep evidence that third-party assumptions are reflected in continuity strategies and contracts where appropriate. ¹

What evidence matters most in an ISO 22301 audit?

Auditors typically sample a critical service and test traceability: BIA inputs, scoring criteria, approvals, risk scenarios, treatments, and the continuity plan/exercise that reflects those results. Missing approvals and missing traceability are common failure points. ¹

Can a GRC tool replace a BCMS tool for this?

It can, if it supports controlled criteria, repeatable workflows, approvals, and traceability to continuity plans and exercises. Many teams keep the system of record in Daydream for resilience workflows and link out to enterprise GRC where risk treatments are managed.

Footnotes

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