ADOPTION DECISION TREE AND DEPENDENCY MATRIX

Scope Selection · Safe Tailoring · Required Companion Artifacts

Table of Contents

1. Purpose and Scope
2. Adoption Decision Tree
3. Safe Tailoring Rules
4. Dependency Matrix
5. Required, Conditional, Recommended, and Example Labels
6. Adoption Gates
7. Document Control

1. Purpose and Scope

CERG is modular, but it is not arbitrary. Some artifacts can be deferred safely. Others must travel together because they form an operating loop.

This document helps an adopter decide:

• Which CERG path applies.
• Which documents are required immediately.
• Which documents are conditional on regulatory or environmental scope.
• Which artifacts must be adopted together.
• Which tailoring choices are safe.
• Which tailoring choices break the model.

2. Adoption Decision Tree

2.1 Readiness gate

Before adopting CERG, answer these questions:

If all answers are yes, continue.

2.2 Path selection

Security team size 2-8 people?
  yes -> CERG Lite
  no -> continue

One-person security function?
  yes -> use CERG as a planning reference; adopt MVC only after an Executive Sponsor and independent High/Critical risk approver are named
  no -> continue

Existing security team with multiple functions but limited formal governance?
  yes -> CERG Standard
  no -> continue

Regulatory obligation or OT/CUI/SOX scope exists?
  yes -> CERG Regulated overlay on Lite or Standard
  no -> CERG Standard

2.3 Regulatory overlay selector

3. Safe Tailoring Rules

3.1 Safe tailoring

These changes are acceptable when documented in the Organization Adaptation Profile:

• Combine multiple CERG roles into one person in a small team.
• Use spreadsheets instead of a GRC platform.
• Rename roles to match local job titles while preserving CERG accountability.
• Defer standards for environments that do not exist.
• Adopt only the core standards needed for current scope.
• Use manual evidence collection before automation exists.
• Use a lightweight Cyber Oversight Group if the executive team is small.
• Store records in ticketing systems when required fields are preserved.

3.2 Unsafe tailoring

These changes break the model:

• Deleting the risk register.
• Treating security exceptions as informal approvals.
• Allowing Engineering to accept high risk without business or CISO authority.
• Claiming regulatory alignment without the required operational package and evidence.
• Marking controls implemented without evidence.
• Adopting standards but not procedures or records.
• Running vulnerability scans without asset ownership, remediation SLAs, or exception handling.
• Treating vendor security review as optional for systems that handle sensitive data, privileged access, or regulated scope.
• Removing document control, version history, or approval status.

4. Dependency Matrix

4.1 Core dependencies

4.2 Procedure dependencies

4.3 Standard dependencies

4.4 Regulated package dependencies

5. Required, Conditional, Recommended, and Example Labels

CERG adopters should label adopted artifacts in their local catalog using these values.

5.1 Preliminary default labels

6. Adoption Gates

Gate 0: Not Ready

The organization has no named owner, no executive support, unclear scope, or no willingness to maintain records.

Exit criteria:

• Security owner named.
• Executive sponsor identified.
• Scope and regulators listed.
• Decision made to maintain records and evidence.

Gate 1: Spine Adopted

The organization has adopted the core CERG spine.

Exit criteria:

• Policy signed.
• Organization Adaptation Profile completed.
• Role Assignment Map completed.
• Initial risk register created.
• Initial exposure backlog created.
• Document catalog updated.

Gate 2: Operating

The organization is producing recurring security work from the MVC spine.

Exit criteria:

• At least two recurring risk register reviews completed, including recorded decisions, owners, and next actions.
• Exposure or vulnerability management cycle running with SLA metrics produced for at least two cycles.
• Risk exceptions and acceptances follow CERG-PRC-RM-001, with no informal high-risk approvals.
• Project intake or architecture review path exists, and at least one disposition has been issued. If no real project occurred, a tabletop review with a documented disposition is acceptable.
• Asset inventory has owners for the assets in the initial exposure scope.
• Evidence index exists and links risk, exposure, ownership, exception, and decision records.
• First metrics report produced and reviewed by the CISO or equivalent security owner.
• Each pillar has produced at least one operating record. In small teams, this means the Engineering, Risk, and Governance accountabilities are evidenced even if one person holds multiple roles.

Gate 2 to Gate 3 Transition Test

The organization should not start broad standard-layer adoption until Gate 2 is stable. Gate 3 adoption begins when the CISO or equivalent security owner records that all of the following are true:

If any condition is missing, remain at Gate 2 and fix the operating loop before adopting additional documents. Gate 3 is triggered by evidence that the MVC runs, not by the calendar reaching day 60 or day 90.

Gate 3: Governed

The organization can explain and evidence its control posture.

Exit criteria:

• Control baseline status recorded.
• Core standards adopted.
• Evidence quality checks applied.
• Cyber Oversight Group or equivalent meets on cadence.
• Program improvement register active.

Gate 4: Adaptive

The organization improves based on evidence, threats, incidents, metrics, and maturity results.

Exit criteria:

• Control effectiveness tested.
• Threat intelligence changes detection or priorities.
• Lessons learned produce control or procedure updates.
• Maturity assessment drives program priorities.
• Board or executive reporting influences risk and resourcing decisions.

7. Document Control

Revision History

Review Triggers

• New adoption path.
• New regulated operational package.
• New core standard or procedure dependency.
• User feedback indicating over-adoption or unsafe tailoring.
• Catalog change affecting document IDs or status.

Related Documents

• START-HERE - First 48 hours guide
• CERG-GOV-IMP-001 - Implementation and Adaptation Guide
• CERG-GOV-IMP-002 - Adoption Safety Guide
• CERG-GOV-IMP-003 - Small Team Adoption Path
• CERG-GOV-VAR-001 - Organization Adaptation Profile
• CERG-GOV-CAT-002 - Record Catalog
• CERG-STD-AI-001 - Artificial Intelligence Security Standard
• CERG-TMPL-AI-001 - AI Intake and Sanctioning Template
• CERG-TMPL-AI-002 - Sanctioned AI Tools Register Template
• CERG-TMPL-AI-003 - AI System and Model Register Template

Source: governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md · Download .md · View on GitHub