Activities first, systems second
A BIA that starts from the application inventory produces a criticality per server that no executive can arbitrate. A BIA that starts from the value chain, the activities that make and deliver the product, then maps each to its supporting systems, data and suppliers, produces a criticality the business recognizes as its own. The dependencies are the point: a low-profile ticketing system becomes critical the day the BIA shows that order intake stops without it.
The objectives it produces
For each activity, the maximum tolerable period of disruption, the recovery time objective the continuity plan must meet, the recovery point objective the backups must respect, and the minimum service level during degraded operation. These numbers set the requirements for continuity and disaster recovery, but they also calibrate impact in the risk analysis: an availability scenario on an activity with a four-hour tolerance is scored differently from one with a week.
In NIS2 and DORA
Business continuity, backup management and crisis management are among the NIS2 risk-management measures; DORA requires financial entities to identify and classify their ICT-supported business functions and to run a business impact analysis of their exposure to severe business disruptions, feeding the response and recovery plans. A BIA kept current, per activity and per entity, is what both frameworks assume exists, and what most groups only rebuild during an audit.