Alternative model via Adoption of Existing Classifications (e.g. DRP/BIA)
🎯 Objective
To guide the reuse of existing classifications - namely DRP (Disaster Recovery Plan) and BIA (Business Impact Analysis) - as a basis for application risk classification, avoiding duplicated effort and promoting consistency in the assessment of criticality.
📘 Context
Many organisations already carry out an impact classification based on business continuity, within processes such as DRP or BIA, among others. These classifications generally include attributes such as:
- RTO (Recovery Time Objective)
- RPO (Recovery Point Objective)
- Financial, reputational or operational impact
- Recovery priority
Although they do not focus directly on security, these data are strongly correlatable with application risk and can be used as initial input or justification for the risk classification prescribed in SbD-ToE.
🔁 Practical mapping between DRP/BIA and security risk
| DRP/BIA classification | Interpretation in the SbD-ToE context |
|---|---|
| Critical | High Risk |
| Important / Medium | Medium Risk |
| Non-essential / Low | Low Risk |
⚠️ This mapping must be confirmed by security analysis, considering the nature of the data and the exposure of the application.
📝 Practical example
A system classified as Critical in the DRP, with the following parameters:
- RTO: < 4h
- RPO: < 1h
- Personal and billing data
- Integration with third parties
- Exposed to the internet
→ Must automatically be classified as High Risk, requiring:
- Formal threat modelling
- Complete security requirements
- Continuous automated testing
- Active monitoring
📌 Recommendations
- Validate that the DRP/BIA classification is up to date and corresponds to the scope of the current application
- Attach or reference the impact classification in the repository where the risk classification is documented
- If the application is composed of multiple modules, consider classification per component, not only globally
- In case of divergence between the DRP classification and the one observed in security, record both rationales and discuss with the teams involved
🧩 Operational integration
In practice, these classifications can be reused in three ways:
- Direct import of the data into the risk register (e.g. file, wiki, tool)
- Cross-linking between artefacts (e.g. link to the DRP record in the risk register)
- Single template that includes business impact and security risk fields
A good practice is to include this validation as one of the criteria in the classification checklist.