The same incident can be read two ways: an unavailable server is a technical problem, but the interruption of the business process it supports (invoicing, regulatory filings, service delivery) is what produces the financial, contractual and regulatory consequences. The technical criticality and the business criticality of a resource do not always coincide.
A Business Impact Analysis (BIA) exists to establish this distinction. Conducted as a systems inventory, it misses its purpose; it is a business-first exercise that answers one question: if this process stops, what are the consequences for the business, and within what timeframe?
This guide presents a BIA methodology suited to small and medium-sized businesses (SMBs), achievable in a few working sessions without dedicated tooling. It draws on published sources: the NIST Cybersecurity Framework (CSF) 2.0, NIST SP 800-34, CISA's Cyber Essentials and ANSSI's EBIOS Risk Manager method.
What is a Business Impact Analysis (BIA)?
A BIA is a systematic process to identify and evaluate potential effects of disruptions to critical business operations. According to NIST SP 800-34 Rev. 1, the BIA is Step 2 of a seven-step contingency planning process, designed to identify and prioritize critical IT systems by understanding their role in supporting mission and business processes.
For SMBs, NIST CSF 2.0 reinforces this through the Identify function, specifically Asset Management (ID.AM), which requires that assets are prioritized based on classification, criticality, resources, and impact on the mission.
The starting point of a BIA is therefore the business process, not the technology: the first question is about what the business produces and what it needs to keep operating, not about the list of servers.
Why SMBs need a different approach
In large organizations, a BIA involves dedicated business continuity teams, specialized software and multiple workshops. An SMB works with limited time and staff; the principles remain the same, only the execution needs to be leaner.
CISA's Cyber Essentials for small businesses explicitly recommends that leaders approach cybersecurity as a business risk and identify their dependencies on information technology. The U.S. Small Business Administration recommends that SMBs use planning tools like the FCC's Small Biz Cyber Planner 2.0 or CISA's free Cyber Resilience Review (CRR) to assess risk without enterprise overhead.
The ANSSI EBIOS Risk Manager method is explicitly designed to be adaptable regardless of size, sector, or whether information systems are being developed or already exist. Its "Workshop 1" focuses on identifying missions, business assets, and supporting assets. This structure scales well for smaller teams.
The SMB BIA framework: a 5-step process
Based on NIST, CISA, and ANSSI guidance, here is a practical BIA framework designed for resource-constrained SMBs.
Step 1: Map business processes, not IT inventory
Start with what the business does, not what it owns.
List 5 to 10 core business processes. For a typical SMB, these might include customer order processing and invoicing, payroll and HR administration, client service delivery (consulting, manufacturing, healthcare), regulatory reporting and compliance, sales and marketing operations, and supplier and supply chain management.
Ask yourself: if this process stopped for 1 hour, 1 day, or 1 week, what would the business consequences be?
The NIST CSF 2.0 Identify function emphasizes understanding the organization's mission, objectives, stakeholders, and activities. This is your starting point.
Step 2: Identify resources required for each process
For each business process, list the resources required to execute it. NIST SP 800-34 categorizes these as People (specific roles, expertise, key individuals), Data (customer records, financial data, IP, operational data), Applications (CRM, ERP, accounting software, custom tools), Infrastructure (servers, cloud services, networks, endpoints), Third parties (SaaS providers, payment processors, logistics partners), and Facilities (office space, production floors, utilities).
This aligns with NIST CSF 2.0 ID.AM-01 through ID.AM-08, which covers inventories of hardware, software, services, data, and suppliers.
Step 3: Evaluate impact over time
For each process-resource pair, estimate the impact of disruption across three time horizons. NIST SP 800-34 provides a template for this: identify disruption impacts and allowable outage times for each critical resource.
Time horizons and impacts: 0 to 4 hours (operational delays, immediate revenue loss, customer frustration), 4 to 24 hours (missed deadlines, contractual penalties, regulatory exposure), 1 to 7 days (reputational damage, client churn, cash flow crisis, legal liability).
Use a simple severity scale: Critical (business survival threatened, safety or legal compliance at risk), High (major revenue loss or regulatory breach, recovery difficult), Medium (significant operational disruption, manageable with workarounds), and Low (minor inconvenience, easily absorbed).
ANSSI's EBIOS Risk Manager uses a similar four-tier severity scale: critical, serious, significant, and minor. It assesses impact on the safety of persons and assets and the survival of the structure.
Step 4: Set recovery priorities
Based on impact assessments, assign recovery priorities. NIST SP 800-34 recommends a simple High/Medium/Low scale. High means it must be restored within allowable outage time to prevent critical business failure. Medium means it is important for full operations but can tolerate longer disruption. Low means it is non-essential and can be restored when higher priorities are stable.
For each high-priority resource, define Recovery Time Objective (RTO): the maximum acceptable downtime (e.g., 4 hours). Also define Recovery Point Objective (RPO): the maximum acceptable data loss measured in time (e.g., 1 hour of transactions).
Step 5: Document and review
Your BIA does not need to be a 50-page report. A 2 to 3 page spreadsheet or document is sufficient for most SMBs. Include: business process inventory, resource dependencies, impact severity ratings, recovery priorities and RTO/RPO targets, and assigned owners for each process.
CISA's Cyber Resilience Review (CRR) evaluates the maturity of your capabilities across 10 domains, including Asset Management and Service Continuity Management. Use the CRR's self-assessment option to validate your BIA against recognized standards at no cost.
Common SMB BIA mistakes to avoid
Starting with technology instead of business is a common mistake. If your BIA begins with "we have three servers and two firewalls," you have inverted the logic. Start instead with "we process 50 invoices per day. What do we need to keep doing that?"
Most SMBs run critical processes through SaaS platforms like QuickBooks, Salesforce, or Google Workspace. NIST CSF 2.0 GV.SC-04 requires that suppliers are known and prioritized by criticality. If your CRM provider has an outage, your BIA should account for that.
Not all data deserves the same protection. Customer payment data may be High priority; last year's marketing collateral may be Low. NIST CSF ID.AM-05 explicitly calls for prioritization based on classification, criticality, resources, and impact on the mission.
The BIA is a living document. NIST SP 800-34 emphasizes that the plan should be updated regularly to remain current with system enhancements. Review your BIA quarterly, or whenever major business changes occur (new product lines, new suppliers, M&A activity).
How your BIA feeds the NIST CSF 2.0
Your BIA directly feeds into the broader NIST CSF 2.0 structure. Asset inventory and prioritization map to Identify, Asset Management (ID.AM). Risk severity assessments map to Identify, Risk Assessment (ID.RA). RTO/RPO targets map to Recover, Incident Recovery Plan Execution (RC.RP). Supplier criticality ratings map to Govern, Cybersecurity Supply Chain Risk Management (GV.SC). Preventive control gaps map to Protect, Technology Infrastructure Resilience (PR.IR).
A BIA is rarely a standalone effort. Once you have mapped impact and priorities, the same inputs feed your maturity assessment against CSF 2.0, and through it, your readiness for ISO 27001 or SOC 2 and your obligations under NIST CSF, NIS2, and GDPR.
The BIA in Komplyo
Komplyo uses NIST CSF 2.0 as the assessment framework and projects the same answers onto ISO 27001, SOC 2 and GDPR through the mappings between frameworks. The priorities established in a BIA (critical processes, supplier criticality, recovery objectives) correspond to the Identify, Govern and Recover functions assessed in the questionnaire, and the identified gaps feed a prioritized roadmap and the generated documents. The free diagnostic (23 questions, around 5 minutes) gives an indicative score by CSF function.
Frequently asked questions
What is the difference between a BIA and a risk assessment?
A risk assessment estimates the likelihood and impact of specific threats like ransomware, flood, or supplier failure. A BIA focuses on consequences over time if a business process or resource becomes unavailable, regardless of cause. In NIST CSF 2.0 terms, the BIA feeds Asset Management (ID.AM) and Risk Assessment (ID.RA). The two are complementary.
How long does a BIA take for an SMB?
For most SMBs, a focused BIA covering 5 to 10 core processes takes a few working sessions, not months. A 2 to 3 page output is sufficient. The goal is clarity on priorities, not exhaustive documentation.
What do RTO and RPO mean?
RTO (Recovery Time Objective) is the maximum acceptable downtime. RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time (e.g., one hour of transactions). RTO answers "how fast?" and RPO answers "how much data?"
Is a BIA useful without a regulatory mandate?
Yes. Even without a regulatory mandate, a BIA establishes what to protect and recover first, which structures the incident response. It is also a prerequisite for frameworks like ISO 27001 and an element of due diligence expected by enterprise customers.
How does a BIA connect to ISO 27001 and SOC 2?
A BIA produces the asset prioritization, business continuity, and recovery inputs that both frameworks expect. With Komplyo, those same inputs are scored against NIST CSF 2.0 and projected onto ISO 27001 and SOC 2; the same questions are never asked twice. See ISO 27001 or SOC 2: how to choose.
Summary
A Business Impact Analysis is not about producing the most comprehensive technical inventory. It establishes, in business terms, which processes keep the company running and what must be protected and restored first. For an SMB, the entry point is the process (invoicing, payroll, regulatory deadlines, service delivery), not the equipment; technical resources appear at step 2, as dependencies of those processes.
The published frameworks (NIST CSF 2.0, NIST SP 800-34, CISA's resources and ANSSI's EBIOS Risk Manager) provide the structure; the knowledge of the business, specific to each company, provides the content.