KPIs and Metrics - Application Classification
Scope and purpose
The indicators in this domain assess the quality, coverage and currency of the application risk classification process. Classification is the starting point of the entire SbD-ToE model: without a correct classification, the requirements applied are the wrong ones, exceptions carry inadequate approval authority, and controls are not proportional to the real risk.
Classification is not a one-off event - it is a continuous process that must reflect architectural, regulatory or functional changes. A system classified as L1 that has evolved to process large-scale personal data and was never reclassified is not an L1 system: it is an L3 system with L1 controls.
The CLA indicators feed the cross-cutting dimensions T-01 (Control coverage) and T-06 (SbD-ToE maturity).
Denominator and portfolio foundation
The CLA indicators are the origin of the denominator for all domain KPIs of the SbD-ToE programme. CLA-K01 establishes F-02 - the inventory of applications classified by risk level, which serves as the shared denominator for all chapters. Without a complete and up-to-date CLA-K01, the percentages of the other chapters have no interpretable basis.
The relationship is direct: F-01 (total inventory) and F-02 (classified by level) are absolute metrics that precede any domain percentage. See kpis-governanca.md - section "Portfolio foundation".
Conventions
| Symbol | Meaning |
|---|---|
| ✔ | Mandatory threshold for this level |
| - | Not applicable or not mandatory at this level |
| ↓ | Inverse indicator - a lower value indicates better performance |
Thresholds are cumulative: L3 includes all the obligations of L1 and L2.
Indicator types:
| Code | Meaning |
|---|---|
| Q% | Quantitative percentage |
| Q# | Quantitative count |
| Qt | Quantitative temporal (days) |
| Bin | Binary - verifiable existence with mandatory evidence |
Indicator catalogue
| ID | Indicator | Type | L1 | L2 | L3 | Dim. T | Period |
|---|---|---|---|---|---|---|---|
| CLA-K01 | % of portfolio applications with a formal risk classification documented and accessible | Q% | 100% | 100% | 100% | T-01 | Quarterly |
| CLA-K02 | % of classifications reviewed within the cycle defined per level (L3: quarterly; L2: half-yearly; L1: annual) | Q% | ≥ 90% | ≥ 95% | 100% | T-01 | Per cycle |
| CLA-K03 | % of applications with a significant change (architecture, data, regulation) whose classification was updated within ≤ 30 days | Q% | ≥ 80% | ≥ 95% | 100% | T-01 | Per event |
| CLA-K04 | % of L2/L3 system classifications validated by AppSec or GRC (not only the owner's self-assessment) | Q% | - | ≥ 90% | 100% | T-01 | Half-yearly |
| CLA-K05 | % of applications with residual risk formally documented and accepted by an owner with proportional authority | Q% | - | ≥ 85% | 100% | T-01 | Half-yearly |
| CLA-K06 | # of applications classified as L1 without review in the last 12 months and with a significant functional change recorded | Q# ↓ | = 0 | = 0 | = 0 | T-01 | Half-yearly |
Supplementary definitions
CLA-K01 - Documented classification: a classification is considered documented when it includes: (a) the risk level assigned (L1/L2/L3); (b) the criteria that determined the level (data type, exposure, criticality); (c) the owner responsible for the classification; (d) the date of the last review. Informal or verbal classifications do not satisfy this criterion.
CLA-K02 - Review cycles per level:
- L3: quarterly review or at each major release, whichever occurs first
- L2: half-yearly review or at each major release that changes the attack surface
- L1: annual review or after any significant functional change
CLA-K03 - Significant change: includes any of the following: (a) introduction of new types of personal or sensitive data; (b) integration with new external or third-party systems; (c) architecture change with impact on the attack surface; (d) change in the applicable regulatory context; (e) security incident revealing an underestimation of risk.
CLA-K04 - Validation by AppSec/GRC: validation may be carried out in a formal review, in the application onboarding process, or in an audit cycle. The criterion is the existence of a second pair of eyes with competence and independence relative to the application owner.
CLA-K05 - Accepted residual risk: residual risk is the risk that remains after the controls have been applied. Its formal acceptance requires: identification of the requirements not applied or partially applied, justification, compensating measures, and approval by an owner with authority proportional to the risk level (see Ch. 14 addon/12-processo-excecoes.md).
CLA-K06 - Undetected under-classification: this indicator is intended to detect situations in which an L1 application has evolved functionally without reclassification. Detection may be based on: changelog audit, review of product tickets, or analysis of integration with new systems.
Collection and instrumentation
| Indicator | Primary source | Instrumentation support | Automation |
|---|---|---|---|
| CLA-K01 | Application inventory / CMDB / GRC | Centralised application register | Partial |
| CLA-K02 | Classification register + review dates | GRC with review-expiry alerts | Partial |
| CLA-K03 | Change management system + classification register | Correlation between change tickets and reclassification date | No |
| CLA-K04 | Review register with validator identification | GRC + approval register | No |
| CLA-K05 | Residual risk register per application | GRC / risk decision repository | No |
| CLA-K06 | L1 application inventory + functional change log | Cross-audit between CMDB and changelog | No |
Cross-references
| Document | Relationship |
|---|---|
addon/01-modelo-classificacao-eixos.md | Classification model and criteria underpinning CLA-K01/K03 |
addon/04-risco-residual.md | Residual risk documentation process (CLA-K05) |
addon/02-ciclo-vida-risco.md | Review cycles that define the CLA-K02 thresholds |
Ch. 14 addon/12-processo-excecoes.md | Residual risk acceptance (CLA-K05) |
Ch. 14 kpis-governanca.md | Cross-cutting dimensions T-01, T-06 |