business-impact-analysis
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.