FRAMEWORK SYSTEM MAP

Front Door · Document Relationships · Adoption Navigation

Table of Contents

1. Purpose and Scope
2. The CERG Spine
3. How the Library Fits Together
4. How Work Moves Through CERG - 4.1 How the three pillars interact during a single event - 4.2 When the three pillars collapse onto fewer people
5. Navigation by User Need
6. Navigation by Adoption Path
7. Navigation by Pillar
8. Document Control

1. Purpose and Scope

CERG is intentionally complete. That completeness can make the first hour difficult for a new reader. This document is the map.

It explains how the policy, framework, operating model, risk model, controls, standards, procedures, templates, records, evidence, metrics, and improvement loops relate to one another. It does not replace those documents. It tells the reader which document to open next and why.

Use this document when:

• A leader asks, “What is CERG?”
• A new adopter asks, “Where do I start?”
• A practitioner asks, “Which artifact owns this activity?”
• A contributor asks, “Where does a proposed document belong?”
• An auditor asks, “How do policy statements become evidence?”

2. The CERG Spine

The CERG spine is the minimum chain that turns security intent into operating work.

Cybersecurity Policy
  -> CERG Framework
  -> CERG Operating Model
  -> Risk Management Framework
  -> Unified Control Baseline
  -> Standards
  -> Procedures and Plans
  -> Templates and Records
  -> Evidence
  -> Metrics and Oversight
  -> Program Improvement

3. How the Library Fits Together

3.1 Authority hierarchy

3.2 Execution chain

Policy principle
  -> control objective
  -> standard requirement
  -> procedure step
  -> assigned role
  -> record created
  -> evidence stored
  -> metric updated
  -> oversight decision

If any link is missing, the program can still have activity, but it will not have an auditable operating loop.

3.3 Three-pillar accountability

4. How Work Moves Through CERG

CERG work should not move by informal chat alone. It should move through one of the canonical flows in FLOW-001.

4.1 How the three pillars interact during a single event

The three pillars are not three teams that vote on everything. They are three accountability lines that each own a distinct question. During a single event, each pillar does one thing and only one thing.

A worked example: a critical vulnerability hits an internet-facing application server on a Tuesday morning.

1. Risk validates reachability, sets severity, opens the Finding Record, and starts the SLA clock.
2. Engineering owns the remediation: patch, configuration change, WAF rule, or service isolation. Engineering captures implementation evidence.
3. Governance confirms the SLA clock is correct, the evidence quality is acceptable, the dashboard reflects status, and any required escalation reaches the right authority. Governance does not run the patch.

The handoffs are explicit. The records are explicit. The clock is explicit. No pillar holds the work hostage waiting for consensus.

For canonical worked examples, read the Day in the Life stories. They are the canonical reference for what each pillar does during a real event. Stories 2, 4, 5, 6, and 8 walk a single event from detection through closure and show the three-pillar handoff in motion. Stories 9 and 10 show how the pillars work together across time.

4.2 When the three pillars collapse onto fewer people

In small teams (CERG Lite, 2-8 people), the three pillars collapse onto fewer heads. The collapse is intentional, documented in the Decision Log per IMP-002 §4, and follows the role consolidation map in IMP-003 §4. The questions do not collapse, only the heads. Risk still triages. Engineering still builds. Governance still routes. One person may answer all three questions in a single hour, but the questions remain distinct.

Story 8 (CERG Lite - Maria and the Tuesday scanner report) is the canonical worked example of the collapse pattern.

5. Navigation by User Need

6. Navigation by Adoption Path

6.1 CERG Lite

Use when the organization has a small security team or first security hire. The goal is to create a real operating spine without adopting every document.

Start with:

1. Policy
2. Framework
3. Operating Model
4. Document Catalog
5. RMF
6. Risk Register and Exception Process
7. Risk Register Templates
8. Exposure Management Procedure
9. Record Catalog
10. Role-Based Implementation Checklists

To see what this looks like in practice on a 2-8 person team, read the CERG Lite day-in-the-life story.

6.2 CERG Standard

Use when the organization has an existing security function and needs consistent operation.

Add:

• Core standards for access, assets, configuration, IT/cloud/SaaS, logging, endpoint, network, and resilience.
• Architecture review and project intake.
• Third-party and supply-chain risk.
• Metrics and reporting.
• Evidence quality and audit procedure.

For worked examples of how the three pillars produce outcomes together, see the Day in the Life examples — Stories 1, 2, 3, 5, and 7 cover the most common Standard-team situations.

6.3 CERG Regulated

Use when the organization has explicit regulatory obligations.

Add the applicable package:

For regulator-facing walkthroughs, see the Day in the Life examples — Story 3 (audit request) and Story 6 (third-party incident notification) are written so a regulated audience can map them straight to their own audit and notification obligations.

7. Navigation by Pillar

8. Document Control

Revision History

Review Triggers

• New top-level governance artifact.
• Change to adoption paths.
• Change to canonical cross-pillar flows.
• New regulated operational package.
• User feedback indicating navigation confusion.

Related Documents

• CERG-GOV-FRM-001 - CERG Framework
• CERG-GOV-OM-001 - Operating Model
• CERG-GOV-FLOW-001 - Cross-Pillar Operational Flows
• CERG-GOV-IMP-001 - Implementation and Adaptation Guide
• CERG-GOV-IMP-005 - Adoption Decision Tree and Dependency Matrix
• CERG-GOV-CAT-002 - Record Catalog

Source: governance/CERG-GOV-FRM-002_Framework_System_Map.md · Download .md · View on GitHub