Analyzing the worst-case scenario resulting from the maximum disruption and defining the Maximum Tolerable Disruption Threshold (MTDT) are crucial steps in ensuring operational resilience. The worst-case scenario is the one resulting from the analysis related to "Extreme Cyber Attack"[1].
As for all dependency mapping steps of the methodology, the Service Owner is accountable for this activity and relies on business and IT SMEs. It is thus mandatory for architects to first get in touch with the Service Owner and the Operational Resilience Manager prior organizing any workshop.
The Maximum Tolerable Disruption Threshold (MTDT) is defined in the RISK0449 policy. It is a multi-dimensional measure that quantifies the tolerable level of service disruption based on time and other considerations, such as volume, customers affected, market impact, and firm impacts.
It represents the maximum disruption that a vital service can tolerate without unduly affecting any of the defined impact categories, such as market integrity, safety and soundness, and customer tolerance.
The MTDT is a mandatory input to this activity. It is usually summarized in a document that can be shared by the Service Owner.
The definition of the worst-case scenario and its impact on the business process involves a collaborative effort between process owners, and SMEs such as Enterprise/Functional Architects, Business Analysts, Product Owners and Application Managers.
For the identified worst-case, the analysis determines which activities would be affected and how:
| Impact | Description | Modeling |
|---|---|---|
| Performed | Activities that must be done anyway, using their associated critical applications | Automated / Manual |
| Manual | Activities that may need to be done manually without application support | Manual |
| Deferred | Activities that are postponed until normal operations resume | Deferred (light grey) |
| Skipped | Activities that may not be performed at all | Skipped (dark grey) |
Operation (worst-case) set as either
Manual (fully manual), Automated (supported by one or more applications),
Deferred or Skipped (not performed at all)A diagram, based on the one created previously to document the organized process, is created to visually depict these impacts.
The following diagram illustrates the worst-case scenario for the Cash Payments - Outgoing process.
Based on the MTDT and the definition of the worst-case scenario, it is then required to check if all critical applications are still needed. We'll classify them as "vital applications".
A diagram, similar to the one created at the step "Map Applications to Activities", is then created showing the application landscape under the worst-case scenario.
A focus should be made on deferred activities to ensure that we have a good knowledge and understanding of data that are needed as input to these activities, and data that result from them.
This is required to decide how these activities will be later done during the "back to normal" phase (when the major disruption will end), and can help define which data should be captured to enable a "replay" of the transactions.