# Business Impact Analysis: [Organization or scope name]

> A stand-alone business impact analysis (BIA) that identifies the
> organization's prioritized activities, assesses how the impact of a
> disruption grows over time, and sets the maximum tolerable period of
> disruption (MTPD), recovery time objective (RTO), recovery point
> objective (RPO) and minimum business continuity objective (MBCO) for
> each activity, together with the people, information, ICT, facilities
> and suppliers each one needs. Structure aligned with ISO 22301:2019
> with Amd 1:2024 (clause 8.2.2) and ISO/TS 22317:2021, with NIST SP
> 800-34 Rev. 1 as a free alternative method. The results feed the
> business continuity plan, the disaster recovery plan and the risk
> assessment. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Run the BIA before you choose continuity strategies. A BIA answers
  "what matters most and how fast", the risk assessment answers "what
  could disrupt it", and the plans answer "how we recover".
- Work top down: products and services, then the activities that deliver
  them, then the resources each activity needs. Interview activity
  owners, do not fill the tables from a desk.
- Agree the impact scale (section 2) with top management before any
  interview. Changing the scale halfway invalidates earlier scores.
- Time objectives must fit together: RTO shorter than MTPD with margin,
  supporting ICT RTO no longer than the activity RTO, RPO matched to how
  much rework the activity can absorb.
- The worked example follows a fictional freight forwarder, Tervane
  Logistics. Every figure marked *Example* is invented.
- Related documents: Business Continuity (`compliance/business-continuity`),
  Disaster Recovery Plan (`ops/disaster-recovery-plan`), Risk Methodology
  (`compliance/risk-methodology`), Risk Register (`compliance/risk-register`),
  Asset Inventory (`compliance/asset-inventory`), Supplier Security
  Assessment (`compliance/supplier-security-assessment`), Backup Policy
  (`ops/backup-policy`), Capacity Plan (`ops/capacity-plan`).
-->

## Document control

<!-- Guidance: Identify the scope covered by this BIA cycle and who signed off the impact criteria. A BIA without a named approver for the criteria is hard to defend at audit. -->

| Field | Value |
|---|---|
| Document ID | [BIA-2026-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@business-continuity-manager] |
| Approvers/reviewers | [@coo], [@cio], [@cfo], [@head-of-risk], [activity owners] |
| Scope of this BIA | [Legal entities, sites, products and services covered] |
| BIA cycle | [Annual / After significant change], reference date YYYY-MM-DD |
| Linked management system | [ISO 22301 BCMS / ISO/IEC 27001 ISMS / None] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Top management sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information officer | [@name] | [Decision] | YYYY-MM-DD |
| Chief financial officer (impact criteria) | [@name] | [Decision] | YYYY-MM-DD |
| Business continuity manager | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft, impact criteria agreed |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Interviews with five activity owners recorded |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved, objectives handed to BCP and DR owners |

## Contents

1. Purpose, scope and method
2. Impact categories and criteria
3. Products, services and activities
4. Impact over time
5. Time objectives
6. Prioritized activities
7. Dependencies and resources
8. Gap analysis
9. Outputs and traceability
10. Review and maintenance
11. Glossary and references

## 1. Purpose, scope and method

<!-- Guidance: State why this BIA exists, what it covers and how it was done. Questions: which products and services are in scope? Which sites and entities? Who was interviewed? Pitfall: a BIA scoped to "IT systems" only. ISO 22301 expects the BIA to start from the products and services the organization delivers, then work down to activities and resources. -->

### 1.1 Purpose

This BIA determines which activities of [Organization] must be resumed
first after a disruption, how quickly, at what minimum level, and with
which resources. Its results are the basis for the continuity
strategies and solutions in [BCP reference] and the recovery design in
[DR plan reference].

### 1.2 Scope

| Item | In scope | Out of scope (with reason) |
|---|---|---|
| Legal entities | [Entity names] | [Entity, reason] |
| Sites | [Sites] | [Site, reason] |
| Products and services | [List] | [List, reason] |
| Time horizon assessed | [4 hours to 2 weeks] | |
| *Example:* Tervane Logistics | Head office, two cross-dock warehouses, customs brokerage, freight forwarding | Leased truck fleet (operated by a contractor under its own continuity plan) |

### 1.3 Method

The method follows the steps that ISO 22301:2019 clause 8.2.2 sets for a
BIA, written here in original wording:

1. Define the impact types and the criteria that describe each level of
   impact (section 2).
2. Identify the activities that support the delivery of products and
   services (section 3).
3. Assess the impacts of not performing each activity over time
   (section 4).
4. Find the point at which the impact of not resuming an activity becomes
   unacceptable, and set the prioritized timeframe for resuming it at a
   specified minimum capacity (section 5).
5. Use the results to identify prioritized activities (section 6).
6. Determine the resources needed to support prioritized activities,
   and the dependencies, including partners and suppliers, and
   interdependencies between activities (section 7).

ISO/TS 22317:2021 gives guidance on running the BIA as a programme,
scoping it, and analysing at the level of products and services,
processes, activities and resources. NIST SP 800-34 Rev. 1 (section 3.2)
gives a free alternative for information systems in three steps:
determine mission and business processes and recovery criticality,
identify resource requirements, and identify recovery priorities for
system resources.

```mermaid
flowchart TD
  A["Agree impact criteria with top management"] --> B["List products and services"]
  B --> C["Identify supporting activities"]
  C --> D["Interview activity owners: impact over time"]
  D --> E["Set MTPD, RTO, RPO and MBCO"]
  E --> F["Rank prioritized activities"]
  F --> G["Map dependencies and resources"]
  G --> H["Compare with current capability: gaps"]
  H --> I["Approve and hand over to BCP, DR and risk assessment"]
  I --> J["Review annually or after significant change"]
  J --> B
```

### 1.4 Data collection

| Technique | Used for | Participants |
|---|---|---|
| Structured interview | Impact over time, minimum capacity, workarounds | Activity owners and deputies |
| Workshop | Calibrating scores across departments | Heads of department, BC manager |
| Document review | Contracts, SLAs, regulatory deadlines, historic incidents | BC manager, legal, procurement |
| System data | Transaction volumes, peak periods, backup schedules | IT operations, finance |

## 2. Impact categories and criteria

<!-- Guidance: Define the scale once and use it everywhere. Each level needs a concrete description per category, ideally with money amounts or counts. Questions: what loss would the board call severe? Which legal deadlines exist? Pitfall: a scale with only words such as "high" and "low", which each interviewee reads differently. -->

Score each impact category from 1 to 5. The overall impact at a point in
time is the highest score in any category, not the average, so that one
severe consequence is never diluted by mild ones.

| Score | Financial (cumulative loss) | Customers and service | Legal and regulatory | Reputation | People and safety |
|---|---|---|---|---|---|
| 1 Minimal | Under [10,000] | Minor delay, no complaints | No breach | No external attention | No effect |
| 2 Minor | [10,000] to under [50,000] | Delays noticed by some customers | Minor breach, self-correctable | Local complaints | Overtime needed |
| 3 Moderate | [50,000] to under [150,000] | Service levels missed for key customers | Breach reportable to a regulator | Trade press coverage | Staff welfare affected |
| 4 Severe | [150,000] to under [500,000] | Key customers lost or penalties triggered | Statutory deadline missed, sanctions likely | National media coverage | Injury risk or loss of key staff |
| 5 Critical | [500,000] or more | Service cannot be delivered, contracts terminated | Licence or authorisation at risk | Sustained national coverage | Serious harm |

Define the unacceptable level: **an activity reaches its MTPD at the
earliest time point where its overall impact score is 4 or higher**.
Record the threshold the sponsor approved: [threshold and approval
reference].

ISO 22301:2019 Amd 1:2024 added a requirement to determine whether
climate change is a relevant issue when the organization determines its
context. Where climate
related events (heat, flood, storms) could affect sites or suppliers,
note them in the risk assessment and check whether they change peak
periods or dependencies recorded here.

## 3. Products, services and activities

<!-- Guidance: Start from what customers receive, then list the activities that deliver it. Questions: which products and services generate most revenue or carry legal obligations? Which activities are shared by several services? Pitfall: listing departments instead of activities; a department often performs both urgent and deferrable work. -->

### 3.1 Products and services

| ID | Product or service | Customers | Contractual or legal commitments | Peak periods |
|---|---|---|---|---|
| PS-01 *(Example)* | Import customs brokerage | Importers, retailers | Declarations within statutory deadlines, customer SLA 4 hours | Weekdays, pre-holiday season |
| PS-02 *(Example)* | Freight forwarding and warehousing | Retail and industrial shippers | Dispatch within 24 hours of order, SLA credits | October to December |
| PS-03 *(Example)* | Shipment visibility | All customers | Portal availability 99.5% monthly | Continuous |
| [PS-NN] | [Product or service] | [Customers] | [Commitments] | [Peaks] |

### 3.2 Activities

| ID | Activity | Supports | Owner | Normal headcount | Main applications |
|---|---|---|---|---|---|
| ACT-01 *(Example)* | Customs declaration filing | PS-01 | [@customs-lead] | 15 | Customs gateway (CGW) |
| ACT-02 *(Example)* | Shipment booking and carrier allocation | PS-02 | [@ops-lead] | 12 | Transport management system (TMS) |
| ACT-03 *(Example)* | Warehouse dispatch | PS-02 | [@warehouse-lead] | 40 | Warehouse management system (WMS) |
| ACT-04 *(Example)* | Customer track-and-trace portal | PS-03 | [@cx-lead] | 6 | Portal, TMS |
| ACT-05 *(Example)* | Payroll | All (internal) | [@payroll-lead] | 3 | Payroll SaaS |
| [ACT-NN] | [Activity] | [PS-NN] | [@owner] | [n] | [Applications] |

## 4. Impact over time

<!-- Guidance: For each activity, ask the owner what happens if it stops at the worst plausible time and stays stopped for 4 hours, 1 day, 3 days, 1 week and 2 weeks. Score every category at every time point. Questions: when do penalties start? When do customers leave? When is a legal deadline missed? Pitfall: scoring the "typical" day instead of the peak period. -->

### 4.1 Time points

Use the same time points for every activity: 4 hours, 24 hours, 72 hours,
1 week (168 hours) and 2 weeks (336 hours). Add shorter points (for
example 1 hour) for activities with real-time obligations.

### 4.2 Detailed assessment (one table per activity)

*Example:* ACT-01 Customs declaration filing, assessed for the peak
season.

| Time point | Financial loss (EUR, cumulative) | Financial score | Customers | Legal and regulatory | Reputation | Overall (highest) |
|---|---|---|---|---|---|---|
| 4 hours | 6,000 | 1 | 2 | 1 | 1 | 2 |
| 24 hours | 48,000 | 2 | 3 | 4 | 3 | 4 |
| 72 hours | 210,000 | 4 | 4 | 5 | 4 | 5 |
| 1 week | 640,000 | 5 | 5 | 5 | 4 | 5 |
| 2 weeks | 1,350,000 | 5 | 5 | 5 | 5 | 5 |

Rationale recorded at interview: goods held at the border start to
accrue storage and demurrage charges after the first day; declarations
not lodged within the statutory window expose customers and the broker
to penalties, which drives the legal score to 4 at 24 hours.

### 4.3 Summary of overall scores

| Activity | 4 h | 24 h | 72 h | 1 week | 2 weeks | Peak period assessed |
|---|---|---|---|---|---|---|
| ACT-01 *(Example)* | 2 | 4 | 5 | 5 | 5 | Pre-holiday season |
| ACT-02 *(Example)* | 1 | 3 | 4 | 5 | 5 | October to December |
| ACT-03 *(Example)* | 2 | 3 | 4 | 5 | 5 | October to December |
| ACT-04 *(Example)* | 1 | 2 | 3 | 4 | 5 | Continuous |
| ACT-05 *(Example)* | 1 | 1 | 2 | 3 | 4 | Payroll run (day 25 of the month) |

## 5. Time objectives

<!-- Guidance: Derive each objective from the impact table and record the reasoning. Questions: at which time point does the score first reach the unacceptable level? How long do detection, decision and invocation take? How much data can the activity re-create by hand? Pitfall: copying IT's current backup schedule into the RPO column; the RPO is a business requirement that IT must then meet. -->

### 5.1 Definitions used in this BIA

| Objective | Meaning in this document | Set by |
|---|---|---|
| MTPD | Time after which the impact of not resuming the activity becomes unacceptable (first score of 4 or higher) | Section 4 results, approved by the sponsor |
| RTO | Target time to resume the activity at its MBCO after a disruption starts | Activity owner, within the MTPD rule below |
| RPO | Maximum age of the data the activity can restart from, measured back from the disruption | Activity owner with the information owner |
| MBCO | Minimum level of output, as a share of normal volume, acceptable during the disruption | Activity owner, agreed with customers where contracts apply |

NIST SP 800-34 Rev. 1 uses maximum tolerable downtime (MTD), which plays
the role of MTPD for an information system, and splits it into RTO plus
work recovery time (WRT): the time to verify data and bring the process
back after the system is restored. Plan so that RTO plus WRT stays within
the MTPD.

### 5.2 Rules

1. RTO is no more than 50% of MTPD, leaving the remainder for detection,
   decision, invocation and work recovery. [Adjust the percentage and
   record the approval.]
2. The RTO of every application and supplier an activity depends on is
   no longer than the activity's RTO.
3. The RPO is no longer than the period of transactions the activity can
   re-enter or reconstruct from other sources within its RTO.
4. MBCO is stated as a measurable volume, not as "reduced service".

### 5.3 Objectives

| Activity | MTPD | RTO | RTO as share of MTPD | RPO | MBCO | Reasoning |
|---|---|---|---|---|---|---|
| ACT-01 *(Example)* | 24 h | 8 h | 33% | 1 h | 60% of declarations | Legal score reaches 4 at 24 h |
| ACT-02 *(Example)* | 72 h | 24 h | 33% | 4 h | 50% of bookings | Customer score reaches 4 at 72 h |
| ACT-03 *(Example)* | 72 h | 24 h | 33% | 1 h | 70% of dispatches | SLA credits at 72 h in peak season |
| ACT-04 *(Example)* | 1 week | 72 h | 43% | 24 h | 40% of tracking queries answered | Customers can phone in the interim |
| ACT-05 *(Example)* | 2 weeks | 1 week | 50% | 24 h | 100% of the payroll run on its due date | Late pay harms staff and breaches contracts |

## 6. Prioritized activities

<!-- Guidance: Rank activities by RTO, then by overall impact at the RTO. The ranking becomes the recovery sequence in the BCP. Questions: which activities must restart together because one feeds the other? Which can wait until normal operations return? Pitfall: ranking by department seniority instead of by impact. -->

| Rank | Activity | RTO | Recovery tier | Must restart together with |
|---|---|---|---|---|
| 1 *(Example)* | ACT-01 Customs declaration filing | 8 h | Tier 1 (under 24 h) | None |
| 2 *(Example)* | ACT-03 Warehouse dispatch | 24 h | Tier 2 (24 to 72 h) | ACT-02 |
| 3 *(Example)* | ACT-02 Shipment booking and carrier allocation | 24 h | Tier 2 (24 to 72 h) | ACT-03 |
| 4 *(Example)* | ACT-04 Customer track-and-trace portal | 72 h | Tier 3 (72 h to 1 week) | ACT-02 data feed |
| 5 *(Example)* | ACT-05 Payroll | 1 week | Tier 4 (over 1 week) | None, but date-driven |
| [n] | [Activity] | [RTO] | [Tier] | [Dependencies] |

ACT-03 ranks above ACT-02 with the same RTO because its RPO is shorter
and its peak-season impact at 72 hours is driven by contractual credits
that start sooner.

Activities not listed as prioritized are resumed after the tiers above,
in the order set by [BC manager] at the time, unless their MTPD
changes at the next review.

## 7. Dependencies and resources

<!-- Guidance: For each prioritized activity, record the minimum resources needed to run at MBCO. Questions: which people with which skills? Which applications and data? Which site or workspace? Which suppliers, and what do their contracts promise? Pitfall: listing the resources used on a normal day; the BIA needs the minimum set at MBCO. -->

### 7.1 People

| Activity | Normal headcount | MBCO | Minimum headcount at MBCO | Key skills or authorisations | Single points of failure |
|---|---|---|---|---|---|
| ACT-01 *(Example)* | 15 | 60% | 9 | Licensed customs declarants | Two staff hold the gateway signing certificate |
| ACT-02 *(Example)* | 12 | 50% | 6 | Carrier contract knowledge | None identified |
| ACT-03 *(Example)* | 40 | 70% | 28 | Forklift licences, dangerous goods training | One shift supervisor per site |
| ACT-04 *(Example)* | 6 | 40% | 3 (2.4 rounded up) | Portal admin rights | None identified |
| ACT-05 *(Example)* | 3 | 100% | 2 (one preparer and one approver can run the full payroll) | Payroll system approver | One approver for bank file release |

### 7.2 Information and ICT

| Application or data set | Supports | Required RTO (from activity) | Required RPO | Current RTO capability | Current RPO capability | Hosting |
|---|---|---|---|---|---|---|
| Customs gateway (CGW) *(Example)* | ACT-01 | 8 h | 1 h | 12 h (supplier contract) | 15 min | SaaS, [Supplier A] |
| TMS *(Example)* | ACT-02, ACT-04 | 24 h | 4 h | 12 h | 1 h | Private cloud |
| WMS *(Example)* | ACT-03 | 24 h | 1 h | 12 h | 4 h | On-premises, site 1 |
| Payroll SaaS *(Example)* | ACT-05 | 1 week | 24 h | 48 h | 24 h | SaaS, [Supplier B] |
| [Application] | [ACT-NN] | [RTO] | [RPO] | [Capability] | [Capability] | [Hosting] |

### 7.3 Facilities and equipment

| Activity | Normal location | Alternative location | Equipment needed at MBCO | Time to ready alternative |
|---|---|---|---|---|
| ACT-01 *(Example)* | Head office | Remote working with VPN | 9 laptops, signing certificates on hardware tokens | 2 h |
| ACT-03 *(Example)* | Cross-dock site 1 | Cross-dock site 2 (spare capacity 30%) | Handheld scanners, label printers | 12 h |
| [Activity] | [Location] | [Alternative] | [Equipment] | [Time] |

### 7.4 Suppliers and partners

| Supplier | Service | Supports | Contractual recovery commitment | Has own continuity plan seen | Alternative supplier |
|---|---|---|---|---|---|
| [Supplier A] *(Example)* | Customs gateway SaaS | ACT-01 | RTO 12 h, RPO 15 min | Yes, summary only | Manual filing via the authority portal |
| [Supplier C] *(Example)* | Contracted truck fleet | ACT-03 | Replacement vehicles within 24 h | Yes | Spot market carriers |
| [Supplier] | [Service] | [ACT-NN] | [Commitment] | [Yes / No] | [Alternative] |

### 7.5 Interdependencies between activities

```mermaid
flowchart LR
  ACT02["ACT-02 Booking"] --> ACT03["ACT-03 Dispatch"]
  ACT02 --> ACT04["ACT-04 Track-and-trace"]
  ACT01["ACT-01 Customs filing"] --> ACT03
  CGW["CGW SaaS (Supplier A)"] --> ACT01
  TMS["TMS"] --> ACT02
  TMS --> ACT04
  WMS["WMS"] --> ACT03
```

Arrows point from the provider of an input to the activity that needs
it. A disruption of the TMS therefore affects ACT-02 and ACT-04 directly
and ACT-03 through the booking feed.

## 8. Gap analysis

<!-- Guidance: Compare each required objective with the current capability and record every shortfall as a gap with an owner. Questions: which application or supplier cannot meet the activity's RTO or RPO? Which skills depend on one person? Pitfall: closing gaps silently by relaxing the RTO; any change to an objective needs the sponsor's approval and a new impact justification. -->

| Gap ID | Activity | Requirement | Current capability | Shortfall | Proposed treatment | Owner | Target date |
|---|---|---|---|---|---|---|---|
| GAP-01 *(Example)* | ACT-01 | CGW RTO 8 h | Supplier contract RTO 12 h | 4 h | Negotiate RTO 6 h at renewal, document manual filing fallback | [@procurement] | YYYY-MM-DD |
| GAP-02 *(Example)* | ACT-03 | WMS RPO 1 h | Backups every 4 h | 3 h | Enable log shipping to site 2 | [@it-ops] | YYYY-MM-DD |
| GAP-03 *(Example)* | ACT-01 | 9 declarants able to sign | 2 certificate holders | Concentration of signing authority | Issue certificates to 3 more declarants | [@customs-lead] | YYYY-MM-DD |
| GAP-04 *(Example)* | ACT-05 | Two bank file approvers | One approver | Single point of failure | Appoint deputy approver | [@cfo] | YYYY-MM-DD |
| [GAP-NN] | [ACT-NN] | [Requirement] | [Capability] | [Shortfall] | [Treatment] | [@owner] | YYYY-MM-DD |

Record each gap in the risk register (`compliance/risk-register`) so
that its treatment is tracked with other risks, and reference the risk
ID here once assigned.

## 9. Outputs and traceability

<!-- Guidance: Show where each BIA result goes. Questions: does every prioritized activity appear in the BCP? Does every required ICT RTO appear in the DR plan? Pitfall: a BIA that is approved and then never read by the teams writing plans. -->

| BIA output | Consumer document | Section or field | Status |
|---|---|---|---|
| Prioritized activities and RTO (section 6) | Business continuity plan | Recovery sequence | [Linked / Pending] |
| ICT RTO and RPO (section 7.2) | Disaster recovery plan | Recovery tiers and backup schedule | [Linked / Pending] |
| Supplier commitments (section 7.4) | Supplier security assessment, contracts | Continuity clauses | [Linked / Pending] |
| Gaps (section 8) | Risk register | Risk entries and treatment plans | [Linked / Pending] |
| Resources at MBCO (section 7) | Continuity strategies and solutions | Resource requirements | [Linked / Pending] |
| Impact criteria (section 2) | Risk methodology | Consequence scale alignment | [Linked / Pending] |

Traceability matrix:

| Activity | MTPD | RTO | BCP procedure | DR tier | Exercise that validated it |
|---|---|---|---|---|---|
| ACT-01 *(Example)* | 24 h | 8 h | BCP-PROC-01 | Tier 1 | EX-2026-02 tabletop |
| ACT-03 *(Example)* | 72 h | 24 h | BCP-PROC-03 | Tier 2 | EX-2026-04 site switch test |
| [ACT-NN] | [MTPD] | [RTO] | [Procedure] | [Tier] | [Exercise] |

## 10. Review and maintenance

<!-- Guidance: Plan when the BIA will be reviewed and what forces an early review. Questions: what organizational changes would make the results wrong? Who checks that every gap has moved? Pitfall: reviewing the document date but not the numbers. -->

Review the BIA at least [annually] and also when any of these triggers
occurs:

- a new product, service, site, legal entity or major customer contract;
- a change of a critical supplier or of a core application;
- a merger, acquisition, restructuring or outsourcing decision;
- an exercise or real disruption showing that an objective was wrong;
- a change in legal or regulatory deadlines that affect impact scores.

| Review | Date | Trigger | Changes made | Approved by |
|---|---|---|---|---|
| [R-01] | YYYY-MM-DD | [Annual / Trigger] | [Summary] | [@name] |

Report the BIA status, open gaps and any changed objectives to the
management review (`compliance/management-review`).

## 11. Glossary and references

<!-- Guidance: Define terms for readers outside business continuity and list the editions used. -->

### 11.1 Glossary

| Term | Meaning in this document |
|---|---|
| Activity | A set of tasks that produces or supports a product or service |
| Prioritized activity | An activity given precedence after a disruption to limit impact |
| MTPD | Maximum tolerable period of disruption, see section 5.1 |
| RTO | Recovery time objective, see section 5.1 |
| RPO | Recovery point objective, see section 5.1 |
| MBCO | Minimum business continuity objective, see section 5.1 |
| MTD | Maximum tolerable downtime, the NIST SP 800-34 term close to MTPD |
| WRT | Work recovery time, the time after system restoration to verify data and resume the process |
| BCMS | Business continuity management system |

### 11.2 References

| Reference | Edition or date | Use |
|---|---|---|
| ISO 22301, *Security and resilience, Business continuity management systems, Requirements* | 2019 with Amd 1:2024; a revision is at committee draft stage (ISO/CD 22301), check the current status | Clause 8.2.2 method steps, cited by clause number |
| ISO/TS 22317, *Security and resilience, Business continuity management systems, Guidelines for business impact analysis* | 2021, second edition | BIA programme and levels of analysis |
| NIST SP 800-34 Rev. 1, *Contingency Planning Guide for Federal Information Systems* | May 2010, updated 11 November 2010 | Free BIA method, MTD, RTO, RPO, WRT |

## Standard and licence note

Structure aligned with ISO 22301:2019 with Amd 1:2024 (clause 8.2.2) and
ISO/TS 22317:2021, cited by name, edition and clause number only, and
based on NIST SP 800-34 Rev. 1, a US government publication. This
template is original text written for this collection and reproduces no
wording, tables or definitions from the ISO documents. Check the current
editions before use, including the status of the ISO 22301 revision.

Official text: ISO, purchase or licensed access:
https://www.iso.org/standard/75106.html (ISO 22301:2019),
https://www.iso.org/standard/88412.html (Amd 1:2024) and
https://www.iso.org/standard/79000.html (ISO/TS 22317:2021), also
available from national standards bodies. NIST SP 800-34 Rev. 1 is free
at https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final.

Template licence: MIT.