Skip to main content

KPIs and Metrics - Secure Deployment

Scope and purpose​

The indicators of this domain assess the security of the deployment process and release management: the coverage of pre-deployment validations, the control and traceability of emergency deployments (break-glass), the quality of deployment evidence artefacts, and the effective separation of configuration between environments.

Deployment is the moment at which the implemented controls become effective - or fail. The DPL indicators focus on the discipline of the process: a deployment without a validated security checklist is not necessarily insecure, but it is a deployment without evidence that security was verified. That distinction is auditable and relevant.

The DPL indicators feed the cross-cutting dimensions T-01 (Control coverage) and T-02 (Exception health).


Denominator and portfolio foundation​

The indicators of this domain use as their denominator F-02 - applications with a formal risk classification (Ch. 01, CLA-K01). The percentages are interpretable only in relation to the set of applications classified at the relevant risk level - not in relation to the total portfolio or to ad-hoc subsets.

See kpis-governanca.md - section "Portfolio foundation" - for the SbD-ToE adoptability funnel and the relation between denominators.


Conventions​

SymbolMeaning
✔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:

CodeMeaning
Q%Quantitative, percentage
Q#Quantitative, count
QtQuantitative, temporal (hours/days)

Indicator catalogue​

IDIndicatorTypeL1L2L3Dim. TPeriod
DPL-K01% of production deployments with a validated and recorded pre-deployment security checklistQ%≥ 70%≥ 95%100%T-01Per release
DPL-K02% of emergency deployments (break-glass) with post-facto approval recorded in less than 24hQ%100%100%100%T-02Per event
DPL-K03% of emergency deployments with notification to the CISO (or equivalent) carried out before or during the deploymentQ%-100%100%T-02Per event
DPL-K04# of production rollbacks for security reasons per quarterQ#mandatory record≤ 2≤ 1T-03Quarterly
DPL-K05% of production environments with verified separation of secrets and configuration from non-productionQ%-≥ 90%100%T-01Half-yearly
DPL-K06% of releases with a traceable deployment evidence artefact (pipeline ID, artefact hash, timestamp)Q%≥ 70%≥ 95%100%T-01Per release
DPL-K07% of emergency deployments with a security post-mortem carried out in less than 5 working daysQ%-≥ 80%100%T-02Per event

Complementary definitions​

DPL-K01 - Validated checklist: a checklist is considered validated when it: (a) was completed by the technical owner of the deployment; (b) includes verification of the pipeline's security gates; (c) is associated with the deployment identifier (pipeline run ID, ticket, change record). Generic checklists with no association to the specific deployment do not satisfy this criterion.

DPL-K02 - Emergency deployment (break-glass): any deployment that bypasses one or more mandatory security gates, or that is carried out outside the change management process defined for L2/L3 systems. Post-facto approval is an exception to the normal process - it is not a permanent alternative. The 24h deadline is absolute; there is no extension.

DPL-K03 - Notification to the CISO: for L3 systems, the notification must be made in real time (during the deployment) or before. For L2 systems, it may be post-event but within the 24h of DPL-K02. The notification channel (email, Slack, ticket) is free; the evidence of notification is mandatory.

DPL-K04 - Rollback for security reasons: includes rollbacks initiated by: discovery of a vulnerability in production, failure of a security control after deployment, insecure configuration detected after deployment, or instruction from the CISO/AppSec. Rollbacks for other reasons (performance, functional bugs) do not enter this indicator.

DPL-K05 - Configuration separation: the separation is considered verified when: (a) production secrets are not accessible in non-production environments; (b) production-specific environment variables do not exist in staging/dev; (c) the verification was carried out by technical audit (configuration scan or IaC review) with recorded evidence.

DPL-K07 - Security post-mortem: must include: the timeline of the event, the root cause, the security impact (actual and potential), corrective actions with an owner and a deadline, and a review of the process that allowed the emergency deployment. Post-mortems without a security root cause analysis do not satisfy this criterion.


Collection and instrumentation​

IndicatorPrimary sourceReference toolsAutomation
DPL-K01Change management system + pipeline logsJira, ServiceNow + pipeline (GitHub Actions, GitLab)Partial
DPL-K02Emergency deployment register + approval systemChange record + exception registerNo
DPL-K03Notification log + communication recordEmail/Slack with timestamp + GRC registerNo
DPL-K04Change management system + incident trackingJira, PagerDuty, ServiceNowPartial
DPL-K05Configuration audit + IaC reviewEnvironment variable audit + IaC scanPartial
DPL-K06Pipeline logs + release registerCI/CD platform (run ID, artefact hash, timestamp)Yes
DPL-K07Post-mortem repositoryConfluence, GitHub (post-mortem templates)No

Cross-references​

DocumentRelation
addon/00-catalogo-requisitos.mdRequirements DPL-001..009 that underpin the indicators
addon/09-excecoes-deploy.mdBreak-glass process and post-facto approval (DPL-K02/K03/K07)
addon/04-validacoes-pre-deploy.mdPre-deployment security checklist (DPL-K01)
Ch. 14 kpis-governanca.mdCross-cutting dimensions T-01, T-02