CERG SERVICE-LEVEL COMMITMENTS

What the Business Can Expect Back From CERG · Reciprocal, Published, Measured

Table of Contents

1. Purpose and Scope
2. Principles
3. Service Commitment Catalog - 3.6 What a missed commitment looks like in practice
4. Escalation Path for Missed Commitments
5. What This Is Not
6. Metrics and Reporting
7. Roles and Responsibilities
8. Document Control

1. Purpose and Scope

CERG’s operating premise is the yes-and default in CERG-GOV-OM-001 §2.2: the hard work is making “yes” safe, and guardrails should make the business move faster, not slower. The entire framework is built on engaging Engineering early, understanding exposure, and making the rules clear enough that work moves.

There is an asymmetry in how that premise is currently operationalized. Every service-level clock in the framework runs against the business: findings have remediation SLAs, exceptions have aging limits, patch currency is tracked. CERG’s own responsiveness back to the business, how fast it answers an architecture review request, dispositions an intake, or responds to an advisory question, is measured only by an annual stakeholder perception survey (CERG-TMPL-GOV-001). By the time that annual survey reports friction, the business has already built its workarounds. Shadow IT and shadow AI are what a slow security function produces.

This document corrects the asymmetry. It publishes CERG’s reciprocal commitments: for every clock CERG runs against the business, CERG runs a clock against itself. It applies to every CERG engagement model in OM-001 §5 (Project, Continuous Service, Advisory, Program Oversight).

A Slow Yes Is a No

“Make yes safe” only enables the business if yes is also fast. A security function that takes three weeks to answer a question has, in practice, said no, because the business has already moved without it. Publishing a clock on ourselves is how we prove the yes-and philosophy is a commitment and not a slogan.

2. Principles

Five principles govern CERG’s service commitments:

1. Reciprocity. For every service-level clock CERG runs against the business, CERG runs a clock against itself. Accountability is symmetric.
2. Tiered. Commitments scale by request criticality and project tier, not one-size-fits-all. A high-impact regulated project and a minor internal tool do not get the same clock.
3. Published. Commitments are visible to the business, not internal targets. The business is entitled to know what to expect and to escalate when it does not get it.
4. Measured. Every commitment maps to a metric in CERG-GOV-MTR-001 and is reported alongside, and with equal weight to, the discipline metrics that measure the business.
5. Escalation, not silence. A missed commitment triggers a defined escalation, never a silent delay. A request that will miss its commitment is surfaced before the clock expires, not after.

3. Service Commitment Catalog

The turnaround values below are preliminary defaults requiring organizational calibration, following the calibration pattern in CERG-GOV-RMF-001 §12. They are starting points for a mid-size organization; each organization calibrates them to its own staffing and demand, and the CISO approves the calibrated set. Business days are used throughout.

3.1 Project Engagement (Engineering-Led, OM-001 §5.1)

3.2 Continuous Service (Risk-Led, OM-001 §5.2)

3.3 Advisory (Cross-Pillar, OM-001 §5.3)

3.4 Program Oversight and Risk Decisions (Governance-Led, OM-001 §5.4)

Intake clock, not decision clock. The commitment in §3.4 is to acknowledge and route the request promptly. The decision authority and the substantive risk judgment remain with the approver named in CERG-GOV-RMF-001 §9.7. SLC commitments govern CERG’s responsiveness; they never compress or override a risk decision.

3.5 Adoption-Phase SLA Targets

The commitment values in §3.1–§3.4 are mature-program targets. New adopters progress through adoption gates; SR metrics use the phase-adjusted targets below until the program reaches Gate 3. Phase context is reported on the CISO Dashboard.

Phase Advancement. Advancement from one gate to the next is recorded in the adoption gates document (CERG-GOV-IMP-005) and communicated to the Cyber Oversight Group. SR metric reporting switches to the next phase target upon confirmation of gate transition.

3.6 What a missed commitment looks like in practice

The SLA commitments above are not abstractions. They show up in real meetings. The worked example below is a fictional but realistic Tuesday morning scenario at a 60-person SaaS company in the second quarter of CERG Standard adoption. It illustrates what the §4 escalation path actually produces.

A product team submits a T1 architecture review intake for a new customer-facing analytics feature on a Tuesday at 9 a.m. The intake is logged in the Project Intake Record, tiered T1 because the workload is internet-facing and handles customer data, and routed to Engineering. Per §3.5 Gate 2, the SR-001 commitment is a 10-business-day architecture review turnaround.

By day 6, Engineering has not started the review. The intake sits in the queue behind two higher-priority reviews. Nobody on Engineering has acknowledged the delay to the product team. By day 9, the product manager pings Engineering directly. Engineering says “we’ll get to it.” By day 11, the 10-business-day commitment has been missed. No notification was sent per §4 step 1.

Here is what the §4 escalation path produces:

1. Day 11 (commitment missed, no notification sent). The Engineering Pillar Leader is auto-notified by the SR-001 metric breach. The single miss is logged. The Engineering Pillar Leader contacts the product manager the same morning with a revised date (day 14) and a reason (“behind on two other T1s; yours is next”). The revised date goes into the intake record.

2. Day 14 (revised date met). The architecture review is delivered. The SR-001 metric records the miss: the commitment clock was 10 business days, the actual was 14. Quality was acceptable; the product team got a useful review.

3. End of month (single miss). The Engineering Pillar Leader reviews the SR-001 trend. One miss in the month is within noise. No further action. The miss is in the dashboard.

4. Quarter review (pattern). If the same pillar has three or more misses in a quarter, the pattern surfaces to the CISO and the Cyber Oversight Group per §4 step 3. The CISO opens a discussion: is the published value mis-calibrated to capacity, or is the pillar overcommitted? The answer drives a workforce-planning or scoping decision, not a “try harder” instruction.

5. Annual (systemic). If the same pillar has chronic misses across two quarters, the CISO records a Program Improvement Register entry per §4 step 4 with source “SLC systemic miss, pillar X, YYYY.” The improvement is owned at the CISO level, not the pillar level, because chronic misses signal a capacity gap CERG must fix.

The same pattern applies to every commitment in §3. The numbers are smaller or larger, the pillar is different, but the chain is the same: miss, log, communicate, escalate by pattern, address systemically.

The point of publishing these commitments is not to create a metric treadmill. The point is to make CERG’s responsiveness visible so that friction is caught early, not when the business has built workarounds. A single miss is acceptable. A pattern is a finding. Chronic is a program-level problem.

For a 90-day narrative that includes the first SR-001 miss in a real adoption arc, see Story 10 (The new CISO’s first 90 days). For the worked example of how a business-side SLA breach is handled by Risk, see Story 2 (Critical vulnerability).

4. Escalation Path for Missed Commitments

When CERG misses, or forecasts that it will miss, a published commitment:

1. Before the clock expires: the owning role notifies the requester that the commitment will be missed, with a revised date and reason. Silence is not permitted.
2. On a miss: the owning Pillar Leader is auto-notified. A single miss is logged.
3. On repeated misses: a pattern of misses in a service category surfaces to the CISO and to the Cyber Oversight Group, mirroring the escalation symmetry that applies to business-side SLA breaches.
4. Systemic misses are a CERG program finding and are recorded in the Program Improvement Register (CERG-GOV-IMPREG-001). A missed commitment is CERG’s problem to fix, not the requester’s problem to absorb. Chronic misses signal a capacity or process gap in CERG, addressed through workforce planning, not by quietly deprioritizing the business.

5. What This Is Not

• Not a guarantee of “yes.” The commitment is to respond within the clock, not to approve. A fast, documented “no” with a path forward satisfies the commitment fully.
• Not a bypass of rigor. SLC commitments never justify a shallow architecture review or a rubber-stamp risk decision. Speed is measured alongside quality, and the anti-shallow-metrics guardrails in CERG-GOV-MTR-001 §8 apply. A fast review that misses a material risk is a failure, not a success.
• Not a substitute for prioritization. When demand exceeds capacity, CERG triages by risk and business criticality and communicates the revised dates per Section 4. It does not silently let the lowest-priority requests rot.

6. Metrics and Reporting

Every commitment in Section 3 maps to a CERG Service Responsiveness metric (SR-001 through SR-005) defined in CERG-GOV-MTR-001. These metrics are reported on the CISO dashboard with equal standing to the business-discipline metrics, and SR-004 (SLC Commitment Adherence) is reported to the Cyber Oversight Group and the board. The annual stakeholder perception survey (CERG-TMPL-GOV-001) provides the qualitative companion to these continuous quantitative measures, so friction is caught monthly rather than once a year.

7. Roles and Responsibilities

8. Document Control

Revision History

Review Triggers

• Annual scheduled review.
• Change to any OM-001 §5 engagement model.
• Calibration of the preliminary default turnaround values.
• A pattern of missed commitments indicating the published values are mis-calibrated to capacity.

Related Documents

• CERG-GOV-OM-001 - Operating Model (engagement models)
• CERG-GOV-MTR-001 - Metrics and Reporting (SR-series metrics)
• CERG-GOV-FLOW-001 - Cross-Pillar Operational Flows (F-02 intake)
• CERG-PRC-AR-001 - Architecture Review and Project Intake
• CERG-TMPL-GOV-001 - Stakeholder Perception Survey
• CERG-GOV-IMPREG-001 - Program Improvement Register

Source: governance/CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md · Download .md · View on GitHub