How bad is not how fast
Basic terms, part 2: protection needs assessment and business impact analysis both ask about damage, but about different damage. One has no clock, the other lives by it. Why the BSI itself warns against merging them, and what separates normal operation from emergency operation.
Many organisations keep two tables. In one, a business application is listed with “availability: high”. In the other, the same application carries a number, say four hours. Both are treated as expressions of how important the thing is, and are used interchangeably.
They answer two different questions, and neither can be derived from the other.
Protection needs ask: how bad?
BSI Standard 200-2 states the goal of the protection needs assessment as deciding, for every object in the information domain, what protection it requires with regard to confidentiality, integrity and availability. Assessed is the expected damage if one of these three is impaired. The standard recommends three categories: normal, high and very high.
What does not appear in that question is time. “Availability: high” says that an outage causes serious damage. It does not say whether that damage occurs after two hours or after two weeks.
The BIA asks: how fast?
That is where the business impact analysis of BSI Standard 200-4 begins. Its goal is to determine consistently whether a business process is time-critical and how long it may be unavailable before intolerable damage occurs. The guiding question carries time within it: what damage potential is to be expected in each time horizon if a business process fails?
Damage is therefore not assessed once but across a course of time. Part of this is the intolerability level: the decision at which damage category the effects of an outage are no longer tolerated.
Two figures that follow
The maximum tolerable period of disruption (MTPD) defines how long a business process may be unavailable before intolerable effects occur. It is a limit, not a target.
The recovery time objective (RTO) is derived from it and assigned to time-critical processes and resources. It is the target that must sit before the limit.
The standard demonstrates this with data breach notification. The statutory deadline is the maximum tolerable period of disruption, because by then the notification must already have been filed. The recovery time objective is derived by subtracting both response time and process execution time from that limit, ideally with a buffer. Anyone recording the 72 hours of Article 33 GDPR as a recovery target has done the arithmetic backwards.
Why the BSI warns against merging them
Both can be coupled, and the standard even recommends it: using the same damage scenarios and categories allows joint collection, which makes deviations between availability in the ISMS and continuity in the BCM easier to spot.
In the same section sits the warning, and it contains the actual distinction: the protection needs assessment considers all resources for normal operation, while the BIA considers the resources for emergency operation. Added to that, protection needs assessments tend, for efficiency, towards maximum groupings that can differ considerably from the clustering used in a BIA.
In plain terms: one analysis asks what must be protected in normal operation. The other asks what must run again first in an emergency. That is not the same list, and not the same order. An application with high protection needs may sit idle for weeks in emergency operation, and a process with normal protection needs may block the entire organisation after four hours.
And criticality?
The word carries both meanings in practice and therefore none. “Critical” may mean high protection needs, time criticality in the BIA sense, or membership of a regulated sector under NIS2 or national critical-infrastructure law.
The question that resolves it is short: critical for what, and from when? Anyone who cannot answer it does not yet have a classification, only a label.
What this means in practice
If only one of the two analyses exists, what is missing is not half of one thing but one whole thing. Without protection needs there is no basis for confidentiality and integrity, which do not appear in a BIA at all. Without a BIA there is no defensible time figure, and therefore no basis for recovery plans, redundancy or emergency operating arrangements.
Only together do they produce the sentence that holds when it counts: this application is this important, and it has this much time.
Sources
BSI Standard 200-2 (IT-Grundschutz methodology), chapter 8.2, and BSI Standard 200-4 (business continuity management), chapter 7, both published by the German Federal Office for Information Security: BSI standards on IT-Grundschutz. The 72-hour deadline is set out in Article 33 GDPR.
Next time: basic, core and standard safeguarding. Three approaches that are regularly mistaken for three maturity levels.
The previous part: Threat is not hazard.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.