START HERE · Adopting CERG

You just found CERG. You have a repo full of Markdown. What do you actually do on Monday morning?

This page is your first 48 hours. Read it before you read anything else.

Step 0: Is CERG right for you right now?

CERG requires organizational commitment. Answer honestly:

• Do you have a named person who will own security? (Even part-time, even informal.)
• Does leadership support establishing guardrails — not just buying tools?
• Can you name the systems, business units, and regulators in your scope?
• Will you track versions, record decisions, and produce evidence?

If you answered no to any of these, start with NIST CSF or CIS Controls. Come back to CERG when you’re ready.

If you answered yes to all four, do not start by reading the whole repository. Pick one entry point, read only the documents needed for that decision, and let the operating cadence pull in the rest.

First rule: do not boil the ocean

CERG is intentionally complete, but first adoption is intentionally narrow. Your first hour should answer one question: what problem are we trying to operate better?

Use these rules:

• Read for a job, not for completeness. Open the documents tied to your role, snag, regulator, or environment.
• Adopt the spine before the library. The Minimum Viable CERG set is enough to start producing decisions, risks, exposure records, and evidence.
• Defer what you do not operate. Do not read OT, CUI, SOX, AI, or workforce-depth documents unless that scope exists now.
• Prefer one worked example over ten abstractions. Read a Day in the Life story that matches your problem before reading every standard.
• Stop reading when you can name the owner, record, decision path, and next action. CERG is an operating model, not a reading challenge.

Pick your entry point

If you are still unsure where to begin, use these helpers before diving into the full library:

• CISO / CSO Executive Briefing Pack - slide-style executive introduction for leaders who need the hook, operating boundaries, anti-patterns, and “who does what” before reading the corpus.
• Framework System Map - how the documents, pillars, records, evidence, and improvement loops fit together.
• Adoption Decision Tree and Dependency Matrix - which path and overlays apply, plus what must be adopted together.
• Role-Based Implementation Checklists - what the CISO, Governance, Risk, and Engineering leads do first.
• Record Catalog - the records and minimum evidence that prove the program is operating.
• Day in the Life examples - eleven narrative walkthroughs showing how the three pillars produce real work during incidents, audits, intake, AI rollouts, access reviews, new-CISO adoption, and OT patch deferral. Read one before you read the standards.
• Role Reader Paths - a sequenced 25-35 minute reading order for the CISO, Risk Lead, Engineering Lead, and Business Owner / System Sponsor if you are taking on a CERG role for the first time.

Adoption suite map

Path 1: CERG Lite (small security team, 2-8 people)

You have: A small team with at least two named participants in cyber risk decisions. No existing framework, or a framework that is not yet operational.

If you are a one-person security function, use CERG as a planning reference and adopt the MVC documents only after you have an Executive Sponsor and an independent approver for High/Critical risk decisions.

Your goal: Stand up a real program without drowning in documents.

First 48 hours

1. Read the Cybersecurity Policy. This is the spine. Nothing is authoritative until an Executive Sponsor signs this.
2. Read the CERG Framework — the three-pillar model. You’ll consolidate roles heavily; that’s expected.
3. Read the Small Team Adoption Path. This is your primary guide. It covers the CERG Lite package, small-team operating rhythm, role consolidation map, first 10 records, and spreadsheet schemas.
4. Read the Role-Based Implementation Checklists. Use the small-team consolidated checklist if one person holds multiple roles.
5. Read the Implementation Guide §4 (MVC). Follow the Minimum Viable CERG sequence.
6. Fork the repo. Do not cherry-pick individual files. The documents are interconnected.
7. Fill in the Organization Adaptation Profile. Set your headcount, sector, and regulators. Do NOT leave the default values.
8. Start the Risk Register. Open the template. Create your first entry. It can be simple.
9. Create the first records from the Record Catalog. Start with role assignment, evidence index, asset extract, top risks, exposure backlog, and exception register.
10. Run the first exposure management cycle. Even if it starts with one Nessus scan on your production subnet, open PRC-VM-001 and follow the observe → validate → assess reachability → classify → treat → verify flow.

Your MVC set

Adopt these eight documents first:

1. Cybersecurity Policy
2. CERG Framework
3. Operating Model (focus on §6, role consolidation)
4. Document Catalog (update it as you go)
5. Risk Management Framework
6. Risk Register & Exception Process
7. Risk Register Templates
8. Exposure Management Procedure

Use the Record Catalog, Adoption Safety Guide, Small Team Adoption Path, and Role-Based Implementation Checklists as adoption aids. They help you adopt the MVC; they are not additional MVC requirements.

Read one story. The CERG Lite day-in-the-life walkthrough shows what your first month of running the MVC actually looks like when two people own everything.

What you can defer

• All 15 standards (bring in individually as needed)
• Most procedures beyond VM and Risk Register
• Operational packages (unless you’re regulated — see Path 3)
• Workforce architecture docs (start with JF-001, defer per-role JDs)
• Machine-readable artifacts
• Detailed job descriptions

Path 2: CERG Standard (existing security team, 6-30 people)

You have: A functioning security team. Policies exist but are fragmented. Tools are deployed but processes are ad hoc.

Your goal: Replace the pile of disconnected documents with a unified operating model.

First 48 hours

1. Read the CERG Framework. Map your existing team to the three pillars. Identify gaps.
2. Read the Implementation Guide §4-5. Follow the MVC sequence plus core standards.
3. Map your current documents to CAT-001. What do you already have that maps to a CERG artifact? What’s missing?
4. Adopt the spine (8 MVC docs) first. Adapt them to your organization — not the other way around.
5. Layer core standards next: Access Management, Asset Management, Configuration Baseline (DISH), IT/Cloud/SaaS where applicable, Logging/Monitoring, and Resilience/Backup.
6. Add Architecture Review and TPRM procedures. These are the two procedures that prevent the most future pain.

Your starting set

MVC (all 8) + Access, Asset, Config Baseline, IT/Cloud/SaaS where applicable, Logging/Monitoring, and Resilience/Backup standards + Architecture Review Procedure, TPRM Procedure.

Path 3: CERG Regulated (NERC-CIP, CMMC, SOX, OT environments)

You have: Regulatory obligations. Auditors. Critical infrastructure. An existing security team.

Your goal: Map CERG to your regulatory framework without duplicating work.

First 48 hours

1. Read the CERG Framework. Understand the three-pillar model.
2. Read the Implementation Guide §4-5.
3. Adopt the MVC spine.
4. Identify your regulatory overlay. Open the relevant operational package: - NERC-CIP → PLN-CIP-001 - CMMC / CUI → PLN-CUI-001 - SOX ITGC → PLN-SOX-001 - ISO 27001 → PLN-ISO-001
5. Map your evidence requirements. Each operational package links evidence to specific CERG procedures. Understanding this linkage is the key to making compliance a byproduct of operations.
6. See the Compliance Matrix. 22 security intents mapped to every framework simultaneously.

Your starting set

MVC + all 15 standards + Architecture Review, TPRM, Change Management, Audit/Evidence procedures + your regulatory operational packages.

What CERG adoption is NOT

• Not a certification. You can adopt CERG and still fail a regulatory assessment if controls aren’t implemented and evidenced.
• Not a substitute for judgment. CERG provides structure. You provide decisions, owners, scope, and risk appetite.
• Not a one-time exercise. A program runs on cadence. If you’re not producing evidence from real work every month, you’re not running CERG.
• Not shelfware. If you fork the repo, rename the company, approve everything, and walk away, you have produced exactly nothing.

What good adoption should feel like

CERG should create operating leverage. After the first cycle, the work should feel clearer, not heavier:

• owners and decision rights are easier to name;
• recurring reviews produce records instead of status theater;
• evidence is easier to retrieve because it was created during the work;
• engineering teams receive clearer guardrails;
• fewer problems depend on the same hero person;
• leaders can see whether the bottleneck is capability, scope, tooling, or staffing.

If adoption mostly adds meetings, manual chasing, or ambiguity, stop adding documents and fix the workflow.

Schedule your first stakeholder survey at month 2

After one full cadence cycle (approximately 60 days), administer the Stakeholder Perception Survey. The survey is how you measure whether the program is reducing drag and confusion for the business, which is the program’s stated mission. Run annually thereafter. Survey results below 3.0 on a Likert scale, or a year-over-year decline of 0.5 points or more, become entries in the Program Improvement Register. The survey is paired with monthly Service Responsiveness metrics (SR-001 through SR-005) so friction is caught continuously, not only once a year.

When you get stuck

Before you ask for help: 1. Re-read the Implementation Guide §9 (Common Adoption Pitfalls). 2. Check your org profile in VAR-001 — are you still using the default values? 3. Run python3 tools/cerg-validate.py — broken links or catalog mismatches will surface mechanical problems. 4. Look at the examples/ directory for sample profiles that match your sector and size.

After the first 30 days

Once MVC is running, layer the remaining documents as needed. The sequence matters less after the spine is in place. Prioritize based on what’s causing the most operational friction.

Before broad standard-layer adoption, use the Gate 2 to Gate 3 transition test in the Adoption Decision Tree and Dependency Matrix. Do not advance just because the calendar says day 60 or day 90. Advance when the MVC has produced risk, exposure, intake, evidence, pillar-accountability, and adoption-plan records.

Back to README · Full catalog · Implementation Guide

Source: START-HERE.md · Download .md · View on GitHub