Use this before writing or revising a continuity or disaster recovery plan, and again when a service, a major supplier or the business model changes. You get two files in a new folder, ./business-impact-analysis/: a spreadsheet you can open in Excel with one row per service, showing what an outage costs over time, how fast it must come back, how much data it may lose, what it depends on and whether today's backups can deliver that (bia.csv), and a short note of the assumptions, who gave each number and the decisions leadership must take (bia-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Leadership sets the objectives and accepts the gaps; the agent prices them.
Inputs to gather
Read the service catalogue or product list, customer contracts and service level terms, the architecture overview, the backup configuration and the records of restore tests, supplier contracts and their service levels, the risk register, and any existing continuity plan. Ask the reader, in one message: what the company earns per day and how it is spread across services, which contracts carry service credits or penalties, the busiest periods of the year, which processes would have regulators asking questions if down, and who signs off on recovery objectives.
Step 1: list services as the customer sees them
List what customers pay for and what keeps the company running: the product, the customer support channel, billing and payments, payroll, sales tooling. Internal systems are dependencies, not services; a database is not a service, the checkout it supports is. For a financial entity under DORA, mark which services support critical or important functions, since much of its continuity work hangs on that list (Art. 11 sets out ICT business continuity, including a business impact analysis). A small entity on the simplified framework (Art. 16) still needs the analysis, in proportion. For an entity in NIS 2 scope, business continuity, backup and crisis management sit among the measures in Art. 21(2)(c).
Step 2: price an outage over time
For each service, estimate the impact at one hour, four hours, one day, three days and one week, in the company's own numbers: revenue lost or deferred, service credits and penalties from contracts, customers likely to leave, regulatory exposure, safety, and the work to catch up afterwards. Note peak periods separately; a payroll outage on the day before payday is a different event from one mid-month. The point where impact becomes unacceptable is the maximum tolerable downtime. Set the recovery time objective below it, and make the margin visible arithmetic: maximum tolerable downtime, minus the time to detect and decide to invoke the plan, minus the time to verify the recovery.
Step 3: set the data loss objective
For each service, ask how much data the business can lose: can the last hour of orders be re-entered from another source, or is it gone? That answer, not the backup schedule, sets the recovery point objective. Record who gave the answer.
Step 4: map dependencies
For each service list the systems, data stores, people, suppliers and locations it needs. Flag single points of failure: one engineer who knows the restore, one region, one supplier with no alternative. Supplier dependencies matter most for small companies running on cloud and software services; their recovery is your recovery. Add the channels the company uses to notify customers and authorities (status page, email provider, support tool) as dependencies of every critical service, because they can fail in the same incident.
Step 5: compare required with achievable
For each service, put side by side: required recovery time and data loss, the backup frequency, the last successful restore test and how long it took, supplier service levels and their own recovery commitments, and people availability. A supplier promising monthly availability of a high percentage still allows hours of outage a month; convert percentages into hours before comparing. Any objective tighter than the last tested restore is a hope, not an objective. List each gap with options: invest (a second region, more frequent backups, a tested runbook), change the commitment, or accept the gap with a leadership decision.
Step 6: write it up
Fill the spreadsheet (bia.csv): service, owner role, impact by time band, maximum tolerable downtime, invocation time, recovery time objective, recovery point objective, dependencies, achievable recovery time and achievable data loss as numbers from the last restore test and backup frequency, gap, proposed option. In the notes (bia-notes.md), record the assumptions, who gave each number, the decisions needed, the owner who triggers a re-review and its default date (twelve months is a sound default). Run a framework lookup for what each framework in scope expects the analysis to record.
What good looks like
- Every objective traces to a priced impact and to the person who confirmed it, and the gap column is filled, not blank.
- A strong practitioner checks the last restore test first; it is the fastest way to find out whether the objectives are real.
- The common mistake is IT picking four hours for everything. Uniform objectives mean nobody asked the business, and the plan cannot prioritise when everything is down at once.
- The tell that it went wrong: objectives tighter than any restore ever tested, no supplier column, and every service marked tier one.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-business-impact-analysis
Rules
- MUST anchor impacts in the company's own figures and record who confirmed each objective.
- MUST compare every objective with the last tested restore and with supplier commitments.
- MUST write outputs only inside
./business-impact-analysis/ and ask before overwriting.
- NEVER set or approve a recovery objective, or accept a gap, on leadership's behalf.
- NEVER run a restore, failover or any test against live systems as part of this analysis.
- NEVER copy confidential financial detail beyond what the analysis needs; use ranges where exact figures are not required.