The CERG Framework

A Scalable, Adaptive Cybersecurity Operating Model

Designed for Adaptive NIST CSF 2.0 maturity. Applicable to IT and OT environments. Calibrated for CMMC, NERC-CIP, and SOX.

Examples in this document reference a large enterprise at the upper bound of what CERG is designed to support — the framework is scaled to fit organizations from 5 people to large regulated entities. Readers should scale down to their environment. Sector-specific illustrative profiles are available in /examples/. See also CERG-GOV-VAR-001 for mechanical adaptation.

Table of Contents

1. Executive Summary
2. The CERG Operating Model
3. Capability Taxonomy: What CERG Builds
4. Cyber Engineering
5. Cyber Risk
6. Cyber Governance
7. Targeting NIST CSF Adaptive Maturity
8. Regulatory Alignment
9. IT/OT Considerations
10. Team Structure and Talent Model
11. Getting Started, The Path to Adaptive
12. Compliance as Exhaust — Evidence Factories
13. Document Control

1. Executive Summary

Cybersecurity teams of all sizes have struggled with the same structural problem for two decades: fragmented tools, siloed teams, and a culture of “no” that slows the business without meaningfully reducing risk. The CERG framework, Cyber Engineering, Risk, and Governance, is a deliberate answer to that problem.

CERG consolidates the core work of a mature cybersecurity function into three tightly coupled, clearly bounded pillars. Together they are pronounced “Surge”, because effective security is fast, powerful, and directional. Surge is not a support function. It is an operational force that enables the business to move confidently.

Why Three Pillars

Most cybersecurity work, outside of Security Awareness and Incident Response, falls naturally into one of three activities:

• Building and deploying secure technology alongside the business
• Assessing exposure and managing risk continuously
• Setting standards, ensuring compliance, and tracking conformance

The CERG model names these activities explicitly, Engineering, Risk, and Governance, and assigns clear ownership, accountabilities, and interaction patterns so that work flows between them without dropping and without creating new silos.

Design Principles

• Scale up or down: applicable to a 5-person team or a 500-person organization
• Regulatory-ready: designed to satisfy CMMC, NERC-CIP, NIST CSF 2.0, 800-53, 800-171, and SOX
• IT/OT aware: principles apply equally to enterprise IT and operational technology environments
• Talent resilient: cross-pillar knowledge sharing means no single person is a point of failure
• Adaptive-targeted: the framework describes what operating at NIST CSF 2.0 Adaptive maturity looks like in practice
• “Yes, and…” oriented: Governance enables the business through risk treatment, not reflexive refusal
• Definition of Done: A CERG task is not done when a meeting happened, a document was approved, a ticket moved columns, a scanner showed fewer highs, or someone said “accepted risk.” A CERG task is done when all of the following are true: (1) an owner is named, (2) a decision is recorded, (3) evidence is linked and independently verifiable, (4) residual risk is understood and documented, (5) the control state or register entry is updated, (6) a next review date exists, and (7) the system of record agrees with the operational reality. This standard applies to every CERG-managed workflow, finding, exception, risk acceptance, architecture review, and metric. If the Definition of Done cannot be satisfied because the organization lacks the tooling or discipline, CERG adoption is not complete.

2. The CERG Operating Model

2.1 The Full Cybersecurity Team

CERG operates as one of three functional groups within the Cybersecurity department, all reporting to the Chief Information Security Officer (CISO). The full structure is:

CERG Scope Note: This framework focuses on the CERG pillars. Security Awareness and Incident Response are adjacent, equally critical functions with distinct operating models. CERG coordinates closely with both, Engineering embeds security requirements that IR and Awareness depend on; Risk produces threat intelligence that feeds both; Governance sets the standards all three operate under.

2.2 The Three Pillars at a Glance

🔧 E: Cyber Engineering

Build securely. Deploy confidently. Consult continuously.

Internal security consultants who partner with IT and business leaders to design, build, and deploy secure technology across the enterprise, in both IT and OT environments.

🔍 R: Cyber Risk

Know your exposure. Manage it deliberately. Never be surprised.

Continuous assessment and management of the organization’s exposure through exposure management, adversarial validation, vendor risk assessment, and threat intelligence.

📋 G: Cyber Governance

Set the rules. Track the work. Enable the business to move with confidence.

The rule-makers, compliance managers, and quality assurance function, responsible for policies, standards, implementation guidance, regulatory compliance, and control evidence.

2.3 How the Pillars Interact

CERG pillars are not sequential. They operate simultaneously and continuously, with structured handoffs and shared accountability for outcomes.

3. Capability Taxonomy: What CERG Builds

CERG is capability-centered. A control is something an organization has: a requirement, configuration, approval, or safeguard. A capability is something the organization can reliably do under real conditions. Tools, standards, and controls matter because they support capability; they are not the capability by themselves.

This taxonomy gives leaders and practitioners a way to ask better questions:

• Can we design secure systems before they go live?
• Can we find and treat exposure before it becomes an incident?
• Can we prove control operation without an audit scramble?
• Can we sustain operations during a cyber event?

3.1 Capability Model

Every CERG capability follows the same evidence chain:

Capability → Owner → Controls and standards → Procedure → Evidence → Validation method

• Capability declares what the program can do.
• Owner names the accountable pillar or adjacent function.
• Controls and standards define the security bar.
• Procedure defines how the work is executed.
• Evidence proves the capability operated.
• Validation method shows the capability works under expected conditions.

This model keeps CERG from becoming a document library or tool inventory. If a capability cannot produce evidence and survive validation, it is not mature yet, even if supporting documents exist.

3.2 Core Capability Reference Set

The following reference set establishes the capability naming pattern. Capability IDs use CAP-{PILLAR}-{DOMAIN}-{SEQ}. The list is not a separate control framework; it is the operating-outcome view of CERG’s existing controls, standards, procedures, and records.

3.3 Capability Maturity Grading

Capability maturity is scored by evidence and validation, not by whether a document exists.

The scoring rule is simple: the capability maturity level is capped by the weakest link in the evidence chain. A strong tool with no owner is not mature. A documented process with no evidence is not mature. A control that works once but is never retested is not adaptive.

3.4 Using Capabilities for Planning

Capability taxonomy gives CERG adopters a practical planning language:

• For leaders: fund the capability gap, not just the product request.
• For small teams: decide which capabilities must be live now and which are explicitly deferred.
• For engineering partners: explain security asks as outcomes, not bureaucracy.
• For auditors: show how evidence is produced by normal operations.
• For hiring: add people only when the capability cannot be made repeatable through clearer ownership, procedure, automation, or scope reduction.

A tool can support a capability. A document can define a capability. A person can own a capability. But the capability exists only when the organization can perform the work, produce evidence, and improve from what it learns.

4. Cyber Engineering

Mission: Build securely. Deploy confidently. Consult continuously.

4.1 Mission

The Cyber Engineering team serves as the organization’s internal security consulting practice. Engineers are assigned to enterprise and IT projects, often as the first security touch point in a project lifecycle, and carry security requirements, design review, and implementation guidance from concept through production handoff.

Engineers do not own the systems they help build. Their role is to ensure that security is designed in from the beginning, that pre-production findings are remediated or risk-accepted before go-live, and that the receiving operations team understands the security posture of what they are taking on.

4.2 Core Functions

• Project intake and early engagement: review of business requirements, solution architecture documents, and procurement specifications
• Security architecture consultation: participating in design reviews, advising on control selection aligned to NIST 800-53 and organizational standards
• Pre-production security review: working with the Risk team to understand vulnerability scan findings and driving remediation with project teams before go-live
• Risk treatment support: assisting project teams in drafting risk acceptance documentation and treatment plans when a vulnerability cannot be remediated prior to launch
• OT/IT convergence advisory: guiding teams through the security implications of connecting or modernizing operational technology environments
• Production handoff: ensuring Governance and Risk have the configuration baseline, asset documentation, and control evidence needed to assume post-production oversight

4.3 Engagement Model

Engineering operates on a lightweight internal consulting model. The goal is to minimize administrative overhead and maximize time on engineering work.

4.4 Illustrative Example: Electrical Utility

Scenario: IT/OT Network Modernization

The utility’s operations team wants to add remote monitoring capability to its substation SCADA systems. An Engineering team member is engaged at the business requirements stage. They review the vendor’s solution architecture, flag the absence of encrypted communications between the historian and the enterprise DMZ, and work with the project team to require TLS enforcement before go-live. The Risk team performs a pre-production scan and finds an unpatched firmware version. Engineering works with the vendor on a patch timeline. When the patch cannot be applied before the project deadline, Engineering helps draft a risk treatment plan with compensating controls, network segmentation, enhanced logging, that Governance reviews for NERC-CIP CIP-005 conformance. VP and CISO sign off. The system goes live with a 90-day remediation commitment documented.

4.5 NIST Framework Alignment: Engineering

5. Cyber Risk

Mission: Know your exposure. Manage it deliberately. Never be surprised.

5.1 Mission

The Cyber Risk team is responsible for understanding the organization’s threat landscape and exposure at all times. Risk does not wait for problems to surface, it hunts for them. Through continuous exposure management, adversarial validation, vendor risk assessment, and threat intelligence, Risk produces the clearest possible picture of what is threatening the organization and how severe those threats are.

Risk serves both a pre-production function (finding issues before systems go live) and a post-production function (tracking drift, emerging CVEs, and changes in the threat environment after systems are in operation).

5.2 Core Functions

• Exposure Management: continuous scanning of IT and OT environments; prioritization of findings by criticality, exploitability, and asset value; tracking remediation to closure
• Adversarial Validation: authorized testing of controls under adversary-like conditions, including penetration testing, red-team operations, purple-team detection validation, cloud attack simulation, and OT-safe assessment where in scope; findings fed back to Engineering and Governance
• Threat Intelligence: monitoring of threat actor activity, emerging CVEs, and sector-specific intelligence (including ICS/SCADA threats for OT environments); distribution of actionable intelligence to Engineering, IR, and Governance
• Vendor and Third-Party Risk: security review of vendor contracts, SaaS solutions, and third-party integrations; contract redline support for security requirements
• Pre-Production Assessment: vulnerability scanning and risk analysis of systems prior to go-live; classification of findings by severity; coordination with Engineering on remediation
• Risk Treatment and Acceptance: for findings that cannot be immediately remediated, Risk co-develops treatment plans with Engineering and provides analysis to support leadership sign-off decisions

5.3 Pre-Production vs. Post-Production Risk

An Important Distinction

A vulnerability found in a pre-production system is not a realized risk, the system is not yet live and has not been exposed. The Risk team treats pre-production findings as engineering inputs, working with the Engineering team to drive remediation before launch. Post-production findings are realized risks to be managed, tracked, and reported. This distinction shapes how findings are communicated, prioritized, and escalated.

5.4 Illustrative Example: Electrical Utility

Scenario: NERC-CIP Vulnerability in a BES Cyber System

During monthly vulnerability scanning, the Risk team identifies that a critical relay management workstation, classified as a BES Cyber System under NERC-CIP CIP-002, is running an operating system version with a known critical vulnerability (CVSS 9.1). The asset cannot be patched within the standard 35-day window due to vendor testing requirements. Risk notifies Governance of a potential CIP-007-6 deviation. Governance initiates the deviation documentation process. Risk produces a threat analysis showing no current exploitation activity targeting this specific system type. Engineering is engaged to add network monitoring on the affected segment as a compensating control. The CISO and VP of Operations sign the deviation. Risk tracks the patch to closure within the extended timeline and provides attestation documentation to Governance for the compliance record.

5.5 NIST Framework Alignment: Risk

6. Cyber Governance

Mission: Set the rules. Track the work. Enable the business to move with confidence.

6.1 Mission

The Cyber Governance team is the rule-making, compliance management, and quality assurance function of the CERG model. Governance defines what good looks like, through policies, standards, and implementation guidance, and then ensures the organization actually gets there through compliance tracking, audit support, and control evidence management.

Governance operates from a “yes, and…” philosophy. The goal is never to block the business but to ensure that when the business accepts risk, that risk is documented, owned, and managed. Governance provides the framework within which Engineering and Risk do their best work.

6.2 Core Functions

• Policy and Standard Development: creating, maintaining, and retiring cybersecurity policies, standards, and procedures aligned to NIST 800-53, 800-171, CSF, and applicable regulations
• Implementation Guidance: translating policy requirements into practical, actionable guidance for IT and OT teams; bridging the gap between regulatory language and operational reality
• Compliance Management: tracking the organization’s compliance posture against NERC-CIP, CMMC, SOX, and other applicable requirements; managing the compliance calendar
• Control Evidence Management: setting standards for what constitutes acceptable evidence; collecting, organizing, and maintaining the control evidence library; coordinating audit responses
• Risk Treatment Tracking: maintaining the organization’s risk register; tracking open risk treatment plans to completion; escalating overdue or deteriorating items to the CISO
• Quality Assurance: periodic review of Engineering deliverables and Risk outputs to ensure conformance with organizational standards; not an adversarial audit but a collaborative QA function
• Regulatory Liaison: serving as the primary point of contact for regulators and external auditors; managing examination logistics; coordinating response to findings and enforcement actions

6.3 The “Yes, And…” Standard

Governance reserves the right to say no, particularly for significant NERC-CIP deviations or CMMC non-conformances where regulatory exposure is material. But the default orientation is enabling the business with guardrails, not closing doors. CERG publishes and reports against its own service-level commitments (CERG-GOV-SLC-001), so that a fast, safe yes is a measured obligation: a slow yes is a no the business routes around.

6.4 Evidence Standards

Governance sets the evidence standard, what constitutes acceptable proof that a control is operating effectively. Each pillar collects evidence appropriate to its work:

• Engineering produces: architecture review documentation, pre-production checklists, risk acceptance packages, handoff documentation, configuration baselines
• Risk produces: vulnerability scan reports, penetration test findings, threat intelligence reports, vendor risk assessments, patch tracking records
• Governance produces: policy documents, compliance matrices, audit reports, risk register entries, regulatory correspondence, exception approvals

Governance maintains the evidence library and ensures that evidence is organized, dated, attributed, and retained per regulatory requirements, NERC-CIP requires evidence retention for specified periods; CMMC requires evidence available for assessment.

6.5 Illustrative Example: Electrical Utility

Scenario: CMMC Level 2 Assessment Preparation

The utility has a contract with the Department of Energy that requires CMMC Level 2 compliance. Governance leads the preparation effort. They map all 110 NIST 800-171 practices to the organization’s existing controls, identifying 14 gaps. Governance works with Engineering to remediate 9 of the gaps through technical implementation. Three gaps are addressed through policy and procedure updates that Governance drafts. Two gaps require Risk to perform additional scanning and document compensating controls. Governance manages the evidence package, pulling architecture review records from Engineering, vulnerability reports from Risk, and policy documents from its own library. When the C3PAO assessment team arrives, Governance coordinates the logistics, manages the information requests, and tracks findings to closure post-assessment.

6.6 NIST Framework Alignment: Governance

7. Targeting NIST CSF 2.0 Adaptive Maturity

7.1 What Adaptive Means

The NIST Cybersecurity Framework defines four tiers of organizational maturity: Partial, Informed, Repeatable, and Adaptive. Most organizations operating a mature security program reach Repeatable, processes are defined, practiced, and reviewed. Adaptive goes further.

At the Adaptive tier, an organization does not just respond to the threat environment, it anticipates it. Risk management is integrated into the fabric of business decision-making. Cybersecurity considerations are part of every significant investment, acquisition, and operational change. The security function continuously learns from internal events and external intelligence, and updates its practices accordingly.

7.2 How CERG Produces Adaptive Behavior

The CERG model is designed to produce Adaptive-tier behavior through its structure, not just its aspirations.

7.3 CSF Core Function Coverage

The NIST CSF 2.0 Core consists of six functions. CERG provides primary or strong supporting ownership for all six.

8. Regulatory Alignment

8.1 NERC-CIP

NERC-CIP is the primary regulatory framework for bulk electric system (BES) cybersecurity. For an electrical utility, NERC-CIP requirements are non-negotiable and carry significant enforcement risk.

8.2 CMMC: Cybersecurity Maturity Model Certification

CMMC Level 2 requires implementation and assessment of all 110 practices in NIST SP 800-171. For organizations handling Controlled Unclassified Information (CUI) on behalf of the federal government, CMMC certification is a contract requirement. CERG provides the operational backbone for CMMC compliance.

• Engineering implements the technical controls across the 14 CMMC domains, access control, configuration management, system and communications protection, and others, during project delivery
• Risk performs the periodic assessments required by CMMC practice CA.2.157 and manages the Plan of Action & Milestones (POA&M) for open findings
• Governance maintains the System Security Plan (SSP), manages the evidence library, coordinates C3PAO assessment logistics, and tracks POA&M items to closure

8.3 SOX

For organizations subject to SOX ITGC requirements, CERG provides the structural foundation for compliance without requiring a separate compliance team.

• SOX ITGC: Governance owns the IT General Controls framework and evidence library. Engineering ensures change management controls are embedded in deployment processes. Risk monitors access and configuration integrity in financial systems.

The Regulatory Advantage of CERG

Organizations with multiple regulatory obligations, a utility managing NERC-CIP, CMMC, and SOX simultaneously, typically struggle with duplicated effort and conflicting timelines. CERG centralizes the regulatory function in Governance while ensuring that Engineering and Risk produce compliance evidence as a byproduct of their daily work, not as a separate compliance exercise. One team, one evidence library, one compliance posture.

9. IT/OT Considerations

9.1 The Air-Gapped Starting Point

Most organizations with OT environments today maintain a degree of air-gap separation between their operational technology networks and enterprise IT. For an electrical utility, this typically means:

• SCADA systems, energy management systems (EMS), and substation automation on isolated OT networks
• Historian servers in a DMZ acting as the data bridge between OT and IT
• Jump servers or data diodes controlling any permitted data flows
• Physical controls limiting access to OT environments

CERG is designed to operate in this context. The air-gap is a security control, Governance documents it, Risk validates it, and Engineering designs to preserve it while enabling the operational visibility the business needs.

9.2 The Modernization Pressure

The push to modernize OT infrastructure is real. Utilities are evaluating advanced metering infrastructure (AMI), remote monitoring, predictive maintenance, and grid modernization initiatives that all require some level of IT/OT integration. CERG’s role is to ensure that modernization happens securely, not to prevent it.

Engineering’s Role in IT/OT Convergence

When the business initiates an IT/OT convergence project, Engineering must be engaged before the vendor is selected and before the architecture is set. The engineering team reviews whether the proposed integration can be achieved while maintaining the electronic security perimeters required by CIP-005, the configuration management discipline required by CIP-010, and the segmentation required to limit the blast radius of a cyber event in either direction. This is far more effective and far less expensive than retrofitting security after the system is installed.

9.3 OT-Specific Risk Considerations

The Risk team’s approach to OT environments differs from IT in several important ways:

• Scanning must be OT-safe: active network scanning of OT environments can disrupt control processes. Risk uses passive monitoring, vendor-provided scan tools, and approved active scanning windows coordinated with OT operations.
• Patch windows are constrained: OT systems often cannot be patched on standard IT timelines due to vendor testing requirements, operational windows, and redundancy limitations. Risk tracks OT patch compliance separately and initiates NERC-CIP deviation processes when SLAs cannot be met.
• Availability is the primary objective: in OT environments, availability often outranks confidentiality in the risk calculus. Risk team members must understand this trade-off and communicate findings in terms of operational impact, not just CVSS scores.
• Threat intelligence must include ICS-specific sources: Risk maintains subscriptions to ICS-CERT advisories, E-ISAC threat intelligence, and vendor-specific security bulletins for all OT platforms in use.

9.4 Governance in OT Environments

NERC-CIP creates a distinct compliance obligation for BES Cyber Systems that sits alongside, and sometimes in tension with, broader IT governance. Governance manages this by:

• Maintaining separate but linked policy structures for IT and OT, common principles, tailored implementation requirements
• Tracking CIP-002 categorized assets separately in the risk and compliance registers with their specific regulatory requirements
• Managing NERC-CIP deviation and mitigation plan processes as a distinct workflow with defined escalation paths to the CISO and, where required, regulatory notification
• Coordinating with the reliability operations team to ensure that security controls and compliance actions do not inadvertently introduce reliability risk

10. Team Structure and Talent Model

10.1 Illustrative Team Structure

The illustrative organization for this framework is a large enterprise with several thousand employees and a substantial contractor workforce. The total protected population — identities, devices, and access relationships — approaches 28,000. CERG for this organization is a 60-person team reporting to the CISO, operating alongside Security Awareness and Incident Response.

This is an intentionally large example. The goal is to show what CERG looks like at full scale, with real operational velocity and complexity, so that teams of any size can see the complete model and trim to fit their environment. A 6-person CERG running this framework looks different in headcount, not in structure.

At this scale, the workload is substantial across all three pillars. Engineering carries approximately 125 active project engagements per year with roughly 40 running concurrently, spanning infrastructure, enterprise applications, cloud migrations, and third-party integrations. Engineers are aligned to specific business verticals and develop fluency in the systems they support, not just the security controls that apply to them.

Risk operates at equivalent velocity. The vendor risk program may cover thousands of active vendors and an extended workforce of remote contractors. Exposure management may span 100,000+ assets across enterprise IT, OT networks, and cloud environments. Adversarial validation runs on continuous cycles across pen test, red-team, purple-team, cloud, and OT-safe activities where in scope. Threat intelligence is a production function producing actionable intelligence distributed to Engineering, Incident Response, and leadership.

Governance operates as a domain-expert function. Subject matter experts carry deep technical knowledge — network security, identity and access management, cloud security, OT/ICS security, cryptography — and translate expertise into implementation guidance that engineering and operations teams use. The compliance portfolio may span multiple regulatory frameworks simultaneously. The evidence library is a living system, not a pre-audit scramble. The policy and standards catalog is actively maintained, version-controlled, and tied to regulatory citation.

A representative staffing structure for a CERG of this scale:

This distributes the 60-person team across approximately 14 Engineering staff, 15 Risk staff, and 13 Governance staff, with the CISO and pillar managers rounding out the team. The specific allocation will shift based on organizational priorities: a cloud migration program will weight Engineering more heavily; a regulatory audit cycle will weight Governance.

Scaling the Model

Most organizations will run a smaller CERG than this example, and that is by design. A municipal utility with a 6-person cyber team might place 2 engineers, 2 risk analysts, and 2 governance analysts in CERG, with each person carrying the full scope of their pillar. A regional cooperative with a single cybersecurity hire might have that person operate across all three pillars with the CISO providing strategic direction. The framework is the same at every size. The roles compress; the responsibilities do not disappear, they concentrate. Understanding the full-scale model helps smaller teams identify what they are covering, what they are deferring, and where they need to prioritize as they grow.

10.2 The Left-Right Knowledge Model

One of CERG’s explicit design goals is talent resilience, the ability to absorb the loss of any single team member without stopping work. The mechanism for achieving this is deliberate left-right knowledge sharing within and across pillars.

• Within each pillar, team members document their work in a shared and accessible way, not as bureaucratic overhead but as operational artifacts that others can follow
• Governance’s policies and standards serve as the knowledge base for Engineering and Risk, new arrivals can orient themselves by reading what Governance has documented
• Risk’s vulnerability reports and threat intelligence give Engineering context for why certain design decisions matter
• Engineering’s architecture and handoff documents give Risk a current map of what is in the environment and how it is configured

In practice, this means that a new Cyber Engineer can learn the organization’s standards from Governance, understand the current threat environment from Risk, and have context for every major system from Engineering’s project documentation. Onboarding accelerates. Knowledge is in the system, not in someone’s head.

10.3 CERG and the Adjacent Teams

11. Getting Started: The Path to Adaptive

11.1 Phase 1: Establish (Months 1–3)

The first priority is standing up the CERG structure and establishing the baseline work products each pillar needs to function.

• Engineering: Document the active project portfolio. Identify any in-flight projects that should receive a retroactive engineering review. Establish the lightweight intake process.
• Risk: Stand up or audit the exposure management program. Ensure IT and OT environments are covered with appropriate scanning approaches. Inventory threat intelligence feeds.
• Governance: Conduct a policy gap assessment against NIST 800-53 and applicable regulatory frameworks. Identify the three to five most critical missing or out-of-date policies. Build or inherit the risk register.

11.2 Phase 2: Operate (Months 4–9)

With the structure in place, the focus shifts to operating CERG as a team and building the cross-pillar working rhythms.

• Establish a regular CERG operating cadence, weekly pillar syncs, monthly cross-pillar review, quarterly CISO briefing
• Engineering begins processing the project intake queue and building the first round of handoff documentation
• Risk begins producing regular vulnerability reports with prioritized findings and tracking remediation to SLA
• Governance completes the first compliance self-assessment against NERC-CIP and CMMC; begins building the evidence library
• All pillars begin practicing the “yes, and…” model on real business requests

11.3 Phase 3: Mature (Months 10–18)

The CERG model begins demonstrating Repeatable behavior. The path to Adaptive requires building the continuous improvement and integration functions.

• Risk begins producing structured threat intelligence reports distributed to Engineering, IR, and leadership
• Governance launches a formal QA cycle, quarterly reviews of Engineering and Risk work products against defined standards
• Engineering demonstrates consistent early engagement on projects, present at business requirements stage, not called in at go-live
• First external validation: coordinate a NERC-CIP compliance audit or CMMC readiness assessment to measure progress and identify gaps
• Begin building the metrics program, vulnerability SLA adherence, time-to-engage on new projects, evidence collection completeness, policy currency

11.4 Adaptive Indicators

An organization operating at Adaptive maturity will demonstrate these observable behaviors:

• The security team is engaged in business planning conversations before projects are funded, not after they are designed
• Threat intelligence from Risk actively changes Engineering design decisions and Governance policy priorities
• When a significant vulnerability or threat emerges, the organization has a clear, practiced process for assessing impact, communicating status, and executing response, within hours, not days
• External auditors and regulators find organized, complete, and timely evidence, because evidence collection is a byproduct of daily work, not a pre-audit scramble
• New team members become productive faster because the CERG knowledge base, policies, standards, architecture documents, risk reports, is current, accessible, and well-organized
• The CISO can credibly report the organization’s risk posture to the board using data from the risk register and compliance program, not gut feel

12. Compliance as Exhaust — Evidence Factories

Regulatory alignment is a byproduct of running the program well. Evidence is produced once, from operational work, then reused across frameworks. Capabilities declare what the program can do; evidence factories produce the independently verifiable proof; compliance consumers reuse that proof without a parallel scramble. These evidence factories show the mapping:

This is where CERG can beat traditional GRC: compliance becomes exhaust from good operations, not a parallel workstream. Evidence packages are generated from operational records, not assembled from scratch before an audit. The Compliance Calendar maps each evidence factory to its production cadence.

13. Document Control

Revision History

Review Triggers

• Material change to CERG structure or operating model
• Framework version change
• Direction from the CISO or executive leadership

Related Documents

Source: governance/CERG-GOV-FRM-001_CERG_Framework.md · Download .md · View on GitHub