Business Impact Analysis Template

1. Purpose

The Business Impact Analysis (BIA) Template provides a structured method for identifying critical business services, understanding the consequences of disruption, determining recovery priorities, and establishing recovery requirements.

The BIA helps the organization determine:

Which business services are critical
What happens if they become unavailable
How quickly they need to be recovered
How much data loss is acceptable
Which information is critical
Which technology and suppliers support the service
Which people and skills are required
What minimum level of service is required
What dependencies could prevent recovery
Where continuity and recovery investment is required

BIA answers the business question: “What would happen if this service stopped, and how quickly do we need it back?”

2. When to Perform a BIA

Perform or review a BIA when:

A new critical business service is introduced
A major business process changes
A new technology platform is introduced
The organization enters a new market
A critical supplier changes
Cloud architecture changes
Significant incidents occur
Recovery requirements change
RTO/RPO requirements change
There is a significant regulatory or contractual change
Business continuity plans are updated
Disaster recovery architecture changes
Periodic BCP/DR review is performed

The review frequency should be defined based on business criticality and risk.

3. BIA Identification

Field	Details
BIA ID	BIA-YYYY-XXXX
Assessment Date
Business Unit
Business Service
Process Name
Process Owner
Business Owner
BIA Assessor
Review Date
Version
Status	Draft / Approved / Review

4. Business Service Identification

Identify the service being assessed.

Field	Details
Business Service
Description
Business Owner
Business Function
Customers Served
Internal Users
External Users
Geographic Scope
Operating Hours
Critical Periods
Service Criticality

Example

Business Service: Customer SaaS Platform

Description: Provides customers with access to the organization’s cloud-based application.

Business Owner: Head of Product

Users: External customers and internal support teams

Criticality: High

5. Business Service Description

Describe what the service does and why it is important.

Document:

Purpose
Key activities
Customers
Business outcomes
Revenue dependency
Regulatory dependency
Contractual dependency
Internal dependency
External dependency

Example

The SaaS platform provides customers with access to application functionality and customer data. Its availability directly affects customer operations, contractual commitments, support operations, and revenue.

6. Criticality Assessment

Assess the importance of the service.

Factor	Low	Medium	High	Critical
Customer Impact	☐	☐	☐	☐
Revenue Impact	☐	☐	☐	☐
Operational Impact	☐	☐	☐	☐
Regulatory Impact	☐	☐	☐	☐
Contractual Impact	☐	☐	☐	☐
Information Security Impact	☐	☐	☐	☐
Reputation Impact	☐	☐	☐	☐
Safety/People Impact	☐	☐	☐	☐

Overall Criticality: __________________

The organization should define what Low, Medium, High, and Critical mean.

7. Impact of Disruption

Assess what would happen if the service became unavailable or degraded.

Consider:

Financial impact
Customer impact
Operational impact
Legal impact
Regulatory impact
Contractual impact
Information security impact
Reputation
Strategic impact
Employee impact
Supplier impact

8. Impact Over Time

Impact often increases as an outage continues.

Disruption Period	Business Impact	Consequence
0–1 hour
1–4 hours
4–8 hours
8–24 hours
1–3 days
3–7 days
>7 days

The time periods should be adapted to the service.

9. Maximum Tolerable Period of Disruption

Determine the maximum period for which the business can tolerate the service being unavailable before the consequences become unacceptable.

MTPD: __________________

Example

A customer-facing SaaS service may have an MTPD of 8 hours because a longer disruption could result in significant customer, contractual, operational, or financial consequences.

MTPD is an organizational business requirement and should be supported by documented impact analysis.

10. Recovery Time Objective

Determine the required recovery time.

MTPD: __________

Target RTO: ______

The RTO should normally be shorter than the MTPD to provide recovery margin.

Example

MTPD: 8 hours
RTO: 4 hours

The organization therefore aims to restore the service within 4 hours rather than waiting until the maximum tolerable disruption period.

11. Recovery Point Objective

Determine how much data loss can be tolerated.

Target RPO: __________________

Consider:

Transaction frequency
Data criticality
Customer requirements
Regulatory requirements
Business process requirements
Backup capability
Replication capability

Example

RPO: 1 hour

This means the organization requires recovery to a point no more than approximately one hour behind the disruption point, subject to the defined recovery architecture and actual capability.

12. Minimum Business Service Level

Determine the minimum level of service required during disruption.

Function	Normal Service	Minimum Service
Customer Login	Full	Required
Core Transactions	Full	Required
Reporting	Full	Limited
Analytics	Full	Not required
Administration	Full	Limited

The minimum service level should be agreed with the Business Owner.

13. Degraded Operations

Determine whether the service can operate temporarily at a reduced level.

Examples:

Manual processing
Read-only mode
Limited customer functionality
Reduced transaction capacity
Alternate communication
Offline processing
Delayed reporting

Document:

Degraded operating mode: __________________

Maximum duration: _________________________

Risks: ___________________________________

14. Business Process Dependencies

Identify what the service depends on.

People

☐ Process Owner
☐ Technical specialists
☐ Administrators
☐ Customer support
☐ Management
☐ Supplier personnel

Technology

☐ Application
☐ Database
☐ Cloud
☐ Network
☐ Storage
☐ Identity
☐ Security tools
☐ Monitoring
☐ Backup

Information

☐ Customer data
☐ Transaction data
☐ Business records
☐ Configuration
☐ Source code
☐ Credentials/secrets

Suppliers

☐ Cloud provider
☐ SaaS provider
☐ Payment provider
☐ DNS provider
☐ Identity provider
☐ Managed service provider

15. Critical Information

Identify information required to operate or recover the service.

Information	Classification	Criticality	Recovery Requirement
Customer Database	Confidential	Critical	Immediate
Application Configuration	Internal	High	Required
Source Code	Confidential	High	Required
Audit Logs	Confidential	High	Required
Marketing Data	Internal	Low	Later

Information classification should follow the organization’s Information Classification Policy.

16. Information Security Impact

Assess the consequences of disruption against:

Confidentiality

Could disruption or recovery expose information?

Integrity

Could information be corrupted, lost, duplicated, or incorrectly restored?

Availability

How long can the information or system remain unavailable?

Privacy

Could customer, employee, or personal information be affected?

Regulatory

Could disruption result in regulatory obligations or non-compliance?

Document significant impacts.

17. Customer Impact

Determine how disruption affects customers.

Consider:

Number of affected customers
Customer-critical functionality
Contractual SLA
Customer data
Customer operations
Customer communication
Customer support
Financial consequences

Impact Area	Assessment
Customers Affected
Estimated Number
Critical Customers
Contractual SLA
Customer Data
Customer Communication
Business Consequence

18. Financial Impact

Assess potential financial consequences.

Consider:

Lost revenue
SLA credits
Recovery costs
Emergency supplier costs
Customer compensation
Regulatory penalties where applicable
Operational costs
Employee costs
Business opportunity loss

Exact financial estimates should be documented where meaningful and available.

19. Regulatory and Contractual Impact

Identify requirements that could be affected by disruption.

Consider:

Data protection
Industry regulation
Customer contracts
SLA requirements
Security commitments
Audit requirements
Certification commitments
Reporting obligations

Record:

Requirement: ______________________

Impact: ___________________________

Owner: ____________________________

20. People and Skills

Identify personnel required to continue or recover the service.

Role	Criticality	Primary	Alternate
Business Owner	High
Cloud Engineer	Critical
Database Administrator	Critical
Security Lead	High
Application Engineer	High
Customer Support	Medium

Identify single-person dependencies.

Key-person dependency: ☐ Yes ☐ No

If yes, document the mitigation.

21. Workforce Availability

Determine whether the service can operate if personnel are unavailable.

Consider:

Remote working
Alternate personnel
Cross-training
On-call support
Supplier support
Documentation
Automation

Minimum personnel required: ___________

Maximum acceptable personnel shortage: ___

22. Technology Dependencies

Identify the ICT components required.

Dependency	Type	Criticality	Supplier
AWS	Cloud	Critical	AWS
RDS	Database	Critical	AWS
ECS	Compute	Critical	AWS
SSO	Identity	High
DNS	Network	High
Git Repository	Source Code	High

This information should feed the ICT Dependency Register.

23. AWS SaaS Example

For a typical SaaS platform:

Customer Service

↓

Application

↓

ECS/EKS/EC2

↓

RDS

↓

VPC / Network

↓

IAM

↓

KMS / Secrets

↓

Cloud Monitoring

↓

DNS / WAF / Load Balancer

The BIA should identify which of these dependencies are critical to delivering the business service.

24. Supplier Dependencies

Identify critical suppliers.

Supplier	Service	Dependency	Criticality
Cloud Provider	Infrastructure	Production hosting	Critical
Identity Provider	SSO	User authentication	High
DNS Provider	DNS	Customer access	High
Payment Provider	Payments	Revenue	High

For critical suppliers consider:

Supplier outage
Supplier cyber incident
Supplier recovery capability
Contractual commitments
Alternative suppliers
Exit capability

25. Single Points of Failure

Identify dependencies where one failure could prevent recovery.

Examples:

One administrator
One cloud region
One database
One supplier
One identity provider
One DNS provider
One recovery credential
One backup repository
One person with recovery knowledge

Single Point of Failure	Impact	Mitigation

26. Recovery Priority

Assign recovery priority.

Priority 1 – Critical

Recover immediately.

Priority 2 – High

Recover after critical services.

Priority 3 – Medium

Recover after critical business services.

Priority 4 – Low

Can remain unavailable temporarily.

Service	Priority	Reason
Customer SaaS	P1	Customer critical
Customer Support	P2	Operational support
Internal Analytics	P3	Can operate manually
Marketing Website	P4	Temporary workaround

27. Recovery Sequence

Define the required recovery order.

Example:

Identity and access
Network
Security controls
Storage
Database
Application infrastructure
Application
Integrations
Monitoring
Business validation

The actual sequence should be based on technology dependencies.

28. Recovery Strategy

Identify the strategy required.

Possible strategies:

Backup restoration
Replication
Redundancy
High availability
Alternate cloud region
Alternate cloud account
Infrastructure as Code
Manual workaround
Alternate supplier
SaaS replacement
Remote work
Outsourced processing

Selected strategy: ______________________

Reason: _________________________________

29. Workaround Assessment

Determine whether a manual or alternate process exists.

Workaround available: ☐ Yes ☐ No

If yes:

Workaround: _____________________________

Maximum duration: ________________________

Capacity: ________________________________

Risks: ___________________________________

A workaround should not be assumed to be viable without validation.

30. Recovery Resource Requirements

Identify resources required for recovery.

People

☐ Technical specialists
☐ Business users
☐ Security
☐ Management
☐ Suppliers

Technology

☐ Cloud
☐ Hardware
☐ Software
☐ Network
☐ Backup
☐ Monitoring

Information

☐ Documentation
☐ Configuration
☐ Credentials
☐ Source code
☐ Data

Financial

☐ Emergency budget
☐ Supplier support
☐ Cloud resources
☐ Recovery infrastructure

31. Recovery Cost Consideration

Assess whether the recovery requirement is economically and technically feasible.

Consider:

Recovery infrastructure
Backup storage
Replication
Cloud region
Supplier redundancy
Personnel
Licensing
Testing
Emergency support

The objective is not simply to select the fastest recovery option; it is to determine a recovery capability appropriate to business risk.

32. RTO/RPO Assessment Summary

Business Service	MTPD	RTO	RPO	Priority
Customer SaaS	8h	4h	1h	P1
Customer Database	8h	4h	1h	P1
SSO	8h	4h	4h	P1
Internal Collaboration	24h	8h	24h	P2
Development	48h	24h	24h	P3

The values above are illustrative examples, not universal requirements.

33. Impact Assessment Matrix

Use a consistent organizational scale.

Impact Level	Description
Low	Limited inconvenience; normal operations can continue
Medium	Noticeable operational or customer impact
High	Significant business/customer/financial impact
Critical	Severe impact requiring immediate recovery

Assess each relevant dimension:

Impact Dimension	Level	Explanation
Customer
Financial
Operational
Regulatory
Contractual
Information Security
Reputation
Strategic

34. BIA Risk Considerations

The BIA should identify risks that could prevent recovery.

Examples:

Cloud outage
Cyberattack
Ransomware
Data corruption
Backup failure
Database failure
Network failure
IAM failure
Supplier outage
Key-person dependency
Physical disaster
DNS failure
Source-code loss
CI/CD failure

Link significant risks to the organization’s risk register.

35. BIA Findings

Record gaps identified during the assessment.

Finding ID	Finding	Impact	Risk
BIA-001	Single recovery administrator	High	High
BIA-002	No tested alternate region	High	High
BIA-003	Supplier has no confirmed recovery commitment	Medium	Medium

36. Recovery Capability Gap

Compare required recovery capability with actual capability.

Requirement	Required	Current Capability	Gap
RTO	4h	7h	3h gap
RPO	1h	4h	3h gap
Recovery Personnel	2	1	Staffing gap
Backup	Daily	Daily	None
DR Environment	Required	Partial	Infrastructure gap

A gap should lead to risk treatment, corrective action, or documented risk acceptance.

37. Management Decision

Management should review significant BIA conclusions.

Possible decisions:

☐ Approve recovery requirements
☐ Approve recovery strategy
☐ Fund additional recovery capability
☐ Accept identified risk
☐ Require risk treatment
☐ Require additional testing
☐ Require supplier changes
☐ Require RTO/RPO revision

Management comments:

38. BIA Approval

Role	Name	Decision	Date
Business Owner		Approved / Rejected
IT/ICT Owner		Approved / Rejected
Security Lead		Approved / Rejected
Management		Approved / Rejected

39. Review Triggers

Review the BIA when:

Business service changes
Critical application changes
Cloud architecture changes
New supplier introduced
Supplier changes
Major incident occurs
DR test identifies significant gaps
RTO/RPO changes
Customer requirements change
Regulatory requirements change
Significant organizational change occurs
Major technology migration occurs

40. Relationship With Other ISMS Records

The BIA is a foundational input to:

Business Services

→ Critical Service Register

→ Business Impact Analysis

→ Risk Assessment

→ RTO/RPO Assessment

→ ICT Dependency Register

→ Recovery Strategy

→ Business Continuity Plan

→ ICT Business Continuity Plan

→ Disaster Recovery Plan

→ Backup & Restore Procedure

→ DR Test Plan

→ DR Test Report

→ ICT Recovery Checklist

→ Corrective Action Tracker

→ ISMS Improvement Log

This creates a traceable relationship between business impact and technical recovery requirements.

41. Startup Implementation

A startup does not need a complex BIA for every activity.

Start with the services that could materially affect:

Customers
Revenue
Critical operations
Sensitive information
Regulatory obligations
Contractual commitments

For each critical service determine:

What does the service do?
Who depends on it?
What happens if it stops?
How quickly must it recover?
How much data can be lost?
What technology supports it?
Which suppliers support it?
Who is required to recover it?
What is the recovery strategy?
Has recovery actually been tested?

42. Minimum BIA Record

For a small organization, the minimum practical BIA can contain:

Field
Business Service
Business Owner
Criticality
Customers
Critical Information
Impact of Disruption
MTPD
RTO
RPO
Minimum Service Level
Key People
ICT Dependencies
Supplier Dependencies
Single Points of Failure
Recovery Strategy
Workaround
Recovery Priority
Findings
Management Approval

43. ISO/IEC 27001 Alignment

The BIA supports risk-based information security continuity and recovery planning.

It can provide inputs into:

Information security continuity
ICT readiness for business continuity
Risk assessment
Risk treatment
Backup
Redundancy
Supplier security
Incident management
Disaster recovery
Business continuity
Continual improvement

ISO/IEC 27001 does not prescribe one universal BIA methodology, MTPD, RTO, or RPO. These should be established by the organization based on business impact, risk, dependencies, applicable requirements, and recovery capability.

44. Audit Evidence

An auditor should be able to trace:

Business Service

→ Business Impact

→ Criticality

→ MTPD

→ RTO/RPO

→ Critical Information

→ ICT Dependencies

→ Supplier Dependencies

→ Recovery Strategy

→ BCP/DR Requirements

→ Recovery Testing

→ Findings

→ Corrective Actions

→ Risk Treatment

→ Management Approval

This demonstrates that recovery requirements are derived from business needs and risk rather than arbitrary technical assumptions.

45. Final Audit Trail

Business Service Identified

→ Business Owner Identified

→ Criticality Assessed

→ Customers and Stakeholders Identified

→ Critical Information Identified

→ Business Impact Assessed

→ Impact Over Time Assessed

→ MTPD Defined

→ RTO Defined

→ RPO Defined

→ Minimum Service Level Defined

→ People Dependencies Identified

→ ICT Dependencies Identified

→ Supplier Dependencies Identified

→ Single Points of Failure Identified

→ Recovery Priority Defined

→ Recovery Strategy Identified

→ Workaround Assessed

→ Recovery Capability Compared

→ Gaps Identified

→ Risk Assessed

→ Corrective Actions Defined

→ Management Review

→ BIA Approved

→ Recovery Requirements Updated

46. Final Principle

A Business Impact Analysis should not simply list business processes. It should establish what matters most, what happens when it is disrupted, how quickly it must recover, what information must be protected, what the service depends on, and what recovery capability the business actually requires.

Identify → Understand Impact → Prioritize → Define MTPD/RTO/RPO → Map Dependencies → Define Recovery Requirements → Address Gaps → Approve → Review