Table of Contents

1. Who This Is For
2. The CERG Lite Package
3. Operating Rhythm for a 5-Person Team
4. Role Consolidation Map
5. First 10 Records to Create
6. First Month Success Criteria
7. Manual Fallback Schemas
8. Minimum Viable Evidence Library
9. Document Control

1. Who This Is For

This guide is for teams of 8 people or fewer who want to run CERG as their operating model. It assumes you have read the Adoption Safety Guide and confirmed the prerequisites in §1.

The full CERG corpus describes what a 60-person security team looks like at NIST CSF Adaptive maturity. That is the upper bound. This guide describes the lower bound — what a 5-person team can actually operate without burning out.

The rule: adopt fewer documents, run a lighter cadence, produce simpler evidence, and add complexity only when the team grows or the risk demands it.

2. The CERG Lite Package

These are the documents you actually need first. Everything else in the repo can wait.

Adopt Immediately: MVC (8 documents)

Use as adoption aids, not additional MVC requirements

Adopt When Ready (layered on as the team grows)

Do Not Adopt Yet

The following are explicitly deferred for small teams. Document the deferral in your Decision Log:

• Full workforce planning (WFP-001)
• Succession planning (SUCC-001)
• Maturity self-assessment (MAT-001)
• Any regulatory package that does not apply
• Board/CISO reporting deck template — use a simple status report instead
• Per-role JD documents — JF-001 and JF-002 are sufficient
• Contractor integration guide (CON-001) — unless you have contractors
• Cross-pillar operational flows (FLOW-001) — the procedures themselves (PRC-*) are sufficient for initial adoption
• Stakeholder perception survey (TMPL-GOV-001) — first run at month 2, then annually per IMP-002

3. Operating Rhythm for a 5-Person Team

The full calendar (CAL-001) assumes a 60-person team. Scale it down.

Weekly (1 hour)

Biweekly (1 hour)

Monthly (2 hours)

Quarterly (half day)

Semi-Annual (1 day)

Annual (2-3 days)

4. Role Consolidation Map

A 5-person team covers all 27 canonical roles by consolidating them. The map below is one example — adapt it to your team’s skills. Document your actual assignments in the Decision Log.

If you have 3 people: Consolidate further. Person 1 = CISO + Governance + Risk Register. Person 2 = Engineering + Cloud + Identity. Person 3 = Risk + Compliance + VM. Document every consolidation in the Decision Log per IMP-002 §4. The Role Collision Guide (IMP-002 §7) defines which consolidations require compensating controls.

Authority guardrail: heads collapse; business consequence acceptance does not. A small team still needs a Business Owner or Executive Sponsor outside the security assessor role to acknowledge accepted residual risk. If the CISO/Risk/Governance work is held by one person, use IMP-002 §5 and RMF-001 §9.7 for independent acceptance and escalation.

If you have 1 person: You are not ready to adopt CERG as an operating model. Use CERG as a planning reference. Hire your second person before attempting adoption.

5. First 10 Records to Create

Before you run your first meeting, create these records. They prove the program is operational, not just documented.

Record 1: Organization Profile (IMP-001)

Fill in the organization profile in the Implementation Guide. This is a single document, not a recurring record.

• Organization name
• Named CISO
• Named executive sponsor
• Defined system scope
• Known regulatory obligations
• Tooling inventory

Record 2: Role Assignment Map

A simple table mapping your actual people to canonical roles. Example:

Record 3: Asset Inventory Extract

Do not build a full CMDB. Start with a spreadsheet. List every system you know about. If you do not know about it, write “unknown” in the owner column — that is your first finding.

Aim for 80% coverage in month one. The remaining 20% is your asset discovery backlog.

Record 4: Initial Top 10 Risks

Do not try to build a complete risk register in week one. Identify the 10 risks that keep you up at night. Score them. Assign owners. Schedule treatment.

Record 5: Exposure Backlog

Export your vulnerability scanner results. Prioritize by severity and asset criticality. Assign the top 20 to owners.

Record 6: Exception Register (starts empty)

Create the structure. It will populate as you find things you cannot fix on schedule.

Record 7: Evidence Index

Create the folder structure (see §8). Add one entry for each piece of evidence you already have.

Record 8: Control Implementation Snapshot

If CB-001 is not yet adopted, start with a preliminary snapshot for the obvious control families (AC, IA, CM, CP, RA, SI) and mark it preliminary. Once CB-001 is adopted, convert the snapshot to CB-001 control IDs and record its current status honestly.

Record 9: Regulatory Applicability Decision

For each regulatory framework referenced in CERG, decide: Applicable? Deferred? Not applicable?

Record 10: 30-Day Improvement Backlog

Five things you will fix in the first 30 days. Be specific.

6. First Month Success Criteria

After 30 days of operating CERG with a small team, you should be able to answer “yes” to these questions:

Governance

• [ ] Policy approved by CISO and executive sponsor
• [ ] Organization profile completed
• [ ] Decision log created with at least: role consolidation decisions, regulatory applicability decisions, deferred document decisions
• [ ] Evidence library structure created with at least one piece of evidence per spine control family
• [ ] Document catalog reviewed — deferred documents noted

Risk

• [ ] Top 10 risks identified, scored, and assigned to owners
• [ ] First risk register review held — decisions documented
• [ ] Exposure backlog triaged — criticals assigned, highs prioritized
• [ ] Exception process tested — at least one exception created or the register confirmed empty with rationale
• [ ] Vendor list compiled — high-risk vendors flagged for assessment

Engineering

• [ ] Architecture review process tested — at least one project went through intake
• [ ] Pre-production review conducted for any new systems or major changes
• [ ] Control baseline snapshot completed — honest status for spine controls
• [ ] Asset inventory initiated — 80% coverage target set

Operations

• [ ] First monthly report produced (can be a simple email, not a deck)
• [ ] Improvement backlog created with at least 5 items
• [ ] Team trained on their consolidated roles and handoffs
• [ ] Cross-training plan initiated — each person identified one skill to develop outside their primary pillar

If You Cannot Answer Yes

• Do not declare CERG adopted. You are in the planning phase.
• Do not add more documents. Fix the gaps in the spine first.
• Do not skip the risk register review. It is the heartbeat of the program.
• Do not pretend “Partially Implemented” means “Implemented.” Honest gaps are better than false claims.

7. Manual Fallback Schemas

If you do not have a GRC platform, ticketing system, or evidence management tool, use spreadsheets. These schemas define the minimum columns for each record type. Add columns as needed — do not remove the ones listed.

Risk Register Spreadsheet

Exception Register Spreadsheet

Evidence Index Spreadsheet

Exposure Backlog Spreadsheet

Asset Inventory Spreadsheet

Vendor Inventory Spreadsheet

Decision Log Spreadsheet

8. Minimum Viable Evidence Library

Create this folder structure in your shared drive, document management system, or evidence repository. You do not need a GRC platform to start.

/evidence/
├── 00-program-governance/
│   ├── policy-approvals/
│   ├── org-profile/
│   └── decision-log/
├── 01-risk-register/
│   ├── risk-register-current.xlsx
│   ├── risk-acceptances/
│   └── exception-register-current.xlsx
├── 02-access-management/
│   ├── access-reviews/
│   ├── jml-evidence/
│   ├── privileged-access-reviews/
│   └── mfa-configuration/
├── 03-vulnerability-management/
│   ├── scan-reports/
│   ├── remediation-evidence/
│   └── exception-records/
├── 04-change-management/
│   ├── change-records/
│   └── security-impact-analyses/
├── 05-asset-inventory/
│   ├── asset-inventory-current.xlsx
│   └── network-diagrams/
├── 06-logging-monitoring/
│   ├── log-source-inventory.xlsx
│   └── detection-rule-evidence/
├── 07-backup-recovery/
│   ├── backup-configurations/
│   └── restore-test-results/
├── 08-vendor-risk/
│   ├── vendor-inventory-current.xlsx
│   └── vendor-assessments/
├── 09-incident-response/
│   ├── incident-records/
│   └── lessons-learned/
├── 10-regulatory/
│   ├── sox-evidence/        (if applicable)
│   ├── cmmc-evidence/       (if applicable)
│   └── cip-evidence/        (if applicable)
├── 11-audit/
│   └── audit-evidence-packages/
├── 12-board-reporting/
│   └── monthly-reports/
└── README.md                (explain what is stored where)

Rules for the evidence library:

• Every file in the library has an owner and a retention period.
• Evidence freshness is checked at the monthly review. Stale evidence is flagged.
• The evidence index spreadsheet (§7) maps every file to a control.
• Start with the folders you have evidence for. Empty folders remind you what is missing.
• If you have a GRC platform, migrate the spreadsheets into it when you outgrow manual management. The structure stays the same — the tool changes.

9. Document Control

Revision History

Review Triggers

• Feedback from small-team adopters
• Change to the canonical role roster
• Change to the control baseline
• Direction from the CISO

Related Documents

Source: governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md · Download .md · View on GitHub