CERG OPERATING MODEL

Pillar Structure · Engagement Models · Staffing · Interaction Patterns

Table of Contents

1. Purpose and Scope
2. Operating Premise
3. The Three Pillars
4. Authority, Reporting, and Decision Rights
5. Engagement Models
6. Staffing and Roles
7. Coordination Cadence
8. Interfaces With Other Functions
9. RACI Patterns
10. Maturity, Metrics, and the Adaptive Target
11. Operating Model Control

1. Purpose and Scope

This document describes the operating model for the Cyber Engineering, Risk, and Governance (CERG) function. It defines the three pillars, the authority and reporting structure, the engagement models through which CERG delivers value to the business, the staffing patterns that support those engagements, and the cadence by which CERG operates as one team rather than three silos.

This is not a policy. CERG-POL-001 is the policy. This document is the operating description that every CERG team member, business sponsor, and adjacent function partner can use to understand how the function works and how to engage it.

1.1 Scope

This document applies to:

• The CERG function itself, Engineering, Risk, and Governance pillars under CISO authority
• The interfaces between CERG and adjacent security functions (Awareness, Incident Response), IT and OT delivery teams, business owners, and executive leadership
• The engagement models by which CERG is consumed: project delivery, continuous service, advisory, and program oversight
• The staffing roles within each pillar and the rules of engagement among them

1.2 Relationship to Other Documents

This document is referenced by every CERG standard, procedure, and plan. Where another document assigns work to “Engineering,” “Risk,” or “Governance,” this document defines what those terms operationally mean.

2. Operating Premise

2.1 Why CERG Exists

The traditional separation of cybersecurity into siloed functions, operational security here, GRC over there, engineering security as a third team, produces a predictable failure pattern. Engineering is asked to deliver, then security reviews it after the fact and asks for changes that are now expensive. Risk identifies findings that have no clear path back into engineering planning. Governance writes policy that operators interpret variously, or not at all. Audits and incidents reveal the seams.

CERG consolidates the three core security activities, building secure systems, managing exposure, and governing the program, into one function with one authority. The pillars are distinct in skill set and discipline, but they operate as one team with one CISO and one set of priorities.

2.2 The Yes-And Default

Governance Does Not Exist to Block the Business

CERG’s default orientation is to enable the business with guardrails, not to close doors. When a risk cannot be eliminated, it is documented, owned, treated, and monitored, not refused on principle. Reflexive denial is not a risk management strategy. The hard work is making “yes” safe; “no” is the easy answer, and the wrong one.

2.3 Three Pillars, One Team

CERG operates as one team. The pillars provide structure for skill development, work intake, and accountability, not boundaries to hide behind. Cross-pillar collaboration is the norm. Every Engineering review involves Risk perspective. Every Risk finding has a Governance disposition. Every Governance policy is validated for operational practicability by Engineering and Risk before publication.

3. The Three Pillars

3.1 Cyber Engineering

Mandate. Build secure systems by design. Embed security into architecture, configuration, and operational baselines before production. Be the technical security partner to project delivery.

Core activities.

• Pre-production security architecture review for all in-scope projects
• Reference architectures, landing zones, and configuration baselines per platform class
• Security infrastructure-as-code, policy-as-code, and admission control
• IT/OT convergence advisory and Electronic Security Perimeter design
• Identity platform engineering (IdP, MFA, SSO, PAM, secrets management)
• Cryptography and key management platform engineering
• Endpoint, server, container, and cloud security tooling engineering
• Operational handoff documentation that supports Governance compliance evidence

Engagement default. Project-aligned engagement. Engineering is engaged early in project planning and follows the work through go-live.

3.2 Cyber Risk

Mandate. Maintain continuous visibility into organizational exposure. Drive the work that reduces it. Test that controls hold up under attack.

Core activities.

• Exposure management (scanning, prioritization, remediation tracking) per CERG-PRC-VM-001
• Adversarial validation: penetration testing, red-team operations, purple-team detection validation
• Threat intelligence consumption and translation into detection and posture controls
• Vendor and third-party security risk assessment
• Cloud security posture management (CSPM) and SaaS security posture management (SSPM)
• Identity-threat detection and continuous identity-risk monitoring
• Risk-register intake from technical sources

Engagement default. Continuous service. Risk is always on; engagement is by exposure type, not by ticket.

3.3 Cyber Governance

Mandate. Own the policy library, the compliance posture, the risk register, and the evidence library. Translate regulation into actionable expectations. Coordinate regulator and auditor engagements.

Core activities.

• Policy, standards, and procedures library, including CERG-POL-001 and all subordinate documents
• Compliance program management: NERC-CIP, CMMC, SOX ITGC, and customer-contractual frameworks
• Risk register operation per CERG-PRC-RM-001
• Evidence library curation; production of audit and assessment evidence
• Regulator and assessor liaison
• Awareness program coordination (program ownership rests with a separate Awareness function; Governance coordinates content alignment)
• Risk-register intake from policy, audit, and assessment sources
• Risk treatment data feeds into the standing Incident Response team (a separate function under CISO oversight - see §3.4)

Engagement default. Program oversight and advisory. Governance is engaged when policy interpretation, exception decisions, or regulatory implications enter the conversation.

3.4 What CERG Is Not Responsible For

The following functions are intentionally outside CERG and operate under separate charters:

• Security Awareness program ownership. A distinct function under CISO oversight, coordinated with Governance.
• Incident Response operations and the IR plan itself. A standing Incident Response team within Cybersecurity, reporting to the CISO, owns CERG-PLN-IR-001 and operates the IR capability. CERG feeds detection, vulnerability context, asset documentation, and post-incident risk-register entries into the IR team; CERG does not maintain the plan, run the exercises, or own the regulatory notification clocks. During an active incident, CERG pillars provide Lead Investigator, Engineering Lead, and Governance Lead roles per the IR team’s call.
• Physical Security (non-cyber). Owned by Facilities; CERG coordinates for assets within CIP-006 / PE-family scope.
• Privacy program. A distinct function under Legal / Privacy leadership; coordinates with Governance for breach notification and Restricted-data handling.
• Business Continuity (non-cyber). Owned by Enterprise Risk / Operations; CERG coordinates for cyber-driven business continuity activations.

4. Authority, Reporting, and Decision Rights

4.1 Reporting Line

CERG reports to the CISO. The CISO reports per the organizational structure (typically to the CIO or directly to the CEO depending on org design) and has a defined reporting line to the board (Audit Committee, Risk Committee, or a dedicated Cyber/Technology Committee, per board protocol).

The three pillars report to the CISO through pillar leaders (Manager / Director / VP titles vary by organizational scale).

4.2 Decision Rights

4.3 Escalation Path

Disagreements that the pillars cannot resolve are escalated to the CISO. The CISO maintains a published escalation path that includes a stop-the-line capability for any CERG team member who believes a decision is being made that materially violates policy or creates regulatory exposure.

4.4 Cyber Oversight Group (COG)

The Cyber Oversight Group (COG) is the standing internal forum that reviews cyber risk posture between board cycles. It is chaired by the CISO.

Standing core members (every meeting): - Chief Information Security Officer (CISO) — Chair - Chief Information Officer (CIO) or designee - Chief Operating Officer (COO) or operational equivalent - General Counsel (GC) or designee - Chief Financial Officer (CFO) or designee - Enterprise Risk lead - Governance Pillar Leader (secretariat)

Dynamic members (per agenda): - Business Unit Risk Owner for any system, asset, or process appearing on the agenda — invited for the relevant agenda items - Engineering Pillar Leader — invited when architecture decisions, cloud migration, or OT/IT convergence items are on the agenda - Risk Pillar Leader — invited when risk acceptance review, threat landscape, or adversarial testing results are on the agenda - Any additional subject matter expert whose presence is needed for informed discussion on a specific agenda item, identified by the CISO or Governance Pillar Leader during agenda preparation

Dynamic membership rule: Standing core members participate in every meeting. Dynamic members are invited when their scope of accountability appears on the agenda. The agenda, distributed at least 5 business days before each meeting, lists the attending dynamic members and the items for which their attendance is requested.

The COG meets monthly and serves three purposes:

1. Posture review. The CISO presents the open Risk Register summary, top KRIs from CERG-GOV-MTR-001, and any High or Critical risk acceptance decisions made since the last meeting.
2. Cross-functional treatment alignment. Risks whose treatment crosses business boundaries - e.g., a risk that requires Operations to change a maintenance practice, or Finance to fund a remediation - are surfaced for cross-functional decision or escalation.
3. Pre-board review. The COG serves as the dress rehearsal for board-cycle reporting; material risk decisions surface here first so the board reporting is informed by cross-functional perspective.

The COG is not a risk-acceptance authority. Acceptance authority lives in the CERG-GOV-RMF-001 §9.7 table. The COG is the forum where the right decision-makers are in the room, informed, and aligned. Downstream reports - including the metrics dashboard in CERG-GOV-MTR-001 §9 and the risk-register reporting cadence in CERG-TMPL-RM-001 §7.3 - have the COG as their primary audience.

COG Agenda Template

The Governance Pillar Leader (secretariat) prepares the agenda using the template below, distributes it at least 5 business days before the meeting, and identifies which dynamic members are requested for which items.

COG AGENDA - YYYY-MM-DD

MEETING INFORMATION
   Date       : YYYY-MM-DD
   Time       : [Time / Duration]
   Chair      : CISO
   Secretariat: Governance Pillar Leader

ATTENDEES
   Standing core: CISO, CIO, COO, GC, CFO, ER Lead, Governance Pillar Leader
   Dynamic invited: [BU Risk Owner for Item X], [Pillar Leader for Item Y], [SME as needed]

AGENDA ITEMS

1. ADMINISTRATIVE (5 min)
   - Approval of prior meeting minutes
   - Conflict of interest disclosure (if any)

2. POSTURE REVIEW (20 min) — Lead: CISO
   - Risk Register summary: open entries by severity, new entries since last meeting
   - Top KRIs from CERG-GOV-MTR-001: [list 3-5 KRIs with green/amber/red]
   - High / Critical risk acceptance decisions since last meeting
   - [If dynamic member invited:] [BU Owner] provides context on [relevant KRI or risk item]

3. CROSS-FUNCTIONAL TREATMENT ALIGNMENT (20 min)
   a) [Risk Item 1 — e.g., Cloud migration vendor API exposure] — Owner: [Name]
      - Risk statement, residual score, treatment options
      - Ask (funding / operations change / policy waiver)
      - Discussion / decision
   b) [Risk Item 2 — e.g., OT patching cadence gap] — Owner: [Name]
      - Risk statement, residual score, treatment options
      - Ask
      - Discussion / decision
   c) [Risk Item N]

4. REGULATORY AND AUDIT UPDATE (10 min) — Lead: Governance Pillar Leader
   - Regulatory change tracker: items affecting COG scope
   - Audit / assessment calendar: upcoming engagements
   - Open findings and POA&M status

5. PRE-BOARD REVIEW (10 min) — Lead: CISO
   - Board reporting package (draft) for upcoming cycle
   - Material risk items requiring board attention
   - Decision: approve / revise / hold for next meeting

6. ANY OTHER BUSINESS (5 min)

7. ACTION ITEM REVIEW (5 min)
   - Review action items from prior meeting
   - New action items with owner and target date

MATERIALS ATTACHED
   - Risk Register summary report
   - KRI dashboard (CERG-GOV-MTR-001 §9 extract)
   - Board reporting package draft (if applicable)
   - Risk acceptance records for review items

5. Engagement Models

CERG is consumed by the rest of the organization through four engagement models. Most major initiatives use more than one.

5.1 Project Engagement (Engineering-Led)

Used for new systems, major changes, and significant integrations.

CERG commits to architecture-review intake and disposition turnaround by project tier per CERG-GOV-SLC-001; early engagement only works if engaging CERG is fast.

5.2 Continuous Service (Risk-Led)

Used for ongoing exposure management across the entire estate.

CERG commits to a time-to-coverage target for bringing a new asset under vulnerability and CSPM coverage after go-live, per CERG-GOV-SLC-001.

• Exposure management operates as a standing service per CERG-PRC-VM-001.
• CSPM / SSPM operates continuously across approved cloud and SaaS.
• Threat intelligence consumption produces standing detection and posture work.
• Identity-threat detection operates continuously.

Continuous services do not require project tickets. Business teams are partners in remediation rather than initiators of the work.

5.3 Advisory (Cross-Pillar)

Used when a business unit, IT team, or OT team has a question, decision, or exploration that does not yet require a project.

• Architecture review office hours
• Cloud / SaaS service evaluation advisory
• M&A / divestiture cyber due diligence support
• Vendor selection advisory
• Policy interpretation advisory

Advisory engagements are intentionally low-friction, but low-friction does not mean unmeasured. They are tracked at the activity level, and CERG commits to a published response time for advisory requests per CERG-GOV-SLC-001, so that “engage us early” is backed by a reciprocal commitment to respond quickly.

5.4 Program Oversight (Governance-Led)

Used for regulatory programs, audits, exam cycles, and board reporting.

• NERC-CIP self-certification cycle and CIP-014 / CIP-013 program management
• CMMC pre-assessment and assessment management
• SOX ITGC evidence cycle (quarterly)
• Internal audit coordination
• Customer / partner assessment response

Program oversight engagements are time-bounded with defined entry, milestone, and exit criteria. They are led by Governance with Engineering and Risk supplying evidence and SMEs.

6. Staffing and Roles

CERG staffing is intentionally consistent across the pillars: a pillar leader, senior practitioners with platform / domain ownership, individual contributors who execute the standing work, and rotations or shared roles where the pillars converge.

The structure below is a pattern, not a fixed org chart. Smaller organizations consolidate roles; larger organizations expand them.

6.0 Core Capabilities — What Survives Reorgs

Before defining roles, CERG defines capabilities — the durable work that must get done regardless of headcount, org chart, or reporting structure. Capabilities survive reorgs. Roles are implementation detail.

CERG has 11 core capabilities:

In a small team, one person may hold several capabilities. In a large team, each capability splits into specialized roles. The canonical role roster in §6.1 shows the full specialization; the capability map shows the irreducible minimum.

Role consolidation for small teams:

Principle: A 5-person CERG runs the same 11 capabilities as a 60-person CERG. The difference is headcount per capability, not the capabilities themselves. When headcount increases, roles split. When headcount decreases, roles consolidate. The capabilities remain.

6.1 Canonical Role Roster

This roster is the single source of truth for role names used throughout the CERG document library. When a standard, procedure, plan, or template refers to “the Risk Manager,” it means the canonical name listed below. Documents that use a synonym (column 3) are calling the same role; the corrective action is to update the citing document to the canonical name on its next revision, not to invent a new role.

Roles are organized by pillar. Sub-role variants (e.g., Engineering Pillar Leader - Cloud vs. Engineering Pillar Leader - OT) are scaled out from the canonical name with a parenthetical domain qualifier.

See also: JF-001 for job family grouping and level definitions that organize these roles for career development and hiring. The roster below (and the supporting §6.2-6.4 sections) remains authoritative for role names and pillar assignments.

“CISO designee”

Several subordinate documents reference a “CISO designee” as an approval authority for tactical risk decisions. The CISO designee is whichever named pillar leader (Engineering, Risk, or Governance) the CISO has formally delegated to act on the CISO’s behalf for a specific approval class. Designation is recorded in writing and reviewed at the CISO’s discretion at least annually. Where a document needs to name a specific approver, use the canonical role name (e.g., “Risk Pillar Leader”); reserve “CISO designee” for cases where the delegation may rotate between pillars.

6.2 Cyber Engineering: Typical Roles

6.3 Cyber Risk: Typical Roles

6.4 Cyber Governance: Typical Roles

6.5 Shared and Rotational Roles

Several roles intentionally sit between pillars and rotate:

• Architecture Review Office Hours. Engineering + Risk on rotation.
• Incident Response support rotation. CERG provides Engineering, Risk, and Governance support when activated by the standing IR team; the Incident Commander owns incident decisions and IR on-call operations.
• Audit liaison. Governance-led with Engineering and Risk SMEs.

7. Coordination Cadence

CERG operates as one team because it talks like one team. The standing cadence below is the minimum; teams add working sessions as needed.

Incident Response cadence

8. Interfaces With Other Functions

CERG operates inside a broader organizational ecosystem. The following interfaces are explicit.

9. RACI Patterns

The following patterns illustrate how the pillars typically distribute work. Specific RACI matrices are maintained per process. This is a sample; each standard and procedure cited in CERG-POL-001 §10 has its own. Role names follow the canonical roster in §6.1.

9.1 New Cloud Workload Goes Live

9.2 Open High Vulnerability Past SLA

9.3 CMMC Pre-Assessment Cycle

CMMC pre-assessment work involves two acronyms that appear without prior explanation elsewhere in the suite:

• SPRS - Supplier Performance Risk System. The DoD-operated portal where contractors post their NIST 800-171 self-assessment score and basic assessment confirmation.
• C3PAO - CMMC Third-Party Assessment Organization. An accredited assessor authorized by the Cyber AB to conduct CMMC Level 2 certification assessments.

10. Maturity, Metrics, and the Adaptive Target

10.1 The Adaptive Target

CERG targets NIST Cybersecurity Framework Tier 4, Adaptive posture for the organization. Adaptive does not mean “constantly changing.” It means the organization understands its risk environment, continuously adjusts its program based on what it learns, integrates cybersecurity into enterprise risk and business decisions, and treats lessons learned as a first-class input to the program.

10.2 Maturity Indicators

The following indicators are tracked by Governance and reported to the CISO and the Cyber Oversight Group. They are leading indicators of program maturity, not lagging measures of incident counts. Target values, green/amber/red thresholds, escalation triggers, and reporting cadence live in CERG-GOV-MTR-001 §3; this section names the indicators only.

10.3 Continuous Improvement

Every CERG activity produces feedback into the program backlog:

• Post-incident lessons → Engineering, Risk, Governance backlog items
• Audit findings → POA&M / risk register entries with treatment plans
• Exercise results → Plan and playbook updates
• Adversarial validation findings → Detection rules, posture controls, architectural changes
• Threat intelligence → Standing detection and control updates

The backlog is reviewed monthly. Items that age beyond planned dates without justification are flagged to the CISO and surfaced to the Cyber Oversight Group.

10.4 Knowledge Transfer and Cross-Training

The CERG Framework (FRM-001 Section 9.2) describes the “Left-Right Knowledge Model” as a mechanism for talent resilience: engineers learn Risk thinking, Risk analysts understand Governance, and Governance practitioners understand what is technically possible. Domain X5 in the maturity assessment (MAT-001) scores single-point-of-failure resilience. CERG claims critical roles are backstopped and knowledge is “in the system.”

This section defines how the organization produces evidence that knowledge transfer is actually occurring, not just claimed.

10.4.1 Cross-Training Log

Each pillar maintains a lightweight cross-training log. The log records cross-pillar knowledge activities:

The log is intentionally lightweight. It is not a training management system. Its purpose is to provide evidence that cross-pillar knowledge transfer is occurring on a regular cadence.

10.4.2 Documentation Completeness

Knowledge “in the system” means knowledge that survives when the person who holds it is unavailable. Documentation completeness is measured by two metrics tracked in MTR-001:

• KM-001: Procedure Documentation Currency. Percentage of critical processes with current (less than or equal to 12-month) procedure documentation. A procedure is “critical” if it supports a control marked Implemented in CB-001.
• KM-002: Role Backup Currency. Percentage of canonical roles with a documented secondary or backup who has performed the role in an exercise or real event within 18 months. “Performed” means the backup has executed the role’s core responsibility at least once, not just been named on an org chart.

10.4.3 Cross-Training Expectations

The minimum cross-training expectation per team member is 4 hours per quarter of cross-pillar knowledge activity. This is tracked as metric KM-003 in MTR-001.

Cross-training activities that qualify: - Shadowing a cross-pillar review or engagement - Presenting cross-pillar content at a CERG All-Hands or pillar sync - Participating in a joint review (architecture, threat model, risk assessment) where the participant is from a different pillar than the lead - Rotation assignment of at least one week duration in a different pillar - Participating in a tabletop exercise in a role different from the participant’s day-to-day role

10.4.4 Maturity Assessment Integration

At the annual maturity assessment (MAT-001), domain X5 (Single-Point-of-Failure Resilience) scoring is amended as follows:

A domain scores Adaptive in X5 only when: - (a) Critical roles are backstopped (existing criterion), AND - (b) At least one cross-training activity is documented per critical role per year, AND - (c) Documentation currency metrics (KM-001, KM-002) are green

This ensures that “no single point of failure” is not just a claim about org-chart coverage but is backed by evidence of actual knowledge transfer and current documentation.

11. Operating Model Control

Revision History

Review Triggers

This operating model shall be reviewed annually and upon any of the following:

• Material organizational change affecting CERG structure or reporting
• Material change to scope (e.g., new regulated environment, major M&A)
• A Sev 1 incident or significant audit finding that reveals a structural gap
• CISO transition
• Direction from executive leadership or the board

The CISO owns this document. Cyber Governance maintains it on behalf of the CISO. Changes require CISO approval and broad CERG acknowledgment.

Related Documents

The authoritative inventory is CERG-GOV-CAT-001. The references below are the V1 library at a glance, grouped by role within the operating model.

Source: governance/CERG-GOV-OM-001_CERG_Operating_Model.md · Download .md · View on GitHub