Review Checklist - Application Criticality Classification
This checklist applies to all applications classified according to the criteria defined in Chapter 01 - Application Criticality Classification. It serves as an instrument for periodic verification, internal audit and an operational maturity KPI, making it possible to confirm whether:
- The classification is up to date and justified;
- The corresponding minimum controls have been applied;
- There is traceable evidence supporting the risk decisions.
🗓️ A review is recommended at least at the cadence of Policy 04 (annual at L1, half-yearly at L2, quarterly at L3), or whenever there are relevant changes (functionality, data, exposure).
📋 Verification Items
| Item | Verified? |
|---|---|
| Is there a formal, documented criticality classification covering the three axes (exposure, data, impact)? | ☐ |
| Was the classification approved by the authority proportional to the level (L1 tech lead, L2 AppSec, L3 CISO), dated and assigned to a responsible person? | ☐ |
| Does the assigned level determine and activate the minimum controls, traceable to the current pipeline or backlog? | ☐ |
| Was it assessed whether the risk attributes (detectability, non-determinism, delegation or automatic execution) require reinforcement to the next level up, and was this applied where indicated? | ☐ |
| Whenever automation or decision support (incl. AI) alters exposure, data or delegation, were the axes reassessed with the rationale recorded? | ☐ |
| Are reclassification criteria and triggers documented? | ☐ |
| After each significant change, was the classification reassessed within the defined maximum period (≤30 days)? | ☐ |
| Was the classification reviewed within the periodic cycle for its level (L1 annual, L2 half-yearly, L3 quarterly), with evidence? | ☐ |
| Do risk acceptance decisions verify the formal criteria for the level (sufficient evidence; residual risk within the threshold L1≤9 / L2≤6 / L3≤4)? | ☐ |
| Is the accepted residual risk documented with compensation, owner and expiry date, with no expired exceptions awaiting renewal? | ☐ |
| Is each risk validated by at least one threat from a recognised catalogue (STRIDE, MITRE ATT&CK or CAPEC)? | ☐ |
| Is the application listed in a central inventory or GRC with level, review date, owner and compliance status, accessible for audit? | ☐ |
| Is the classification decision recorded in a versioned, traceable repository? | ☐ |
| Where a tool took part in the classification, are the tool, version, date and final human decision recorded? | ☐ |
🔄 Final Notes
- This checklist may be used as a digital form or review template, and integrated into pipelines, dashboards or backlog tools.
- Complete validation makes it possible to assert compliance with Chapter 01 - constituting objective evidence of maturity and security control in the SbD-ToE model.
- It must be archived as an auditable record and associated with the corresponding release cycle.