PROGRAM IMPROVEMENT REGISTER

Register Schema · Lifecycle · Integration · Reporting · Operating Procedure

Table of Contents

1. Purpose and Scope
2. Why a Separate Improvement Register
3. Register Schema
4. Improvement Lifecycle
5. Integration with the Risk Register
6. Integration with Other CERG Instruments
7. Reporting
8. Roles and Responsibilities
9. Register Maintenance and Hygiene
10. Document Control

1. Purpose and Scope

The CERG Framework targets NIST CSF Adaptive maturity. A defining characteristic of an Adaptive program is that it does not just respond to findings : it changes itself in response to what it learns. It identifies systemic weaknesses, alters its own controls and procedures, and verifies that the changes worked.

This document defines the Program Improvement Register: the authoritative, durable record of every program-level change CERG makes, why it was made, who was accountable, and whether it produced the intended effect. It is the audit trail that answers the assessor’s question: “How has your program evolved, and can you prove that evolution made it better?”

This document applies to every CERG program improvement, regardless of source: lessons learned (PRC-LL-001), intelligence-driven reprioritization, maturity assessment gaps (MAT-001), metric threshold breaches (MTR-001), CISO direction, or external requirement changes.

Program Improvement vs. Operational Change

Patching a server is an operational change. It does not go in the improvement register. Adding a control to CB-001 that requires automated patch verification is a program improvement. It goes in the improvement register.

The test: “Would this change still be relevant to an assessor reviewing our program two years from now?” If yes, it belongs here.

2. Why a Separate Improvement Register

CERG already has a risk register (PRC-RM-001). Using it for program improvements creates three problems:

1. Category error. A risk is a threat-vulnerability-impact-likelihood construct with a treatment plan. A program improvement : “we consolidated two duplicate procedures,” “we raised the architecture review SLA from 85% to 95%,” “we added a new leading indicator” : is not a risk. Forcing it into a risk register schema distorts both the risk data and the improvement data.

2. Noise in risk reporting. The CISO and board review the risk register to understand exposure. Mixing in program improvements : which are positive, forward-looking changes : dilutes the risk signal.

3. Wrong lifecycle. Risks have treatment plans, residual scores, and acceptance decisions. Improvements have implementation, verification, and effectiveness outcomes. The lifecycles are different; the register should be different.

When to Use Each Register

Situation	Correct Register
A vulnerability is found on a production server	Risk register (PRC-RM-001)
The same vulnerability class appears across four pen tests and an audit; the root cause is a missing standard	Improvement register (this document)
A business unit wants to accept a risk for 6 months	Risk register
The exception process itself needs a revision because it takes too long	Improvement register
An incident occurred; the IR team contained it	Risk register (post-incident risk entry)
The incident revealed that detection rules need updating for an entire attack technique family	Improvement register

3. Register Schema

The improvement register is a structured record. Every entry contains the following fields. The register may be maintained in any platform that supports structured data (spreadsheet, database, GRC tool), but the schema is fixed.

One Improvement, One Entry

If an improvement requires changes to three documents and a new tool, it is still one improvement : one root cause analysis, one decision, one accountable owner. The “Affected Artifacts” field captures the scope. Do not create multiple entries for one improvement decision.

4. Improvement Lifecycle

Every improvement follows a defined lifecycle. Status changes are recorded with a date and the role making the change.

4.1 Lifecycle States

Proposed → Approved → In Progress → Complete → Verified → Closed
                  ↘                        ↘
              Declined              Ineffective → Re-Opened → In Progress (revised)

Complete Is Not Closed

“Complete” means the change was made : the standard was amended, the tool was deployed, the procedure was updated. “Verified” means the change worked : the amendment actually prevented recurrence, the tool actually caught the thing it was designed to catch, the procedure actually improved the outcome. An improvement that sits at “Complete” without verification is an open item, not a success.

4.2 Aging Rules

• An improvement in “Proposed” for more than 30 days without an approval decision is escalated to the CISO.
• An improvement in “In Progress” past its target date is flagged at the next quarterly review.
• An improvement in “Complete” for more than one quarter without verification is escalated : the verification was either not planned or is being avoided.
• An improvement in “Re-Opened” for more than two quarters is escalated to the CISO for a decision: revise the approach, accept the gap, or close with a documented rationale.

5. Integration with the Risk Register

The risk register (PRC-RM-001) and the improvement register are distinct instruments with a defined interface.

5.1 Risk-to-Improvement Linkage

When a risk register entry identifies a systemic weakness that requires a program change (not just a risk treatment), the risk register entry references the improvement ID. Example:

• Risk register entry RM-2026-047: “Critical vulnerability in SCADA firmware : CVSS 9.1 : treatment: patch within 90 days.”
• Improvement register entry IMP-2026-001: “Add automated firmware-version discovery to CMDB; amend STD-AM-001 and PRC-VM-001.”
• Risk register entry RM-2026-047 is updated with a reference: “Systemic improvement tracked in IMP-2026-001.”

The risk itself is still managed in the risk register. The systemic fix is managed in the improvement register. They reference each other; neither subsumes the other.

5.2 Improvement-to-Risk Linkage

When an improvement is approved that will reduce a class of risk, the risk register owner is notified. If the improvement changes the residual risk score for any open risk, the risk entry is re-scored at the next monthly risk register review.

5.3 What Does NOT Go in the Improvement Register

• Individual risk entries (use PRC-RM-001)
• Exception requests (use PRC-RM-001 exception workflow)
• Vulnerability remediation tracking (use PRC-VM-001)
• Access review findings (use PRC-AC-002)
• Incident response actions (use PRC-IR-002)
• Audit finding remediation (tracked in PRC-AUD-001; systemic improvements from audit patterns go in the improvement register)

6. Integration with Other CERG Instruments

7. Reporting

7.1 Quarterly CISO Brief

At each quarterly CISO Risk and Posture Review (per GOV-CAL-001), the Governance Pillar Leader presents:

• Improvement register summary: total open, count by status, count by type
• Aging report: improvements past target date, improvements in “Complete” without verification
• Recently verified: improvements verified in the trailing quarter with outcome
• Re-opened count: improvements re-opened in the trailing quarter
• Pipeline health: lessons-intake-to-improvement-approval cycle time (median days)

7.2 Annual Program Evolution Report

At the annual program review, the improvement register provides the narrative backbone for “how the program evolved this year.” The report includes:

• Total improvements proposed, approved, completed, verified, and declined
• Verification pass rate (Effective / total verified)
• Improvements grouped by source (lessons learned, intelligence-driven, maturity gaps, CISO direction)
• Top 5 most impactful improvements (by assessor-visible program change)
• Improvements that changed the control baseline, standards, or metrics

The Annual Evolution Narrative

The improvement register is the raw material for the single most important answer an Adaptive program must give: “How did your program get better this year?” Every improvement that reached “Verified Effective” is a data point in that answer. If the register is empty, the program did not improve : it only operated.

8. Roles and Responsibilities

9. Register Maintenance and Hygiene

9.1 Platform and Access

The improvement register is maintained in a structured platform accessible to all pillar leaders and the CISO. The minimum viable platform is a shared spreadsheet with column-level permissions and an audit log. Larger organizations may use a GRC tool or database.

Regardless of platform, the register must support:

• Filtering by status, type, accountable role, and source
• Date-based aging queries (items past target date, items in Complete without verification)
• Export for quarterly and annual reporting
• Audit trail of status changes (who changed what, when)

9.2 Hygiene Rules

• No orphan entries. Every entry has an accountable role and a target date. Entries without both are returned to Proposed.
• No stale entries. The Governance Pillar Leader reviews the register monthly for entries that have not been updated in 60 days. Stale entries are flagged at the next CERG leadership sync.
• Declined entries are retained. A declined improvement is an audit artifact : it shows the improvement was considered and rejected with rationale. It is not deleted.
• Ineffective entries are re-opened, not deleted. The failure is itself a data point. The original approach, the verification evidence, and the re-open rationale are preserved.

9.3 Archival

The improvement register is archived annually. The archived register becomes an audit artifact. The active register continues with a new year prefix (IMP-YYYY-NNN).

10. Document Control

Revision History

Source: governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md · Download .md · View on GitHub