UNIFIED CONTROL BASELINE

Organizational Baseline · Overlay Matrix · Implementation, Evidence, and Inheritance Model

Table of Contents

1. Purpose and Scope
2. Design Principles
3. The CERG Control Family Spine
4. Implementation Statuses
5. Inheritance Model
6. Organizational Baseline (Core)
7. Control Status Decision Tree
8. Overlay Matrix
9. Control-to-Evidence Mapping
10. Regulatory Crosswalks
11. Governance, Change, and Versioning
12. Document Control

1. Purpose and Scope

The Unified Control Baseline turns the principles in CERG-POL-001, the requirements in subordinate standards, and the philosophy in the CERG Risk Management Framework into an implementation-ready control set. It is the document a control owner, an internal auditor, a CMMC C3PAO, a NERC-CIP auditor, or a SOX auditor opens first.

It applies to every in-scope asset and every CERG-owned control. Where a subordinate standard imposes a more specific requirement, the standard controls and is referenced from the relevant entry here.

One Baseline, Many Audiences

Most programs maintain a separate control library per regulator, one for NIST, one for CMMC, one for NERC-CIP, one for SOX, and then spend a quarter of every audit reconciling them. CERG inverts that: one baseline is implemented once and evidenced once. The crosswalks in Section 9 translate the same evidence into the language each regulator expects.

2. Design Principles

The baseline is built on five non-negotiable principles. Anything that violates them is not in the baseline.

1. NIST is the spine. NIST 800-53r5 control families are the organizing structure. CERG-native controls are layered onto that spine, never the reverse. When a NIST family fully covers an intent, CERG inherits the NIST language and identifier rather than coining a new one.
2. Each control has one accountable CERG pillar. Engineering, Risk, or Governance, never “shared.” Supporting roles are listed separately. Accountability without ambiguity is the prerequisite to evidence.
3. Each control has named evidence. A control without a named evidence artifact is a control without proof; it does not enter the baseline.
4. Overlays add, they do not redefine. CUI, BES, SOX, and Safety overlays add controls or tighten parameters of base controls. They never silently relax the base.
5. Inheritance is documented or it does not exist. Inheritance from cloud/SaaS providers requires the artifact named in Section 5. “We assume the provider handles it” is not inheritance.

3. The CERG Control Family Spine

CERG uses NIST 800-53r5 control families as the top-level grouping. Each family has a one-line CERG intent and a primary owning pillar.

4. Implementation Statuses

Every control entry in the baseline carries one of the following statuses. The set is intentionally small, it survives audits in every framework CERG must support.

What’s Not on the List

“In Progress,” “Undetermined,” “Working On It,” and “Vendor Says Yes” are not statuses. Every entry in the baseline maps to one of the six above. Honesty about Partially Implemented and Planned is worth far more than optimism about Implemented.

5. Inheritance Model

Inherited is the most-abused status in cloud-era control libraries. CERG requires the following Inheritance Evidence Package for any control marked Inherited. Without it, the status defaults to Not Implemented and a finding is opened.

The package has six elements:

1. Provider attestation, current SOC 2 Type II / ISO 27001 / FedRAMP / PCI report containing the inherited control.
2. Shared responsibility mapping, the section of the provider’s shared responsibility matrix that names this control as the provider’s.
3. Customer-side evidence of configuration, proof the customer-side prerequisites are configured (e.g., logging enabled, region selected, IAM lockdown applied) that allow the inherited control to actually protect the customer’s tenancy.
4. Sub-service organization carve-outs, explicit notation if the inherited control depends on a sub-service organization (e.g., AWS underlying Snowflake) and how that dependency is covered.
5. Currency check, attestation expiry date and the calendar entry that re-runs this check.
6. Re-papering trigger, what would cause CERG to re-evaluate inheritance (provider control failure, attestation lapse, scope change, customer-side prerequisite drift).

This package is the basis of every “we inherit it from AWS / Azure / GCP / M365 / Salesforce / ServiceNow / our CMMC enclave provider” claim CERG makes.

6. Organizational Baseline (Core)

The organizational baseline applies to every in-scope asset. Overlays in Section 7 add or tighten controls for High-Impact, CUI, BES, SOX, and OT Safety scopes.

The full implementation-ready control set is captured by family in the sections that follow. Each entry has: Control ID · Action Statement · System Applicability · Owning Pillar · Named Evidence · Frequency · Subordinate Standard.

System Applicability uses one or more of the following values: Hardware, Software, Network, Cloud, Data, Process.

Section 6 entries below are organized by family and reference the subordinate standard for parameter detail. Where parameter detail differs by environment (IT/cloud/SaaS, OT, CUI), the subordinate standard is authoritative; the baseline names the control once.

6.1 Access Control (AC)

6.2 Audit and Accountability (AU)

6.3 Configuration Management (CM)

6.4 Contingency Planning (CP)

6.5 Identification and Authentication (IA)

6.6 Risk Assessment, System and Information Integrity, Supply Chain (RA / SI / SR)

6.7 System and Communications Protection (SC)

6.8 Assessment, Authorization, and Monitoring (CA)

6.9 Awareness and Training (AT)

6.10 Incident Response (IR)

6.11 Physical and Environmental Protection (PE)

6.12 Planning (PL)

6.13 Program Management (PM)

6.14 Personnel Security (PS)

6.15 System and Services Acquisition (SA)

7. Control Status Decision Tree

Use this decision tree to assign honest control implementation statuses. Optimistic status inflation is the most common control failure mode — marking a control “Implemented” without evidence hides the gap from everyone, including yourself.

Is the control applicable to your environment?
  ├─ No  → Not Applicable (document rationale)
  └─ Yes → Is the control fully designed?
              ├─ No  → Planned (design in progress) or Not Implemented (no design)
              └─ Yes → Is it operating consistently?
                          ├─ No  → Partially Implemented (operating gap)
                          └─ Yes → Is there current evidence of operation?
                                      ├─ No  → Partially Implemented (evidence gap)
                                      └─ Yes → Implemented

Status Definitions

7.1 Control Inheritance and Shared Responsibility

Cloud, SaaS, MSP, and OT vendor relationships create shared control environments. “Inherited” is not a free pass — it requires provider evidence AND your own complementary controls.

Inheritance Examples

Shared Responsibility Decision Table

For every control that crosses an organizational boundary, complete this table and retain it with the control evidence:

Provider Evidence Gap Workflow

When provider attestation is missing, expired, or does not cover the customer’s scope, follow this workflow:

Provider Evidence Gap vs. Control Finding. A provider evidence gap is not automatically a control failure. It means the inheritance claim cannot be verified. The control status should be Partially Implemented (evidence gap) or Inherited — Unverified until the workflow is resolved. If the gap persists beyond the re-evaluation trigger without a documented compensating control or risk acceptance, the control defaults to Not Implemented.

8. Overlay Matrix

Overlays add to the organizational baseline. They never silently relax it.

Multiple Overlays at Once

A given system may sit under more than one overlay (a BES system that also processes CUI; a financial system in a CUI enclave). When overlays overlap, the most stringent parameter wins for each individual control. Overlays do not “average.”

9. Control-to-Evidence Mapping

Every control entry in §6 names an evidence artifact in its Evidence column. This section consolidates those artifacts into a single mapping with the repository where the evidence lives, the refresh cadence, and the owning pillar. It is the lookup an auditor opens first.

The discipline rule is unchanged from §2: a control without a named evidence artifact does not enter the baseline; an evidence artifact without a named repository does not satisfy the control. “It’s in someone’s email” is not an evidence repository.

9.1 Evidence Catalog

9.2 Evidence Discipline

Three rules apply to every entry above:

1. Currency (Adoption-Gate Tiered). Evidence captured in the prior refresh cycle is current. Evidence older than one refresh cycle plus 30 days is stale; staleness is a finding in its own right and routes to the owning pillar for action. Examples per cadence: - Annual controls (e.g., CP-4 annual test, CM-3 annual review): evidence is current for 13 months; stale at 13 months + 1 day. - Quarterly controls (e.g., CM-7 least functionality, AC-6 role inventory): evidence is current for 4 months; stale at 4 months + 1 day. - Continuous controls (e.g., AU-2 event logging, CM-6 drift detection): evidence is current for 30 days; stale at 31 days.
2. Attribution. Every evidence artifact carries the named owning role from the canonical roster in CERG-GOV-OM-001 §6.1. “Owned by the team” is not attribution.
3. Retrievability (Adoption-Gate Tiered). Evidence shall be retrievable within the following SLA, tiered by adoption gate: - Gate 1 (Spine, 0–90 days): Within 15 business days of an auditor request. Manual collection is acceptable. - Gate 2 (Operating, 90–180 days): Within 10 business days. Structured evidence index required. - Gate 3 (Governed, 180+ days): Within 5 business days. Tool-supported evidence pipeline. - Gate 4 (Adaptive, mature): Within 2 business days. Automated evidence pipeline. Anything that takes longer than the applicable gate SLA is a process finding regardless of whether the underlying control is operating.

Inheritance Evidence

Controls marked Inherited in §6 use the Inheritance Evidence Package defined in §5 rather than the artifacts above. The Inheritance Evidence Package replaces - it does not supplement - the customer-side evidence artifact for the inherited portion of the control.

10. Regulatory Crosswalks

This section translates each baseline control into the regulator-facing identifier or expectation. It is the read-once map for cross-framework audits: NERC-CIP auditors, CMMC C3PAOs, and SOX external auditors each look at the same controls under different names.

The CERG-GOV-CMX-001 Compliance Matrix is the broader cross-regulator map (intent-level); the table below is the implementation-level crosswalk, control-by-control. Where the two disagree, the Compliance Matrix governs intent and this baseline governs implementation.

10.1 NIST 800-53 → 800-171 r3 / NERC-CIP / CMMC L2 / SOX ITGC

Reading the Crosswalk

A cell marked n/a means the regulator does not have an explicit identifier for the intent; it does not mean the regulator is uninterested. SOX auditors do not have a numbered identifier for unsuccessful-logon thresholds, but they will absolutely ask about brute-force protections on financial-system access. The crosswalk maps named controls, not audit scope.

10.2 Overlay-to-Regulator Mapping

The §8 overlays carry additional crosswalks. Subordinate operational packages own the detail; the table below is the entry point.

10.3 Compliance Matrix Intent-to-Control Bridge

CERG-GOV-CMX-001 (the Compliance Matrix) is organized by 22 cross-regulator intents (“Know what you own,” “Manage vendor risk,” etc.). This baseline is organized by controls (AC-2, AC-3, CM-8, etc.). The table below resolves each Compliance Matrix intent to the §6 controls that implement it. Where an intent is implemented outside the §6 control set, the table names the authoritative subordinate document instead.

Reading the Bridge

The bridge is intentionally implementation-oriented. Every Compliance Matrix intent now points to at least one §6 baseline control row, and the final column points to the documents that carry the deeper operational parameters.

10.4 Family Coverage Note

The CERG control family spine in §3 lists 19 NIST 800-53 families. §6 now includes explicit baseline rows for every family needed by the 22 Compliance Matrix intents, while still keeping environment-specific parameter depth in subordinate standards and procedures.

Baseline vs. Parameter Detail

§6 names the auditable control, owner, evidence, cadence, and implementation document. Subordinate standards and procedures carry the detailed parameter values, workflows, and environment-specific exceptions. If there is a conflict, the stricter requirement applies unless Governance approves a documented exception.

11. Governance, Change, and Versioning

11.1 Ownership

The Governance Pillar Leader owns this baseline. Material changes (additions, removals, parameter changes that affect remediation SLAs or evidence requirements) require CISO approval; non-material changes (clarifications, typo fixes, additional implementation notes) require Governance Pillar Leader approval.

Pillar leaders may propose changes at any time. The Governance Pillar Leader runs an open intake at the monthly Compliance Pulse forum (per CERG-GOV-OM-001 §7).

11.2 Change Triggers

The baseline is reviewed and updated upon any of the following:

• Framework version change. A new version of NIST 800-53, NIST 800-171, NIST CSF, NERC-CIP, CMMC, or any in-scope framework triggers a delta review and, where appropriate, an overlay or control update.
• Regulator action. A new rule, advisory, or enforcement action that changes expectations.
• Material program change. Adoption of a new platform class, retirement of an existing one, or significant change to the asset tiering scheme.
• Audit / assessment finding. A finding from internal audit, external auditor, NERC-CIP audit, CMMC assessment, or C3PAO that points at a baseline gap.
• Sev 1 incident. A confirmed incident whose root cause traces to a missing or weak baseline control.
• Annual review. Even in the absence of triggers, Governance conducts a full annual review.

11.3 Change Workflow

1. Proposal. Submitted to the Governance Pillar Leader with: control(s) affected, change rationale, impact on overlays, evidence implications, and any regulator-facing implications.
2. Assessment. Engineering and Risk review for operational practicability and exposure implications. Comments returned within 10 business days.
3. Decision. Material changes go to CISO at the next Monthly Risk Register Review or sooner if time-sensitive. Non-material changes are approved by the Governance Pillar Leader.
4. Publication. Approved changes are merged into the source markdown with a revision history entry. Subordinate documents that cite the changed control are flagged for refresh in their next review cycle.
5. Notification. Pillar leaders communicate the change at the next CERG All-Hands and at the next Cyber Oversight Group meeting.

11.4 Versioning Rules

This baseline follows semantic-ish versioning:

A change log entry is written for every version bump; the change-log table lives in §12 Revision History.

11.5 Subordinate-Document Synchronization

When a control in §6 or an overlay in §8 changes, Governance issues a “ripple list” naming every subordinate document that references the changed control. The owning pillar leaders are responsible for refreshing those documents within 30 calendar days of the baseline change being approved. The Compliance Pulse forum tracks ripple-list closure each cycle.

12. Document Control

Revision History

Related Documents

Source: governance/CERG-GOV-CB-001_Unified_Control_Baseline.md · Download .md · View on GitHub