Security Governance KPIs Policy
1. Objective
This policy defines the requirements for the definition, collection, analysis and reporting of key performance indicators (KPIs) of the organisation's security governance programme.
A security programme without metrics is a programme without a feedback loop - it is not possible to determine whether it is working, whether it is improving or whether resources are being applied to the right problems. Security governance KPIs turn technical activity into evidence of performance: they allow executive management to take well-founded strategic decisions, to identify systemic deviations before they become incidents, and to demonstrate maturity to regulators and auditors. Poorly defined metrics, or metrics collected without rigour, are as harmful as the absence of metrics - they create false confidence and divert attention from the real risks.
The objective of this policy is to ensure that:
- The security programme has a defined set of KPIs, with established sources, owners and collection cadence
- The KPIs cover the relevant governance dimensions: compliance, operations, incidents, suppliers and maturity
- Reporting is carried out with a cadence proportionate to the risk level and distributed to the correct recipients
- Deviations in critical KPIs give rise to corrective actions with an owner and a deadline
- The maturity level of the programme is assessed periodically with reference to recognised frameworks
2. Scope and applicability
| Level | Applicability |
|---|
| L1 | Basic; minimum compliance KPIs; annual reporting to management |
| L2 | Mandatory; defined set of KPIs; dashboard recommended; half-yearly reporting |
| L3 | Mandatory; complete KPIs; dashboard configured; automatic alerts; quarterly reporting to executive management |
3. KPI categories
Security governance KPIs must cover the following categories:
| KPI | Description | Target |
|---|
| % of applications with an up-to-date compliance repository | Applications with a valid repository (last review within the period) | > 90% |
| % of L2/L3 applications with a designated Security Champion | Applications with a formal owner and training completed | 100% |
| % of SbD-ToE chapters with verified compliance per application | Average coverage of the applicable chapters | > 80% |
| % of active exceptions within the TTL | Non-expired exceptions as a proportion of the active total | > 95% |
| % of exceptions resolved within the deadline | Exceptions with remediation completed within the approved deadline | > 70% |
| KPI | Description | Target |
|---|
| MTTR by severity | Average time between identification and remediation of findings | In line with Policy 19 §4.3 (Critical 30 / 7 / 3 days; High 90 / 30 / 15 days at L1 / L2 / L3) |
| Finding recurrence rate | % of findings of the same type that reappear within 90 days | < 10% |
| % of Critical/High findings remediated within the SLA | Compliance with the SLAs defined in the testing policy | > 90% |
| Rate of active exceptions vs. total findings | Indicator of accumulation of accepted risk | Downward trend |
3.3 Operations and incident response
| KPI | Description | Target |
|---|
| % of P1/P2 alerts responded to within the SLA | Compliance with the SLAs of the alert management policy | > 95% |
| True positive rate (P1/P2 alerts) | % of P1/P2 alerts that correspond to real incidents | > 70% |
| Number of security incidents per period | Trend of occurrences | Downward or stable trend |
| Mean time to detect (MTTD) | Time between the start of the incident and its detection | Internal reference by type |
| Mean time to respond to incidents (MTTR, OPS-K04) | Time between the alert and the start of the mitigation action | ≤ 8 h (L1), ≤ 4 h (L2), ≤ 1 h (L3) |
| % of incidents with a post-mortem held within the deadline | Post-mortems completed ≤ 5 working days after resolution | 100% for P1; > 80% for P2 |
3.4 Pipeline and development
| KPI | Description | Target |
|---|
| % of pipelines with active security gates | Proportion of pipelines with SAST, SCA and secrets scanning | > 95% at L2/L3 |
| Pipeline blocking rate due to security | % of executions blocked by a security gate | Internal reference; downward trend desirable |
| % of artefacts with a generated and signed SBOM | SBOM generation coverage | 100% at L3 |
| % of secrets in a vault vs. hardcoded secrets detected | Proportion of secrets managed correctly | Hardcoded = 0 |
3.5 Suppliers and third parties
| KPI | Description | Target |
|---|
| % of active suppliers with up-to-date due diligence | Suppliers within the reassessment cycle | 100% |
| % of contracts with compliant security clauses | Contracts that include the mandatory minimum clauses | 100% at L2/L3 |
| % of contractors with technical onboarding completed | Active contractors with a validated training track and quiz | 100% |
| Supplier incident notification SLA | Rate of compliance with the contractual notification deadline | > 90% |
| KPI | Description | Target |
|---|
| Mandatory training completion rate | % of staff with a completed training track | > 90% |
| Training quiz pass rate | % of participants with a score ≥ 80% | > 85% |
| % of Security Champions with up-to-date training | Champions with valid, non-expired training | 100% |
4. Data sources and collection
| Category | Primary sources | Responsible for collection |
|---|
| Compliance and traceability | Compliance repositories; GRC tool; owner records | GRC / AppSec |
| Remediation | DefectDojo or a centralised findings platform; tickets | AppSec / DevOps |
| Operations and incidents | SIEM; on-call platform (PagerDuty/OpsGenie); IRP records | SOC / GRC |
| Pipeline and development | CI/CD platform; pipeline records; signed artefacts | DevOps / AppSec |
| Suppliers | Contract records; due diligence results; onboarding | GRC / Procurement |
| Training | LMS; completion records; quiz scores | GRC / HR |
5. Collection and reporting cadence
| Activity | L1 | L2 | L3 |
|---|
| Automatic collection of metrics | Not applicable | Recommended (monthly) | Mandatory (continuous + consolidated monthly) |
| Dashboard updated | Not applicable | Monthly | Continuous |
| Report for Tech Lead / AppSec | Not applicable | Monthly | Monthly |
| Report for CISO / Executive Management | Annual | Half-yearly | Quarterly |
| Report for Audit | Annual | Annual | Half-yearly (or on request) |
6. Intervention thresholds
Certain deviations in the KPIs must trigger immediate corrective actions, regardless of the regular reporting cycle:
| Condition | Action |
|---|
| % of P1 alerts responded to within the SLA < 80% | Immediate review of the on-call and escalation process |
| Finding recurrence rate > 25% | Review of the remediation process and of the development guidelines |
| % of expired exceptions without reassessment > 10% | Audit of exceptions; escalation to decision-makers |
| Active contractor without completed onboarding | Access blocked until onboarding is completed |
| Active supplier with expired due diligence at L3 | Immediate review; suspension of new access until reassessment |
| MTTD of a P1 incident > 24 hours | Review of detection rules and monitoring coverage |
7. Maturity assessment
In addition to the operational KPIs, the organisation must periodically assess the maturity level of the security programme with reference to recognised frameworks:
| Framework | Dimensions assessed | Cadence |
|---|
| OWASP SAMM | Governance, Design, Implementation, Verification, Operations | Annual |
| NIST SSDF | Prepare, Protect, Produce, Respond | Annual |
| BSIMM (optional) | Benchmark against industry | Every 2 years |
The result of the maturity assessment must:
- Be documented and compared with the previous assessment (evolution)
- Identify the dimensions with the largest gap against the organisation's maturity target
- Give rise to an improvement plan with priorities, owners and deadlines
- Be presented to executive management as part of the annual security report
The maturity assessment does not replace the operational KPIs - they are complementary perspectives. The KPIs measure current performance; the maturity assessment measures the installed capability to sustain that performance over time.
| Report type | Recipients | Minimum content |
|---|
| Monthly operational report | AppSec, Tech Leads, DevOps | Status of operational KPIs; deviations; actions in progress |
| Quarterly / half-yearly report | CISO, Executive Management | Aggregated view of the portfolio; trends; strategic KPIs; action plan |
| Report for audit | Internal / external auditors | Compliance status per chapter; evidence; active exceptions; history |
| Continuous dashboard | AppSec, GRC, CISO | Real-time status of critical operational KPIs; active alerts |
9. Responsibilities
| Role | Responsibility |
|---|
| GRC / Compliance | Define and maintain the set of KPIs; coordinate data collection; produce reports; manage threshold alerts |
| AppSec Engineer | Provide data on findings, pipelines and technical compliance; validate the quality of the metrics; support the maturity assessment |
| DevOps / SRE | Provide data on pipelines, alerts and operations; configure collection automation |
| Security Champion | Provide the application's compliance data; update the compliance repository |
| CISO / Executive Management | Analyse reports; approve KPI targets; take data-driven strategic decisions; ensure resources for corrective actions |
10. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- A significant change to the security programme that makes the current KPIs inadequate
- A maturity assessment result that identifies gaps in the defined KPIs
- A regulatory change that imposes new measurement or reporting requirements
11. Normative and technical references
| Reference | Relevance |
|---|
| SbD-ToE Ch. 14 - Governance and Contracting | US-05: governance KPIs; US-11: consolidation of KPIs and maturity |
Organisational Traceability Policy (34_policy-rastreabilidade-organizacional.md) | Data source for compliance KPIs |
Alert Management Policy (31_policy-gestao-alertas.md) | Alert quality KPIs and SLAs |
IRP Policy (32_policy-irp.md) | Incident response KPIs (MTTD, MTTR) |
| OWASP SAMM v2 | Software Assurance Maturity Model - maturity framework |
| NIST SSDF (SP 800-218) | Secure Software Development Framework - practices and maturity |
| BSIMM | Building Security In Maturity Model - industry benchmark |
| ISO/IEC 27001 - A.18 | Compliance; security reviews and audits |
| DORA - Art. 6, 17 | ICT risk management and reporting requirements |
| NIS2 - Art. 21 | Security measures and governance obligations |