# CERG — Full Concatenated Corpus > Every document in the CERG framework concatenated into a single file, > in canonical reading order. Generated from markdown source. --- | 1.22 | 2026-06-11 | Governance Pillar Leader | Workforce architecture and cross-pillar flows amendment. Added §10.4 referencing Job Families Overview (JF-001), NICE Crosswalk (JF-002), Cross-Pillar Operational Flows (FLOW-001), per-role job descriptions, and machine-readable specifications. No changes to the 10 foundational principles. | ### Foundational Security Principles: All Systems · All Environments · All Trust Levels --- | | | |---|---| | **Document ID** | CERG-POL-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Chief Information Security Officer | | **Parent Policy** | Not applicable; this is the parent policy | | **Review Cycle** | Quarterly / Upon Significant Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · NIST RMF | | **Regulations** | NERC-CIP · CMMC Level 2 · SOX ITGC | | **Environments** | All in-scope environments | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The CERG Operating Model](#2-the-cerg-operating-model) 3. [Definitions](#3-definitions) 4. [Foundational Security Principles](#4-foundational-security-principles) 5. [Roles and Responsibilities](#5-roles-and-responsibilities) 6. [Regulatory and Framework Alignment](#6-regulatory-and-framework-alignment) 7. [Exceptions and Risk Acceptance](#7-exceptions-and-risk-acceptance) 8. [Compliance and Enforcement](#8-compliance-and-enforcement) 9. [Policy Review and Maintenance](#9-policy-review-and-maintenance) 10. [Related Documents](#10-related-documents) --- ## 1. Purpose and Scope This document establishes the foundational cybersecurity policy for the organization. It defines the enduring security principles that govern all information and operational technology, regardless of system type, classification, hosting environment, or regulatory regime. These principles are intentionally durable. They do not change based on whether a system is a bulk electric system (BES) asset, a cloud-hosted SaaS application, a contractor-managed endpoint, or a leased data center facility. The standards, procedures, and implementation guidance derived from this policy will address environment-specific requirements. This policy establishes what is always true. ### 1.1 Scope This policy applies to: - All information systems and operational technology owned, operated, leased, or contracted by the organization - All personnel with access to organizational systems, including employees, contractors, consultants, and third-party vendors - All environments, including owned data centers, leased facilities, cloud service providers, SaaS platforms, and remote access connections - All system classifications, including BES Cyber Systems under NERC-CIP, systems handling Controlled Unclassified Information (CUI) under [CMMC](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems, and general enterprise IT - All trust levels, from fully managed corporate devices to third-party contractor equipment accessing organizational resources ### 1.2 Policy Hierarchy This policy sits at the top of the cybersecurity governance hierarchy. Subordinate documents provide the specific requirements and operational detail for implementing these principles: | Level | Document Type | Purpose | | --------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **1 - This document** | **Policy (CERG-POL-001)** | Enduring principles. What is always true. Authority for all below. | | 2 | Standards | Specific, measurable requirements per system type, data class, or regulatory regime (e.g., BES Cyber System Standard, Cloud Security Standard). | | 3 | Procedures | Step-by-step implementation guidance for specific activities (e.g., vulnerability scanning procedure, access review procedure). | | 4 | Guidelines | Non-mandatory best practice and implementation advice. Supports engineering and operational teams. | --- ## 2. The CERG Operating Model Cybersecurity operations are organized into three tightly coupled pillars under the Cyber Engineering, Risk, and Governance (CERG) framework. This model consolidates the core security work of the organization, eliminates structural silos, and produces Adaptive-tier maturity as defined by the NIST Cybersecurity Framework. | **Engineering** | **Risk** | **Governance** | | -------------------------------- | ------------------------ | --------------------- | | Security architecture and design | Exposure management | Policy and standards | | Pre-production reviews | Penetration testing | Compliance management | | Control implementation | Threat intelligence | Evidence and audit | | Configuration baselines | Vendor risk assessment | Risk register | | IT/OT convergence advisory | Risk treatment support | Regulatory liaison | These pillars operate simultaneously and continuously, not sequentially. CERG coordinates closely with the Security Awareness and Incident Response functions, which operate under separate charters. All CERG activities are subject to CISO oversight and report to the board through the CISO's risk and compliance reporting function. > **The "Yes, And…" Standard** > > Governance does not exist to block the business. The default orientation is enabling the business with guardrails, not closing doors. When a risk cannot be eliminated, it is documented, owned, treated, and monitored. Reflexive refusal is not an acceptable risk management strategy. CERG publishes and reports against its own service-level commitments ([`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md)), so that making yes safe is an accountable, measured commitment and not only an aspiration. --- ## 3. Definitions The following terms are used throughout this policy and all subordinate documents. |Term|Definition| |---|---| |**Asset**|Any information system, operational technology device, application, data repository, or network component owned, operated, leased, or contracted by the organization. Includes physical and virtual instances across all environments.| |**BES Cyber System**|A grouping of BES Cyber Assets that perform one or more reliability tasks for a functional entity, as defined by NERC-CIP CIP-002.| |**CERG**|The Cyber Engineering, Risk, and Governance operating model. The three-pillar security function responsible for building secure systems, managing exposure, and governing the security program.| |**CUI**|Controlled Unclassified Information. Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls (32 CFR Part 2002).| |**DISH**|**D**efensive **I**nfrastructure **S**ystem **H**ardening. The CERG-published set of secure configuration baselines applied to in-scope assets per asset class. Authoritative baselines are maintained in [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md).| |**Environment**|The hosting and operational context of an asset: owned data center, leased data center, cloud infrastructure (IaaS/PaaS), SaaS platform, or contractor-managed facility.| |**Executive Sponsor**|The named business or operational executive accountable for the systems, processes, or programs within a defined scope. The Executive Sponsor concurs on Critical-severity risk acceptance decisions per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7, sits on the Cyber Oversight Group when a system in their scope is on the agenda, and is named per system in the categorization register.| |**OT / ICS**|Operational Technology / Industrial Control Systems. Hardware and software that monitors and controls physical devices, processes, and events in industrial environments, including SCADA systems, energy management systems, and substation automation.| |**POA&M**|**P**lan of **A**ction and **M**ilestones. A documented record of open findings, their compensating controls, named owners, and target remediation dates. POA&Ms are mandatory under DFARS / CMMC for CUI scope and are produced as part of every System Security Plan; CERG also uses POA&M as the standard format for tracking open security findings outside CUI scope.| |**PPR**|**P**riority **P**atch **R**equest. CERG's emergency-response remediation tier, invoked for vulnerabilities listed in the CISA KEV catalog or confirmed under active exploitation. SLA values and trigger criteria live in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5.2.| |**Risk Acceptance**|A documented management decision to acknowledge a risk and take no further action to reduce it. Approval authority and acceptance duration are defined in the canonical Risk Acceptance Authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7.| |**Risk Treatment**|The process of selecting and implementing controls to modify risk. Includes risk reduction (implement controls), risk transfer (insurance, contract), risk avoidance (cease activity), and risk acceptance.| |**SSP**|**S**ystem **S**ecurity **P**lan. The authoritative document for a system in regulated scope (most commonly CUI / CMMC) that records system boundary, categorization, control implementation status, and responsible parties. POA&M entries are tracked as an attachment to the SSP.| |**System Trust Level**|The classification of confidence placed in a system or connection based on its ownership, management, and verification status. Ranges from fully trusted (organization-owned, managed, and monitored) to untrusted (unmanaged third-party or external networks).| |**Vulnerability**|A weakness in an information system, system security procedure, internal control, or implementation that could be exploited or triggered by a threat source.| --- ## 4. Foundational Security Principles The following ten principles constitute the enduring security requirements of this organization. They apply universally, to every asset, every environment, every trust level, and every regulatory context. Subordinate standards define how these principles are implemented in specific contexts. > **How to Read These Principles** > > Each principle states a universal mandate, what must always be true. The rationale explains why. The references identify the NIST controls and regulatory requirements the mandate satisfies. Implementation specifics (thresholds, timelines, approved tools, exceptions) are defined in subordinate standards. --- ### Principle 1: Maintain an Authoritative, Current Inventory of All Assets **Mandate** - The organization shall maintain a complete and current inventory of all assets within scope of this policy. - Each asset record shall include, at minimum: asset identifier, system type (IT or OT), data classification, regulatory designation (BES Cyber System, CUI environment, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant system, or general IT), asset owner, and hosting environment. - Asset inventory shall be updated upon any addition, modification, or decommission of an in-scope asset. - Cyber Engineering is responsible for producing asset documentation at project handoff. Cyber Risk is responsible for validating inventory coverage through scan and assessment activities. **Rationale** You cannot protect what you do not know you own. An incomplete inventory is not a documentation gap, it is an unmanaged attack surface and, for regulated systems, a compliance gap that may constitute a reportable finding independent of any security event. **References** `NIST CSF 2.0 IDENTIFY` · `NIST 800-53 CM-8` · `NIST 800-171 03.04.01` · `NIST RMF Step 1` · `NERC-CIP CIP-002` · `CMMC CM.L2-3.4.1` --- ### Principle 2: Enforce Least Privilege and Verify Identity for All Access **Mandate** - Access to all organizational assets shall be granted on the basis of least privilege, the minimum access required to perform an authorized function. - Identity shall be verified before access is granted. Multi-factor authentication (MFA) is required for all remote access and all access to privileged functions, regardless of network segment or system type. - Default, shared, and generic credentials shall be eliminated. Each user, system, and service shall be uniquely identified. - Accounts shall be provisioned, modified, and deprovisioned through a documented lifecycle process tied to authoritative sources (e.g., HR system, approved request workflow). Access reviews shall be conducted on a frequency defined in subordinate standards. - Privileged access shall be managed under heightened controls, documented separately from standard user access, and subject to enhanced logging and session controls. **Rationale** Credential-based attacks are the leading initial access vector. Excessive privilege is the primary lateral movement enabler. Together, weak authentication and over-provisioned accounts convert every phishing attempt or credential theft into a potential enterprise-wide breach. In OT environments, over-privileged access to control systems may have no detective controls to catch misuse, prevention is the only effective control layer. **References** `NIST CSF 2.0 PROTECT` · `NIST 800-53 AC-2, AC-6, IA-2, IA-5` · `NIST 800-171 03.01.01–03.01.03, 03.05.01–03.05.03` · `NIST RMF Step 3` · `NERC-CIP CIP-004 R4, CIP-005 R2, CIP-007 R5` · `CMMC AC.L1-3.1.1, AC.L2-3.1.5, IA.L1-3.5.1, IA.L2-3.5.3` · `SOX ITGC access controls` --- ### Principle 3: Harden All Systems to a Documented Baseline **Mandate** - All organizational assets shall be configured to a documented, approved security baseline prior to production deployment and maintained against that baseline throughout their operational life. - Unnecessary services, protocols, ports, and software components shall be disabled or removed. Default configurations shall be replaced with organization-approved secure configurations. - Configuration baselines shall be documented per asset class and maintained as a living artifact by Cyber Engineering. - Deviation from an approved baseline requires a documented exception with compensating controls, owner acknowledgment, and a defined remediation timeline. Exceptions shall be tracked in the risk register. **Rationale** Default and unrestricted configurations are the attack surface that was never needed. Hardening eliminates exposure that cannot be exploited because it does not exist. In OT environments, unnecessary ports and services are a compliance finding under NERC-CIP CIP-007 R1 independent of whether a vulnerability exists in them, the control obligation is categorical. **References** `NIST CSF 2.0 PROTECT` · `NIST 800-53 CM-6, CM-7` · `NIST 800-171 03.04.06, 03.04.07` · `NIST RMF Step 3` · `NERC-CIP CIP-007 R1, CIP-010 R1` · `CMMC CM.L2-3.4.6, CM.L2-3.4.7` --- ### Principle 4: Segment Networks and Protect Sensitive Data **Mandate** - Networks shall be divided into defined security zones. Access between zones shall be explicitly permitted, documented, and enforced by technical controls. - Environments containing regulated or sensitive data, including BES Cyber Systems, CUI-handling systems, and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems, shall be isolated from general-purpose networks through documented, validated controls. - Data shall be protected in transit using approved encryption standards. Data at rest that is classified as sensitive, regulated, or subject to contractual protection requirements shall be encrypted using organization-approved methods. - IT and OT network interconnections shall receive heightened architectural scrutiny. All data flows crossing an IT/OT boundary require documented authorization, shall be minimized to operational necessity, and shall be validated through regular assessment. **Rationale** Flat networks convert a single compromised endpoint into an enterprise-wide breach. In IT environments, segmentation limits data theft and ransomware propagation. In OT environments, the consequence of inadequate segmentation is not data loss, it is potential manipulation or disruption of physical processes affecting operational reliability. The blast radius is not a technical metric; it is a reliability and safety metric. **References** `NIST CSF 2.0 PROTECT` · `NIST 800-53 SC-7, SC-8, SC-28` · `NIST 800-171 03.13.01, 03.13.08, 03.13.10` · `NIST RMF Step 3` · `NERC-CIP CIP-005 (ESP/EAP), CIP-011` · `CMMC SC.L1-3.13.1, SC.L2-3.13.16` --- ### Principle 5: Identify and Remediate Vulnerabilities on a Defined Schedule **Mandate** - The organization shall maintain continuous visibility into vulnerabilities affecting in-scope assets through a documented exposure management program operated by Cyber Risk. - Vulnerabilities shall be assessed for severity, exploitability, and asset criticality. Findings shall be tracked to remediation or documented risk acceptance within the SLAs published in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5.2. - OT and BES Cyber Systems shall be scanned using approved methods that do not introduce operational risk. Timelines for OT remediation shall account for vendor testing requirements and operational windows, with NERC-CIP deviation processes invoked as required. - Vulnerabilities identified during pre-production assessment shall be remediated or formally risk-accepted prior to production deployment per the Risk Acceptance Authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. High and Critical severity findings require documented authorization at the level named in that table before go-live. - The organization shall conduct periodic adversarial validation, including penetration testing, red team operations, and purple-team detection validation where in scope, to validate that controls function under active attack conditions, not only under passive assessment. **Rationale** The majority of successful breaches exploit known vulnerabilities for which patches exist. An unmanaged vulnerability is not a theoretical risk, it is a documented entry point. In OT environments, the risk calculus is more complex: patching too quickly without vendor validation can introduce reliability risk; patching too slowly creates security exposure and regulatory non-compliance. Both failure modes require management. **References** `NIST CSF 2.0 IDENTIFY, DETECT` · `NIST 800-53 SI-2, RA-5, CA-8` · `NIST 800-171 03.11.02` · `NIST RMF Steps 4, 6` · `NERC-CIP CIP-007-6 R2, CIP-010 R3` · `CMMC RA.L2-3.11.2, SI.L1-3.14.1, CA.L2-3.12.1` --- ### Principle 6: Control, Log, and Monitor All Privileged and Remote Access **Mandate** - All privileged access sessions and all remote access connections to organizational assets shall be logged. Log data shall include at minimum: identity, source, target system, session initiation and termination time, and actions performed where technically feasible. - Session recording shall be applied to high-risk access as defined in subordinate standards. - Log data shall be protected from modification and retained for periods defined per regulatory requirement. Log review shall occur on a defined cadence with findings escalated through the risk management process. - Continuous monitoring capabilities, including security information and event management (SIEM) or equivalent, shall be deployed to detect anomalous activity across in-scope systems. OT monitoring shall use passive or approved active methods that do not introduce operational risk. - Threat intelligence shall be integrated into monitoring to enable detection of known adversary techniques relevant to the organization's industry and system profile. **Rationale** Controls that cannot be observed cannot be verified. Privileged and remote access are the primary targets for both external attackers and malicious insiders post-compromise. Without logging, misuse is invisible, incident response is unattributable, and regulatory reporting is inaccurate. NERC-CIP CIP-005 R2 treats unlogged remote access to BES systems as a reportable condition regardless of whether any misuse occurred. **References** `NIST CSF 2.0 PROTECT, DETECT` · `NIST 800-53 AU-2, AU-9, AU-11, AU-12, AC-17, SI-4` · `NIST 800-171 03.03.01, 03.14.06` · `NIST RMF Steps 3, 6` · `NERC-CIP CIP-005 R2, CIP-007 R4` · `CMMC AU.L2-3.3.1, AU.L2-3.3.2, SI.L2-3.14.6` · `SOX ITGC access logging` --- ### Principle 7: Manage Configuration Changes Through a Controlled Process **Mandate** - All changes to in-scope assets, including software, firmware, configuration, and network changes, shall be authorized, documented, and reviewed prior to implementation. - Configuration baselines shall be compared before and after changes to verify that only intended modifications were made. - Unauthorized configuration changes shall be detected through technical controls and treated as security events subject to investigation. - Change records shall be retained as audit evidence in accordance with applicable regulatory requirements. **Rationale** A hardened system that drifts back to an insecure state provides the same exposure as a system that was never hardened. Configuration drift is the primary mechanism by which effective controls degrade. Unauthorized changes are a primary persistence technique for advanced attackers, an adversary who disables a logging agent or opens a firewall rule has bypassed your controls without exploiting a single CVE. [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) treats unauthorized changes to financial systems as a control failure independent of any security event. **References** `NIST CSF 2.0 PROTECT` · `NIST 800-53 CM-3, CM-5` · `NIST 800-171 03.04.03` · `NIST RMF Step 3` · `NERC-CIP CIP-010 R1` · `CMMC CM.L2-3.4.3` · `SOX ITGC change management` --- ### Principle 8: Extend Security Requirements to Third Parties and the Supply Chain **Mandate** - All third-party vendors, contractors, and service providers with access to organizational assets or data shall be assessed for security risk prior to onboarding and on a recurring basis defined in subordinate standards. - Contractual agreements with third parties shall include security requirements addressing, at minimum: data handling, incident notification, access controls, right-to-audit provisions, and applicable regulatory compliance obligations. - Software and technology acquired from third parties shall be assessed for supply chain integrity risk. Vendor-provided code and firmware shall be validated through organization-approved integrity verification methods. - Third-party access shall be subject to the same least privilege, MFA, and logging requirements as organizational users. Remote access by vendors to OT and BES Cyber Systems requires explicit authorization and shall be logged and monitored. **Rationale** The organization's security posture extends only as far as its weakest trusted third party. Third parties with legitimate access are a primary attack vector, not because they are adversaries, but because they represent a trusted pathway that may be compromised without the organization's knowledge. The SolarWinds supply chain compromise demonstrated that a trusted, certified vendor can become an unwitting attack delivery mechanism at scale. Vendor questionnaires do not catch compromised software build pipelines. **References** `NIST CSF 2.0 GOVERN` · `NIST 800-53 SA-9, SR-3` · `NIST 800-171 03.01.20` · `NIST RMF Step 2` · `NERC-CIP CIP-013` · `CMMC SR.L2 family` · `SOX ITGC third-party SOC 2` --- ### Principle 9: Formalize Risk Management and Maintain an Active Risk Register **Mandate** - All identified risks to organizational assets and operations shall be documented in the organizational risk register with, at minimum: risk description, affected assets, risk owner, severity, treatment decision, compensating controls, and target closure date. - Risk treatment decisions, including risk acceptance, require documented approval from the authority named in the canonical Risk Acceptance Authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. - The risk register shall be reviewed in two cadences per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §8.2: weekly for High and Critical items, monthly in full. Overdue or deteriorating risk items shall be escalated to the CISO and the Cyber Oversight Group. - Risk management is an organizational function, not a security team function. Business unit owners bear accountability for the risks associated with their systems and processes. Cyber Governance facilitates and tracks; it does not absorb accountability on behalf of the business. **Rationale** Risks that are not formally documented are effectively accepted without acknowledgment, compensating controls, or accountability. When an undocumented risk materializes into an incident, there is no audit trail, no owner, and no record of what was understood at the time. Regulatory bodies treat the absence of documented risk decisions as evidence of a deficient risk management program, not as evidence that risk did not exist. **References** `NIST CSF 2.0 GOVERN` · `NIST 800-53 RA-3, PM-9` · `NIST 800-171 03.11.01` · `NIST RMF Steps 4–5` · `NERC-CIP CIP-003` · `CMMC RA.L2-3.11.1` · `SOX ERM interface` --- ### Principle 10: Prepare for, Respond to, and Learn from Security Events **Mandate** - The organization shall maintain documented, tested incident response and recovery plans that address the full lifecycle of a security event: detection, containment, investigation, notification, recovery, and lessons learned. - Incident response plans shall include regulatory notification timelines and contact procedures for all applicable frameworks. Responsible parties shall know their roles before an incident occurs. - Incident response capabilities shall be tested through tabletop exercises and simulated events at a frequency defined in subordinate standards. Untested plans shall not be treated as operational. - Post-incident reviews shall produce documented lessons learned that are tracked to closure through Engineering (architectural improvements), Risk (threat landscape and assessment updates), and Governance (policy, standard, and playbook revisions). - Recovery capabilities, including backup restoration, shall be tested on a defined schedule. Restoration of in-scope systems shall follow documented procedures that account for system-specific regulatory and operational constraints. **Rationale** An organization that has not practiced its incident response plan has a documented assumption, not an operational capability. The incident itself may be unavoidable; poor response is not. NERC-CIP CIP-008 makes this concrete for BES environments: the regulatory notification clock runs whether or not the organization is ready. The organization that recovers fastest from a significant event, and learns from it most completely, is the one most likely to avoid the next one. **References** `NIST CSF 2.0 RESPOND, RECOVER` · `NIST 800-53 IR-2, IR-4, IR-8, CP-2, CP-9` · `NIST 800-171 03.06.01–03.06.03` · `NIST RMF Step 6` · `NERC-CIP CIP-008, CIP-009` · `CMMC IR.L2-3.6.1, IR.L2-3.6.2` --- ## 5. Roles and Responsibilities The following table defines accountability for this policy and the principles it establishes. Detailed role descriptions and RACI matrices are maintained in the CERG Operating Model documentation. |Role|Responsibility| |---|---| |**Chief Information Security Officer (CISO)**|Policy owner. Responsible for the cybersecurity program. Approves policy, standards, and risk acceptances per the canonical authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Reports compliance posture and material risks to the Cyber Oversight Group, executive leadership, and the board.| |**Cyber Engineering (CERG Pillar)**|Implements security controls through project delivery. Produces asset documentation and configuration baselines. Ensures systems are designed to conform to this policy and subordinate standards prior to production deployment.| |**Cyber Risk (CERG Pillar)**|Maintains continuous visibility into organizational exposure. Operates the exposure management, adversarial validation, threat intelligence, and vendor risk programs. Identifies and communicates risk to Engineering, Governance, and leadership.| |**Cyber Governance (CERG Pillar)**|Develops and maintains the policy and standards library. Tracks compliance posture across all applicable frameworks. Maintains the risk register and evidence library. Coordinates regulatory examinations and audits. Operates the compliance calendar.| |**Business Unit Leaders / Asset Owners**|Accountable for the security posture of systems within their operational scope. Authorize risk treatment decisions. Support Engineering and Risk engagement. Provide operational context for compliance and risk activities.| |**IT and OT Operations Teams**|Responsible for implementing and maintaining security controls on systems under their management. Participate in engineering reviews, vulnerability remediation, and change management processes.| |**All Personnel with System Access**|Responsible for complying with this policy and all applicable subordinate standards and procedures. Required to complete role-appropriate security training. Required to report suspected security events.| --- ## 6. Regulatory and Framework Alignment This policy is designed to satisfy the foundational policy and governance requirements of all applicable frameworks simultaneously. The table below maps each framework to the principles it addresses. Subordinate standards provide framework-specific implementation requirements. |Framework / Regulation|Primary Control Families Addressed|Principles Satisfied| |---|---|---| |**[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)**|All 6 functions: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER|All 10 principles| |**[NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Rev 5**|PL, PM, RA, CA, AC, IA, SC, CM, SI, AU, IR, CP, PE, PS, SA, SR|All 10 principles| |**[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) Rev 3**|All 17 families (CUI environments)|Principles 1–7, 9–10| |**NIST RMF**|Steps 1–6 (Categorize through Monitor)|All 10 principles| |**NERC-CIP**|CIP-002 through CIP-014 (BES Cyber Systems)|Principles 1–7, 9–10| |**[CMMC](https://dodcio.defense.gov/CMMC/) Level 2**|All 110 practices across 14 domains|Principles 1–7, 9–10| |**[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC**|Change management, access, and availability controls|Principles 3, 4, 5, 7, 8| > **The CERG Regulatory Advantage** > > Organizations managing multiple regulatory obligations simultaneously, NERC-CIP, [CMMC](https://dodcio.defense.gov/CMMC/), and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), typically suffer from duplicated effort, conflicting timelines, and fragmented evidence. The CERG model centralizes policy and compliance management in Governance while Engineering and Risk produce compliance evidence as a byproduct of their daily work. One policy hierarchy. One evidence library. One compliance posture. --- ## 7. Exceptions and Risk Acceptance Exceptions to this policy are recognized as operationally necessary in specific, documented circumstances. An exception does not suspend a principle, it documents that a principle cannot be fully satisfied and defines the compensating controls and management accountability that apply in its place. ### 7.1 Exception Process - Any personnel may initiate an exception request through Cyber Governance using the organization's approved exception request process. - Exception requests shall document: the principle or requirement subject to exception, the business or operational justification, the affected systems, the proposed compensating controls, the risk owner, and the proposed exception duration. - Cyber Risk shall assess the risk associated with each exception and provide a written finding to support the approval decision. - Approval authority follows the canonical Risk Acceptance Authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Exceptions affecting BES Cyber Systems, CUI environments, or SOX-relevant systems may require additional escalation as defined in applicable regulatory deviation procedures. - Approved exceptions shall be entered into the risk register and tracked to expiration or remediation. Exceptions shall not be renewed without a new approval cycle. ### 7.2 Regulatory Deviations For regulated environments, exceptions with regulatory implications shall follow the applicable deviation or mitigation plan process in addition to this exception process: - **NERC-CIP deviations:** Governance initiates the CIP deviation documentation process. Compensating measures are implemented immediately. Regulatory notification is completed per applicable CIP standard timelines. - **[CMMC](https://dodcio.defense.gov/CMMC/) non-conformances:** Governance maintains the Plan of Action and Milestones (POA&M) in the System Security Plan (SSP). Open POA&M items are tracked to closure with leadership visibility. --- ## 8. Compliance and Enforcement Compliance with this policy is mandatory for all personnel within scope. Cyber Governance is responsible for tracking compliance posture and reporting material gaps to the CISO. ### 8.1 Compliance Monitoring - Cyber Governance shall maintain a master compliance calendar covering all applicable frameworks and conduct ongoing monitoring of the organization's posture against each. - Cyber Risk shall produce vulnerability and exposure data that informs the compliance posture assessment. - Cyber Engineering shall produce handoff documentation and pre-production confirmations that serve as compliance evidence for Engineering activities. - Evidence shall be collected as a byproduct of daily operations, not assembled retroactively in anticipation of audits. The evidence library shall be current, organized by control and regulatory citation, and retained per applicable framework requirements. ### 8.2 Non-Compliance Non-compliance with this policy shall be managed through the risk register and exception process defined in Section 7. Willful or repeated non-compliance by personnel shall be referred to Human Resources and may result in disciplinary action up to and including termination. Non-compliance findings identified by external regulators or auditors shall be escalated to the CISO immediately and tracked through the Governance risk register. The CISO shall determine whether escalation to executive leadership or the board is required. --- ## 9. Policy Review and Maintenance This policy shall be reviewed annually by Cyber Governance and updated as needed to reflect changes in the threat environment, organizational structure, or applicable regulatory requirements. This policy shall also be reviewed and updated upon: material changes to applicable regulations, significant organizational changes affecting scope, a significant security incident that reveals a gap in foundational principles, or direction from the CISO or executive leadership. Proposed updates shall be reviewed by Cyber Engineering and Cyber Risk to ensure operational practicability before submission for CISO approval. Approved revisions shall be version-controlled and distributed to all personnel with compliance obligations under this policy. ### 9.1 Document History |Version|Date|Summary|Author / Approver| |---|---|---|---| |1.0|2026-05-01|Initial release. Establishes the ten foundational principles, the CERG operating model, the canonical definitions (including DISH, PPR, POA&M, SSP, Executive Sponsor), and the policy hierarchy. Subordinate standards, procedures, plans, and templates derive from this policy.|CISO| --- ## 10. Related Documents The authoritative inventory, IDs, owners, status, and deferred / planned artifacts is maintained in [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) Document Catalog and Naming Convention. The summary below reflects the V1 library. ### 10.1 Cross-Cutting Instruments | Document | ID | Owner | | --- | --- | --- | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Cyber Governance | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Cyber Governance | | Metrics, Dashboard, and CISO/Board Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Cyber Governance | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | CISO | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Cyber Governance | | Compliance Matrix | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) | Cyber Governance | | Risk Taxonomy | [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) | Cyber Risk | | CERG Framework (narrative) | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | CISO | ### 10.2 Standards | Document | ID | Owner | | --- | --- | --- | | IT (Hosted, Cloud, and SaaS) Security Standard | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Cyber Governance | | Grid Control Systems Security Standard | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Cyber Governance | | CUI Handling Standard | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | Cyber Governance | | Access Management Standard | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Cyber Governance | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Cyber Engineering | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Cyber Risk | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Cyber Engineering | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Cyber Engineering | ### 10.3 Procedures, Plans, and Templates | Document | ID | Owner | | --- | --- | --- | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Cyber Risk | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Cyber Governance | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Cyber Engineering | | Access Management Runbook | [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Cyber Engineering | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Cyber Risk | | Adversarial Validation Procedure | [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Cyber Risk | | Incident Response Plan | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Standing IR team | | CUI / CMMC Operational Package | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | Cyber Governance | | NERC-CIP Operational Package | [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | Cyber Governance | | SOX ITGC Operational Package | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | Cyber Governance | | Risk Register Templates and Reporting | [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Cyber Governance | ### 10.4 Workforce Architecture and Operational Flows The following documents extend this policy into workforce management and cross-pillar operations. They are additive — they do not amend or supersede the principles in §4. | Document | ID | Owner | | --- | --- | --- | | Job Families Overview | [`CERG-GOV-JF-001`](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) | Governance Pillar Leader (Policy & Standards) | | NICE Workforce Framework Crosswalk | [`CERG-GOV-JF-002`](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | Governance Pillar Leader (Policy & Standards) | | Cross-Pillar Operational Flows | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Governance Pillar Leader | | Per-Role Job Descriptions (27 documents) | See [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) for index | Pillar Leaders (delegated per family) | | Machine-Readable Specifications | See [`machine-readable/METADATA.yaml`](../machine-readable/METADATA.yaml) | Governance Pillar Leader (Document Control) | --- ## 11. Document Control | Field | Value | |---|---| | **Document ID** | CERG-POL-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Chief Information Security Officer | | **Effective Date** | 2026-05-01 | | **Review Cycle** | Quarterly / Upon Significant Change | | **Next Scheduled Review** | 2027-05-01 | | **Frameworks** | NIST CSF 2.0; NIST 800-53r5; NIST 800-171r3; NIST RMF | | **Regulations** | NERC-CIP; CMMC Level 2; SOX ITGC | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-01 | CISO | Initial release. Establishes the ten foundational principles, CERG operating model, definitions, and policy hierarchy. | | 1.21 | 2026-05-22 | CISO | Updated framework references and regulatory alignment. | ### Review Triggers - Material change to applicable regulations - Significant organizational change affecting scope - Significant security incident revealing a policy gap - Direction from the CISO or executive leadership ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | CERG Operating Model | [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | Operating model detail | | CERG Framework | [CERG-GOV-FRM-001](CERG-GOV-FRM-001_CERG_Framework.md) | Narrative framework | | Document Catalog | [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Master document inventory | | Risk Management Framework | [CERG-GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk lifecycle | --- ## CERG Risk Management Framework | | | |---|---| | **Document ID** | CERG-GOV-RMF-001 | | **Version** | 1.33 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - CERG Cybersecurity Policy | | **Review Cycle** | Annual; triggered by significant regulatory change or organizational change | | **Frameworks** | NIST SP 800-37 (RMF); NIST SP 800-53r5; NIST CSF 2.0 | | **Regulations** | NERC-CIP (CIP-005, CIP-007, CIP-010); CMMC L2; SOX ITGC | | **Environments** | All in-scope environments: IT, OT, Cloud, CUI | > *A NIST-grounded, operationally adaptive risk management framework designed for IT and OT environments across CMMC, NERC-CIP, and SOX.* --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Framework Architecture](#2-framework-architecture) 3. [Phase 1, Categorize](#3-phase-1--categorize) 4. [Phase 2, Select](#4-phase-2--select) 5. [Phase 3, Implement](#5-phase-3--implement) 6. [Phase 4, Assess](#6-phase-4--assess) 7. [Phase 5, Authorize](#7-phase-5--authorize) 8. [Phase 6, Monitor](#8-phase-6--monitor) 9. [Risk Register and Risk Treatment](#9-risk-register-and-risk-treatment) 10. [IT/OT Risk Management Considerations](#10-itot-risk-management-considerations) 11. [Regulatory Alignment Quick Reference](#11-regulatory-alignment-quick-reference) 12. [Risk Appetite Calibration](#12-risk-appetite-calibration) 13. [Document Control and Review](#13-document-control-and-review) --- ## 1. Purpose and Scope The CERG Risk Management Framework (CERG-RMF) defines how CERG, the Cyber Engineering, Risk, and Governance function, identifies, assesses, treats, and monitors cybersecurity risk across the enterprise. It is the connective tissue between the three CERG pillars and the foundational document that gives every risk decision a shared vocabulary, a shared process, and a clear owner. This framework is purpose-built to: - Align with NIST RMF Steps 1–6 (Categorize, Select, Implement, Assess, Authorize, Monitor) while making each step operationally practical within CERG's three-pillar model. - Satisfy the risk management requirements of [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (Adaptive tier), [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Rev 5, [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) Rev 3, [CMMC](https://dodcio.defense.gov/CMMC/) Level 2, NERC-CIP, and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC simultaneously. - Apply equally to IT and OT environments, accounting for the operational availability constraints and extended patch windows common in industrial and grid-connected systems. - Scale from a 5-person team to a 500-person organization without requiring structural changes. > **Design Intent** > > Risk management in CERG is not a periodic checkbox exercise. It is a continuous, adaptive cycle, one that feeds intelligence back into Engineering, drives accountability through Governance, and produces a risk posture the CISO can defend to regulators, auditors, and the board at any point in time. --- ## 2. Framework Architecture ### 2.1 The CERG-RMF Cycle The CERG Risk Management Framework operates as a continuous cycle, not a linear waterfall. Each phase feeds the next, and intelligence gathered in later phases (Monitor, Assess) loops back to update decisions made in earlier ones (Categorize, Select). This is the structural characteristic that distinguishes an Adaptive-tier program from a Repeatable one. The six phases map directly to the NIST RMF, with CERG pillar ownership assigned at each step: | Phase | NIST RMF Step | CERG Primary Owner | Supporting Pillars | | ------------- | ------------------- | ------------------ | ------------------ | | 1. Categorize | Step 1 - Categorize | Governance | Engineering, Risk | | 2. Select | Step 2 - Select | Governance | Engineering | | 3. Implement | Step 3 - Implement | Engineering | Governance | | 4. Assess | Step 4 - Assess | Risk | Governance | | 5. Authorize | Step 5 - Authorize | Governance | Risk, Engineering | | 6. Monitor | Step 6 - Monitor | Risk + Governance | Engineering | #### Phase RACI Sub-Matrices The following RACI sub-matrices resolve pillar ownership ambiguity for specific activities within each phase. **R** = Responsible (does the work), **A** = Accountable (owns the outcome — one per row), **C** = Consulted (provides input before decision), **I** = Informed (notified after decision). ##### Phase 1: Categorize — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | System impact-level determination (CIA) | R | C | I | | Regulatory scope declaration (BES/CUI/SOX) | A/R | C | C | | Asset inventory handoff from Engineering | I | R | A | | Data classification mapping | R | C | C | | System Categorization Register maintenance | A/R | I | I | ##### Phase 2: Select — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | Baseline control selection per impact level | A/R | C | I | | Overlay identification (CUI/BES/SOX/etc.) | A/R | C | C | | Tailoring and compensating control approval | A | R | C | | Exception/Deviation scoping | A | R | C | | Control selection documentation for SSP | A/R | C | I | ##### Phase 3: Implement — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | Baseline design and configuration | C | A/R | I | | Control implementation | I | A/R | C | | Implementation evidence collection | C | R | A | | Handoff package preparation | C | A/R | C | | Pre-production security review | C | R | A | ##### Phase 4: Assess — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | Vulnerability scanning and coverage | I | C | A/R | | Penetration testing coordination | I | C | A/R | | Control effectiveness testing | C | C | A/R | | Finding validation and prioritization | I | R | A | | Risk assessment report production | C | I | A/R | ##### Phase 5: Authorize — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | Authorization package assembly | A/R | C | C | | POA&M compilation and tracking | A/R | I | C | | CISO recommendation preparation | A | C | R | | Business-owner acceptance coordination | A/R | I | I | | Authorization letter and recordkeeping | A/R | I | I | ##### Phase 6: Monitor — RACI | Activity | Governance | Engineering | Risk | |----------|-----------|-------------|------| | Continuous vulnerability monitoring | I | C | A/R | | Configuration drift detection and remediation | I | A/R | C | | Threat intelligence ingestion and analysis | I | I | A/R | | Risk register updates and review | A/R | C | R | | Control effectiveness re-assessment | A | C | R | | Compliance calendar execution | A/R | I | I | ### 2.2 [NIST CSF 2.0](https://www.nist.gov/cyberframework) Function Mapping [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) defines six functions. The CERG-RMF operationalizes all six within the risk cycle: | [CSF](https://www.nist.gov/cyberframework) Function | CERG-RMF Phase(s) | What CERG Does | |---|---|---| | **GOVERN** | Categorize, Authorize | Sets risk strategy, risk appetite, and accountability structures. Maintains policy hierarchy that governs all risk decisions. | | **IDENTIFY** | Categorize, Assess | Maintains asset inventories and system categorization. Conducts risk assessments, threat modeling, and vendor risk reviews. | | **PROTECT** | Select, Implement | Engineering designs and deploys protective controls per selected baselines. Governance sets the standard; Risk validates effectiveness. | | **DETECT** | Monitor, Assess | Risk operates vulnerability scanning, threat intelligence, and anomaly detection. Feeds findings to IR and Governance continuously. | | **RESPOND** | Monitor (IR hand-off) | Risk provides threat context during incidents. Governance owns playbook library and post-incident documentation. | | **RECOVER** | Monitor (lessons learned) | Governance captures lessons learned and drives improvement tracking. Engineering supports architectural changes post-incident. | --- ## 3. Phase 1: Categorize ### 3.1 Objective Categorization establishes the impact level of each system and data type, the foundation for every subsequent risk decision. A system that is improperly categorized will be under-controlled or over-controlled; neither outcome is acceptable. ### 3.2 What Gets Categorized - All information systems and technology assets (IT and OT) that store, process, or transmit organizational data or perform operational functions. - Data types by confidentiality, integrity, and availability (CIA) impact: Low, Medium, or High, per FIPS 199 / [NIST 800-60](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final). - Operational Technology systems are categorized with additional consideration for Safety, Reliability, and Continuity impacts, recognizing that an OT system failure may carry consequences beyond information loss. > **OT Categorization Note** > > For OT environments, including BES Cyber Systems under NERC-CIP and ICS/SCADA systems in manufacturing or utilities, availability and integrity are typically the dominant impact categories. Confidentiality, while important, is often secondary to the consequences of a system outage or process manipulation. Categorization must reflect this reality, and control selection must weight accordingly. ### 3.3 CERG Roles in Categorization | Pillar | Categorization Responsibility | |---|---| | **Governance** | Leads the categorization process. Maintains the system categorization register. Ensures regulatory designations (BES Cyber System, CUI scope, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) scope) are documented and current. Coordinates annual review. | | **Engineering** | Provides technical input on system function, data flows, interconnections, and dependencies. Produces or confirms asset documentation at project handoff. | | **Risk** | Validates asset inventory completeness via scan coverage. Identifies systems that may be missing from the register. Contributes threat context to impact analysis. | ### 3.4 Categorization Outputs - **System Categorization Register**: master list of all in-scope systems with CIA impact ratings, regulatory designations, and assigned asset owners. - **Data Classification Map**: inventory of data types by sensitivity level, mapped to the systems that handle them. - **Regulatory Scope Declarations**: explicit documentation of which systems are in-scope for NERC-CIP (BES/EACMS/PACS), [CMMC](https://dodcio.defense.gov/CMMC/) (CUI enclave), and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC. ### 3.5 Regulatory Alignment: Categorize | Framework | Categorization Requirement | CERG Satisfies Via | |---|---|---| | NIST RMF | Step 1: Categorize the system using FIPS 199 / [NIST 800-60](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final) | System Categorization Register; CIA impact ratings per asset | | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) | RA-2: Security Categorization | Governance-maintained categorization register reviewed annually | | NERC-CIP | CIP-002: BES Cyber System identification and categorization (High/Medium/Low) | Governance leads CIP-002 process; Engineering validates connectivity; Risk confirms inventory | | [CMMC](https://dodcio.defense.gov/CMMC/) | All 14 domains require defined CUI scope | CUI enclave declaration maintained by Governance; boundary confirmed by Engineering | | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) | ITGC scoping: identify systems that support financial reporting | Governance maintains [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC system register in coordination with Finance and Internal Audit | --- ## 4. Phase 2: Select ### 4.1 Objective Control selection translates categorization outputs into a tailored set of security controls appropriate to the system's impact level, operating environment (IT vs OT), and applicable regulatory requirements. Governance leads selection; Engineering translates selected controls into technical implementation requirements. ### 4.2 Control Baseline Structure CERG uses a layered baseline model. Every system inherits the Organizational Baseline. Systems with elevated categorization or regulatory scope inherit additional overlay controls: | Baseline Layer | Applies To | Primary Source | |---|---|---| | **Organizational Baseline** | All systems | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Rev 5 Moderate baseline; [NIST CSF 2.0](https://www.nist.gov/cyberframework) Subcategories | | **High Impact Overlay** | Systems with any High CIA impact rating | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) High baseline additions | | **CUI Overlay** | Systems handling Controlled Unclassified Information | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) Rev 3 | | **BES Overlay** | BES Cyber Systems, EACMs, PACSs | NERC-CIP CIP-002 through CIP-014 | | **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC Overlay** | Systems supporting financial reporting | COSO/ITGC: Change management, access, availability | | **OT Safety Overlay** | ICS/SCADA with safety implications | IEC 62443 + [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) supplemental controls | > **The Overlay Principle** > > Overlays do not restart the control selection process, they add to the organizational baseline. A system in both the CUI scope and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) scope carries the organizational baseline plus both applicable overlays. Governance tracks the combined control set per system; Engineering implements it. This prevents the "compliance tunnel vision" problem where teams optimize for one framework and inadvertently create gaps in another. ### 4.3 Tailoring and Scoping Not every control applies equally to every system. CERG's tailoring process allows for three types of adjustments, all of which require documentation and, above a threshold, CISO or Risk approval: | Tailoring Action | Definition | Approval Required | |---|---|---| | **Compensating Control** | An alternative control that meets the intent of the baseline control when the standard control cannot be implemented (common in OT environments) | Risk assessment + Risk Pillar Leader approval | | **Control Enhancement** | Additional control implementation above baseline, based on threat intelligence or risk assessment findings | Engineering + Governance alignment | | **Exception / Deviation** | Documented acknowledgment that a control cannot be satisfied; requires compensating controls and risk acceptance | Per the canonical Risk Acceptance Authority table in [§9.7 Risk Acceptance Authority](#97-risk-acceptance-authority-canonical) | --- ## 5. Phase 3: Implement ### 5.1 Objective Implementation translates selected controls into working technical and administrative safeguards. In CERG, implementation is Engineering's domain, but it is not Engineering's burden alone. Governance provides the standard; Risk validates the result. ### 5.2 Engineering's Implementation Model Cyber Engineering operates as an internal consulting function. Engineers embed with IT and business project teams early, before architecture decisions are locked, and ensure that security controls are designed in, not bolted on after the fact. | Project Stage | Engineering Role | CERG-RMF Output | |---|---|---| | **Concept / Requirements** | Engage at business requirements stage. Identify regulatory scope and control obligations. Flag OT safety considerations early. | Preliminary security requirements documented in project charter. | | **Design / Architecture** | Review proposed architecture. Validate that selected controls are achievable in the design. Identify gaps and drive remediation before build begins. | Security architecture review (SAR) findings; control gap list. | | **Build / Configure** | Provide hands-on implementation support. Produce or validate configuration baselines. Document control implementation for evidence library. | Configuration baselines; implementation records for Governance evidence library. | | **Pre-Production** | Coordinate pre-production Risk assessment (vulnerability scan, architecture review). Confirm open findings are remediated or risk-accepted. | Pre-production sign-off; open risk items transferred to risk register. | | **Production Handoff** | Produce handoff documentation: asset registration, baseline, control mapping, open risks. Transfer ongoing oversight to Risk and Governance. | Handoff package; asset added to categorization register. | ### 5.3 Implementation Standards Engineering implements controls to the following baselines, maintained as living standards by Governance: - **CIS Benchmarks** (Level 1 minimum, Level 2 for High-impact and BES systems) for server, endpoint, and network device hardening. - **[NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final)** supplemental guidance for OT and ICS system hardening, recognizing that CIS benchmarks may not directly apply to industrial control systems. - **Organizational configuration baselines** maintained per platform class (Windows Server, Linux, network infrastructure, cloud, OT/ICS), version-controlled by Governance. - **Zero-trust architecture principles** for network segmentation, identity verification, and least-privilege access, applicable to both IT and OT network boundaries. > **OT Implementation Reality** > > In OT environments, "implement the control" and "deploy the patch" are not always immediately achievable. Operational availability requirements, vendor support limitations, and safety system constraints mean that some controls require compensating measures and extended implementation timelines. CERG's risk register and exception process exist precisely for this situation. Engineering documents the gap, Risk assesses the exposure, and Governance records the compensating controls and target remediation date. For NERC-CIP environments, this triggers the deviation and mitigation plan process. --- ## 6. Phase 4: Assess ### 6.1 Objective Assessment validates that implemented controls are working as intended. In CERG, assessment is Cyber Risk's core function, executed continuously through exposure management and threat intelligence, and periodically through structured security assessments and adversarial validation. ### 6.2 Assessment Portfolio | Assessment Type | Frequency | Pillar Owner | Primary Output | |---|---|---|---| | **Continuous Vulnerability Scanning** | Continuous (authenticated scan weekly; unauthenticated daily) | Risk | Prioritized finding register with SLA tracking; remediation evidence. | | **OT / ICS Vulnerability Assessment** | Quarterly minimum; OT-safe passive scanning methods | Risk + Engineering | OT-specific finding register; compensating control documentation for unpatchable findings. | | **Adversarial Validation - External Pen Test** | Annual minimum; after significant architecture changes | Risk (internal) / Third Party | Pen test report; findings tracked to closure with Engineering review. | | **Adversarial Validation - Internal Pen Test** | Annual minimum; includes lateral movement and privilege escalation testing | Risk | Internal pen test report; architecture remediation recommendations for Engineering. | | **Adversarial Validation - Purple Team** | Quarterly minimum for detection validation where detection engineering is in scope | Risk + Incident Response | Detection validation results; tuned analytics and control-improvement actions. | | **Adversarial Validation - OT / ICS Red Team** | Biennial minimum (or as required by NERC-CIP or contract) | Risk + Third Party | Red team report; OT-specific findings require CISO review before disclosure. | | **Vendor / Third-Party Risk Assessment** | At onboarding; annually for Critical vendors; triggered by incidents or contract changes | Risk | Vendor risk rating; contract risk terms; ongoing monitoring requirements. | | **Security Control Assessment (SCA)** | Annual; scope aligned to regulatory cycle | Risk + Governance | SCA report; POA&M updates; evidence for authorization decision. | | **Threat Intelligence Review** | Continuous ingestion; structured analysis weekly; strategic briefing monthly | Risk | Threat intel products: tactical (IOCs), operational (TTPs), strategic (threat landscape). | ### 6.3 Finding Severity and SLAs All findings from assessment activities are assigned a severity rating and a remediation SLA. Exceptions to SLAs require documented risk acceptance per the process in [§9.7 Risk Acceptance Authority](#97-risk-acceptance-authority-canonical). The authoritative remediation-SLA table lives in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5. The values published there govern every CERG-managed scan, adversarial validation, and assessment finding across IT, cloud, SaaS, and (with the BES schedule overlay) OT environments. Pillar dashboards and KRIs in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) measure compliance against PRC-VM-001's SLA values, not against a separate table. > **One Source of Truth** > > Earlier drafts of this document carried a parallel SLA table. That table has been retired so that there is exactly one place in the library where a remediation SLA can be changed. If you find a stale SLA citation in another document, the corrective action is to update the citing document to point at PRC-VM-001 , not to restate the values. --- ## 7. Phase 5: Authorize ### 7.1 Objective Authorization is a formal risk acceptance decision made by an accountable leader before a system is allowed to operate or continue operating. It is the point at which residual risk is explicitly acknowledged, owned, and documented. In CERG, Governance structures and manages the authorization process; the CISO is the primary Authorizing Official (AO) for the cybersecurity program. ### 7.2 Authorization Decision Types | Decision Type | When Applied | Authorizing Authority | |---|---|---| | **Authority to Operate (ATO)** | New systems entering production after pre-production assessment. Full ATO requires all High and Critical findings resolved or risk-accepted. | CISO (with Risk and Engineering concurrence) | | **Interim Authority to Operate (IATO)** | Systems with residual High findings that have documented compensating controls and an approved remediation timeline (maximum 90 days). OT systems with constrained patch windows may require IATO. | CISO; must include documented compensating controls and target full ATO date | | **Denial of Authorization (DATO)** | Systems where residual risk exceeds the organization's risk appetite and compensating controls are insufficient. System must be isolated or decommissioned. | CISO (mandatory notification to CEO and Board for business-critical systems) | | **Ongoing Authorization** | Systems with continuous monitoring in place that demonstrate consistent control effectiveness. Replaces periodic point-in-time reauthorization for mature, stable systems. | CISO with quarterly Risk and Governance attestation | ### 7.3 Authorization Package Contents Governance assembles the authorization package for CISO review. A complete package includes: - **System Security Plan (SSP)**: documents system boundary, categorization, control implementation status, and responsible parties. - **Risk Assessment Report (RAR)**: Risk-produced finding report from pre-authorization assessment activities. - **Plan of Action and Milestones (POA&M)**: documents all open findings with owners, compensating controls, and target remediation dates. - **Continuous Monitoring Strategy**: defines ongoing monitoring activities that will maintain risk visibility post-authorization. - **Regulatory Compliance Attestation**: Governance attestation that applicable regulatory controls are satisfied or that deviations are documented per regulatory process. > **Authorizing OT Systems** > > For OT and BES Cyber Systems, authorization must explicitly address operational continuity risk alongside cybersecurity risk. A finding that would result in DATO for an IT system (e.g., unpatched Critical vulnerability) may result in IATO for a BES system if immediate isolation would cause a reliability event. The NERC-CIP deviation and mitigation plan process must be initiated in parallel. The CISO coordinates with Operations leadership and, where required, the Reliability Coordinator. --- ## 8. Phase 6: Monitor ### 8.1 Objective Continuous monitoring is the phase that separates Adaptive-tier programs from Repeatable ones. It is not a periodic review, it is an always-on operational posture that keeps the organization's risk picture current, feeds intelligence back into earlier RMF phases, and provides the CISO with real-time awareness of the organization's exposure. ### 8.2 Monitoring Program Components | Component | Pillar Owner | Frequency | Output / Deliverable | |---|---|---|---| | Exposure scan coverage | Risk | Continuous | Updated finding register; SLA tracking dashboard; escalation alerts for Critical findings. | | Configuration drift detection | Risk + Engineering | Continuous (automated) | Drift alerts to Engineering; deviation from baseline triggers change management review. | | Threat intelligence ingestion | Risk | Continuous; structured analysis weekly | Tactical threat products (IOCs); operational advisories; strategic threat briefings for CISO. | | Risk register review | Governance | Monthly (full); weekly (high/critical items) | Updated risk register with treatment status; escalation to CISO for items approaching SLA. | | POA&M status tracking | Governance | Biweekly | POA&M status report; owner accountability communications; escalation for missed milestones. | | Control effectiveness review | Risk + Governance | Quarterly | Control testing results; evidence library updates; findings fed into next SCA cycle. | | Compliance calendar execution | Governance | Per regulatory schedule | Regulatory submissions, evidence packages, audit coordination, deviation filings. | | Vendor and supply chain monitoring | Risk | Continuous (automated); quarterly structured review | Vendor risk rating updates; notification of third-party breaches or advisories. | | CISO risk dashboard | Governance + Risk | Weekly refresh; real-time for Critical events | Executive risk posture summary; KRI trending; board-ready quarterly summary. | ### 8.3 Key Risk Indicators (KRIs) | KRI | Target | Owner | Escalation Trigger | |---|---|---|---| | Mean Time to Remediate - PPR (0-day) | ≤48 hours (Internet-facing) / ≤72 hours (internal) per [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5 | Risk | Any PPR finding past SLA | | Mean Time to Remediate - Critical | ≤3 days per [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5 | Risk | Any Critical past SLA without documented compensating control | | Mean Time to Remediate - High | ≤15 days per [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5 | Risk | Any High past SLA without approved exception | | Scan Coverage - IT | ≥98% of known assets | Risk | <95% coverage | | Scan Coverage - OT | ≥90% of known assets (passive methods) | Risk | <85% coverage | | Open Critical/High Findings | 0 Critical past SLA; <10 High past SLA | Risk + Governance | Any Critical past SLA; >10 High past SLA | | Risk Register Items Past Target Date | 0 items past target date | Governance | Any item >30 days past target; CISO briefing required if more than 3 items are past target at the monthly Risk Posture Review | | Policy Review Compliance | 100% of policies reviewed within defined cycle | Governance | Any policy >12 months since last review | | SSP / Authorization Currency | 100% of in-scope systems with current ATO/IATO | Governance | Any in-scope system without current authorization | | Vendor Risk Assessments Current | ≥95% of Critical vendors with current assessment | Risk | <90% triggers escalation | | Security Training Completion | ≥95% completion within defined window | Governance (coord w/ Awareness) | <90% completion triggers escalation to CISO | --- ## 9. Risk Register and Risk Treatment ### 9.1 The Risk Register The CERG Risk Register is the authoritative record of all identified, assessed, and tracked cybersecurity risks. It is owned by Governance, populated by Risk, and informed by Engineering. It is not a spreadsheet that lives on a network share, it is a living operational tool that drives accountability and informs every authorization decision. ### 9.2 Risk Statement Format (FAIR-Aligned) Every risk entered into the register is written in a single, consistent statement format derived from the FAIR (Factor Analysis of Information Risk) model. FAIR decomposes risk into a Loss Event Frequency (LEF) and a Loss Magnitude (LM); the CERG statement format makes both halves explicit so that every register entry can be reasoned about, compared, and rolled up the same way. **Canonical risk statement:** > *"[Threat community] using [threat action / vector] against [affected asset / scope] could result in [primary and secondary loss types] of [loss magnitude range], at an estimated frequency of [LEF range]."* **Components:** | Component | What It Captures | Examples | |---|---|---| | **Threat community** | Who or what is initiating the loss event (FAIR Threat Community). See §9.3. | Organized cybercriminal, nation-state, malicious insider, negligent insider, third-party supply chain | | **Threat action / vector** | How the loss event is initiated | Ransomware, credential stuffing, phishing, exploitation of unpatched CVE, lateral movement from compromised vendor | | **Affected asset / scope** | What is harmed and the scope of harm | The CUI enclave, a specific BES Cyber System, the SOX-relevant ERP, the corporate identity store | | **Loss types** | One or more of FAIR's six primary loss forms | Productivity, response, replacement, fines and judgments, competitive advantage, reputation | | **Loss magnitude range** | Expected loss as a calibrated range (PERT min / most likely / max) | $250K - $1.5M - $4M | | **LEF range** | Expected frequency the loss event occurs in a year (PERT min / most likely / max) | 0.05 - 0.15 - 0.4 (i.e., once every 2 to 20 years) | Risk statements that cannot be written in this form are not yet risks; they are observations or findings. Findings remain in the vulnerability or assessment register until they can be expressed in a complete loss-event scenario, at which point they are promoted to the Risk Register. ### 9.3 Threat Community Reference The FAIR Threat Community is the actor or natural force that initiates a loss event. The taxonomy below is the CERG default. Subordinate documents , particularly [`CERG Risk Taxonomy`](CERG-GOV-TAX-001_Risk_Taxonomy.md) , extend it with sector-specific actors (e.g., ICS-targeted APTs for OT). | Community | Examples | Primary Loss Forms | |---|---|---| | **Nation-state / APT** | State-aligned threat actors with strategic objectives (intellectual property, infrastructure pre-positioning) | Replacement, competitive advantage, response, reputation | | **Organized cybercriminal** | Financially motivated groups (ransomware, BEC, fraud) | Response, replacement, productivity, fines and judgments | | **Hacktivist** | Ideologically motivated; disruption and disclosure | Reputation, productivity, response | | **Malicious insider** | Authorized user acting against the organization | Replacement, competitive advantage, fines and judgments | | **Negligent insider** | Authorized user causing loss through error or policy violation | Productivity, response, fines and judgments | | **Third-party / supply chain** | Trusted vendor or service compromised, propagating to the organization | Response, productivity, fines and judgments | | **Non-malicious (environmental)** | Natural events, infrastructure failures, accidental conditions | Productivity, replacement, response | ### 9.4 Risk Register Data Elements | Field | Description | |---|---| | **Risk ID** | Unique identifier (format: CERG-RISK-YYYY-NNN) | | **Source** | How the risk was identified: vulnerability scan, pen test, threat intel, vendor assessment, audit, self-identification, or incident. | | **Affected System(s)** | System(s) or asset(s) associated with the risk, with regulatory designation (BES/CUI/SOX) noted. | | **Risk Statement** | The canonical FAIR-aligned statement per §9.2. | | **Threat Community** | Selected from §9.3 (one primary; additional secondaries permitted). | | **Threat Action / Vector** | How the loss event is initiated. | | **Loss Types** | One or more of: productivity, response, replacement, fines and judgments, competitive advantage, reputation. | | **Likelihood (LEF)** | Rated using the band table in §9.5; supported by a PERT range where calibration data exists. | | **Impact (LM)** | Rated using the band table in §9.5; supported by a PERT range where calibration data exists. | | **Overall Severity** | Composite severity rating per §9.5: Critical / High / Medium / Low / Informational. | | **Risk Owner** | Accountable leader (business unit or IT/OT operations) responsible for risk treatment decision. | | **Treatment Decision** | Remediate / Mitigate / Transfer / Accept - with documented rationale per §9.6. | | **Compensating Controls** | Controls in place that reduce exposure while the primary risk remains open. | | **Target Remediation Date** | Committed date for risk closure or next status review. | | **Approval** | Authority approving the treatment decision; date; reference to the canonical authority table at §9.7. | | **Status** | Approved | | **Regulatory Implication** | Whether the risk has regulatory reporting, deviation, or mitigation plan implications (NERC-CIP, CMMC, SOX). | ### 9.5 Likelihood, Impact, and Severity Bands CERG uses a 5x5 model: likelihood and impact are each rated 1-5, scored, and mapped to a severity band. The bands below are the canonical CERG model. Every CERG document that scores risk must produce the same severity rating as this table. **Likelihood (LEF) bands.** Calibrated as expected loss events per year. Tune the numeric ranges against your loss-event history; the band labels are fixed. | Score | Label | Annualized Frequency | |---|---|---| | 5 | Very High | >10 events / year | | 4 | High | 1 - 10 events / year | | 3 | Medium | 1 event / 1 - 10 years | | 2 | Low | 1 event / 10 - 100 years | | 1 | Very Low | <1 event / 100 years | **Impact (LM) bands.** Calibrated against organizational loss-magnitude reference points. The dollar bands below are preliminary defaults requiring organizational calibration; the Risk pillar lead refreshes them annually with Finance using revenue, insurance retention, downtime cost, and regulatory exposure as the basis. | Score | Label | Loss Magnitude (preliminary default requiring organizational calibration) | |---|---|---| | 5 | Catastrophic | >$10M single-event loss; material to financial statements; sustained reputation damage | | 4 | Major | $1M - $10M single-event loss; regulatory enforcement action; significant reputation damage | | 3 | Medium | $100K - $1M single-event loss; reportable to leadership; limited reputation impact | | 2 | Minor | $10K - $100K single-event loss; absorbed within normal operating costs | | 1 | Negligible | <$10K single-event loss; no leadership notification required | **Composite severity.** Likelihood score x Impact score = Severity score; mapped to band. | Severity Score | Severity Band | |---|---| | 20 - 25 | **Critical** | | 12 - 19 | **High** | | 6 - 11 | **Medium** | | 2 - 5 | **Low** | | 1 | **Informational** | **Exposure-management precedence.** This 5x5 risk score determines register severity and acceptance authority. It does not replace exposure-treatment clocks. When a vulnerability, KEV item, PPR-tier exposure, or other finding is governed by [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md), the PRC-VM classification and SLA are authoritative for remediation timing. Use the stricter outcome when risk score and exposure SLA point to different urgency. ### 9.6 Risk Treatment Options | Treatment | Definition | When Appropriate | CERG Process | |---|---|---|---| | **Remediate** | Eliminate the risk by removing the vulnerability, threat source, or exposure. | When technically feasible within a reasonable timeframe and at proportionate cost. | Engineering leads technical remediation. Risk verifies closure via rescan or retest. Governance closes the risk register item. | | **Mitigate** | Reduce the likelihood or impact of the risk to an acceptable level through compensating controls. | When full remediation is not immediately feasible (common in OT); when residual risk after mitigation falls within risk appetite. | Engineering implements compensating controls. Risk validates control effectiveness. Governance documents and tracks to eventual remediation. | | **Transfer** | Shift the financial impact of the risk through insurance or contractual liability provisions. | For risks where cyber insurance coverage is appropriate and available. | Governance coordinates with Legal/Finance for contract and insurance language. Risk quantifies the risk for insurance submission. | | **Accept** | Formally acknowledge and document the risk without further treatment, when residual risk falls within risk appetite. | For Low/Informational risks where cost of treatment exceeds the risk value; or when all other options have been exhausted and the risk owner is willing to own the consequence. | Requires documented approval at the authority level defined in §9.7. Risk provides a written risk finding. Governance records the acceptance in the risk register. The business owner accepts the residual risk — security does not accept business risk. | ### 9.7 Risk Acceptance Authority (Canonical) This table is the single source of truth for who may accept residual risk. Every other CERG document that references acceptance authority points at this section. Security can assess, recommend, document, validate compensating controls, and escalate. But the business owner owns the consequence. Risk acceptance requires a business risk owner at every level where business impact exists. The CISO approves on behalf of the cybersecurity program; the Business Owner or Executive Sponsor accepts on behalf of the business unit that bears the operational impact. | Residual Risk | Risk Role | Governance Role | Business Role | Acceptance By | Documentation | Default Max Duration | |---|---|---|---|---|---|---| | **Critical** | Signs finding; validates compensating controls; provides written risk assessment | Structures acceptance package; ensures regulatory notification; tracks conditions | **Executive Sponsor** accepts business consequence; Board notified at next cycle | **CISO + Executive Sponsor** | Risk assessment, compensating controls, business justification, target remediation date | **30 days**; renewal requires material change in treatment plan | | **High** | Signs finding; validates compensating controls; provides written risk assessment | Structures acceptance package; ensures conditions documented | **Business Owner** accepts business consequence | **CISO + Business Owner** | Risk assessment, compensating controls, business justification, target remediation date | **90 days**; renewal requires documented progress toward remediation | | **Medium** | Performs risk assessment; confirms residual risk level | Confirms exception conditions; documents acceptance in register | **Business Owner** accepts business consequence | **Business Owner + Pillar Leader or Governance Pillar Leader** | Risk assessment, compensating controls, target remediation date | **180 days**; renewal requires confirmation that conditions have not worsened | | **Low** | Confirms low residual risk (if needed) | Approves procedural exception; tracks in risk register | **Business Owner** owns local decision | **Business Owner + Risk Register Owner** | Brief justification; tracked in risk register | **365 days**; annual review at minimum | | **Informational** | N/A | Tracks in register; reports in quarterly trending | **No formal acceptance required** | Risk Register Owner | Tracked in risk register | Reviewed annually | > **Duration rule** > > The durations above are CERG defaults. If an environment-specific rule, regulatory package, POA&M, CIP deviation, contract, or procedure sets a shorter duration, the shortest applicable duration wins. > **Renewals** > > No acceptance renews automatically. An acceptance at any tier requires a fresh approval cycle at expiration. An acceptance renewed more than twice without movement on the treatment plan escalates one tier above the original approver. > **Role names** below match the canonical roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. If a role name disagrees with that roster, the roster wins. ### 9.7a Policy Exception vs. Risk Acceptance These are not the same thing. Collapsing them into one process creates confusion about who owns what. | Scenario | Type | Path | Owner | |----------|------|------|-------| | "We cannot meet password length because legacy system maxes at 12 characters" | **Policy / control exception** | Governance-owned exception workflow | Governance Pillar Leader | | "The legacy system is Internet-reachable, privileged, and has weak auth" | **Risk** | Risk-owned residual risk analysis | Risk Pillar Leader | | "We will isolate it, broker access, monitor sessions, and retire by Q3" | **Treatment** | Engineering + Risk | Engineering Pillar Leader | | "The VP of Operations accepts the residual risk until Q3" | **Business risk acceptance** | Business owner accepts per §9.7 | Business owner | **Governance** owns the exception workflow: when a control cannot be met, Governance determines whether the gap is a procedural exception (low risk, documented and tracked) or a risk event (requires Risk assessment). **Risk** owns residual risk analysis: when a gap creates material exposure, Risk quantifies it, validates compensating controls, and recommends treatment. **Business** owns the consequence: business leaders accept risk on systems they own, because they own the operational impact. Use separate artifacts for the two paths. A policy or control exception uses the [Security Exception Request Form](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) and stays in the exception register with a linked risk entry when residual exposure exists. A residual-risk acceptance uses the [Risk Acceptance Request Form](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) and follows the authority table in §9.7. [`CERG-TMPL-RM-003`](../templates/CERG-TMPL-RM-003_Risk_Acceptance_Memo_Template.md) may be used only as a lightweight supporting memo or attachment to `TMPL-RM-004`; it does not create a separate acceptance path. ### 9.8 Risk Appetite and Tolerance CERG's risk appetite is expressed in two complementary ways: a qualitative posture statement that informs every treatment decision, and a quantitative loss-exposure tolerance that anchors acceptance decisions at the Critical and High bands. The CISO maintains both; the Board reviews appetite annually. **Qualitative posture.** CERG operates under a "Yes, And…" orientation: the default response to a business request is "yes, and here are the conditions that make this safe." Reflexive refusal is not an acceptable risk management strategy. At the same time, three categories receive a deliberately low appetite: | Category | Appetite | |---|---| | Loss of life, physical safety, or grid reliability | **None.** Any credible scenario triggers immediate Critical treatment regardless of LEF or LM scoring. | | Material loss of CUI or DFARS-regulated data | **Very Low.** Treatment defaults to Remediate; Accept requires CISO + Executive Sponsor + 90-day re-review. | | Material misstatement of SOX-relevant financial data caused by ITGC failure | **Very Low.** Treatment defaults to Remediate; Accept requires CISO + Executive Sponsor + Audit Committee notification. | | Operational disruption to enterprise IT services | Medium. Treatment chosen on a cost / business value basis. | | Loss of low-sensitivity, broadly available data | Higher. Acceptance is appropriate where treatment cost exceeds loss magnitude. | **Quantitative tolerance (preliminary calibration).** Annualized Loss Exposure (ALE = LEF x LM) is summed across the open risk register quarterly. The bands below are preliminary values calibrated for a mid-market organization ($500M-2B revenue, moderate regulatory exposure). The CISO updates these in coordination with the CFO at the next CERG/Finance joint review — see §9.8.1 for the calibration workbook. | Posture Indicator | Value (Preliminary) | Recommended Range by Org Size | Action | |---|---|---|---| | Total open ALE (Critical + High) | <$5M | Small (<$100M rev): <$500K · Mid: <$5M · Large: <$25M | Within appetite; continue normal monitoring | | Total open ALE (Critical + High) | $5M - $15M | Small: $500K-$2M · Mid: $5M-$15M · Large: $25M-$100M | Within tolerance; CISO briefs Cyber Oversight Group monthly | | Total open ALE (Critical + High) | >$15M | Small: >$2M · Mid: >$15M · Large: >$100M | Above tolerance; CISO briefs Board at the next cycle; mandatory treatment plan within 60 days | | Single-risk ALE | >$2M | Small: >$250K · Mid: >$2M · Large: >$10M | Mandatory CISO review at acceptance; auto-escalates to High at minimum | > **Calibration is the work.** Values above are preliminary defaults for a mid-market organization; they are not approved appetites until Finance signs the calibration. The pattern — qualitative posture per category plus quantitative ALE bands — is the part that does not change. See §9.8.1 for the full calibration workbook with revenue-gated scaling. #### 9.8.1 Risk Appetite Calibration Workbook The risk appetite values in §9.8 are preliminary defaults calibrated to a mid-market organization ($500M-2B revenue). Calibrate them to your organization using the prompts below. Document the calibrated values in your Decision Log (IMP-002 §4). **How to read the preliminary values:** The bands are derived from a simple ratio of revenue × risk factor. A small organization ($100M revenue) would set tolerance at ~5% of revenue for single-risk ALE bands; a large enterprise ($5B+) at ~2%. The mid-market defaults below use the midpoint of this range. The Risk pillar lead recalculates these annually when revenue is updated. **Financial Calibration Inputs:** - Annual revenue: $_________ - Critical service downtime cost (per hour): $_________ - Regulatory fine exposure (per incident): $_________ - Cyber insurance retention: $_________ - Cyber insurance coverage limit: $_________ - Board reporting materiality threshold: $_________ **Operational Calibration Inputs:** - Maximum tolerable downtime for Tier 1 systems: _________ hours - Maximum data loss tolerance (RPO): _________ hours - Customer notification threshold: _________ records affected - Operational safety threshold: [Describe safety impact that triggers Critical classification] **Output — Calibrated Values:** | Band | Mid-Market Preliminary | Your Calibrated Value | |------|-----------------------|-----------------------| | Total open ALE — OK | <$5M | $_________ | | Total open ALE — Caution | $5M - $15M | $_________ - $_________ | | Total open ALE — Escalate | >$15M | >$_________ | | Single-risk ALE — CISO review | >$2M | >$_________ | | Catastrophic single-event LM | >$10M | >$_________ | | Major single-event LM | $1M - $10M | $_________ - $_________ | | Medium single-event LM | $100K - $1M | $_________ - $_________ | | Minor single-event LM | $10K - $100K | $_________ - $_________ | | Negligible LM | <$10K | <$_________ | > **Fallback:** If you cannot calibrate these values, document in the Decision Log that risk acceptance uses qualitative judgment until calibration occurs. Do not make acceptance decisions against uncalibrated values. #### 9.8.2 Risk Acceptance Is Not Remediation > **Risk acceptance does not make the risk disappear.** It is a deliberate decision to tolerate a known risk under specific conditions for a defined period. It does not: > > - Make the finding disappear from the risk register > - Reset the remediation SLA without documented approval > - Transfer accountability from the business owner to security > - Satisfy a regulatory requirement by itself > - Excuse the organization from monitoring the risk > > **A risk acceptance that is not reviewed on cadence is not a treatment — it is neglect.** Every acceptance must have: a named business owner, a documented rationale, compensating controls where applicable, an expiration date, and a review commitment. ### 9.9 Worked Example: Risk Register Entry The example below shows a single register entry written in the canonical format. Fields not relevant to the scenario are marked n/a; everything else is filled in as it would appear in the live register. ``` Risk ID: CERG-RISK-2026-0142 Source: Pre-production assessment - substation modernization project Affected System(s): Substation Gateway "EAST-SS-04" (BES Cyber System, Medium Impact); vendor remote-access path through the EACMS jump server. Risk Statement: Organized cybercriminal threat communities using ransomware delivered via a compromised vendor remote-access path against the EAST-SS-04 BES Cyber System could result in productivity loss, response costs, replacement costs, and NERC reliability fines of $1.2M - $3.5M - $8.0M, at an estimated frequency of 0.05 - 0.12 - 0.25 events per year. Threat Community: Organized cybercriminal (primary); third-party / supply chain (secondary) Threat Action / Vector: Ransomware via compromised vendor remote-access path Loss Types: Productivity, response, replacement, fines and judgments Likelihood (LEF): Score 3 (Medium) - 0.12 events / year most-likely Impact (LM): Score 4 (Major) - $3.5M most-likely Overall Severity: Score 12 - HIGH Risk Owner: VP, Transmission Operations Treatment Decision: Mitigate (vendor MFA hardening + session brokering + read-only engineering connection until vendor remediation completes) Compensating Controls: PAM session recording on EACMS; deny-by-default on inbound vendor address space outside maintenance windows; passive OT detection on E/W traffic from EACMS Target Remediation Date: 2026-09-30 Approval: CISO per §9.7 (HIGH severity); acceptance recorded 2026-05-15 Status: In Remediation Regulatory Implication: NERC-CIP CIP-005 R2, CIP-013 supply chain; CIP deviation not required because compensating controls maintain ESP integrity. ``` --- ### 9.10 Event-Driven Re-Assessment Triggers An accepted risk is automatically re-opened for re-assessment when any of the following trigger events occur. Re-assessment follows the full treatment evaluation process in §9.6 and may result in a changed severity score, a new treatment strategy, or re-confirmation of the existing acceptance. | Trigger Event | Action | Rationale | |--------------|--------|-----------| | CVE added to CISA KEV catalog affecting the accepted vulnerability | Immediate re-score; treat as Critical if exploitation is active | KEV listing signals active exploitation; accepted risk tolerance is invalidated | | Exploit observed in the wild for the accepted vulnerability (per Threat Intelligence) | Re-score within 5 business days; re-assess treatment urgency | Threat landscape has materially changed since acceptance | | Affected asset changes criticality tier | Re-score within 30 days | Asset criticality is an input to the risk score; a tier change shifts the calculation | | Regulatory change materially alters compliance impact | Re-score within 30 days of regulatory effective date | Regulatory non-compliance may make the risk unacceptable under any treatment | | Related incident occurs involving the accepted vulnerability or affected asset | Immediate re-score as part of F-06 post-incident review | An incident proves the risk was underestimated | | Acceptance renewed more than twice without treatment progress | Escalate one approval tier above original approver (per §9.7); create Finding Record | Repeated renewal without treatment signals acceptance complacency | | Scenario pressure-test (per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)) reveals an unbroken kill-chain on an asset in the scenario blast radius | Open Finding Record (F-04); re-score every register risk touching the affected crown jewel | A top-down test proved a chain the bottom-up register did not surface | The Risk Register Owner is responsible for monitoring these triggers. Threat Intelligence (TI-001) supplies the exploit observation feed. The Evidence Librarian monitors KEV catalog changes. Governance Pillar Leader maintains the regulatory change watch. The Risk Pillar Leader supplies the scenario pressure-test feed per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md). --- ## 10. IT/OT Risk Management Considerations ### 10.1 Why OT Requires a Different Lens IT and OT environments share the same fundamental risk equation - threats, vulnerabilities, and consequences - but OT environments introduce constraints that require deliberate adaptation of standard risk management practices. Availability is not a configuration preference in a power grid or a manufacturing line; it is a safety and reliability imperative that can carry regulatory, legal, and physical-world consequences. CERG's RMF is designed from the ground up to respect this reality. OT-specific adaptations are documented below. | RMF Phase | Standard IT Approach | OT Adaptation | |---|---|---| | **Categorize** | CIA-based impact ratings per FIPS 199 | Add Safety and Reliability as explicit impact dimensions. BES Cyber Systems classified per CIP-002 High/Medium/Low impact in addition to FIPS 199 ratings. | | **Select** | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Moderate/High baseline | Apply OT Safety Overlay: IEC 62443 practices; [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) supplemental controls; vendor-specific hardening where CIS benchmarks don't apply. | | **Implement** | Patch and configure to baseline | OT patch windows are defined by operational schedules (planned outages, maintenance windows). Compensating controls bridge the gap. No emergency patching without operations and safety sign-off. | | **Assess** | Authenticated vulnerability scans; penetration testing | OT scans use passive/OT-safe methods to avoid disrupting process operations. Active scanning requires operations coordination and maintenance window scheduling. | | **Authorize** | ATO/IATO per residual risk | OT authorization explicitly documents operational availability risk alongside cybersecurity risk. NERC-CIP deviation process runs in parallel for BES systems. | | **Monitor** | Continuous automated monitoring | OT monitoring uses passive network visibility tools (e.g., Dragos, Claroty, Nozomi). Change management is stricter; unauthorized changes carry safety implications. | > **The OT Risk Principle** > > An unpatched vulnerability in a BES Cyber System is a real risk. An unplanned outage of a BES Cyber System is also a real risk - one that carries NERC reliability implications, potential regulatory fines, and public safety consequences. CERG's risk management process treats both risks seriously and documents the tradeoff explicitly. The CISO owns the cybersecurity risk. Operations leadership owns the reliability risk. Both sign the authorization. --- ## 11. Regulatory Alignment Quick Reference The CERG-RMF satisfies the risk management requirements of all applicable frameworks. The table below maps each framework's risk-specific requirements to the CERG-RMF phase and CERG pillar that addresses them. | Framework | Risk Management Requirement | CERG-RMF Phase | Pillar | |---|---|---|---| | **NIST RMF** | Steps 1-6: Categorize, Select, Implement, Assess, Authorize, Monitor | All phases | All pillars | | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | GOVERN: Risk strategy, risk appetite, accountability structures | Phase 5 (Authorize) | Governance | | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | IDENTIFY: Asset management, risk assessment, improvement | Phases 1, 4, 6 | Risk + Governance | | **[NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | RA-2, RA-3, RA-5, CA-2, CA-5, CA-7 (Categorization, Risk Assessment, Vuln Monitoring, Control Assessments, POA&M, Continuous Monitoring) | All phases | Risk + Governance | | **[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) Rev 3** | 03.11 Risk Assessment family; 03.12 Security Assessment family; all documentation requirements | Phases 1, 4, 5, 6 | Risk + Governance | | **NERC-CIP** | CIP-002: BES Cyber System categorization; CIP-007 R2: Patch management cadence; CIP-010 R3: Vulnerability assessments; deviation and mitigation plan process | Phases 1, 4, 6 | Governance + Risk | | **CMMC Level 2** | RA.L2-3.11.1, RA.L2-3.11.2; CA.L2-3.12.1; all 110 practices documented in SSP and POA&M | Phases 1, 4, 5, 6 | Risk + Governance | | **SOX ITGC** | Change management controls; access controls; IT availability controls; ITGC control assessment and evidence | Phases 4, 5, 6 | Governance + Engineering | --- ## 12. Risk Appetite Calibration Risk appetite is not a once-and-done statement. An Adaptive organization formally recalibrates its risk appetite based on business changes, incident experience, threat landscape shifts, and regulatory changes. This section defines when, how, and with what inputs the CISO and leadership recalibrate the organization's risk appetite. ### 12.1 Calibration Cadence Risk appetite is reviewed: - **Annually**, aligned with the annual planning cycle and the CISO Risk and Posture Review (per GOV-CAL-001) - **When triggered** by any of the following events: - A major incident (Critical severity, or any incident requiring board notification) - Merger, acquisition, or divestiture activity - Entry into a new market, product line, or regulated domain - A material regulatory framework change (new regulation, major amendment, new enforcement posture) - CISO or board request - A peer benchmarking finding (PRC-TI-001 Section 10.2) that shows a significant gap from sector norms ### 12.2 Inputs to the Review The annual risk appetite review is prepared by the Governance Pillar Leader with inputs from all pillars. The review package contains: 1. **Incident history (trailing 12 months):** frequency by severity, root cause clusters, control failures identified (per CEF-001), and incident trends 2. **Threat landscape assessment:** from the most recent quarterly assessment (PRC-TI-001 Section 9.1), including top threat actors, TTP changes, and exploited vulnerabilities 3. **Business strategy changes:** new markets, products, technologies, partnerships, or organizational changes from the executive planning cycle 4. **Regulatory changes:** new or modified compliance obligations, enforcement trends, upcoming assessment or audit milestones 5. **Peer and industry incident data:** from external incident learning (PRC-TI-001 Section 10.3) and peer benchmarking (PRC-TI-001 Section 10.2) 6. **Current risk register state:** risk concentration by pillar, OU, and control family; treatment effectiveness rate (RA-EFF-001); exception renewal rate (RA-EFF-002) 7. **Current metric threshold performance:** which thresholds are producing actionable signals vs. noise (per MTR-001 Section 10) ### 12.3 Calibration Decisions The review produces one of two outputs: **Option A: No change.** Current risk appetite remains appropriate. The decision is documented with the specific rationale and the data that supported it. "No change" is a deliberate conclusion, not a default. **Option B: Risk appetite adjustment.** A revised risk appetite statement is produced, plus cascading changes: | Cascade | Action | Owned By | |---|---|---| | Metric thresholds | Tighten or relax relevant thresholds in MTR-001 per the Threshold Calibration procedure (MTR-001 Section 10) | Governance Pillar Leader | | Control baseline priorities | Controls protecting against newly elevated risks get increased review frequency and potentially tighter effectiveness thresholds | Pillar leader of affected controls | | Exception authority | The severity band at which a pillar leader can approve vs. requires CISO vs. requires board is adjusted if the risk appetite change warrants it | CISO | | Investment signals | If appetite tightens in an area, tooling, staffing, or capability gaps are identified and routed to budget planning | CISO | | Improvement register | Each cascading change is recorded in IMPREG-001 (Type: Metric or threshold change, Control amendment, Staffing or budget) with the risk appetite review as the source | Governance Pillar Leader | ### 12.4 Approval - The CISO approves the risk appetite statement and all cascading changes. - If the change materially affects enterprise risk posture, the board or Cyber Oversight Group is informed or approves per the organization's governance charter. - The approved risk appetite statement is published and becomes the authoritative reference for all subsequent risk decisions until the next calibration. ### 12.5 Cascade Tracking Cascading changes from a risk appetite adjustment are tracked in the improvement register (IMPREG-001) until verified. A metric threshold change is verified when it produces one full quarter of actionable signals. A control priority change is verified when the control's effectiveness metric reflects the new posture. No cascading change is considered complete until it is verified Effective. ### 12.6 Worked Calibration Example: Mid-Market Utility > **Purpose** > > This worked example shows how a fictitious organization — Contoso Energy Solutions ($1.2B revenue, NERC-CIP Low + SOX scope) — calibrates risk appetite bands from business inputs. First-time adopters can use this as a template for their own calibration. #### 12.6.1 Business Profile | **Parameter** | **Value** | |---|---| | Revenue | $1.2B (mid-market utility) | | Regulatory scope | NERC-CIP (Low Impact BES), SOX ITGC | | Cyber insurance retention | $500K (self-insured retention) | | Estimated downtime cost per day (Tier 1) | $120K (billing + operations) | | Estimated downtime cost per day (Tier 2) | $30K (internal systems) | | IT/OT asset count | ~2,500 IT + ~300 OT/BES assets | | Security team size | 8 people (CISO + 3 Engineering + 2 Risk + 2 Governance) | | Maturity baseline | CERG MAT-001: Initial (3.2) | #### 12.6.2 Inputs to Calibration **A. Incident history (trailing 12 months):** - 1 ransomware event (contained, cost: $350K within retention) - 3 phishing-related credential theft events (no material loss) - 2 OT patching gaps identified in CIP self-certification (no incident) - Trend: incident frequency stable, severity increasing (ransomware was new) **B. Threat landscape:** - Sector: Energy/Utilities — targeted by state-sponsored and ransomware groups - Top TTPs: Initial Access via VPN/vendor, Lateral Movement via RDP, Data Exfiltration via cloud storage - KEV exploits targeting utility sector: 4 in trailing 12 months **C. Business strategy:** - Cloud migration program (Year 1–2): moving 40% of IT workloads to AWS - OT/IT convergence pilot (Year 2): SCADA historian integration with cloud analytics - Capital budget for cyber: $2.1M (flat vs. prior year) - Revenue growth target: 5% organic, no M&A planned #### 12.6.3 Calibration Calculations **Step 1 — Establish ALE bands as % of revenue** Using revenue-based calibration as the primary anchor: | **Risk Band** | **ALE Range** | **% of Revenue** | **Rationale** | |---|---|---|---| | Low | < $120K | < 0.01% | Below insurance retention; routine operational cost | | Medium | $120K – $1.2M | 0.01% – 0.10% | Within insurance retention; multiple events could exhaust retention | | High | $1.2M – $6M | 0.10% – 0.50% | Exceeds insurance retention; would require capital reallocation | | Critical | > $6M | > 0.50% | Material to earnings; board notification threshold | **Step 2 — Single-risk ALE as function of insurance retention and downtime cost** Single-risk ALE = (Exposure Frequency × Loss Event Value). For this calibration, the CISO and CFO agree: | **Risk Scenario** | **Frequency (per year)** | **Loss Event** | **Single-Risk ALE** | **Band** | |---|---|---|---|---| | Ransomware encrypts Tier 1 billing system | 0.2 (1 in 5 years) | $350K (within retention) + $480K (4 days downtime at $120K/day) = $830K | $166K | Medium | | CUI data breach via compromised vendor | 0.1 (1 in 10 years) | $2.1M (notification + legal + regulatory fines) | $210K | Medium | | OT BES Cyber System compromise (loss of view) | 0.05 (1 in 20 years) | $5M (NERC fine + restoration + reliability coordinator penalties) | $250K | Medium-High | | SOX ITGC control failure → material weakness | 0.15 (1 in 7 years) | $1.5M (audit + remediation + reporting delay costs) | $225K | Medium | | Cloud misconfiguration → data exposure | 0.3 (1 in 3 years) | $200K (within retention) | $60K | Low | **Step 3 — Example calibrated risk appetite bands for the 5×5 matrix** Mapping the ALE bands to the existing 5×5 scoring framework for this example organization. These dollar bands are illustrative calibration output, not a replacement for the canonical severity bands in §9.5 or the acceptance authority in §9.7: | **5×5 Score** | **Label** | **Corresponds to ALE** | **Appetite Position** | |---|---|---|---| | 1 | Informational | < $50K | Track for trend; no formal acceptance required unless a regulator, contract, or business owner requires it | | 2–5 | Low | $50K – $120K | May be accepted under §9.7 with Business Owner + Risk Register Owner approval | | 6–11 | Medium | $120K – $1.2M | May be accepted under §9.7 with Business Owner + Pillar Leader or Governance Pillar Leader approval | | 12–19 | High | $1.2M – $6M | Exceptional; requires CISO + Business Owner approval under §9.7 | | 20–25 | Critical | > $6M | Avoid or remediate by default; acceptance requires CISO + Executive Sponsor approval and board notification under §9.7 | **Step 4 — Regulatory overlay adjustments** | **Regulatory Scope** | **Adjustment to Bands** | **Rationale** | |---|---|---| | NERC-CIP (Low Impact BES) | Critical band triggers at > $4M (not $6M) | NERC penalty exposure + reliability risk lowers the threshold | | SOX ITGC | High band lowered to $1M – $4M | Material weakness disclosure risk + audit costs compress the band | | CUI / CMMC (not in scope) | Standard bands apply | Not applicable until CUI contracts exist | #### 12.6.4 Calibration Output **Risk Appetite Statement (adopted):** > Contoso Energy Solutions accepts residual cybersecurity risk where: > a) The estimated annualized loss exposure (ALE) per risk is below $1.2M (0.10% of revenue), AND > b) The single-risk ALE does not exceed $6M (0.50% of revenue), AND > c) The risk does not threaten NERC-CIP reliability obligations, SOX material weakness reporting, or safety-of-life systems. > > Risk that exceeds any of these thresholds must be treated, transferred, or avoided by default. If leadership proposes acceptance anyway, the approval path in §9.7 still governs; CFO approval and board notification are additional financial-governance requirements for this calibrated example, not substitutes for Business Owner or Executive Sponsor acceptance. **Cascading changes triggered:** | **Cascade** | **Action** | **Owner** | |---|---|---| | Metric thresholds | Tighten NERC-CIP vulnerability SLA from 90 days to 60 days for BES Cyber Systems | Governance Pillar Leader | | Control priorities | Elevate cloud security posture management to High priority (cloud migration program underway) | Engineering Pillar Leader | | Exception authority | Compliance manager may approve Low exceptions for NERC-CIP without pillar leader sign-off | CISO | | Investment signal | Cloud security tooling and OT monitoring identified as budget candidates for next cycle | CISO | #### 12.6.5 How to Use This Example for Your Organization 1. Replace the revenue figure and insurance retention with your organization's numbers. 2. Populate the incident history, threat landscape, and business strategy inputs from your own data. 3. Run the ALE band calculation using your revenue as the denominator. 4. Map single-risk ALEs for your top 5–10 risk scenarios to validate the bands produce actionable prioritization. 5. Add regulatory overlay adjustments for each regulator in your scope. 6. Document the risk appetite statement and cascade changes in the improvement register. --- ## 13. Document Control and Review | Field | Value | |---|---| | **Document ID** | CERG-GOV-RMF-001 | | **Version** | 1.33 | | **Status** | Approved | | **Effective Date** | 2026-06-14 | | **Classification** | Public | | **Document Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Review Cycle** | Annual; triggered by significant regulatory change or organizational change | | **Next Scheduled Review** | 2027-05-26 | | **Parent Document** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - CERG Cybersecurity Policy | | **Related Documents** | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) · [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) · [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) · [`CERG-PRC-TI-001`](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) · System Security Plans (per system) · Plan of Action and Milestones (per system) | ### Revision History | Version | Date | Author | Change Description | |---|---|---|---| | 1.33 | 2026-06-18 | Governance Pillar Leader | Clarified that RMF §9.5 and §9.7 remain canonical for scoring and acceptance authority, separated exception and risk-acceptance template routing, added PRC-VM exposure-SLA precedence, and constrained the calibration example so it cannot override Business Owner / Executive Sponsor acceptance. | | 1.32 | 2026-06-18 | Governance Pillar Leader | Added §12.6 Worked Calibration Example for mid-market utility ($1.2B revenue, NERC-CIP+SOX scope) with ALE bands as % of revenue, single-risk ALE as function of insurance retention and downtime cost, calibrated 5x5 band mapping, regulatory overlay adjustments, and cascading changes. | | 1.31 | 2026-06-14 | Governance Pillar Leader | Clarified canonical risk-acceptance authority, default acceptance durations, and the shortest-applicable-duration rule. | | 1.0 | 2026-05-01 | Cyber Governance | Initial release. Establishes the CERG-RMF cycle, the FAIR-aligned risk statement format, the 5x5 likelihood/impact model, the canonical risk acceptance authority table, and the risk appetite and tolerance posture. Retires the parallel SLA table in favor of the single source of truth in CERG-PRC-VM-001. Adopts canonical ID CERG-GOV-RMF-001 per CERG-GOV-CAT-001 §5.2. | | 1.3 | 2026-05-26 | Cyber Governance | Added Section 12 Risk Appetite Calibration: annual and triggered review cadence, structured input package, calibration decision framework with cascading changes (metric thresholds, control priorities, exception authority, investment signals), approval workflow, and cascade tracking through the improvement register. Renumbered Document Control to Section 13. | --- | | | |---|---| | **Document ID** | CERG-GOV-FLOW-001 | | **Version** | 1.4 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed operations | --- ## Table of Contents 1. [Flow Structure Conventions](#1-flow-structure-conventions) 2. [Operating Principles](#2-operating-principles) 3. [Canonical Roles](#3-canonical-roles) 4. [Flow-to-Record Crosswalk](#4-flow-to-record-crosswalk) 5. [CAT-002 Record Field Authority](#5-cat-002-record-field-authority) 6. [Default SLA Policy](#6-default-sla-policy) 7. [Allowed Decision Classes](#7-allowed-decision-classes) 8. [Shared State Models](#8-shared-state-models) 9. [Flow F-01: Control Intent to Implementation](#9-flow-f-01--control-intent-to-implementation) 10. [Flow F-02: Project Intake, Architecture Review, and Threat Modeling](#10-flow-f-02--project-intake-architecture-review-and-threat-modeling) 11. [Flow F-03: Asset Registration and Coverage Validation](#11-flow-f-03--asset-registration-and-coverage-validation) 12. [Flow F-04: Finding to Remediation, Exception, or Residual Risk](#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) 13. [Flow F-05: Change and Release Security Routing](#13-flow-f-05--change-and-release-security-routing) 14. [Flow F-06: Incident to Recovery to Standards Feedback](#14-flow-f-06--incident-to-recovery-to-standards-feedback) 15. [Flow F-07: Metrics, Oversight, and Improvement Routing](#15-flow-f-07--metrics-oversight-and-improvement-routing) 16. [Automation Integration Points](#16-automation-integration-points) 17. [Evidence Quality Tiers](#17-evidence-quality-tiers) 18. [LLM Execution Directives](#18-llm-execution-directives) 19. [Flow-to-CAT-002 Record Crosswalk](#19-flow-to-cat-002-record-crosswalk) 20. [Recommended Implementation Sequence](#20-recommended-implementation-sequence) 21. [Document Control](#21-document-control) --- ## 1. Flow Structure Conventions Every flow in this document follows a consistent structure. When implementing a flow, use these conventions to ensure completeness. ### Entry and Exit Criteria | Flow | Trigger (Entry) | Exit Criteria | |------|----------------|---------------| | F-01 Control Intent | Policy/standard/baseline change, audit finding, recurring incident, regulatory requirement, CISO directive | Implementation completed + Risk validated + Evidence linked + Dashboard updated | | F-02 Project Intake | New application/service/change, cloud/SaaS adoption, new integration, regulated/AI/OT project | Security disposition issued + pre-go-live remediation done + post-go-live risks recorded + owners confirmed + handoff delivered | | F-03 Asset Registration | Go-live approval, new asset, major change, ownership change, decommission | Owner confirmed + classification complete + coverage validated + gaps resolved as finding/risk | | F-04 Finding → Remediation | Vulnerability, adversarial test, threat intel, third-party, incident, audit, architecture review | Treatment executed + validated + exception/acceptance recorded if used + evidence linked + reporting updated | | F-05 Change & Release | Normal/major/emergency change, release candidate, config/identity/encryption change | Change executed + control continuity checked + SIA reviewed + emergency bypass recorded + evidence linked | | F-06 Incident → Recovery | Incident declared by standing IR team, material event, third-party incident with internal impact, active exploitation, regulatory notification support request | IR-owned response closed or stabilized + CERG support evidence delivered + lessons learned routed + corrective actions assigned | | F-07 Metrics & Oversight | Monthly/quarterly cycle, threshold breach, missed SLA, maturity assessment, board request | Metrics collected + thresholds evaluated + actions assigned for outliers + CISO review done + report published | ### Flow Record Crosswalk After each flow executes, the CAT-002 canonical records below must exist or be explicitly marked not applicable. If a required record is missing, the flow is incomplete. [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) is authoritative for record names, aliases, owners, required fields, and evidence value; this table only shows flow handoff expectations. | Flow | CAT-002 canonical records | Common local aliases used in this flow | |------|---------------------------|----------------------------------------| | F-01 Control Intent | Control Implementation Record; Evidence Index Entry; Reporting Metric Record | Control Change Record; control implementation row | | F-02 Project Intake | Project Security Review Record; Threat Model Record; Risk Register Entry if deferred risk remains | Project Intake Record; Architecture Review Record; security review ticket | | F-03 Asset Registration | Asset Inventory Record; Asset Coverage Record; Finding Record or Risk Register Entry if coverage gap remains | Asset Record; CMDB item; coverage row | | F-04 Finding → Remediation | Finding Record; Risk Register Entry if promoted; Security Exception Record or Risk Acceptance Record if used | Risk Record; Exception Record; acceptance request | | F-05 Change & Release | Security Change Review Record; Evidence Index Entry; Risk Register Entry or Security Exception Record if emergency bypass creates residual exposure | Change Record; SIA; release security review | | F-06 Incident → Recovery | IR-owned Incident Record; Lessons Learned Record; Program Improvement Record if CERG changes are required | IR ticket; CERG support log; Improvement Record | | F-07 Metrics & Oversight | Reporting Metric Record; Oversight Decision Record; Program Improvement Record for assigned actions | Metric row; dashboard item; improvement backlog item | ### SLA Exception Logic Flow-level SLA rules do not override procedure-specific clocks. For exposure management, [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) is authoritative. For risk acceptance and exception duration, [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) and [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) govern. Use the shortest applicable clock. | Exception | Applies To | Record outcome | |-----------|-----------|----------------| | **False Positive** | F-04 (Findings) | Close Finding Record with rationale and evidence of false-positive determination. | | **Compensating Control in Place** | F-04 (Findings) | Create Security Exception Record when a control is not met as written; create Risk Register Entry or Risk Acceptance Record if residual exposure remains. | | **Vendor Patch Unavailable** | F-04 (Findings), F-01 (Control Intent) | Create Third-Party Finding / Finding Record and vendor evidence trail; create Security Exception Record or Risk Acceptance Record only if continued operation creates accepted residual risk. | | **OT Maintenance Window** | F-04 (Findings), F-05 (Change) | Follow PRC-VM and OT/CIP routing; create Risk Register Entry if delay exceeds allowed window or requires business consequence acceptance. | | **Business Outage Risk** | F-04 (Findings), F-05 (Change) | Create Risk Register Entry. Business Owner or Executive Sponsor accepts residual business consequence per RMF-001 §9.7 if deferral is chosen. | | **Emergency Remediation** | F-04 (Findings) | Execute remediation immediately. Create Security Change Review Record post-hoc per F-05 emergency change rules. | | **Reopened Finding** | F-04 (Findings) | Reopen Finding Record, increment recurrence counter, and apply the owning procedure's clock from reopen/reclassification. | | **Accepted Risk Expiration** | F-04 (Findings), RMF-001 | Auto-create Finding Record if acceptance expires without renewal; original acceptance approver is notified. | | **KEV / Active Exploitation Override** | F-04 (Findings) | Reclassify per PRC-VM, including Material Risk — PPR where applicable; PRC-VM SLA governs. | ## 2. Operating Principles ### Record Authority and Conversion Summary [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) is authoritative for record names, aliases, owners, required fields, and evidence value. The table below summarizes how operational terms used in flows map to CAT-002 records; it does not redefine the records. | Operational term | CAT-002 canonical record | Conversion / handoff rule | |------|--------------------------|---------------------------| | **Finding** | Finding Record | May promote to Risk Register Entry if SLA is exceeded, business decision is required, exploitation is active, or crown jewel / regulated scope is affected. | | **Risk** | Risk Register Entry | May require Security Exception Record if control deviation is involved; may require Risk Acceptance Record if residual risk is accepted. | | **Exception** | Security Exception Record | Expired exceptions without renewal become Findings; residual risk acceptance follows RMF-001 §9.7. | | **Vulnerability / exposure observation** | Exposure Backlog Item or Finding Record | Raw scanner output becomes a Finding Record only after PRC-VM triage/validation. | | **Control Gap** | Finding Record or Risk Register Entry | Usually becomes a Risk Register Entry when systemic impact or business consequence exists. | | **Incident** | IR-owned Incident Record | Lessons learned may create Findings, Risk Register Entries, Program Improvement Records, or Control Implementation Records. | **Conversion Rules:** - A Finding promotes to a Risk Register Entry when: SLA is exceeded, the affected asset is Tier 0/Tier 1, exploitation is active, remediation requires a business decision, or compensating controls are needed. - A Risk Register Entry that involves a control deviation creates or links to a Security Exception Record. - A Security Exception Record that expires without renewal auto-creates a Finding Record. - A recurring Finding in the same control family triggers a Control Implementation Record (flow-local alias: Control Change Record) under F-01. 1. **One material event creates one primary record and one accountable owner.** CERG repeatedly emphasizes authoritative records and explicit ownership as the basis for mature execution. 2. **Pre-production security work is Engineering-led unless explicitly escalated.** CERG positions Engineering as the embedded consulting and architecture-review function for projects before production. 3. **Post-production findings are Risk-led unless they are active incident-response actions.** CERG assigns Risk responsibility for continuous exposure identification through exposure management, adversarial testing, vendor assessment, and monitoring. 4. **Governance owns control intent, conformance scope, exception authority routing, evidence rules, and reporting.** CERG's governance layer includes the control system for the program: baseline, calendar, evidence, metrics, compliance mapping, and oversight artifacts. 5. **No issue may remain in an undefined state.** Every issue must become one of: remediation, compensating control, exception, accepted residual risk, or incident action. 6. **Evidence must be created during execution and linked to the primary record.** CERG's annual calendar and reporting model both assume evidence-producing activities generate or refresh evidence as part of the operating rhythm. 7. **Missed review cadence, missing ownership, or missing evidence creates a finding or risk record.** The CERG annual calendar explicitly states that missed activities are tracked as program findings or risk-register entries. 8. **Routing thresholds prevent ceremony creep.** Not every workflow requires all three pillars. The default is not "all three pillars must agree." The default is: Engineering handles known patterns, Risk engages when exposure is novel or elevated, Governance owns policy and evidence, and Business owns the consequence. Handoffs are good. Endless consensus is not. | Work Type | Required Pillars | Rationale | |-----------|-----------------|-----------| | Low-risk known pattern (e.g., capacity increase, DISH-conformant config change, standard user provisioning) | Engineering only; auto-evidence | Known-safe changes do not require governance or risk review. Evidence is generated automatically. | | Moderate known pattern (e.g., approved SaaS with no sensitive data, pre-approved architecture pattern) | Engineering + Governance conformance check | Governance confirms the pattern is still valid; no Risk engagement unless the checklist flags a risk concentration threshold. | | Novel architecture (e.g., new technology stack, first-of-its-kind integration, citizen-development platform) | Engineering + Risk threat model | Risk performs threat modeling; Governance is informed but does not gate. | | Regulated / OT / Crown Jewel (e.g., BES Cyber System change, CUI environment modification, SOX-relevant system) | All three pillars | Regulatory, safety, or material-financial impact requires full cross-pillar engagement. | | High residual risk (e.g., accepted Critical risk, exception past SLA with no compensating control) | Risk-led package + Business acceptance | Risk owns the finding and treatment recommendation; Business accepts the residual risk per RMF-001. | | Policy deviation only, low residual risk (e.g., password length exception, SSO bypass with documented compensating control) | Governance-owned exception | Governance owns the exception workflow, confirms compensating controls, and tracks expiration. | 9. **Every major event must produce a standards/process/metrics feedback decision.** CERG's RMF, incident plan, maturity model, and metrics apparatus all imply that mature operation requires monitoring and response to feed continuous improvement. 10. **If a required actor does not respond within SLA, the primary owner may proceed with documented rationale.** When Governance, Engineering, or Risk fails to act within the flow-defined SLA, the primary owner documents the default decision, proceeds with the next workflow step, and creates a Finding Record noting the missed SLA. No flow may stall indefinitely waiting for a single actor. --- ## 3. Canonical Roles Use the following canonical role names consistently across all records and flows: - **Engineering Pillar** - **Risk Pillar** - **Governance Pillar** - **CISO** - **Business Owner** - **Asset Owner** - **Technical Owner** - **Risk Register Owner** - **Evidence Librarian** - **Incident Commander** - **Control Owner** --- ## 4. Flow-to-Record Crosswalk Every material workflow must resolve to one primary system-of-record object. FLOW identifies the operational handoff; [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) defines the authoritative record name and alias mapping. | Flow concept | CAT-002 canonical record | Common FLOW alias | |---|---|---| | Control intent implementation | Control Implementation Record | Control Change Record | | Project / architecture review | Project Security Review Record | Project Intake Record; Architecture Review Record | | Threat modeling | Threat Model Record | Threat model artifact | | Asset registration | Asset Inventory Record | Asset Record | | Security coverage validation | Asset Coverage Record | Coverage row | | Finding treatment | Finding Record | Finding ticket; exposure finding | | Risk treatment | Risk Register Entry | Risk Record | | Control deviation | Security Exception Record | Exception Record | | Residual-risk acceptance | Risk Acceptance Record | Acceptance request; risk memo | | Security-relevant change | Security Change Review Record | Change Record | | Incident response | Incident Record | IR ticket / incident case | | Evidence indexing | Evidence Index Entry | Evidence Record | | Program improvement | Program Improvement Record | Improvement Record | | Metrics and oversight | Reporting Metric Record; Oversight Decision Record | Metric row; oversight decision | --- ## 5. CAT-002 Record Field Authority FLOW does not define required record fields independently. Every authoritative record uses the minimum required fields in [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) §3 plus the record-specific fields implied by its source procedure or template. Flow implementers may add local tool fields, but they must preserve CAT-002 canonical record type, owner, status, decision, due/review date, evidence link, and closure rationale. When a flow below lists a primary record, read it as a CAT-002 canonical record name. Parenthetical names such as `Change Record`, `Risk Record`, or `Control Change Record` are local aliases only. --- ## 6. Default SLA Policy | Activity | SLA | |----------|-----| | Triage due | 5 business days | | Assignment due | 5 business days | | Validation due | 5 business days | | Evidence link due | 3 business days | | Escalate if past due | Yes | --- ## 7. Allowed Decision Classes All workflows should terminate in one of the following decision classes: - **Remediate pre-production** - **Remediate post-production** - **Compensating control** - **Exception required** - **Risk acceptance required** - **Block release** - **Monitor only** - **Incident response** - **Standards update required** - **Metrics update required** --- ## 8. Shared State Models ### 8.1 Project Security Review State Model Allowed states: - Intake open - Scope defined - Architecture review in progress - Threat model in progress - Remediation required pre-go-live - Approved for go-live - Approved with post-go-live risk - Blocked pending prerequisite - Closed ### 8.2 Finding Lifecycle State Model Allowed states: - New - Triage - Assigned - Treatment planned - In engineering work - Exception review - Risk acceptance review - Validation pending - Residual monitoring - Closed ### 8.3 Asset Coverage Lifecycle Allowed states: - Discovered - Registered - Owner confirmed - Classified - Control coverage pending - Fully covered - Coverage gap open - Decommissioned ### 8.4 Incident Lifecycle Allowed states: - Detected - Validated - Classified - Containment active - Investigation active - Recovery active - Lessons learned pending - Corrective action open - Closed ### 8.5 Control Change Lifecycle Allowed states: - Proposed - Approved for design - Implementation designed - Validation defined - Rollout in progress - Validation pending - Evidenced - Reported - Closed --- ## 9. Flow F-01 — Control Intent to Implementation ### Purpose Convert governance-originated control intent into implementable technical change and risk-validated outcomes. ### Primary Owner **Governance Pillar** ### Supporting Owners - Engineering Pillar - Risk Pillar ### Trigger Events - Policy changed - Standard changed - Control baseline changed - Material audit finding - Recurring incident pattern - Repeated exception in same control family - Regulatory requirement added - Board or CISO directive ### Primary Record **Control Implementation Record** (flow-local alias: Control Change Record) ### Required Inputs - Control ID - Source reason (policy change, standard change, audit finding, etc.) - Affected environments - Affected asset classes - Implementation deadline - Required evidence - Reporting metric target - Exception path - Preventive / detective / corrective classification ### Workflow 1. Governance creates the **Control Implementation Record** (or local Control Change Record alias). 2. Governance defines **control intent and conformance scope**. 3. Engineering produces the **implementation design**. 4. Risk defines **validation criteria before rollout**. 5. Governance approves the **evidence plan**. 6. Engineering executes rollout and records implementation evidence. 7. Risk validates effectiveness. 8. Governance updates dashboard/reporting and closes or reopens the record. ### Decision Logic - If validation is effective, close the record. - If validation is ineffective, reopen or create Engineering action. - If the control cannot be met as written or by deadline, route to exception workflow. ### Evidence Required - Implementation design package - Validation plan - Control test or outcome evidence - Updated Reporting Metric Record - Linked Evidence Index Entry ### SLA - Governance publishes package: 5 business days - Engineering design: 10 business days - Risk validation plan: 5 business days - Evidence link: 3 business days ### Escalation - Missing Engineering design after SLA → escalate to CISO and create finding - Missing validation → do not allow closure; create risk record ### Closure Criteria - Implementation completed - Risk validated - Evidence linked - Dashboard updated --- ## 10. Flow F-02 — Project Intake, Architecture Review, and Threat Modeling ### Purpose Ensure that new systems and major changes enter production with known scope, required controls, and explicit security disposition. ### Primary Owner **Engineering Pillar** ### Supporting Owners - Risk Pillar - Governance Pillar ### Trigger Events - New application - New service - Major change - New cloud or SaaS adoption - New integration - Internet-exposed component - Regulated-scope project - AI system introduction - IT/OT convergence change ### Primary Record **Project Security Review Record** (front-door alias: Project Intake Record) ### Required Inputs - Project name - Business owner - Technical owner - Intended go-live date - Asset class - Data classification - Regulatory scope - AI use category, model/provider, and proposed agency boundary where AI is in scope - Hosting environment - External dependencies - Privilege model - Logging plan - Backup / recovery plan ### Review Tiers Projects are triaged into one of three review tiers based on risk characteristics. The tier determines review depth, not whether a review occurs. PRC-AR-001 provides the detailed procedure for each tier. | Tier | Criteria | Review Depth | Architecture Review | Threat Model | Governance Conformance | |------|----------|-------------|---------------------|--------------|------------------------| | **T1 — Full Review** | Internet-exposed, regulated-scope, sensitive data, OT/safety impact, new platform pattern, high-risk third-party, complex privileged path | Full Phase 2-4 per PRC-AR-001 | Full architecture review | Full threat model | Governance issues Conformance Scope Statement | | **T2 — Lightweight Review** | Internal service on reviewed platform, reuse of approved architecture pattern, capacity addition to reviewed system, non-sensitive data, no regulatory scope | Checklist review per PRC-AR-001 §4 | Checklist-based architecture review | Threat model review (confirm existing model covers change) | Governance confirms existing conformance applies | | **T3 — Automated-Only** | Pre-approved change pattern (e.g., config update within baseline, dependency bump within allowed range), citizen-development platform app, pipeline already enforces SAST/policy-as-code/CSPM gates | Automated gates only; no manual review | Automated SAST + policy-as-code pass = architecture review satisfied | N/A (platform-level threat model covers) | Automated CSPM posture check = conformance satisfied | ### AI Routing Rules When AI is in scope, the Project Intake Record links to an AI intake record using [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) or an equivalent local record. Routing is based on the AI use case, data classification, and agency boundary: - **Consumed AI services** may follow T2 or a pre-approved architecture pattern when the use case, user population, and maximum data classification match the sanctioned AI tools register. - **Built AI, embedded AI, AI agents, model-serving platforms, RAG systems, or AI with consequential action capability** default to T1 unless Engineering documents why an approved pattern fully covers the use. - **AI processing Confidential, Restricted, CUI, BES Cyber System Information, SOX-relevant data, personal data at material scale, or safety-impacting data** requires Governance conformance review and Risk participation. - **AI-enabled vendor features** trigger third-party reassessment when the feature changes data use, training, retention, subprocessors, user population, or decision impact. - Approved consumed AI tools update the sanctioned AI tools register using [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md). Built or embedded AI systems update the AI system and model register using [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md). ### Workflow (by Tier) **T1 — Full Review:** 1. Engineering opens **Project Intake Record** and assigns T1. 2. Engineering performs initial security scoping. 3. Engineering performs full **Architecture Review** (PRC-AR-001 Phase 2). 4. Engineering performs full **Threat Model** (PRC-AR-001 Phase 2). 5. Governance issues **Conformance Scope Statement**. 6. Risk participates per risk concentration thresholds. 7. Engineering classifies issues as pre-go-live or post-go-live. 8. Engineering issues final security disposition. **T2 — Lightweight Review:** 1. Engineering opens **Project Intake Record** and assigns T2. 2. Engineering completes the T2 checklist (PRC-AR-001 §4). 3. Engineering confirms existing threat model covers the change; documents any delta. 4. Governance confirms existing conformance scope applies. 5. Engineering issues disposition. Risk participates only if checklist flags a risk concentration threshold. **T3 — Automated-Only:** 1. Engineering opens **Project Intake Record** and assigns T3. 2. Automated gates execute: SAST scan, policy-as-code validation, CSPM posture check. 3. If all gates pass: Engineering issues disposition. No manual review required. 4. If any gate fails: revert to T2 and flag the failure for Engineering review. ### Risk Concentration Thresholds Risk participation is required when one or more of the following are true: - Sensitive data present - Regulated scope present - Internet exposure present - High-risk third-party dependency present - Complex privileged path present - OT or safety impact present - AI system has autonomous or tool-using agency beyond draft/recommendation - AI use expands beyond the sanctioned tool's approved use case, user population, or maximum data classification ### Allowed Dispositions - Approved for go-live - Approved with pre-go-live remediation - Approved with post-go-live risk record - Blocked pending prerequisite ### Mandatory Rules - Every identified issue must be classified as **pre-production remediation** or **post-production managed risk**, not both. - Any issue deferred beyond go-live must create a **Risk Record** and, where nonconformance exists, an **Exception Record candidate**. - No go-live proceeds without named business and technical owners. - If the project touches or creates a Tier 0/Tier 1 crown jewel (per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)), the crown-jewel minimum control profile (CJ-001 §3.3) is a pre-go-live requirement, and the relevant loss scenarios become threat-model design targets per [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md). ### Closure Criteria - Security disposition issued (approved, approved-with-remediation, approved-with-risk, or blocked) - All pre-go-live remediation completed and validated - Post-go-live risk records created for deferred issues - Named business and technical owners confirmed - Production Handoff Security Summary delivered ### Evidence Required - Architecture Review Record - Threat Model Record - Conformance Scope Statement - Production Handoff Security Summary - AI Intake and Sanctioning Record where AI is in scope - Sanctioned AI Tools Register entry or AI System and Model Register entry where AI is approved ### Escalation - Go-live requested while blocked → escalate to CISO - Missing ownership or scope → hold project and create finding --- ## 11. Flow F-03 — Asset Registration and Coverage Validation ### Purpose Ensure every in-scope asset has ownership, classification, regulatory designation, and required control coverage. ### Primary Owner **Engineering Pillar** ### Supporting Owners - Risk Pillar - Governance Pillar ### Trigger Events - Project approved for go-live - New asset discovered - Major asset change - Ownership change - Environment change - Regulatory scope change - Asset decommission request ### Primary Record **Asset Inventory Record** (local alias: Asset Record) ### Asset Classes and Registration Requirements Assets are classified by lifecycle to determine registration depth. Ephemeral and auto-scaling assets are registered via automated discovery, not manual entry. | Asset Class | Examples | Registration Method | Required Fields | |------------|----------|-------------------|-----------------| | **Persistent** | Physical servers, VMs, databases, network appliances, SaaS platforms | Manual or automated via CMDB integration | All 14 fields below | | **Dynamic** | Long-lived cloud instances (EC2, GCE), Kubernetes nodes, PaaS services | Automated via cloud API / CSPM discovery | Asset ID, type, environment, classification, owner, scan coverage, logging source. Remaining fields derived from tags or platform defaults. | | **Ephemeral** | Auto-scaling instances, spot instances, containers, serverless functions, batch jobs | Automated via cloud API / orchestrator; registered at the *workload level*, not per-instance | Workload ID (e.g., ECS service name, Lambda function name, Deployment name), type, environment, classification, owner, scan coverage (inherited from platform). Individual instances tracked as members of the workload group. | **Workload-level registration** means that a Kubernetes Deployment, an ECS Service, or a Lambda function is registered once. Individual pods, tasks, or invocations are tracked as members of that workload group. Coverage validation (§ Coverage Requirements) is assessed at the workload level, not the instance level. ### Required Inputs - Asset ID - Asset type - Asset owner - Business owner - Technical owner - Environment - Data classification - Regulatory scope - Criticality - Support team - Logging source expected - Scanning required - Backup required - Access review required ### Workflow 1. Engineering creates or updates **Asset Record**. 2. Engineering confirms owner and classification. 3. Risk validates scan coverage and exposure visibility. 4. Governance maps asset to control and calendar obligations. 5. Governance determines whether any coverage gap is a finding or risk. ### Coverage Requirements - Owner assigned - Classification complete - Regulatory flag present if applicable - Scan coverage established if required - Logging source established if required - Backup assignment established if required - Access review population assigned if required - For crown-jewel assets (Tier 0/Tier 1 per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)), the CJ-001 §3.3 minimum control profile is present and verified, not merely scanned ### Closure Criteria - Asset owner assigned and confirmed - Classification complete - Regulatory flag set if applicable - Scan coverage established if required - Logging source established if required - Backup assignment established if required - Access review population assigned if required - Any coverage gap resolved as finding or risk record - Crown-jewel minimum control profile verified for Tier 0/Tier 1 assets (per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)) ### Evidence Required - Asset Inventory Record - Asset Coverage Record / coverage validation result - Governance obligation map ### Metrics Generated - Asset coverage completeness % - Assets missing owner % - Assets missing scan coverage % - Assets missing logging % --- ## 12. Flow F-04 — Finding to Remediation, Exception, or Residual Risk ### Purpose Convert discovered exposure into a deterministic treatment path: remediation, compensating control, exception, formal risk acceptance, or incident handling. ### Primary Owner **Risk Pillar** ### Supporting Owners - Engineering Pillar - Governance Pillar ### Trigger Events - Vulnerability discovered - Adversarial validation result - Threat intelligence match - Third-party risk result - Incident follow-on issue - Audit finding - Architecture review deferred issue ### Primary Record **Finding Record** ### Required Inputs - Finding ID - Finding source (vulnerability, adversarial, threat intel, third-party, incident, audit, architecture review) - Severity (Critical, High, Medium, Low) - Exploitability assessment - Affected assets - Business owner - Technical owner - Regulatory scope - Recommended treatment class - Due date ### Workflow 1. Risk creates **Finding Record** and triages. 2. Risk identifies exposure path and treatment options. 3. Engineering assesses technical feasibility of treatment. 4. Governance determines whether exception or acceptance process is required. 5. Engineering executes remediation or compensating control if approved. 6. Risk validates closure or establishes residual monitoring. 7. Governance updates reporting and escalates recurring patterns. ### SLA Authority This flow does not define a separate vulnerability or exposure remediation clock. For vulnerabilities, KEV items, active exploitation, scanner observations, and confirmed reachable exposures, [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §7.2 is the canonical SLA source. FLOW F-04 uses the finding state and record handoff; PRC-VM determines the treatment clock. | PRC-VM Classification | Treatment Clock | |---|---| | **Material Risk — PPR** | 48 hours (Internet-facing) / 72 hours (internal) | | **Confirmed Exposure — Critical** | 3 days | | **Confirmed Exposure — High** | 15 days | | **Confirmed Exposure — Medium** | 30 days | | **Confirmed Flaw, Not Exposed** | 90 days / next maintenance window | | **Hygiene Debt** | Patch hygiene cadence per PRC-VM §10 | For non-exposure findings such as audit findings, architecture review issues, or third-party assessment gaps, the owning procedure or record sets the due date. If more than one SLA or due date applies, use the shortest applicable clock. ### Risk Promotion Rules — When a Finding Becomes a Risk Register Entry Not every finding needs a risk register entry. Promote a Finding to a Risk Record when any of these conditions are met: | Condition | Action | Rationale | |-----------|--------|-----------| | SLA for remediation is exceeded | Create Risk Record with severity based on original finding | An overdue finding represents active, unmanaged exposure | | Affected asset is Tier 0 (Crown Jewel) or Tier 1 (Critical) | Create Risk Record regardless of severity | High-criticality assets warrant formal risk tracking | | Active exploitation confirmed (KEV-listed, exploit in wild) | Create Risk Record; treat as Critical | Active exploitation invalidates the original severity assessment | | Remediation requires a business decision (budget, outage window, vendor coordination) | Create Risk Record with business owner assigned | Business decisions require business accountability | | Compensating controls are needed | Create Risk Record and Exception Record | Compensating controls represent a deviation from the control baseline | | Repeated finding — same vulnerability class, same system, more than twice | Create Risk Record; escalate to root cause analysis | Recurrence signals a systemic issue, not a one-time miss | | Regulatory deviation required (CIP, CMMC, SOX) | Create Risk Record and initiate regulatory deviation process | Regulatory implications require formal tracking | A Finding that does not meet any promotion condition is closed through the standard remediation → validation → closure path. ### Closure Validation Rules Who can close a finding, and what evidence is required, depends on severity and source: | Severity | Who Can Close | Minimum Evidence | Retest Required? | |----------|--------------|-----------------|-----------------| | **Critical** | Risk Pillar (must validate) | E3 evidence per AUD-001; authenticated re-scan or adversarial re-test | Yes — mandatory | | **High** | Risk Pillar (must validate) | E3 evidence; authenticated re-scan or equivalent validation | Yes — mandatory | | **Medium** | Engineering may self-close with automated validation | E2 minimum; authenticated re-scan or SAST re-scan | Yes — automated re-scan acceptable | | **Low** | Engineering may self-close with automated validation | E2 minimum; scan report or equivalent | At discretion of closer | **Additional closure rules:** - Engineering may not close a Critical or High finding unilaterally. Risk must validate. - Self-service closure (Medium/Low) requires the automated validation to reference a specific pipeline run, scan job, or test execution with a timestamp. - If closure validation fails (retest shows finding still present): reopen the finding, increment the recurrence counter, and escalate per the recurring finding rules below. - Closure must include a statement of what changed: "Patched to version X," "Parameterized query at line Y," "Added WAF rule Z." "Fixed" is insufficient. ### Recurring Finding Escalation A finding that reappears after closure is different from a new finding. Escalate recurring findings as follows: | Recurrence | Action | Escalation | |-----------|--------|-----------| | 1st recurrence (same vulnerability class, same system) | Reopen with "Recurring" flag; verify original closure evidence was valid | Notify Pillar Leader | | 2nd recurrence | Root cause analysis required; document why the fix did not hold | Escalate to Pillar Leader; create Finding Record for the root cause | | 3rd recurrence | Treat as systemic control failure | Create Risk Record; escalate to CISO; consider Control Change Record (F-01) | Recurring findings across multiple systems in the same control family trigger a Control Change Record regardless of recurrence count per system. ### Allowed Treatment Paths - Immediate remediation - Planned remediation - Redesign - Compensating control - Exception request - Formal risk acceptance - Incident response (if active exploitation exists) ### Mandatory Rules - No finding may remain undefined beyond triage SLA or the owning procedure's classification deadline. - Engineering may not close a Critical, High, Material Risk, PPR, adversarial, audit, or regulated-scope finding unilaterally; Risk must validate. - **Self-Service Closure (Medium/Low):** Engineering may close Medium and Low findings when automated validation confirms the fix and no regulated-scope, active-exploitation, adversarial-test, or audit requirement requires independent validation. Automated validation includes: authenticated vulnerability re-scan (findings from scanning), SAST re-scan passing (findings from code review), CSPM posture check passing (findings from cloud posture), or policy-as-code gate passing (findings from IaC review). Risk validates Medium/Low findings by exception — spot-checking a sample rather than re-validating every closure. - Any control not met as written or on time routes to exception review; any residual risk accepted after that review follows [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 and [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). - Accepted residual risk requires the Business Owner or Executive Sponsor acceptance required by RMF-001 §9.7, rationale, conditions, review cadence, and expiration if applicable. ### Validation Method by Finding Source | Finding Source | Minimum Validation Method | Sufficient Evidence | |----------------|--------------------------|---------------------| | Vulnerability scan | Authenticated re-scan of affected asset | Scan report showing finding resolved | | Adversarial test | Targeted re-test of the specific finding | Test report confirming closure | | Code review (SAST) | Re-scan + code diff review for High/Critical | Scan report + reviewer sign-off | | Architecture review | Architecture Review Record updated | Signed disposition from Engineering | | Threat intelligence | IOC search across environment | Negative search result | | Audit finding | Evidence package per auditor specification | Auditor acceptance confirmation | | Third-party risk | Vendor attestation or re-assessment | Updated vendor assessment | ### Closure Criteria - Treatment executed (remediation, compensating control, exception, or risk acceptance) - Risk validation confirms closure or establishes residual monitoring - Exception or risk-acceptance record created if used - Evidence linked to finding record - Reporting updated ### Evidence Required - Triage result - Engineering treatment plan - Remediation or compensating-control evidence - Validation result - Exception or risk-acceptance record if used ### Escalation | Trigger | Escalation Target | Action | |----------|------------------|--------| | Material Risk — PPR unassigned after **4 hours** | CISO | Immediate notification; CISO may invoke incident response | | Material Risk — PPR past PRC-VM SLA | CISO | Mandatory review; create Risk Record for delayed treatment and route any acceptance through RMF-001 §9.7 | | Confirmed Exposure — Critical unassigned after **1 business day** | Pillar Leader (Risk) | Pillar Leader must assign or explain; CISO informed for regulated or crown-jewel scope | | Confirmed Exposure — Critical or High past PRC-VM SLA | Governance Pillar Leader + CISO | Create exception/risk-acceptance record as applicable; escalate treatment blocker | | Confirmed Exposure — Medium past PRC-VM SLA | Risk Pillar Leader | Included in monthly roll-up report; risk of SLA drift | | Confirmed Flaw Not Exposed or Hygiene Debt past applicable cadence | Risk Pillar Leader | Included in quarterly review or patch-hygiene review | | Repeated exception in same control family | Governance Pillar Leader | Create Control Change Record (F-01) | | Engineering refuses or stalls treatment | Pillar Leader (Risk → Engineering) | Cross-pillar escalation; CISO if unresolved after 5 business days | --- ## 13. Flow F-05 — Change and Release Security Routing ### Purpose Ensure that security-significant changes receive consistent cross-pillar handling. ### Primary Owner **Engineering Pillar** ### Supporting Owners - Risk Pillar - Governance Pillar ### Trigger Events - Normal change requested - Major change requested - Emergency change requested - Release candidate created - Production configuration change - Identity model change - Encryption or key change - New external dependency ### Primary Record **Security Change Review Record** (local alias: Change Record) ### Required Inputs - Change ID - Change type (normal, major, emergency) - Affected assets - Implementation window - Rollback plan - Security impact analysis - Data classification - Regulatory scope - Testing plan ### Change Classification and Required Activities Not all changes carry the same security risk. The table below defines what each change class requires. "SIA" = Security Impact Analysis. "CC" = Control Continuity check. | Change Class | Examples | SIA Required | SIA Depth | Control Continuity Scope | Risk Review | Fast-Lane Eligible | |-------------|----------|-------------|-----------|--------------------------|-------------|--------------------| | **Pre-Approved** | Documentation update, dashboard color change, log format adjustment, non-security config change within approved baseline, dependency bump within allowed semver range | No | N/A | None — change has no security surface | No | Yes — deploy immediately, record change post-hoc | | **Standard** | New feature deployment, scaling adjustment, routine cert rotation, IAM role addition within existing policy, database schema change | Yes | Lightweight — confirm change does not alter security boundary | Verify specific controls affected by the change (e.g., cert rotation → CR-001 controls; IAM change → AC-2 controls) | No, unless risk-significant criteria met | No — standard flow | | **Major** | New service introduction, architecture change, firewall rule change, encryption protocol change, identity model restructure, new external dependency | Yes | Full — assess impact across all control families | Verify all controls on affected assets; confirm no control regression | Yes — mandatory Risk review | No — requires full review | | **Emergency** | Active incident remediation, zero-day patch, critical service restoration | Yes — post-execution within 24 hours | Full — documented after execution | Verify as soon as practical; automate where possible | Post-execution; linked risk or exception required for any deviation | Yes — bypass normal gates; document rationale and create post-hoc record | **Control Continuity Scope by Change Class:** - **Pre-Approved:** No control continuity check required. - **Standard:** Verify the specific controls directly affected by the change. A cert rotation verifies CR-001 controls. An IAM role addition verifies AC-2 controls for the new role. Do not re-verify unrelated controls. - **Major:** Verify all controls mapped to the affected assets (per CB-001). Confirm no control has regressed. - **Emergency:** Verify as soon as practical. Automated CSPM/CNAPP scanning is acceptable as control continuity evidence. Document any gaps as a finding. ### Workflow 1. Engineering classifies the change per the table above and opens the **Security Change Review Record** (or local Change Record alias). 2. For Pre-Approved: deploy immediately; create Change Record post-hoc. Skip to step 6. 3. For Standard: Engineering completes lightweight SIA. For Major/Emergency: Engineering completes full SIA. 4. Risk reviews if change is risk-significant (Standard) or mandatory (Major/Emergency). 5. Governance applies conformance and evidence requirements (Standard/Major/Emergency). 6. Engineering executes the change. 7. Engineering performs control continuity checks per the scope defined above. 8. Governance verifies evidence and closes or reopens the change. ### Risk-Significant Change Criteria - Internet exposure changed - Privileged access changed - Logging coverage impacted - Backup or recovery path changed - Encryption or key handling changed - Third-party dependency added or materially modified - Regulated-scope asset impacted - Emergency bypass used ### Mandatory Rules - Emergency security deviations require linked risk or exception review. - Change closure requires control continuity verification, not only service success. - Missing rollback strategy blocks major-change approval. ### Closure Criteria - Change executed successfully - Control continuity checks passed - Security Impact Analysis completed and reviewed - Risk or exception record created if emergency bypass used - Evidence linked to change record - Governance verification complete ### Evidence Required - Security Impact Analysis - Test evidence - Control continuity result - Linked risk or exception if applicable --- ## 14. Flow F-06 — Incident to Recovery to Standards Feedback ### Purpose Define how CERG supports the standing Incident Response team during and after an incident, then converts verified lessons into engineering controls, risk posture, governance artifacts, metrics, and program improvements. > **IR Ownership:** The standing Incident Response team owns incident declaration, classification, command, the IR plan, regulatory notification-clock process, and exercise management. CERG is not responsible for IR operations. This flow defines CERG's *supporting role* during incidents: supplying asset context, exposure analysis, control evidence, recovery dependencies, regulatory mapping support, and post-incident improvement routing. The Incident Commander's authority during an active incident supersedes any CERG workflow step. ### Primary Owner **Incident Commander / Standing Incident Response Team** for active incident operations. **CERG Governance Pillar** for CERG-owned evidence packaging, lessons-learned routing, standards feedback, and improvement tracking after the IR team requests support or closes active response. ### Supporting Owners - Engineering Pillar - Risk Pillar - Governance Pillar - CISO - Evidence Librarian ### Trigger Events - Incident declared by the Incident Commander or standing IR team - Material security event requiring CERG support - Third-party incident with internal impact - Active exploitation of a known issue in CERG-managed scope - Incident Commander, Legal, or Governance request for regulatory evidence or control-impact support ### Primary Record **IR-owned Incident Record** during active response. **Lessons Learned Record** and/or **Program Improvement Record** when the incident produces a CERG control, risk, standard, evidence, or metric change. ### Required Inputs - Incident ID - Incident Commander - Severity assigned by the IR process - Detected time or timeline reference - Affected assets - Suspected scope - Business owner - Regulatory scope - CERG support requested - Evidence-preservation requirements - Containment or recovery decisions requiring CERG execution ### Incident Severity Reference Incident severity and response clocks are governed by the Incident Response Plan, not by this flow. CERG records use the paired labels below only to align CERG support records with the IR-owned incident record. | IR Severity | CERG Support Label | Meaning | |---|---|---| | **Sev 1** | **P1 / Critical** | Material business, safety, reliability, regulated-data, or crown-jewel impact. | | **Sev 2** | **P2 / Significant** | Confirmed compromise or regulated impact requiring full IR coordination. | | **Sev 3** | **P3 / Moderate** | Scoped compromise or material event requiring targeted CERG support. | | **Sev 4** | **P4 / Minor** | Localized event or alert requiring routine support or monitoring only. | ### Workflow 1. Incident Commander or standing IR team declares the incident, assigns severity, and opens the IR-owned Incident Record. 2. Incident Commander requests CERG support and names the CERG outputs needed: asset context, logs, control evidence, risk history, vendor context, recovery dependency, regulatory mapping support, or technical execution. 3. Risk supplies exposure context, threat intelligence, affected-control analysis, and investigation support under Incident Commander / Lead Investigator direction. 4. Engineering executes containment, eradication, recovery, access, network, configuration, or restoration changes approved through the IR process. 5. Governance supplies regulatory mapping, evidence indexing, decision-log support, and reporting artifacts under Incident Commander and Legal direction. Governance does not own the notification-clock process. 6. Evidence Librarian preserves CERG-produced evidence and links it to the IR-owned Incident Record or submitted evidence package. 7. After active response is closed or stabilized, Governance opens the CERG Lessons Learned Record and feedback decision record. 8. Engineering, Risk, and Governance assign corrective actions, Risk Register Entry updates, standards/procedure changes, Reporting Metric Record updates, or Program Improvement Records. ### Mandatory Post-Incident CERG Outputs - CERG support actions and evidence package - Root cause or control-failure input supplied to the IR team - Risk-register update decision - Control, standard, or procedure change decision - Metrics/KRI update decision - Corrective-action owner and due date - Program Improvement Record when the lesson changes how CERG operates ### Mandatory Rules - CERG does not close the incident; the Incident Commander or standing IR team closes active response. - CERG's post-incident work is not complete until the lessons-learned decision is recorded, even if technical recovery is complete. - If an incident exposes previously accepted risk, the acceptance rationale and treatment conditions must be reviewed through the risk process. - A recurring incident pattern in the same control family creates a Control Change Record or Program Improvement Record. - Regulatory notification decisions are made through the IR, Legal, and executive process; CERG Governance records and preserves the supporting evidence it supplies. ### Closure Criteria for CERG Support - Incident Commander has closed or stabilized the active-response phase, or released CERG from active support. - CERG support actions are recorded and linked to the IR-owned Incident Record. - CERG-produced evidence package is stored and indexed. - Root cause and control-failure inputs are delivered to the IR team or lessons-learned process. - Lessons-learned decision recorded: standards, procedure, risk, control, metric, or no-change-with-rationale. - Corrective actions assigned with owner and due date. - Previously accepted risk reviewed if the incident exposed it. ### Evidence Required - IR timeline reference or incident record link - CERG support action log - Asset, data, control, risk, vendor, or recovery evidence supplied to the IR team - Evidence-preservation and submission package links - Lessons-learned or Program Improvement Record --- ## 15. Flow F-07 — Metrics, Oversight, and Improvement Routing ### Purpose Convert operational data into management action, improvement backlog, standards review, risk escalation, and board-grade reporting. ### Primary Owner **Governance Pillar** ### Supporting Owners - Risk Pillar - Engineering Pillar - CISO ### Trigger Events - Monthly reporting cycle - Quarterly reporting cycle - Metric threshold breach - Repeated missed SLA - Maturity assessment run - Board or executive request - Repeated control failure pattern ### Primary Record **Reporting Metric Record** ### Required Inputs - Metric name - Metric definition - Source system - Reporting period - Threshold (green / amber / red) - Actual value - Evidence link - Accountable role - Interpretation note ### Workflow 1. Governance collects metrics per canonical dictionary. 2. Risk supplies exposure and residual-risk metrics. 3. Engineering supplies implementation and quality metrics. 4. Governance evaluates thresholds and trends. 5. Governance assigns action type for each outlier. 6. CISO reviews material outliers and escalations. 7. Governance publishes monthly or quarterly report. ### Allowed Action Types - Engineering action - Risk escalation - Governance standards review - Exception review - No action with rationale ### Baseline Cross-Pillar Metrics - % of new assets fully covered within SLA - % of pre-production findings closed before go-live - % of post-production findings assigned within 5 business days - % of exceptions with active compensating controls - Median time from discovery to validated closure - % of incidents resulting in standards or procedure update - % of board metrics backed by direct evidence - % of Critical/High findings where validation method was E3 (adversary-facing test or authenticated re-scan) vs. E2 (process artifact only) - % of accepted risks re-opened due to threat landscape change within 12 months of acceptance - weighted sum of (open findings × 1) + (open exceptions × 3) + (accepted risks × 2) per NIST control family - % of exceptions within 30 days of expiration without a renewal or closure decision - % of flow steps where a pillar missed its SLA, reported monthly per pillar - **Review cycle time by tier**: median hours/days from F-02 intake to security disposition, reported by review tier (T1/T2/T3) — measures whether review depth is proportional to project risk - **Deployment frequency of reviewed projects**: number of deployments per week for projects that passed F-02 review — measures whether security review enables or impedes delivery velocity - **Pre-approved change ratio**: % of F-05 changes classified as Pre-Approved vs. Standard/Major — measures whether the change classification model is appropriately tuned; a ratio below 30% suggests over-classification - **Automated closure rate**: % of F-04 Medium/Low findings closed via self-service automated validation vs. manual Risk validation — measures automation adoption - **SLA breach rate by pillar**: % of flow steps where a pillar missed its SLA, reported monthly per pillar — identifies bottlenecks across Engineering, Risk, and Governance ### Mandatory Rules - Every threshold breach must produce an action type or explicit no-action rationale. - Metrics without evidence links are not board-reportable. - Repeated outlier in same control family creates a Control Change Record or Improvement Record. --- ### Closure Criteria - Metrics collected from all three pillars per canonical dictionary - Thresholds and trends evaluated - Action type assigned for every outlier (engineering action, risk escalation, standards review, exception review, or no-action-with-rationale) - Material outliers reviewed by CISO - Monthly or quarterly report published - Repeated outliers in same control family escalated to Control Change Record or Improvement Record ## 16. Automation Integration Points The flows in this document describe human-driven steps, but automated security controls can satisfy or accelerate many of them. The table below defines where automation is accepted as valid execution and what evidence is required. | Flow Step | Automated Equivalent | Evidence Required | Tier Equivalent | |-----------|---------------------|-------------------|-----------------| | F-02 Architecture Review | SAST scan passes in CI/CD pipeline; policy-as-code gates pass at apply time | Pipeline run ID + scan results | T3 (Automated-Only) for pre-approved patterns; supports T2 (Lightweight) for internal services | | F-02 Threat Model | Platform-level threat model on file; change within modeled scope | Reference to existing threat model + delta analysis | T2/T3 | | F-03 Asset Registration | Cloud API / CSPM auto-discovery; tag-based owner/classification assignment | CSPM inventory export; tag audit log | Automated for Dynamic and Ephemeral classes | | F-04 Finding Validation | Authenticated vulnerability re-scan; SAST re-scan; CSPM posture re-check; policy-as-code gate re-run | Scan report + finding ID correlation | E3 for code/vulnerability findings; E2 for config findings | | F-05 Security Impact Analysis | IaC diff analysis; policy-as-code evaluation of proposed change; blast radius assessment from CMDB | Automated SIA report; policy evaluation result | Standard/Major — augments but does not replace human SIA for Major changes | | F-05 Control Continuity Check | CSPM/CNAPP posture scan post-deployment; automated control test suite | Posture scan report; test suite results | Acceptable for Standard changes; augments Major change CC | | F-07 Metric Collection | API integration with scanning tools, pipeline analytics, CSPM dashboards | API response or dashboard export with timestamp | Fully automated | **Automation Evidence Standard:** Automated evidence must be traceable to a specific pipeline run, scan job, or API call with a timestamp and a unique identifier. A link to the pipeline run (e.g., CI/CD run #1247) is sufficient; screenshots are not required when a programmatic reference is available. **When Automation Satisfies a Step Entirely:** For T3 (Automated-Only) projects and Pre-Approved changes, automated gate passage satisfies the requirement with no human review. For T2 and Standard changes, automation satisfies evidence requirements but a human reviewer confirms it. For T1 and Major changes, automation augments but does not replace human review. --- ## 17. Evidence Quality Tiers Not all evidence proves the same thing. Flows reference evidence by tier so that operators know what level of proof is required. | Tier | Name | What It Proves | Example | Required For | |------|------|---------------|---------|--------------| | **E1** | Control Exists | The artifact that implements the control is present | JML log file exists in the evidence library | Routine governance checks (F-03, F-07) | | **E2** | Control Operates | The control processed a transaction successfully | JML log shows 3 leavers processed this month; access review spreadsheet completed | Standard evidence collection; Medium/Low finding closure (F-04) | | **E3** | Control Is Effective | An adversary-facing test, independent verification, or automated re-validation confirms the control works as intended | Automated authenticated vulnerability re-scan confirming fix; SAST re-scan passing with no regressions; policy-as-code gate passing for IaC change; CSPM posture check confirming drift remediation. Full penetration test is E3+ and reserved for adversarial-sourced findings (pen test, red team) or when automated validation is architecturally impossible. | Critical/High finding closure (F-04); control test results (F-01); incident post-mortem validation (F-06) | Flows that specify "Evidence Required" should note the minimum tier. Where E3 is not feasible (e.g., architecturally impossible to test), the rationale must be documented in the record. --- ## 18. LLM Execution Directives These instructions tell an LLM how to execute the flows without ambiguity: 1. **Always identify the primary record before taking action.** If no primary record exists, create it first. 2. **Always assign exactly one accountable role.** Supporting roles may be many; accountability must be singular. 3. **If an issue is pre-production, default owner is Engineering.** If post-production, default owner is Risk. If it concerns standards, exceptions, evidence, or reporting, include Governance. 4. **Never close a finding based on implementation evidence alone.** Require validation from Risk. 5. **Never treat control deviation informally.** If deadline or control intent cannot be met, route to an Exception Record. 6. **If required owner, classification, or evidence is missing, mark the item blocked or gap-open and create a finding or risk as defined by the relevant flow.** 7. **At closure of any major event, require a feedback destination:** standards, procedure, metric, backlog, risk register, or no-change-with-rationale. 8. **If SLA breach occurs, escalate according to the flow; do not silently continue.** 9. **Use canonical CERG role names and record names consistently.** 10. **Prefer evidence generation during execution over retrospective evidence collection.** --- ## 19. Flow-to-CAT-002 Record Crosswalk FLOW does not maintain standalone record templates. Use [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) §3 for minimum required fields and §4 for canonical record names, owners, triggers, and evidence value. Use the source procedure or template named in CAT-002 for record-specific fields. | Flow | Primary CAT-002 record | Source of detailed fields | |---|---|---| | F-01 Control Intent | Control Implementation Record | CAT-002 §4.1; CB-001; FLOW F-01 evidence plan | | F-02 Project Intake | Project Security Review Record; Threat Model Record | PRC-AR-001; PRC-TM-001; TMPL-AR-001 where used | | F-03 Asset Registration | Asset Inventory Record; Asset Coverage Record | STD-AM-001; FLOW F-03 coverage requirements | | F-04 Finding Treatment | Finding Record; Risk Register Entry; Security Exception Record; Risk Acceptance Record | PRC-VM-001; PRC-RM-001; TMPL-RM-002; TMPL-RM-004 | | F-05 Change & Release | Security Change Review Record | PRC-CHG-001 and local change system fields | | F-06 Incident Support | IR-owned Incident Record; Lessons Learned Record; Program Improvement Record | PLN-IR-001; PRC-IR-002; PRC-LL-001; CAT-002 incident boundary rules | | F-07 Metrics & Oversight | Reporting Metric Record; Oversight Decision Record; Program Improvement Record | MTR-001; IMPREG-001; CAT-002 §4.1 | If a local tool cannot use the CAT-002 canonical name directly, store the canonical record type as a tag, custom field, evidence-index value, or cross-reference. Local names are aliases, not separate record authority. --- ## 20. Recommended Implementation Sequence ### Phase 1 Implement: - Global contract (§1-7) - Shared state models (§8) - Flow F-02 (Project Intake / Architecture Review / Threat Model) - Flow F-03 (Asset Registration / Coverage Validation) - Flow F-04 (Finding to Remediation / Exception / Risk) ### Phase 2 Implement: - Flow F-05 (Change and Release Security Routing) - Flow F-06 (Incident to Recovery to Standards Feedback) ### Phase 3 Implement: - Flow F-01 (Control Intent to Implementation) - Flow F-07 (Metrics, Oversight, and Improvement Routing) --- ## 21. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-FLOW-001 | | **Version** | 1.4 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed operations | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.4 | 2026-06-18 | Governance Pillar Leader | Converted FLOW record sections into CAT-002 crosswalks, removed local record-template authority, updated primary-record names to CAT-002 canonical records, and clarified alias handling. | | 1.3 | 2026-06-18 | Governance Pillar Leader | Replaced F-04 competing severity SLA table with PRC-VM SLA authority, removed contradictory closure rules, and aligned residual-risk acceptance with RMF-001 §9.7. | | 1.2 | 2026-06-18 | Governance Pillar Leader | Rewrote F-06 to preserve Incident Commander / standing IR team authority for active incident operations while defining CERG support, evidence, and post-incident improvement routing. | | 1.1 | 2026-06-17 | Governance Pillar Leader | Added AI routing rules to F-02, including AI intake, sanctioned-tool register, system/model register, and escalation criteria for sensitive data, regulated scope, consequential decisions, and autonomous agency. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Seven cross-pillar operational flows, five shared state models, five minimum record templates, LLM execution directives, and recommended implementation sequence. | ### Review Triggers - Change to the CERG Operating Model (OM-001) - Change to the Risk Management Framework (RMF-001) - Change to the Control Baseline (CB-001) - Material incident or audit finding that exposes a flow gap - Direction from the CISO Governance owns this document. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical roles and pillar structure | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk treatment, exception, and acceptance rules | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control inventory and evidence standards | | Compliance Matrix | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) | Regulatory and framework mapping | | Metrics and Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Metric definitions and reporting cadence | | Annual Calendar | [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | Operating rhythm and cadence | | Architecture Review Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Project intake and architecture review process | | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Governs AI use categories, AI-specific threats, sanctioned tools, and shadow AI | | AI Intake and Sanctioning Template | [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | Required AI intake record for F-02 where AI is in scope | | Sanctioned AI Tools Register Template | [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) | Register updated when consumed AI tools are approved | | AI System and Model Register Template | [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | Register updated when built or embedded AI systems are approved | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Exception and risk acceptance workflow | | Incident Response Plan | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Standing IR procedures | --- ### Cyber Engineering, Risk & Governance: CERG Framework > **How to read this matrix:** Each row represents a security _intent_, the underlying goal that multiple frameworks are all trying to achieve. The regulatory and NIST columns show where each framework addresses that intent. Where multiple frameworks align to one row, a single control effort satisfies all of them. Items marked **⚠ Unique** have requirements that don't fully overlap with the other frameworks and warrant dedicated attention. --- | | | |---|---| | **Document ID** | CERG-GOV-CMX-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on framework version change | | **Frameworks** | NIST 800-53r5; NIST 800-171r3; NIST CSF 2.0; NIST RMF | | **Regulations** | NERC-CIP; CMMC L2; SOX ITGC | | **Environments** | All in-scope environments | --- ## Table of Contents 1. [Know what you own: maintain an authoritative asset inventory](#1-know-what-you-own-maintain-an-authoritative-asset-inventory) 2. [Identify and remediate known vulnerabilities on a defined schedule](#2-identify-and-remediate-known-vulnerabilities-on-a-defined-schedule) 3. [Control who can access what: enforce least privilege](#3-control-who-can-access-what-enforce-least-privilege) 4. [Authenticate users and systems: verify identity before granting access](#4-authenticate-users-and-systems-verify-identity-before-granting-access) 5. [Harden systems: remove what isn't needed, lock down what is](#5-harden-systems-remove-what-isnt-needed-lock-down-what-is) 6. [Protect data in transit and at rest: encryption as a baseline control](#6-protect-data-in-transit-and-at-rest-encryption-as-a-baseline-control) 7. [Segment networks: limit lateral movement and blast radius](#7-segment-networks-limit-lateral-movement-and-blast-radius) 8. [Manage vendor and third-party risk: extend controls beyond the perimeter](#8-manage-vendor-and-third-party-risk-extend-controls-beyond-the-perimeter) 9. [Control and log privileged/remote access: know who did what, when](#9-control-and-log-privilegedremote-access-know-who-did-what-when) 10. [Conduct adversarial testing: find what scanners miss](#10-conduct-adversarial-testing-find-what-scanners-miss) 11. [Train and background-check personnel with access to sensitive systems](#11-train-and-background-check-personnel-with-access-to-sensitive-systems) 12. [Write and maintain policies: define what good looks like](#12-write-and-maintain-policies-define-what-good-looks-like) 13. [Manage configuration changes: track drift, prevent unauthorized changes](#13-manage-configuration-changes-track-drift-prevent-unauthorized-changes) 14. [Collect, protect, and retain audit evidence: prove controls are working](#14-collect-protect-and-retain-audit-evidence-prove-controls-are-working) 15. [Assess your own security posture: periodic internal evaluation](#15-assess-your-own-security-posture-periodic-internal-evaluation) 16. [Manage risk formally: document, accept, or treat identified risks](#16-manage-risk-formally-document-accept-or-treat-identified-risks) 17. [Protect physical access to critical systems: cyber starts at the door](#17-protect-physical-access-to-critical-systems-cyber-starts-at-the-door) 18. [Monitor threats continuously: detect what vulnerability scans miss](#18-monitor-threats-continuously-detect-what-vulnerability-scans-miss) 19. [Plan and practice incident response: know what to do before it happens](#19-plan-and-practice-incident-response-know-what-to-do-before-it-happens) 20. [Manage recovery: restore operations and capture lessons learned](#20-manage-recovery-restore-operations-and-capture-lessons-learned) 21. [Manage accounts throughout their lifecycle: provisioning through termination](#21-manage-accounts-throughout-their-lifecycle-provisioning-through-termination) 22. [Define and enforce a compliance calendar: no surprises at audit time](#22-define-and-enforce-a-compliance-calendar-no-surprises-at-audit-time) 23. [Quick Reference: Pillar Summary](#quick-reference-pillar-summary) 24. [Key Consolidation Opportunities](#key-consolidation-opportunities) 23. [Document Control](#document-control) ## 1. Know what you own: maintain an authoritative asset inventory **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) IDENTIFY · 800-53 CM-8 · 800-171 3.4.1 · RMF Step 1| |NERC-CIP|CIP-002 (BES asset categorization)| |[CMMC](https://dodcio.defense.gov/CMMC/)|CM.2.061| **What "done" looks like:** Living asset register with classification, owner, and regulatory designation (BES/CUI). Engineering produces at project handoff; Risk validates via scan coverage. --- ## 2. Identify and remediate known vulnerabilities on a defined schedule **Primary Pillar:** Risk **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) IDENTIFY · 800-53 SI-2, RA-5 · 800-171 3.11.2 · RMF Step 6| |NERC-CIP|CIP-007-6 R2 (patch management), CIP-010 R3 (vuln assessment)| |[CMMC](https://dodcio.defense.gov/CMMC/)|RM.2.141, SI.2.214| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC patch/change risk| **What "done" looks like:** Continuous scan coverage across IT and OT; prioritized finding register with SLA tracking; deviation/exception process for OT-constrained systems. --- ## 3. Control who can access what: enforce least privilege **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 AC-2, AC-6 · 800-171 3.1.1–3.1.3 · RMF Step 3| |NERC-CIP|CIP-004 R4 (access management), CIP-005 R2 (interactive remote access)| |[CMMC](https://dodcio.defense.gov/CMMC/)|AC.1.001, AC.1.002, AC.2.006| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC access control (segregation of duties)| **What "done" looks like:** Role-based access model implemented; privileged access managed separately; access reviews on defined cycle; MFA enforced for remote and privileged access. --- ## 4. Authenticate users and systems: verify identity before granting access **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 IA-2, IA-5 · 800-171 3.5.1–3.5.3 · RMF Step 3| |NERC-CIP|CIP-005 R2 (EACMS authentication), CIP-007 R5 (account management)| |[CMMC](https://dodcio.defense.gov/CMMC/)|IA.1.076, IA.3.083| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC authentication controls| **What "done" looks like:** MFA deployed for all remote and privileged access; default/shared credentials eliminated; password policy enforced by technical control, not just policy. --- ## 5. Harden systems: remove what isn't needed, lock down what is **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 CM-6, CM-7 · 800-171 3.4.6, 3.4.7 · RMF Step 3| |NERC-CIP|CIP-007 R1 (ports and services), CIP-010 R1 (config baseline)| |[CMMC](https://dodcio.defense.gov/CMMC/)|CM.2.061, CM.2.064| **What "done" looks like:** Secure configuration baselines (CIS benchmarks or equivalent) documented and enforced for each platform class; deviation from baseline requires documented exception. --- ## 6. Protect data in transit and at rest: encryption as a baseline control **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 SC-8, SC-28 · 800-171 3.13.8, 3.13.10 · RMF Step 3| |NERC-CIP|CIP-011 (BES Cyber System Information protection)| |[CMMC](https://dodcio.defense.gov/CMMC/)|SC.3.177, SC.3.187| **What "done" looks like:** Encryption standards defined and applied to all CUI/BCSI environments; key management process documented; TLS enforced on all external-facing interfaces. --- ## 7. Segment networks: limit lateral movement and blast radius **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 SC-7 · 800-171 3.13.1 · RMF Step 3| |NERC-CIP|CIP-005 (Electronic Security Perimeters and EAPs)| |[CMMC](https://dodcio.defense.gov/CMMC/)|SC.1.175| **What "done" looks like:** Documented network zones with access control lists; OT/ICS and CUI environments isolated; ESP/EAP documented for all BES Cyber Systems. --- ## 8. Manage vendor and third-party risk: extend controls beyond the perimeter **Primary Pillar:** Risk **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 SA-9, SR-3 · 800-171 3.1.20 · RMF Step 2| |NERC-CIP|CIP-013 (supply chain risk management)| |[CMMC](https://dodcio.defense.gov/CMMC/)|SR.3.169| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC third-party SOC 2 review| **What "done" looks like:** Vendor risk assessment program with tiered review depth; contract security requirements (right-to-audit, incident notification, data handling); supply chain risk management plan. --- ## 9. Control and log privileged/remote access: know who did what, when **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 AU-2, AU-12, AC-17 · 800-171 3.3.1 · RMF Step 3| |NERC-CIP|CIP-005 R2 (interactive remote access), CIP-007 R4 (security event logging)| |[CMMC](https://dodcio.defense.gov/CMMC/)|AU.2.041, AU.2.042| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC access logging and review| **What "done" looks like:** All privileged and remote sessions logged; session recordings for high-risk access; log retention per regulatory requirement; log review process defined and tracked. --- ## 10. Conduct adversarial testing: find what scanners miss **Primary Pillar:** Risk **Regulations:** [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST **⚠ Unique:** No direct NERC-CIP analog |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) IDENTIFY · 800-53 CA-8 · 800-171 3.11.1 · RMF Step 4| |[CMMC](https://dodcio.defense.gov/CMMC/)|CA.2.157 (pen test as part of assessment)| **What "done" looks like:** Annual minimum pen test schedule; scope includes internal, external, and (where applicable) OT/ICS targets; findings tracked to closure with Engineering review of architectural impacts. --- ## 11. Train and background-check personnel with access to sensitive systems **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 PS-2, AT-2 · 800-171 3.9.1 · RMF Step 1| |NERC-CIP|CIP-004 (personnel training and risk assessment)| |[CMMC](https://dodcio.defense.gov/CMMC/)|PS.2.127, AT.2.056| **What "done" looks like:** Role-based training program with completion tracking; background check process for privileged users; CIP-004 training records maintained per regulatory retention requirement. --- ## 12. Write and maintain policies: define what good looks like **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 PL-1, PM-1 · 800-171 3.12.4 · RMF Step 1| |NERC-CIP|CIP-003 (security management controls, senior manager approval)| |[CMMC](https://dodcio.defense.gov/CMMC/)|All 14 domains require policy documentation| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC policy requirements| **What "done" looks like:** Policy library version-controlled and reviewed on defined cycle; each policy mapped to regulatory citation; senior leader approval documented; implementation guidance published for each policy. --- ## 13. Manage configuration changes: track drift, prevent unauthorized changes **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 CM-3, CM-5 · 800-171 3.4.3 · RMF Step 3| |NERC-CIP|CIP-010 R1 (configuration change management)| |[CMMC](https://dodcio.defense.gov/CMMC/)|CM.2.062| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC change management (key [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC control)| **What "done" looks like:** All changes to in-scope systems go through documented change process; baseline comparison before/after; unauthorized change detection via config monitoring; [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) change tickets retained as audit evidence. --- ## 14. Collect, protect, and retain audit evidence: prove controls are working **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 AU-9, AU-11 · 800-171 3.3.2 · RMF Step 6| |NERC-CIP|CIP-007 R4 (log retention), all CIP standards require evidence retention| |[CMMC](https://dodcio.defense.gov/CMMC/)|AU.2.042, all domain documentation| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|Audit trail retention for ITGC and financial system access| **What "done" looks like:** Evidence library organized by control and regulatory citation; retention periods enforced per framework (NERC-CIP: per standard, [CMMC](https://dodcio.defense.gov/CMMC/): available for assessment, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204): per audit retention requirements); pre-audit evidence review process. --- ## 15. Assess your own security posture: periodic internal evaluation **Primary Pillar:** Risk **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) IDENTIFY · 800-53 CA-2 · 800-171 3.12.1 · RMF Step 4| |NERC-CIP|CIP-010 R3 (annual vuln assessment)| |[CMMC](https://dodcio.defense.gov/CMMC/)|CA.2.157 (assessment of security requirements)| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC control self-assessment| **What "done" looks like:** Annual security assessment cycle with documented scope, findings, and remediation plan; self-assessment results feed risk register and POA&M; Governance tracks findings to closure. --- ## 16. Manage risk formally: document, accept, or treat identified risks **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 RA-3, PM-9 · 800-171 3.11.1 · RMF Step 4–5| |NERC-CIP|CIP-003 (risk management), deviation/mitigation plan process| |[CMMC](https://dodcio.defense.gov/CMMC/)|RM.2.141, RM.3.144 (POA&M management)| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|Enterprise risk management (ERM) interface| **What "done" looks like:** Risk register maintained with owner, severity, treatment status, and target closure date; POA&M current and leadership-reviewed quarterly; risk acceptance documented with CISO or VP sign-off per policy. --- ## 17. Protect physical access to critical systems: cyber starts at the door **Primary Pillar:** Governance **Regulations:** NERC-CIP · · NIST **⚠ Unique:** NERC-CIP most prescriptive, CIP-006/CIP-014 unique to BES environments |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 PE-2, PE-3 · RMF Step 3| |NERC-CIP|CIP-006 (physical security of BES Cyber Systems), CIP-014 (transmission physical security)| **What "done" looks like:** Physical access controls documented for all in-scope locations; access lists maintained and reviewed; visitor logs retained; NERC-CIP deviation process invoked when physical security controls are temporarily impaired. --- ## 18. Monitor threats continuously: detect what vulnerability scans miss **Primary Pillar:** Risk **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) DETECT · 800-53 SI-4, IR-4 · 800-171 3.14.6 · RMF Step 6| |NERC-CIP|CIP-007 R4 (security event monitoring)| |[CMMC](https://dodcio.defense.gov/CMMC/)|SI.2.216, IR.2.092| **What "done" looks like:** SIEM or equivalent collecting logs from in-scope systems; defined alert thresholds; analyst review cadence; threat intelligence feeds integrated; OT monitoring via passive methods where active scanning would introduce operational risk. --- ## 19. Plan and practice incident response: know what to do before it happens **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) RESPOND · 800-53 IR-2, IR-4, IR-8 · 800-171 3.6.1–3.6.3 · RMF Step 6| |NERC-CIP|CIP-008 (incident reporting and response planning)| |[CMMC](https://dodcio.defense.gov/CMMC/)|IR.2.092, IR.2.093| **What "done" looks like:** Documented IR plan with roles, escalation paths, and regulatory notification requirements; tabletop exercise at least annually; CIP-008 reporting timelines documented and practiced; lessons learned feed risk register. --- ## 20. Manage recovery: restore operations and capture lessons learned **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST **⚠ Unique:** CIP-009 unique to BES, highly prescriptive on testing cadence |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) RECOVER · 800-53 CP-2, CP-9 · 800-171 3.6.2 · RMF Step 6| |NERC-CIP|CIP-009 (recovery plans for BES Cyber Systems)| |[CMMC](https://dodcio.defense.gov/CMMC/)|RE.2.137| **What "done" looks like:** Recovery plans documented, tested, and updated annually; backup and restoration tested; post-incident review drives updates to Engineering architecture, Risk assessments, and Governance playbooks. --- ## 21. Manage accounts throughout their lifecycle: provisioning through termination **Primary Pillar:** Engineering **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) PROTECT · 800-53 AC-2 · 800-171 3.1.1 · RMF Step 3| |NERC-CIP|CIP-004 R4 (access management), CIP-007 R5 (account management)| |[CMMC](https://dodcio.defense.gov/CMMC/)|AC.2.005, AC.2.006| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|ITGC joiner/mover/leaver process| **What "done" looks like:** Automated provisioning/deprovisioning tied to HR system; access reviews on defined cycle; privileged account inventory; shared/service account governance documented. --- ## 22. Define and enforce a compliance calendar: no surprises at audit time **Primary Pillar:** Governance **Regulations:** NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) · NIST **⚠ Unique:** Governance operational discipline, no direct technical control analog |Framework|Requirement| |---|---| |NIST|[CSF](https://www.nist.gov/cyberframework) GOVERN · 800-53 PM-14 · RMF Step 6| |NERC-CIP|All CIP standards have annual and periodic review requirements| |[CMMC](https://dodcio.defense.gov/CMMC/)|Annual self-assessment or C3PAO assessment cycle| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)|Annual ITGC audit cycle| **What "done" looks like:** Master compliance calendar covering all frameworks; activities assigned to owners in CERG; upcoming deadlines visible to CISO; evidence collection treated as ongoing, not pre-audit scramble. --- ## Quick Reference: Pillar Summary |Pillar|Control Areas Owned|Key Frameworks Satisfied| |---|---|---| |**Engineering**|Asset inventory · Least privilege · Authentication · System hardening · Encryption · Network segmentation · Logging · Config change management · Account lifecycle|NERC-CIP CIP-005/007/010/011 · [CMMC](https://dodcio.defense.gov/CMMC/) AC/IA/SC/CM domains · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC| |**Risk**|Exposure management · Vendor risk · Adversarial testing · Self-assessment · Threat monitoring|NERC-CIP CIP-007/010/013 · [CMMC](https://dodcio.defense.gov/CMMC/) RM/CA/SI domains · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) third-party| |**Governance**|Policy & standards · Personnel training · Evidence management · Risk register · Physical security · IR planning · Recovery · Compliance calendar|NERC-CIP CIP-003/004/006/008/009/014 · [CMMC](https://dodcio.defense.gov/CMMC/) all documentation · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [CMMC](https://dodcio.defense.gov/CMMC/) SSP/POA&M| --- ## Key Consolidation Opportunities These control areas produce evidence satisfying four or more frameworks simultaneously. One team effort, multiple checkboxes. 1. **Asset inventory**, CIP-002 + [CMMC](https://dodcio.defense.gov/CMMC/) CM + NIST CM-8 2. **Access management**, CIP-004/005/007 + [CMMC](https://dodcio.defense.gov/CMMC/) AC + [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC 3. **Configuration change management**, CIP-010 + [CMMC](https://dodcio.defense.gov/CMMC/) CM + [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC 4. **Audit evidence and log retention**, all CIP standards + [CMMC](https://dodcio.defense.gov/CMMC/) AU + [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) 5. **Exposure management**, CIP-007/010 + [CMMC](https://dodcio.defense.gov/CMMC/) RM/SI + [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) patch risk 6. **Policy and standards**, CIP-003 + [CMMC](https://dodcio.defense.gov/CMMC/) (all 14 domains) + [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC --- --- ## 23. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CMX-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on framework version change | | **Next Scheduled Review** | 2027-05-01 | | **Frameworks** | NIST 800-53r5; NIST 800-171r3; NIST CSF 2.0; NIST RMF | | **Regulations** | NERC-CIP; CMMC L2; SOX ITGC | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-01 | Cyber Governance | Initial release. Compliance matrix mapping security intents to NIST, CMMC, NERC-CIP, and SOX frameworks. | | 1.21 | 2026-05-22 | Cyber Governance | Updated framework references and pillar alignments. | ### Review Triggers - Framework version change (NIST 800-53, NIST 800-171, CMMC, NERC-CIP) - New regulatory requirement - Material change to organizational scope - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Unified Control Baseline | [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control spine, overlays, evidence mapping | | CERG Framework | [CERG-GOV-FRM-001](CERG-GOV-FRM-001_CERG_Framework.md) | Narrative framework | | Document Catalog | [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Master document inventory | --- ## 22 Control Areas Mapped to Security Risks: All Pillars · All Severity Levels > **How to read this document:** Each control area is mapped to the specific risk it prevents and how it differs from similar-looking controls. Where controls address overlapping threat categories, the nuance column explains the distinct failure mode each one guards against. --- | | | |---|---| | **Document ID** | CERG-GOV-TAX-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on framework or organizational change | | **Frameworks** | NIST CSF 2.0 (IDENTIFY); ISO/IEC 27001 A.5, A.8; NIST SP 800-53r5 RA-3, RA-5, RA-7 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope: IT, OT, Cloud | --- ## Theme 1 - Visibility: knowing what you own and what's happening ### 1.1 Know what you own: maintain an authoritative asset inventory **Pillar:** Engineering | **Severity:** Critical **Risk prevented:** Shadow IT and unmanaged attack surface. Assets you don't know exist can't be patched, monitored, or protected. Attackers routinely compromise forgotten systems, decommissioned servers, unregistered OT devices, contractor-managed endpoints, because they appear on no one's radar. **Nuance vs. similar controls:** The OT dimension is distinct from IT: an unregistered BES Cyber System isn't just an unpatched box, it's a potential NERC-CIP CIP-002 violation that could affect grid reliability and trigger enforcement. The risk isn't just exploitation; it's an invisible compliance gap and an unreported reliability asset. --- ### 1.2 Monitor threats continuously: detect what vulnerability scans miss **Pillar:** Risk | **Severity:** Critical **Risk prevented:** Undetected intrusion and dwell time. Vulnerability scans find known weaknesses at a point in time. Continuous monitoring catches active adversary behavior, lateral movement, credential misuse, anomalous data flows, that scans never see. The longer dwell time, the greater the blast radius. **Nuance vs. similar controls:** In OT environments, a missed intrusion isn't just a data breach, it's potential manipulation of physical processes. A compromised SCADA workstation detected at 30 days dwell looks entirely different from one detected at 6 months. The monitoring gap directly determines whether an incident stays contained or becomes an operational emergency. --- ### 1.3 Assess your own security posture: periodic internal evaluation **Pillar:** Risk | **Severity:** High **Risk prevented:** Unknown control failures and compliance drift. Controls degrade. Configurations change. People leave. Periodic self-assessment catches the gap between what the policy says and what is actually happening in the environment, before a regulator or adversary does. **Nuance vs. similar controls:** Where continuous monitoring catches active threats, self-assessment catches structural drift, a firewall rule opened for a project that was never closed, an access review that stopped happening when the person who ran it departed. The risk here is systemic erosion, not a single event. --- ## Theme 2 - Identity: controlling who gets in and what they can do ### 2.1 Control who can access what: enforce least privilege **Pillar:** Engineering | **Severity:** Critical **Risk prevented:** Over-privileged accounts as a force multiplier for attackers. When a compromised account has access to everything, attackers move laterally without needing to escalate. Least privilege limits the blast radius, an attacker operating within one account's permissions can only reach what that account can reach. **Nuance vs. similar controls:** Least privilege is architectural risk reduction, not detective. It doesn't stop the initial compromise, it limits what an attacker can do afterward. The absence of least privilege transforms every phishing success into a potential enterprise-wide breach. In OT environments, over-privileged accounts can reach control systems that have no detective controls to catch misuse. --- ### 2.2 Authenticate users and systems: verify identity before granting access **Pillar:** Engineering | **Severity:** Critical **Risk prevented:** Credential-based attacks and identity fraud. Weak or absent authentication is the entry point for most breaches, password spray, credential stuffing, phishing for MFA bypass, default credentials on OT devices. Authentication failure means the attacker is inside and appears legitimate. **Nuance vs. similar controls:** Authentication and least privilege are often confused. Authentication is the gate, does this person or system prove who they are? Least privilege is what happens after the gate. A strong authentication control with excessive permissions still produces a high-impact breach. A well-scoped account with weak authentication is still easily compromised. Both must be present. --- ### 2.3 Manage accounts throughout their lifecycle: provisioning through termination **Pillar:** Engineering | **Severity:** High **Risk prevented:** Orphaned credentials and insider threat via ghost accounts. Accounts not deprovisioned on departure become permanent backdoors, accessible to the former employee, to anyone who later obtains those credentials, or to attackers who enumerate inactive accounts. Provisioning failures (over-granting at hire) compound over time as roles change. **Nuance vs. similar controls:** Lifecycle management addresses a temporal risk that point-in-time authentication and access controls miss entirely. An account that was appropriate at hire may become a critical violation 18 months later after a role change. The specific failure mode is stale privilege accumulation, a risk that grows invisibly over time rather than from a single event. --- ### 2.4 Control and log privileged/remote access: know who did what, when **Pillar:** Engineering | **Severity:** High **Risk prevented:** Undetectable abuse of elevated permissions and remote sessions. Privileged access, local admin, domain admin, root, OT engineer credentials, is the primary target for attackers post-compromise. Without logging and session controls, privileged misuse (insider or external) is invisible and unattributable. **Nuance vs. similar controls:** This control addresses accountability and forensics, not prevention. Least privilege reduces what privileged accounts can reach; logging makes their actions visible afterward. The risk is not just breach, it's breach without attribution, which makes incident response impossible and regulatory reporting inaccurate. CIP-005 R2 treats unlogged remote access to BES systems as a reportable violation regardless of whether misuse occurred. --- ## Theme 3 - Hardening: reducing the attack surface of systems themselves ### 3.1 Harden systems: remove what isn't needed, lock down what is **Pillar:** Engineering | **Severity:** High **Risk prevented:** Unnecessary services and default configurations as entry points. Default credentials, open ports serving unused protocols, and unneeded services are free entry points for attackers. System hardening eliminates the attack surface that was never needed in the first place. **Nuance vs. similar controls:** Hardening is permanent risk reduction through design, distinct from patching (which addresses known vulnerabilities in needed software). An unneeded service running an unpatched protocol is doubly exposed, it wouldn't be exploitable at all if the service were disabled. In OT environments, CIP-007 R1 makes unnecessary ports and services a compliance finding independent of whether any vulnerability exists in them. --- ### 3.2 Segment networks: limit lateral movement and blast radius **Pillar:** Engineering | **Severity:** Critical **Risk prevented:** Unconstrained lateral movement enabling enterprise-wide compromise. Flat networks allow an attacker who compromises one endpoint to reach everything. Segmentation is the primary architectural control that limits an intrusion to the segment where it began. **Nuance vs. similar controls:** Segmentation and hardening both reduce attack surface, but at different layers. Hardening reduces what an attacker can exploit on a single system. Segmentation limits where an attacker can go after they've exploited it. For OT environments, the consequence is not just data loss, a flat IT/OT network means a ransomware event that begins in enterprise IT can reach operational control systems. CIP-005 ESP requirements exist because this failure mode affects grid reliability, not just data confidentiality. --- ### 3.3 Manage configuration changes: track drift, prevent unauthorized changes **Pillar:** Engineering | **Severity:** High **Risk prevented:** Configuration drift creating exploitable vulnerabilities and undetected tampering. Systems drift from their secure baselines over time, through patches, updates, human error, and deliberate tampering. Unauthorized configuration changes are a primary persistence technique for advanced attackers. **Nuance vs. similar controls:** Configuration management addresses a risk that hardening alone cannot, an initially hardened system that drifts back to an insecure state. The distinct risk here is change without authorization: an attacker who modifies a firewall rule or disables a logging agent has bypassed your controls without exploiting a CVE. [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) treats unauthorized changes to financial systems as a control failure independent of any security event. --- ### 3.4 Protect data in transit and at rest: encryption as a baseline control **Pillar:** Engineering | **Severity:** High **Risk prevented:** Data interception, exfiltration, and regulatory exposure for unprotected sensitive data. Unencrypted data in transit is readable by anyone on the network path. Unencrypted data at rest is readable by anyone with storage access. For CUI and BCSI, unencrypted data is a compliance violation independent of whether it was accessed. **Nuance vs. similar controls:** Encryption is a last-resort control, it assumes the perimeter has already failed and the data has been accessed. Its value is that even with access, the data is useless without the key. The OT-specific nuance: CIP-011 applies to BES Cyber System Information, not to operational data flows, protecting the documentation and configuration of grid systems, not the operational telemetry itself. --- ## Theme 4 - Exposure management: finding and fixing weaknesses before attackers do ### 4.1 Identify and remediate known vulnerabilities on a defined schedule **Pillar:** Risk | **Severity:** Critical **Risk prevented:** Known, exploitable vulnerabilities providing attackers a reliable entry point. The majority of successful breaches exploit known vulnerabilities for which patches exist. An unpatched CVE with a public exploit is a guaranteed entry point given sufficient attacker persistence. **Nuance vs. similar controls:** Exposure management in OT is categorically different from IT. A CVSS 9.x vulnerability in an enterprise server gets patched within 35 days. The same severity finding in a BES relay management workstation may require vendor testing before any patch can be applied, introducing a compliance tension between CIP-007-6 patch timelines and operational safety requirements. The risk calculus shifts: patching too fast can introduce reliability risk; patching too slow creates security and compliance exposure. --- ### 4.2 Conduct adversarial testing: find what scanners miss **Pillar:** Risk | **Severity:** High **Risk prevented:** Logic vulnerabilities, misconfigurations, and chained attack paths that automated scanning cannot find. Automated vulnerability scans find known CVEs. Penetration testing finds the things that have no CVE, overly permissive trust relationships, weak segmentation that passes a scan but fails under an active attack, authentication bypasses that require human ingenuity to construct. **Nuance vs. similar controls:** This is distinct from exposure management in both what it finds and what it validates. Exposure management confirms known weaknesses. Adversarial testing confirms that your controls actually work under adversarial conditions, that your network segmentation stops a real attacker, not just a scan. Segmentation testing validates that sensitive environments are actually isolated, not just documented. --- ## Theme 5 - Third-party and supply chain risk: extending controls beyond the perimeter ### 5.1 Manage vendor and third-party risk: extend controls beyond the perimeter **Pillar:** Risk | **Severity:** High **Risk prevented:** Trusted third-party access as a vector for breach and data exposure. Third parties with legitimate access to your environment are a primary attack vector, through their compromised credentials, their compromised infrastructure, or malicious code in their products. The SolarWinds supply chain attack demonstrated that even trusted, certified vendors can be weaponized. **Nuance vs. similar controls:** Vendor risk has two distinct threat models that require different controls. Access-based risk (the vendor has credentials or a connection into your environment) is addressed through access controls and remote access logging. Software supply chain risk (the vendor's product contains malicious or vulnerable code) is addressed through CIP-013 supply chain risk management controls and software integrity verification. These require different assessment frameworks, a vendor questionnaire doesn't catch a compromised software build pipeline. --- ## Theme 6 - Governance: the operating framework that makes everything else consistent ### 6.1 Write and maintain policies: define what good looks like **Pillar:** Governance | **Severity:** High **Risk prevented:** Inconsistent security decisions and unenforceable standards without written policy. Without documented policy, security decisions are made ad hoc, varying by person, by team, and by pressure. You cannot hold anyone accountable to a standard that was never written down, and regulators will cite the absence of policy as a standalone finding. **Nuance vs. similar controls:** Policy risk is distinct from technical control risk. A technically hardened system with no supporting policy has no mechanism for ensuring that hardening is maintained, that exceptions are managed, or that new systems are hardened to the same standard. Policy failure doesn't cause a breach directly, it causes the conditions under which breaches happen systematically rather than occasionally. --- ### 6.2 Train and background-check personnel with access to sensitive systems **Pillar:** Governance | **Severity:** High **Risk prevented:** Insider threat enablement and human error as the leading breach vector. Untrained personnel make security decisions without understanding consequences, clicking phishing links, misconfiguring systems, sharing credentials. Unvetted personnel with privileged access represent an unquantified insider threat. CIP-004 treats unvetted access to BES Cyber Systems as a reportable violation. **Nuance vs. similar controls:** Training and background checks address different threat profiles within the personnel risk category. Training reduces unintentional insider risk, the well-meaning employee who makes a dangerous mistake. Background checks address intentional insider risk, the person who should not have been granted access in the first place. Both are required; neither substitutes for the other. --- ### 6.3 Manage risk formally: document, accept, or treat identified risks **Pillar:** Governance | **Severity:** High **Risk prevented:** Untracked risk accumulation and accountability gaps when controls fail. Risks that are not formally documented tend to be informally ignored. When an accepted risk materializes into an incident, the absence of a documented risk decision means no one is accountable, no compensating controls were required, and there is no audit trail to demonstrate that the risk was understood. **Nuance vs. similar controls:** Risk management is not the same as exposure management. Exposure management tracks technical findings in systems. Risk management tracks organizational decisions, the choice to accept a finding, the compensating controls committed to in exchange for that acceptance, and the timeline for eventual remediation. The regulatory exposure for unmanaged risk is the absence of documented decisions, not the existence of vulnerabilities. --- ### 6.4 Collect, protect, and retain audit evidence: prove controls are working **Pillar:** Governance | **Severity:** High **Risk prevented:** Inability to demonstrate control effectiveness, triggering regulatory findings and enforcement. A control that cannot be evidenced is treated as a control that does not exist by regulators and auditors. Evidence loss or gaps, whether from poor retention practices or from failure to collect in the first place, can convert a security success into a compliance failure. **Nuance vs. similar controls:** Evidence risk is bureaucratic, not technical. You can have a fully functioning security program that fails an audit because no one collected the records proving it functioned. The distinct failure mode: a pre-audit scramble to reconstruct evidence often produces incomplete or inconsistent records that create more questions than they answer. NERC-CIP evidence retention is explicitly tiered by standard and requirement, loss of required evidence is itself a potential violation. --- ### 6.5 Define and enforce a compliance calendar: no surprises at audit time **Pillar:** Governance | **Severity:** Medium **Risk prevented:** Missed regulatory deadlines and last-minute compliance failures under time pressure. Compliance obligations have hard deadlines, annual NERC-CIP evidence reviews, C3PAO assessment cycles, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC audit milestones. Organizations that don't track these systematically miss them, producing findings that would have been preventable with basic operational discipline. **Nuance vs. similar controls:** The calendar is a meta-control, it doesn't prevent any specific attack, but its absence causes compliance failures across every framework simultaneously. A missed [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC audit milestone is a different risk than a missed annual NERC-CIP vulnerability assessment: one creates financial-control audit exposure, the other can produce an enforcement notice. The calendar ensures the right activity reaches the right people with sufficient lead time to actually happen. --- ### 6.6 Plan and practice incident response: know what to do before it happens **Pillar:** Governance | **Severity:** Critical **Risk prevented:** Chaotic, slow, or incorrect response that amplifies breach impact. Untested incident response plans fail under the stress of an actual incident, people don't know their roles, communications break down, regulatory notification timelines are missed. The incident itself may be unavoidable; poor response execution is not. **Nuance vs. similar controls:** IR planning and IR execution are different risks. An untested plan is a documented assumption, it may be entirely wrong about how an incident actually unfolds. CIP-008 makes the gap concrete: a utility that experiences a reportable cybersecurity incident without a tested, compliant IR plan faces both the incident impact and an enforcement action for the plan failure. The NERC regulatory notification clock starts running whether or not the utility is ready. --- ### 6.7 Manage recovery: restore operations and capture lessons learned **Pillar:** Governance | **Severity:** Critical **Risk prevented:** Extended outages and repeated incidents from failure to restore and learn. Recovery capability determines how long an organization remains impaired after a significant event. For BES environments, extended recovery directly translates to grid reliability risk. Absent lessons learned, the same vulnerability or process failure recurs. **Nuance vs. similar controls:** Recovery risk is often treated as identical to IR risk, but they address different phases. IR is about containing and investigating; recovery is about restoring operations safely. CIP-009 is notably prescriptive about testing cadence specifically because restoration of a BES Cyber System that fails introduces its own reliability risk. The lesson-learned function is what converts a security incident into a permanent improvement, its absence means incidents are events rather than inputs. --- ### 6.8 Protect physical access to critical systems: cyber starts at the door **Pillar:** Governance | **Severity:** High **Risk prevented:** Physical bypass of all logical controls. An attacker with physical access to a system can bypass authentication, install hardware implants, exfiltrate data directly, and destroy equipment, all without triggering a single network-based alert. Physical security is the control that all cyber controls depend on. **Nuance vs. similar controls:** CIP-006 is unique in treating physical access to BES Cyber Systems as a distinct compliance requirement, not because physical threats are new, but because the consequence of physical compromise to a substation or control center is a reliability event, not just a data breach. --- ## Quick Reference: Severity Summary |Severity|Control Areas| |---|---| |**Critical**|Asset inventory · Threat monitoring · Least privilege · Authentication · Network segmentation · Exposure management · IR planning · Recovery| |**High**|Self-assessment · Account lifecycle · Privileged access logging · System hardening · Config change management · Encryption · Adversarial testing · Vendor risk · Policy & standards · Personnel training · Risk management · Audit evidence · Physical security| |**Medium**|Compliance calendar| --- ## Quick Reference: Pillar Summary |Pillar|Control Areas Owned| |---|---| |**Engineering**|Asset inventory · Least privilege · Authentication · Account lifecycle · Privileged access logging · System hardening · Network segmentation · Config change management · Encryption| |**Risk**|Threat monitoring · Self-assessment · Exposure management · Adversarial testing · Vendor risk| |**Governance**|IR planning · Recovery · Physical security · Policy & standards · Personnel training · Risk management · Audit evidence · Compliance calendar| --- --- ## Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-TAX-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on framework or organizational change | | **Next Scheduled Review** | 2027-05-01 | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-01 | Cyber Risk | Initial release. Risk taxonomy with categories, definitions, and control mappings. | | 1.21 | 2026-05-22 | Cyber Risk | Updated category definitions and regulatory mappings. | ### Review Triggers - New regulatory framework affecting risk categories - Material change to organizational scope or structure - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Risk Register and Exception Process | [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Uses taxonomy for risk categorization | | Document Catalog | [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Master document inventory | --- ## ANNUAL SECURITY AND GOVERNANCE CALENDAR ### Program Cadence · Control Reviews · Audit Readiness · Exercises · Board Reporting --- | | | |---|---| | **Document ID** | CERG-GOV-CAL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | | **Review Cycle** | Annual / On major program, regulatory, or reporting cadence change | | **Frameworks** | NIST CSF 2.0 GOVERN · NIST 800-53r5 PM, CA · ISO/IEC 27001 Clauses 9 and 10 | | **Regulations** | Cross-cutting; SOX, CMMC, NERC-CIP, privacy, customer assurance where applicable | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Calendar Rules](#2-calendar-rules) 3. [Standing Cadence Summary](#3-standing-cadence-summary) 4. [Annual Calendar by Quarter](#4-annual-calendar-by-quarter) 5. [Monthly Operating Rhythm](#5-monthly-operating-rhythm) 6. [Quarterly Operating Rhythm](#6-quarterly-operating-rhythm) 7. [Annual Operating Rhythm](#7-annual-operating-rhythm) 8. [Event-Driven Triggers](#8-event-driven-triggers) 9. [Calendar Maintenance](#9-calendar-maintenance) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope CERG contains review cycles, reporting cycles, test cadences, evidence refreshes, access reviews, tabletop exercises, audits, board reporting, DR tests, policy reviews, vendor reviews, and maturity assessments across many documents. This calendar consolidates those recurring obligations into one operating instrument. It applies to all CERG-owned governance, risk, engineering, audit, evidence, and reporting activities. It does not replace the detail in each governing standard or procedure. It gives the CISO, Governance Pillar Leader, Risk Pillar Leader, Engineering Pillar Leader, and Evidence Librarian a single look-ahead view of what must happen, when, and who owns it. > **A Program That Has No Calendar Has No Operating System** > > Policies say what must be true. Procedures say how work happens. The calendar says when the program proves it. Without a calendar, every review becomes a surprise, every audit becomes a scramble, and every control owner becomes a heroic exception handler. --- ## 2. Calendar Rules 1. The calendar is maintained by the Governance Pillar Leader. 2. Each activity has exactly one accountable role, using canonical roles from `CERG-GOV-RAC-001`. 3. The more specific source document controls when a cadence conflict exists. 4. Evidence-producing activities create or refresh evidence under `CERG-PRC-AUD-001`. 5. Missed calendar activities are tracked as program findings or risk-register entries. 6. Activities may be consolidated for small teams, but the role accountability does not disappear. 7. Regulated-scope activities are not moved without approval from the appropriate accountable role. --- ## 3. Standing Cadence Summary | **Cadence** | **Activity** | **Accountable Role** | **Primary Evidence** | **Source** | |---|---|---|---|---| | Daily / Continuous | Critical risk, exposure, logging, backup, identity, and monitoring signals reviewed through dashboards and queues. | Risk Pillar Leader | Dashboard snapshots, queue metrics, risk updates | `CERG-GOV-MTR-001`, `CERG-PRC-VM-001`, `CERG-STD-LM-001` | | Weekly | High-priority risk, exception, vulnerability, vendor, and audit blockers reviewed. | Risk Pillar Leader | Weekly action tracker | `CERG-PRC-RM-001`, `CERG-PRC-AUD-001` | | Monthly | CERG leadership operating review. | Governance Pillar Leader | Monthly leadership report | `CERG-GOV-MTR-001`, `CERG-TMPL-MTR-001` | | Monthly | CERG service-level commitment (SLC) adherence review. | CISO / Pillar Leaders | SLC adherence snapshot (SR-004) | `CERG-GOV-SLC-001`, `CERG-GOV-MTR-001` | | Monthly | POA&M and remediation status review. | Risk Register Owner | POA&M status report | `CERG-TMPL-CUI-002`, `CERG-PRC-RM-001` | | Monthly | Asset inventory reconciliation. | Engineering Pillar Leader | Inventory export, reconciliation log | `CERG-STD-AM-001`, `CERG-GOV-CB-001` | | Monthly | Logging and detection coverage review. | Risk Pillar Leader | SIEM source inventory, coverage gap report | `CERG-STD-LM-001`, `CERG-GOV-CB-001` | | Quarterly | Access recertification and privileged access review. | Engineering Pillar Leader | Recertification report, PAM review | `CERG-STD-AC-001`, `CERG-GOV-CB-001` | | Quarterly | Metrics and risk posture brief to oversight forum. | Governance Pillar Leader | CISO / board reporting deck | `CERG-GOV-MTR-001`, `CERG-TMPL-MTR-001` | | Quarterly | Exception aging and renewal review. | Risk Register Owner | Exception register extract | `CERG-PRC-RM-001`, `CERG-TMPL-RM-002` | | Quarterly | Evidence quality sample. | Evidence Librarian | Evidence sample worksheet | `CERG-PRC-AUD-001`, `CERG-TMPL-AUD-001` | | Semiannual | Vendor tier refresh for Critical and High vendors. | Vendor Risk Analyst | TPRM refresh report | `CERG-PRC-TPRM-001`, `CERG-TMPL-TPRM-001` | | Annual | Policy, standard, procedure, plan, and template reviews. | Governance Pillar Leader | Review record, revision decision | `CERG-GOV-CAT-001` | | Annual | Maturity self-assessment. | Governance Pillar Leader | Maturity scorecard | `CERG-GOV-MAT-001` | | Annual | Disaster recovery and cyber recovery exercise. | Engineering Pillar Leader | DR test report, lessons learned | `CERG-PLN-BC-001`, `CERG-STD-RES-001` | | Annual | Tabletop exercise. | Risk Pillar Leader | Tabletop package and after-action items | `CERG-PRC-IR-002` | | Annual | Control baseline review. | Governance Pillar Leader | Baseline review record | `CERG-GOV-CB-001` | | Annual | Penetration test or adversarial validation planning and results review. | Risk Pillar Leader | Test plan, report, remediation tracker | `CERG-PRC-AV-001` | | Annual | ISO management review and internal audit package where ISO scope applies. | Governance Pillar Leader | Internal audit report, management review record | `CERG-PLN-ISO-001` | --- ## 4. Annual Calendar by Quarter ### Q1: Reset, Baseline, and Plan | **Month** | **Activity** | **Accountable Role** | **Output** | |---|---|---|---| | January | Confirm annual CERG calendar, owners, and regulated-scope milestones. | Governance Pillar Leader | Approved calendar and owner list | | January | Refresh artifact review schedule from the catalog. | Governance Pillar Leader | Document review tracker | | January | Review prior-year risks, exceptions, audit findings, POA&M items, and open executive actions. | Risk Pillar Leader | Prior-year closeout summary | | February | Confirm annual audit and assurance plan. | Evidence Librarian | Evidence request forecast | | February | Refresh vendor tiers for Critical and High providers. | Vendor Risk Analyst | Vendor tier report | | March | Prepare Q1 CISO / board posture deck. | Governance Pillar Leader | Q1 reporting deck | ### Q2: Evidence, Testing, and Assurance | **Month** | **Activity** | **Accountable Role** | **Output** | |---|---|---|---| | April | Run quarterly access review and privileged access review. | Engineering Pillar Leader | Access review evidence | | April | Execute evidence quality sample. | Evidence Librarian | Evidence sample worksheet | | May | Run tabletop exercise or scenario workshop. | Risk Pillar Leader | Tabletop after-action report | | May | Run crown-jewel scenario pressure-test (first half). | Risk Pillar Leader | Scenario pressure-test report; Finding Records for gaps | | May | Review threat modeling and architecture review throughput. | Engineering Pillar Leader | Architecture review metrics | | June | Prepare Q2 CISO / board posture deck. | Governance Pillar Leader | Q2 reporting deck | ### Q3: Resilience, Maturity, and Regulatory Readiness | **Month** | **Activity** | **Accountable Role** | **Output** | |---|---|---|---| | July | Run DR / cyber recovery exercise planning or execution. | Engineering Pillar Leader | DR exercise package | | July | Review backup immutability and restore evidence. | Engineering Pillar Leader | Backup assurance record | | August | Conduct maturity self-assessment. | Governance Pillar Leader | Maturity scorecard | | August | Refresh control baseline and control-to-procedure traceability. | Governance Pillar Leader | Baseline and traceability update | | September | Prepare Q3 CISO / board posture deck. | Governance Pillar Leader | Q3 reporting deck | ### Q4: Closeout, Certification, and Next-Year Planning | **Month** | **Activity** | **Accountable Role** | **Output** | |---|---|---|---| | October | Complete annual policy, standard, procedure, plan, and template reviews. | Governance Pillar Leader | Review records and revision backlog | | October | Review ISO, CMMC, SOX, CIP, privacy, and customer-assurance readiness. | Governance Pillar Leader | Assurance readiness summary | | November | Approve next-year cyber governance plan, test plan, and budget inputs. | Chief Information Security Officer (CISO) | Next-year plan | | November | Review exception aging and risk acceptance renewals before year end. | Risk Register Owner | Exception renewal packet | | November | Run crown-jewel scenario pressure-test (second half). | Risk Pillar Leader | Scenario pressure-test report; Finding Records for gaps | | December | Prepare Q4 / annual CISO and board posture deck. | Governance Pillar Leader | Annual reporting deck | --- ## 5. Monthly Operating Rhythm The monthly operating review uses a standard agenda: 1. material risk changes; 2. open Critical and High residual risks; 3. exception aging and upcoming expirations; 4. exposure and remediation SLA posture; 5. audit findings and evidence blockers; 6. vendor risk escalations; 7. project intake and threat modeling throughput; 8. metrics outside threshold; 9. decisions needed from the CISO or oversight forum; 10. open actions from the prior meeting. The output is a monthly action tracker and a metrics snapshot. The action tracker is not optional. If a meeting produces decisions but no action record, the program has no memory. --- ## 6. Quarterly Operating Rhythm The quarterly rhythm produces CISO or oversight reporting using `CERG-TMPL-MTR-001`. At minimum, the quarterly package includes: - posture summary and trend; - material risk changes; - open High and Critical risks; - exceptions opened, closed, expired, or renewed; - control and audit findings; - program maturity movement; - vendor and supply-chain risk movement; - incident and resilience summary; - decisions required from leadership. --- ## 7. Annual Operating Rhythm The annual rhythm resets the program. It includes: - artifact review and catalog reconciliation; - maturity self-assessment; - control baseline review; - annual assurance plan; - annual tabletop and recovery exercises; - annual review of regulated-scope requirements; - budget, staffing, and program planning input; - board / executive annual summary. Annual work should not wait until Q4. Q4 is for closeout and next-year planning, not for discovering that the year's required evidence was never collected. --- ## 8. Event-Driven Triggers Calendar activities also occur when triggered by events. | **Trigger** | **Required Calendar Action** | **Accountable Role** | |---|---|---| | Major incident | Post-incident review, risk updates, evidence preservation, recovery lessons learned | Risk Pillar Leader | | Material architecture change | Architecture review, threat modeling, risk treatment update | Engineering Pillar Leader | | New regulated scope | Catalog, control baseline, evidence, and reporting cadence review | Governance Pillar Leader | | New Critical or High vendor | TPRM assessment and executive risk decision where required | Vendor Risk Analyst | | Failed control test | POA&M entry, risk update, retest schedule | Evidence Librarian | | Missed recovery objective | DR plan update, risk entry, executive escalation | Engineering Pillar Leader | | New law, framework version, or customer obligation | Applicability assessment and artifact update plan | Governance Pillar Leader | --- ## 9. Calendar Maintenance The Governance Pillar Leader maintains this calendar. The Evidence Librarian maintains evidence that required activities occurred. The Risk Register Owner tracks missed or materially delayed activities when they create residual risk. Calendar maintenance includes: - annual confirmation of all recurring activities; - monthly review of upcoming activities due in the next 60 days; - quarterly reconciliation against the document catalog and planned artifacts; - update after any new artifact introduces a review cycle or evidence cadence; - removal of activities that are retired by approved catalog amendment. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CAL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on major program, regulatory, or reporting cadence change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST CSF 2.0 GOVERN; NIST 800-53r5 PM, CA; ISO/IEC 27001 Clauses 9 and 10 | | **Regulations** | Cross-cutting; SOX, CMMC, NERC-CIP, privacy, customer assurance where applicable | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes the annual CERG security and governance operating calendar, including monthly, quarterly, annual, and event-driven activities. | ### Review Triggers - New artifact introduces a recurring activity - Existing artifact changes review cycle or evidence cadence - New regulated scope enters CERG - CISO changes reporting cadence - Audit or assessment finding related to program cadence ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory and review trigger source | | Metrics Dashboard and Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Reporting cadence and dashboard source | | Maturity Self-Assessment and Scorecard | [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Annual maturity assessment source | | Consolidated Roles and RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Accountability source for calendar activities | --- ## CERG OPERATING MODEL ### Pillar Structure · Engagement Models · Staffing · Interaction Patterns --- | | | |---|---| | **Document ID** | CERG-GOV-OM-001 | | **Version** | 1.26 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Chief Information Security Officer | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Organizational Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · NIST RMF · ISO 27001 | | **Audience** | All CERG personnel; business sponsors; IT and OT leadership; executive leadership | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Operating Premise](#2-operating-premise) 3. [The Three Pillars](#3-the-three-pillars) 4. [Authority, Reporting, and Decision Rights](#4-authority-reporting-and-decision-rights) 5. [Engagement Models](#5-engagement-models) 6. [Staffing and Roles](#6-staffing-and-roles) 7. [Coordination Cadence](#7-coordination-cadence) 8. [Interfaces With Other Functions](#8-interfaces-with-other-functions) 9. [RACI Patterns](#9-raci-patterns) 10. [Maturity, Metrics, and the Adaptive Target](#10-maturity-metrics-and-the-adaptive-target) 11. [Operating Model Control](#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](CERG-POL-001_Cybersecurity_Policy.md) 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](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)** - 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](CERG-POL-001_Cybersecurity_Policy.md) and all subordinate documents - Compliance program management: NERC-CIP, [CMMC](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC, and customer-contractual frameworks - Risk register operation per **[CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md)** - 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`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) 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 | **Decision** | **Authority** | |---|---| | Policy approval ([CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) and subordinate standards) | CISO | | Standards / procedure approval | Pillar leader; CISO for material changes | | Risk acceptance - all severities | Per the canonical Risk Acceptance Authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 | | Exception approval | Per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) §8, which routes to RMF §9.7 for approval authority | | Incident classification & containment | Incident Commander (CISO or designee), per the standing IR team (see §3.4) | | External notification (regulator, public) | IC + CISO + Legal | | Pre-production go/no-go for in-scope projects | Engineering pillar leader with Risk input; escalation to CISO if business and CERG disagree | | Vendor onboarding approval (Tier 1) | Risk pillar leader; CISO for material risk exceptions | | New SaaS / cloud service approval | Governance + Engineering; CISO for Restricted-data placements | | Budget allocation across pillars | CISO | ### 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`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md), 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`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §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`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §9 and the risk-register reporting cadence in [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) §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`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md); early engagement only works if engaging CERG is fast. | **Phase** | **CERG Activity** | **Lead Pillar** | |---|---|---| | Concept | Lightweight architectural consult; data classification and environment-tier discussion. | Engineering | | Design | Formal security architecture review; reference-architecture / landing-zone selection; threat-model session for novel components. | Engineering (+ Risk for threat modeling) | | Build | Engineering partner embedded with the project team; pipeline gates configured; identity / cryptography / monitoring requirements implemented. | Engineering | | Pre-production | Pre-production security review; vulnerability assessment; pen-test where warranted; risk-register entries for any acceptance sought. | Engineering + Risk | | Production | Handoff to operations; baselines committed; ongoing CSPM / SSPM coverage; exposure management onboarding. | Engineering → Risk | | Continuous | Continuous monitoring; periodic re-review; governance evidence integration. | Risk + Governance | ### 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`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md). - Exposure management operates as a standing service per [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). - 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`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md), 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](https://dodcio.defense.gov/CMMC/) pre-assessment and assessment management - [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) 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: | Capability | Description | Primary Pillar | |-----------|-------------|---------------| | **Security Architecture** | Design review, threat modeling, pre-production assessment, pre-approved patterns | Engineering | | **Identity and Security Platform Engineering** | IdP architecture, PAM, secrets management, IaC, cloud landing zones, endpoint security platform | Engineering | | **Exposure Management** | Observation collection, exposure path validation, classification, treatment tracking, verification | Risk | | **Threat and Adversarial Validation** | Penetration testing, red team, purple team, threat intelligence production, detection validation | Risk | | **Third-Party Edge Management** | Vendor tiering and assessment, SaaS governance, MSP/MSSP requirements, SBOM, supply chain compromise response | Risk | | **Risk Register and Analysis** | Risk identification, scoring, treatment recommendation, appetite calibration, board reporting | Risk | | **Policy and Standards** | Policy authorship, standard maintenance, style governance, version control, regulatory citation mapping | Governance | | **Compliance and Evidence** | Evidence library management, control-to-evidence mapping, audit coordination, POA&M tracking, regulatory submissions | Governance | | **Metrics and Reporting** | CISO dashboard, board reporting, KRI/KPI maintenance, maturity assessment, stakeholder perception | Governance | | **Program Improvement** | Lessons learned, improvement register, control effectiveness testing, maturity advancement | Governance | | **Executive Risk Decision Support** | Cyber Oversight Group preparation, risk appetite affirmation, executive escalation, budget defense | CISO / Governance | 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:** | Small Team (≤5 people) | Capabilities Consolidated | |------------------------|--------------------------| | CISO / Security Lead | Executive Risk Decision Support + Risk Register + Program Improvement | | Security Engineer | Security Architecture + Identity/Platform Engineering + Exposure Management | | Risk Analyst | Threat/Adversarial Validation + Third-Party Edge Management | | Governance Lead | Policy/Standards + Compliance/Evidence + Metrics/Reporting | **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](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) 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. | Canonical Role | Pillar / Group | Common Synonyms (Do Not Use) | Primary Responsibilities | |---|---|---|---| | **Chief Information Security Officer (CISO)** | Executive | - | Strategy, board reporting, final authority on High and Critical risk acceptance per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. | | **Executive Sponsor** | Business / Executive | "VP," "Executive Sponsor," "Leadership" | Concurrence for Critical risk acceptance per RMF §9.7; business representative on the COG; named per system in the categorization register. | | **Engineering Pillar Leader** | Engineering | "Engineering Pillar Leader," "Engineering Manager" (when speaking of the pillar lead) | Pillar accountability; project intake; reference-architecture authority. | | **Cloud Security Engineer** | Engineering | "Cloud Security Engineer" | Cloud platforms, IaC, CSPM gating, landing-zone authority. | | **Identity Engineer** | Engineering | "Identity Engineer," "Identity Engineer" | IdP, MFA, SSO, PAM, secrets management, federation. | | **OT Security Engineer** | Engineering | "OT Security Engineer," "OT Security Engineer" | IT/OT convergence, ESP/EAP design, BES Cyber System baselines. | | **Application Security Engineer** | Engineering | "Application Security Engineer," "Application Security Engineer" | SAST/DAST, SDLC controls, threat modeling. | | **Endpoint Engineer** | Engineering | "Endpoint Engineer" | Endpoint, EDR, OS baselines. | | **Cryptography Engineer** | Engineering | "Cryptography Engineer" | Key management, CA hierarchy, TLS posture, FIPS compliance. | | **Pre-production Reviewer** | Engineering (rotated) | - | Owns the pre-production checklist; signs off on go-live readiness. | | **Risk Pillar Leader** | Risk | "Risk Pillar Leader" (when speaking of the lead), "Risk Manager" | Pillar accountability; exposure posture reporting; Medium severity risk-acceptance authority per RMF §9.7. | | **Exposure Management Lead** | Risk | "Exposure Management Lead" | Operates [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md); owns SLAs and posture metrics. | | **Adversarial Testing Lead** | Risk | "Adversarial Testing Lead," "Adversarial Testing Lead" | Operates [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md); pen test, red team, purple team. | | **Threat Intelligence Analyst** | Risk | "Threat Intelligence Analyst" | Threat-actor tracking; advisories; intel-to-detection translation. | | **Vendor Risk Analyst** | Risk | "Vendor Risk Analyst," "Vendor Risk Analyst" | Operates [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md); SCCT participation. | | **OT Risk Analyst** | Risk | - | OT-safe vuln assessment, ICS threat intelligence. | | **Identity Risk Analyst** | Risk | - | UEBA, identity-threat detection, OAuth and token risk. Mature-program specialization; in small teams the Detection Engineer or Risk Pillar Leader covers the work. | | **Detection Engineer** | Risk | "Detection Engineer," "Detection Engineer" | Detection-rule authoring; ATT&CK coverage; tuning lifecycle. | | **Governance Pillar Leader** | Governance | "Governance Pillar Leader," "Governance Pillar Leader" (when speaking of the lead) | Pillar accountability; regulator and auditor liaison; CISO reporting; Low and Informational severity risk-acceptance authority per RMF §9.7. | | **NERC-CIP Compliance Manager** | Governance | "NERC-CIP Compliance Manager" | OT and BES Cyber System compliance posture. | | **CMMC / Federal Compliance Manager** | Governance | "CMMC / Federal Compliance Manager" | CUI posture; SSP and POA&M maintenance. | | **SOX ITGC Lead** | Governance | "SOX ITGC Lead" | ITGC control evidence and audit coordination. | | **Policy & Standards Manager** | Governance | "Policy & Standards Manager" | Document library, version control, review cycles. | | **Risk Register Owner** | Governance | "Risk Register Owner" | Operates [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md); curates the register; runs the Monthly Risk Register Review. | | **Evidence Librarian** | Governance | - | Cross-framework evidence library curation. | | **Incident Commander** | Adjacent (IR team) | "IC" | Single-decision authority during an active incident. | | **Lead Investigator** | Adjacent (IR team) | - | Risk-side technical lead during an active incident. | > **"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 | **Role** | **Focus** | |---|---| | Engineering Pillar Leader | Pillar accountability; project intake; reference-architecture authority. | | Cloud Security Engineer | Cloud platforms, landing zones, IaC, CSPM gating. | | Identity Engineer | IdP, MFA, SSO, PAM, secrets management, federation. | | OT Security Engineer | IT/OT convergence, ESP/EAP design, BES Cyber System baselines (see [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md)). | | Application / Application Security Engineer | SAST/DAST integration, SDLC controls, threat modeling. | | Endpoint / Endpoint Engineer | Endpoint controls, EDR engineering, OS baselines. | | Cryptography Engineer | Key management, CA, TLS posture, FIPS compliance. | | Pre-production Reviewer (often a rotated function) | Owns the pre-production checklist; signs off on go-live readiness. | ### 6.3 Cyber Risk: Typical Roles | **Role** | **Focus** | |---|---| | Risk Pillar Leader | Pillar accountability; exposure posture reporting. | | Exposure Management Lead | Operates [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md); owns the SLAs and posture metrics. | | Detection Engineer | CSPM / SSPM operations and detection rules. | | Threat Intelligence Analyst | Source curation, internal advisories, detection translation. | | Adversarial Testing Lead (Red Team) | Internal or partner-managed offensive validation. | | Vendor / Third-Party Risk Analyst | Vendor assessment and continuous monitoring. | | OT Risk Analyst | OT-safe vulnerability assessment; ICS threat intelligence. | | Identity Risk Analyst | UEBA, identity-threat detection, OAuth / token risk. Mature-program specialization; consolidated under Detection Engineer / Risk Pillar Leader in smaller teams. | ### 6.4 Cyber Governance: Typical Roles | **Role** | **Focus** | |---|---| | Governance Pillar Leader | Pillar accountability; regulator and auditor liaison; CISO reporting. | | NERC-CIP Compliance Manager | OT/BES compliance posture (see [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md)). | | [CMMC](https://dodcio.defense.gov/CMMC/) / Federal Compliance Manager | CUI posture (see [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md)). | | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC Lead | ITGC control evidence and audit coordination. | | Policy & Standards Manager | Document library curation; review cycles. | | Risk Register Owner | Operates [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md); curates the register. | | Evidence Librarian | Maintains the cross-framework evidence library. | | Governance Pillar Leader (IR liaison) | Supports the standing IR team with evidence, reporting, regulatory context, and lessons-learned intake. The standing IR team, not CERG Governance, maintains [CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md), runs IR exercises, and owns notification clocks. | ### 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. | **Forum** | **Cadence** | **Participants** | **Purpose** | |---|---|---|---| | CERG Leadership Sync | Weekly | CISO + pillar leaders | Cross-pillar priorities, blockers, escalations. | | Risk Posture Review (High / Critical items) | Weekly | Risk + Engineering + Governance | Top-of-list High and Critical risks, treatment progress, SLA breaches. Aligns with [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §8.2 weekly cadence for High and Critical items. | | Monthly Risk Register Review (full register) | Monthly | Risk Register Owner + Risk + Engineering + Governance | Full register pass, POA&M status, treatment closures, exception renewals. Aligns with [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §8.2 monthly full cadence. | | Pre-production Review Board | Twice weekly | Engineering + Risk + Governance | Pre-production go/no-go for in-scope projects. | | Vulnerability Triage | Daily / standing | Risk team + Engineering rep | PPR / Critical / Internet-exposed findings per [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5.2. | | Threat Intelligence Brief | Weekly | Risk + Engineering + Governance | Relevant intel, posture implications. | | Compliance Pulse | Bi-weekly | Governance + Engineering + Risk | Open compliance items, evidence gaps, regulator calendar. | | CERG All-Hands | Monthly | All CERG | Program updates, recognition, knowledge sharing. | | Cyber Oversight Group (COG) | Monthly | Per §4.4 | Cyber posture, cross-functional risk treatment alignment, pre-board review. | | CISO Risk & Posture Review | Quarterly | CISO + leadership | Material risks, posture trends, regulatory cycle, budget. | | Succession Readiness Review | Quarterly (concurrent with CISO Risk & Posture Review) | CISO + pillar leaders + HR business partner | Successor identification, readiness assessments per [`CERG-GOV-SUCC-001`](CERG-GOV-SUCC-001_Succession_Planning_and_Talent_Review_Framework.md), development plan progress, critical role risk. | | Board Cyber Brief | Quarterly (per board protocol) | CISO → Audit / Risk / Tech Committee | Posture, material incidents, top risks, program initiatives. | > **Incident Response cadence** --- ## 8. Interfaces With Other Functions CERG operates inside a broader organizational ecosystem. The following interfaces are explicit. | **Function** | **Interface** | |---|---| | **Incident Response (standing team)** | Owns [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md). CERG feeds detection telemetry, vulnerability context, asset documentation, and post-incident risk-register entries. During an active incident, CERG provides Lead Investigator (Risk), Engineering Lead, and Governance Lead roles per the IR team's call. | | **Security Awareness** | Awareness owns training program design, delivery cadence, completion evidence, and phishing-simulation communications. Governance coordinates policy/control content alignment and evidence quality; Risk provides threat-actor context and may support phishing-simulation analysis. CERG does not own enterprise training completion or awareness campaign operations. | | **Internal Audit** | Receives evidence from Governance; engages SMEs from Engineering and Risk; findings tracked in the risk register. | | **Legal** | Engaged at activation for Sev 1/2 incidents; engaged for regulatory interpretation, breach notification, customer contractual obligations, and privilege judgments. | | **Privacy / DPO** | Coordinates with Governance on Restricted-data handling and breach notification under GDPR / HIPAA / state laws. | | **Enterprise Risk Management** | Receives quarterly cyber risk feed at the Cyber Oversight Group (§4.4); interface ensures cyber risks appear in enterprise risk reporting. | | **Internal Communications / PR** | Engaged for material incident communications and major program announcements. | | **Procurement / Vendor Management** | Coordinates third-party assessments and DFARS / CMMC flow-down; Governance is the security signatory. | | **Human Resources** | Coordinates joiner / mover / leaver, personnel risk assessments (NERC-CIP CIP-004), and disciplinary referrals for willful non-compliance. | | **IT Operations** | Executes Engineering-designed controls; jointly owns endpoint, server, network, and SaaS administration. | | **OT Operations** | Co-owns CIP-008 incident response, CIP-007 patching cycles, and ESP/EAP architecture. CERG defers to operations on grid-impact judgments. | | **Business Unit Owners** | Sponsor systems, approve treatments, own residual risk for systems in scope. Designated Executive Sponsors sit on the Cyber Oversight Group when systems in their scope are on the agenda. | | **Executive Leadership and the Board** | Receive standing CISO reporting via the COG; engaged on Sev 1 incidents and material risk decisions. | --- ## 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`](CERG-POL-001_Cybersecurity_Policy.md) §10 has its own. Role names follow the canonical roster in §6.1. ### 9.1 New Cloud Workload Goes Live | **Activity** | **Engineering** | **Risk** | **Governance** | **Business Owner** | **CISO** | |---|---|---|---|---|---| | Approve architecture and landing-zone selection | **R / A** | C | C | C | I | | Implement IAM, network, monitoring controls | **R** | C | I | C | I | | Pre-production vulnerability assessment | C | **R / A** | I | C | I | | Approve go-live | **R** | C | C | **A** | I | | Onboard to CSPM and exposure management | C | **R / A** | I | I | I | | Add to compliance evidence library | C | I | **R / A** | I | I | ### 9.2 Open High Vulnerability Past SLA | **Activity** | **Engineering** | **Risk** | **Governance** | **Business Owner** | **CISO** | |---|---|---|---|---|---| | Identify SLA breach and escalate | I | **R / A** | I | I | I | | Recommend compensating controls | **R / A** | C | C | C | I | | Decide treatment (remediate / mitigate / accept) | C | C | C | **A** | I (review for High+) | | Approve risk acceptance (if High) | I | C | C | C | **A** | | Record in risk register | I | C | **R / A** | I | I | ### 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. | **Activity** | **Engineering** | **Risk** | **Governance** | **Business Owner** | **CISO** | |---|---|---|---|---|---| | Maintain SSP and POA&M | C | C | **R / A** | I | I | | Conduct self-assessment | C | **R** | **A** | C | I | | Submit SPRS score | I | C | **R / A** | I | I | | C3PAO engagement | I | C | **R / A** | I | C | | Remediate POA&M items | **R** | C | **A** | C | I | --- ## 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`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §3; this section names the indicators only. | **Indicator** | **What It Measures** | **Canonical Metric ID** | |---|---|---| | % of in-scope assets in real-time inventory | Visibility | MTR-001 ID-001 | | % of new projects passing pre-production review on first attempt | Engineering quality and "shift left" effectiveness | MTR-001 CM-002 | | Median time-to-remediate by severity | Risk responsiveness | MTR-001 RM-003 / VM-001 | | % of findings within SLA | Risk discipline | MTR-001 VM-001 / VM-002 | | Open exception count and median age | Governance discipline | MTR-001 RM-004 / RM-005 | | % of risks reviewed within scheduled review date | Risk register health | MTR-001 RM-002 | | % of identified High risks with active treatment plans | Treatment discipline | MTR-001 RM-001 | | Time from incident detection to containment (Sev 1/2) | Response capability (IR team owns) | (IR-owned; coordinated with MTR-001) | | % of IRT roles backstopped (no single point of failure) | Continuity | MTR-001 GV-003 | | Audit / assessor findings (count and severity) per cycle | External validation | MTR-001 GV-001 / GV-002 | | Phishing simulation susceptibility trend | Workforce posture (Awareness owns) | (Awareness-owned; coordinated with MTR-001) | | % of vendor reassessments current | Third-party risk discipline | MTR-001 TP-001 / TP-002 | ### 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: | Field | Example | |---|---| | Date | 2026-03-15 | | Participants | Cloud Security Engineer (Engineering), Threat Intelligence Analyst (Risk) | | Activity Type | Shadowing / Joint review / Cross-pillar presentation / Rotation assignment | | Topic | Threat modeling cloud architecture : Risk shares ATT&CK cloud matrix techniques; Engineering shares landing-zone design patterns | | Duration (hours) | 2 | 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 | | | |---|---| | **Document ID** | CERG-GOV-OM-001 | | **Version** | 1.26 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Chief Information Security Officer | | **Approved By** | CISO | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Organizational Change | | **Next Scheduled Review** | 2027-06-14 | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 · NIST RMF · ISO 27001 | | **Environments** | All in-scope environments | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.26 | 2026-06-18 | Governance Pillar Leader | Clarified Identity Risk Analyst as a mature-program specialization covered by Detection Engineer or Risk Pillar Leader in smaller teams. | | 1.25 | 2026-06-18 | Governance Pillar Leader | Clarified Security Awareness as an adjacent function: Awareness owns training operations while CERG coordinates content alignment, evidence quality, and threat context. | | 1.24 | 2026-06-18 | Governance Pillar Leader | Updated §4.4 COG membership with explicit standing-core and dynamic-per-agenda members (Business Unit Risk Owner for systems on agenda, Engineering/Risk pillar leaders as needed). Added COG Agenda Template with dynamic attendee section. | | 1.23 | 2026-06-14 | Governance Pillar Leader | Removed residual IR Plan Steward language and clarified that CERG provides IR support while the standing IR team owns the IR plan, exercises, notification clocks, and incident command. | | 1.0 | 2026-05-01 | CISO + Cyber Governance | Initial release. Establishes the three pillars, decision rights, engagement models, the canonical role roster (§6.1), the Cyber Oversight Group (§4.4), the standing coordination cadence aligned with CERG-RMF §8.2, and the maturity indicator set cross-referenced to CERG-GOV-MTR-001. Clarifies that the Incident Response plan and capability are owned by a standing IR team outside CERG; CERG provides liaison roles and feeds data into the IR program. | | 1.22 | 2026-05-26 | Cyber Governance | Added Section 10.4 Knowledge Transfer and Cross-Training: cross-training log schema, documentation completeness metrics (KM-001, KM-002), cross-training expectations (KM-003, minimum 4 hours/quarter), and maturity assessment integration for domain X5 Adaptive scoring. | ### 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`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md). The references below are the V1 library at a glance, grouped by role within the operating model. | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - defines the CERG operating model at the principle level | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative inventory of every CERG artifact | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control spine, overlays, evidence mapping | | Metrics, Dashboard, and CISO/Board Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | KRIs, KPIs, CISO dashboard | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Lifecycle, FAIR risk statement, canonical approval table, KRI definitions | | Compliance Matrix | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) | Cross-regulator control intent alignment | | Risk Taxonomy | [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) | Risk language and categorization | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Narrative framework document | | Grid Control Systems Security Standard | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT pillar adaptations | | IT (Hosted/Cloud/SaaS) Security Standard | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | IT, cloud, and SaaS pillar adaptations | | CUI Handling Standard | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | CUI scope, SSP/POA&M, CMMC L2 | | Access Management Standard | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Identity lifecycle, MFA, access reviews | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | DISH baselines | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Log sources, retention, detection coverage | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | RTO/RPO, backup, recovery | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Cipher, key, certificate lifecycle | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Canonical vulnerability remediation SLAs | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk register operating procedure | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Pre-production engagement | | Access Management Runbook | [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Identity lifecycle operations | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor tiering, SCCT | | Adversarial Validation Procedure | [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Pen test, red team, purple team | | Incident Response Plan | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Owned by the standing IR team; CERG provides liaison roles | | CUI / CMMC Operational Package | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | CUI/CMMC operational bundle | | NERC-CIP Operational Package | [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | NERC-CIP operational bundle | | SOX ITGC Operational Package | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | SOX ITGC operational bundle | | Risk Register Templates and Reporting | [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Register schema, report templates | --- ## CONSOLIDATED ROLES, RESPONSIBILITIES, AND RACI INSTRUMENT ### Canonical Role Reference · Master RACI · Role Descriptions · Scaling Map --- | | | |---|---| | **Document ID** | CERG-GOV-RAC-001 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) · [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) · [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | | **Review Cycle** | Annual / On any change to the canonical role roster or the artifact catalog | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (PM, PS families) · ISO/IEC 27001 A.5.2, A.5.4 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How This Instrument Relates to the Operating Model](#2-how-this-instrument-relates-to-the-operating-model) 3. [RACI Definitions and Rules](#3-raci-definitions-and-rules) 4. [The Canonical Role Reference](#4-the-canonical-role-reference) 5. [Master RACI: Document Ownership](#5-master-raci-document-ownership) 6. [Master RACI: Standing Processes](#6-master-raci-standing-processes) 7. [Role Descriptions](#7-role-descriptions) 8. [The Scaling Map](#8-the-scaling-map) 9. [Maintaining This Instrument](#9-maintaining-this-instrument) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 establishes the canonical role roster, the single source of truth for role names. §9 of that document gives three sample RACI patterns and states plainly that "specific RACI matrices are maintained per process." That sentence describes a document that did not exist. This is that document. This instrument consolidates, in one place: the canonical role reference, a master RACI for governed artifact stewardship and standing processes, a normalized description for each canonical role, and the scaling map that shows how the roles consolidate onto fewer people as a team gets smaller. It applies program-wide. It is the authoritative answer to two questions a CERG program is asked constantly: "who is accountable for this work?" and "who does what when this process runs?" It is not the authoritative artifact inventory, lifecycle-status register, or document-approval matrix; those are owned by [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md). > **One RACI, So the Answer Is Always the Same** > > Role ambiguity is the failure mode CERG was built to remove. When each document carries its own role table and its own RACI, those tables drift: a role is Accountable in one document and merely Consulted in another for the same work. A reader gets a different answer depending on which document they happen to open. This instrument is the single authoritative RACI. Where a subordinate document's role table disagrees with this instrument, this instrument governs, and the subordinate document is corrected on its next revision. --- ## 2. How This Instrument Relates to the Operating Model The division of labor is deliberate and must stay clean. | **Document** | **Owns** | |---|---| | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 | The canonical role roster: the authoritative list of role *names* and their synonyms. | | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | The authoritative artifact inventory, document ID scheme, lifecycle status, review tier, and approval authority by document type. | | This instrument (`CERG-GOV-RAC-001`) | The consolidated RACI and normalized role *descriptions*: who is Responsible, Accountable, Consulted, and Informed for recurring work and for stewardship of governed artifact families. | | Each standard, procedure, and plan | Its own subject matter. It may carry a local roles table for the reader's convenience, but that table conforms to this instrument and to the catalog authority model. | The Operating Model names the roles. CAT-001 inventories the artifacts and states document-type approval authority. This instrument assigns operating work and stewardship accountability. No new role is introduced here; if a role is needed that the roster does not contain, the roster is amended first, in the Operating Model, and only then does this instrument reference it. --- ## 3. RACI Definitions and Rules | **Letter** | **Meaning** | |---|---| | **R - Responsible** | Does the work. Can be more than one role. | | **A - Accountable** | Answerable for the outcome. Exactly one role per row. The A approves the work of the R. | | **C - Consulted** | Provides input before the work is done. Two-way communication. | | **I - Informed** | Told of the outcome. One-way communication. | Rules that govern every row in this instrument: 1. **Exactly one A per row.** Accountability is never shared. A row with two A's has no owner; a row with no A is unowned work. Either is a finding. 2. **A and R may be the same role.** On any team, and especially a small one, the role accountable for an outcome often also does the work. That is shown as **R/A**. 3. **The A cannot be only Informed.** A role accountable for an outcome is never merely Informed of it. 4. **Approval authority is not overridden here.** Where a row involves risk acceptance, the accountable approver is the one named in the authority table of [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. This instrument does not change who may accept risk. 5. **Roles are canonical.** Every role in this instrument is a canonical role from [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. No synonyms. --- ## 4. The Canonical Role Reference The 27 canonical roles, grouped by pillar, as established in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. This table is a reference copy for use with the RACI below; the Operating Model remains authoritative for the roster itself. | **Group** | **Canonical Roles** | **NICE Work Role Category** | |---|---|---| | Executive | Chief Information Security Officer (CISO); Executive Sponsor | OV (Oversee and Govern) | | Engineering | Engineering Pillar Leader; Cloud Security Engineer; Identity Engineer; OT Security Engineer; Application Security Engineer; Endpoint Engineer; Cryptography Engineer; Pre-production Reviewer | SP (Securely Provision), OM (Operate and Maintain) | | Risk | Risk Pillar Leader; Exposure Management Lead; Adversarial Testing Lead; Threat Intelligence Analyst; Vendor Risk Analyst; OT Risk Analyst; Identity Risk Analyst; Detection Engineer | PR (Protect and Defend), AN (Analyze) | | Governance | Governance Pillar Leader; NERC-CIP Compliance Manager; CMMC / Federal Compliance Manager; SOX ITGC Lead; Policy & Standards Manager; Risk Register Owner; Evidence Librarian | OV (Oversee and Govern) | | Adjacent (IR team) | Incident Commander; Lead Investigator | PR (Protect and Defend), IN (Investigate) | The two Adjacent roles belong to the standing Incident Response team, not to CERG, per [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4. They appear in this instrument only where CERG work interfaces with incident response. --- ## 5. Master RACI: Document Ownership This RACI assigns stewardship accountability for major governed artifact families and high-use artifacts: who maintains content (R), who is accountable for upkeep (A), and who is Consulted and Informed. The complete authoritative inventory, lifecycle status, and document-type approval authority remain in [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) §§4-5. If CAT-001 and this table appear to disagree about whether an artifact exists, its status, owner metadata, or formal approval path, CAT-001 governs; this table is then updated to align. Columns are abbreviated: **ENG-L** Engineering Pillar Leader, **RISK-L** Risk Pillar Leader, **GOV-L** Governance Pillar Leader, **P&S** Policy & Standards Manager, **CISO** Chief Information Security Officer. | **Artifact** | **ENG-L** | **RISK-L** | **GOV-L** | **P&S** | **CISO** | |---|---|---|---|---|---| | `CERG-POL-001` Cybersecurity Policy | C | C | R | C | **A** | | `CERG-GOV-FRM-001` CERG Framework | C | C | R | C | **A** | | `CERG-GOV-OM-001` Operating Model | C | C | **R/A** | C | C | | `CERG-GOV-CAT-001` Document Catalog | I | I | **A** | R | I | | `CERG-GOV-CB-001` Unified Control Baseline | C | C | **R/A** | C | I | | `CERG-GOV-MTR-001` Metrics and Reporting | C | C | **R/A** | C | C | | `CERG-GOV-RMF-001` Risk Management Framework | C | C | **R/A** | C | C | | `CERG-GOV-TAX-001` Risk Taxonomy | C | **R** | **A** | C | I | | `CERG-GOV-CMX-001` Compliance Matrix | C | C | **R/A** | C | I | | `CERG-GOV-IMP-001` Implementation and Adaptation Guide | C | C | **A** | R | C | | `CERG-GOV-VAR-001` Organization Adaptation Profile | C | I | **A** | R | I | | `CERG-GOV-MAT-001` Maturity Self-Assessment | C | C | **R/A** | C | C | | `CERG-GOV-RAC-001` This instrument | C | C | **A** | R | I | | `CERG-STD-IT-001` IT / Cloud / SaaS Security | **R** | C | **A** | C | I | | `CERG-STD-OT-001` Grid Control Systems Security | **R** | C | **A** | C | I | | `CERG-STD-CUI-001` CUI Handling | C | C | **R/A** | C | I | | `CERG-STD-AC-001` Access Management | **R** | C | **A** | C | I | | `CERG-STD-CFG-001` Secure Configuration Baseline | **R/A** | C | C | C | I | | `CERG-STD-LM-001` Logging, Monitoring, Detection | C | **R** | **A** | C | I | | `CERG-STD-RES-001` Cyber Resilience and Backup | **R/A** | C | C | C | I | | `CERG-STD-CR-001` Cryptography and Key Management | **R/A** | C | C | C | I | | `CERG-STD-SDL-001` Secure Software Development | **R/A** | C | C | C | I | | `CERG-STD-AM-001` Asset Management and Inventory | **R/A** | C | C | C | I | | `CERG-STD-NET-001` Network Security and Segmentation | **R/A** | C | C | C | I | | `CERG-STD-EP-001` Endpoint and Mobile Security | **R/A** | C | C | C | I | | `CERG-STD-DG-001` Data Governance and Classification | C | C | **R/A** | C | I | | `CERG-STD-AI-001` Artificial Intelligence Security | **R/A** | C | C | C | I | | `CERG-STD-MSG-001` Email and Messaging Security | **R/A** | C | C | C | I | | `CERG-PRC-VM-001` Exposure Management | C | **R/A** | C | C | I | | `CERG-PRC-RM-001` Risk Register and Exception Process | C | C | **R/A** | C | I | | `CERG-PRC-AR-001` Architecture Review and Project Intake | **R/A** | C | C | C | I | | `CERG-PRC-AC-002` Access Management Runbook | **R/A** | C | C | C | I | | `CERG-PRC-TPRM-001` Third-Party and Supply Chain Risk | C | **R/A** | C | C | I | | `CERG-PRC-AV-001` Adversarial Validation | C | **R/A** | C | C | I | | `CERG-PLN-IR-001` Incident Response Plan | C | C | C | I | C | | `CERG-PLN-CUI-001` CUI / CMMC Operational Package | C | C | **R/A** | C | I | | `CERG-PLN-CIP-001` NERC-CIP Operational Package | C | C | **R/A** | C | I | | `CERG-PLN-SOX-001` SOX ITGC Operational Package | C | C | **R/A** | C | I | | `CERG-TMPL-RM-001` Risk Register Templates | C | C | **R/A** | C | I | > **Standard Authorship Sits With Engineering; Standard Authority Sits With Governance** > > Several standards show the Engineering Pillar Leader as R/A. That is the working reality: Engineering writes and maintains the technical standards because Engineering holds the expertise. It does not change the approval authority in [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) §4, under which a standard is approved by the Governance Pillar Leader with CISO endorsement. The R/A in this table is accountability for the artifact's content and upkeep. The catalog governs who signs it into force. Both are true at once, and neither overrides the other. > > The Incident Response Plan shows no CERG role as A, by design: per [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4 it is owned by the standing IR team. CERG roles are Consulted and Informed only. --- ## 6. Master RACI: Standing Processes This RACI covers the recurring processes that make up the running program. It extends the three sample patterns in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §9 into a complete set. Columns: **ENG** Engineering pillar, **RISK** Risk pillar, **GOV** Governance pillar, **OWNER** Business or Asset Owner, **CISO** Chief Information Security Officer. A cell names the specific canonical role where one role within the pillar carries it. ### 6.1 Engagement and Build | **Process** | **ENG** | **RISK** | **GOV** | **OWNER** | **CISO** | |---|---|---|---|---|---| | Project intake and architecture review | **R/A** | C | C | C | I | | Threat modeling during design | C | **R** | I | C | I | | Secure development gate enforcement | **R/A** | C | I | I | I | | Pre-production review and go-live readiness | **R/A** Pre-production Reviewer | C | C | C | I | | Approve go-live | **R** | C | C | **A** | I | | Asset onboarding to the inventory | **R/A** | C | I | C | I | ### 6.2 Exposure and Risk | **Process** | **ENG** | **RISK** | **GOV** | **OWNER** | **CISO** | |---|---|---|---|---|---| | Exposure scanning and SLA tracking | C | **R/A** Exposure Management Lead | I | I | I | | Vulnerability remediation | **R** | C | I | **A** | I | | Adversarial validation (pen test, red team) | C | **R/A** Adversarial Testing Lead | I | I | I | | Threat intelligence collection and dissemination | C | **R/A** Threat Intelligence Analyst | C | I | I | | Risk register entry and curation | I | C | **R/A** Risk Register Owner | I | I | | Risk treatment decision | C | C | C | **A** | I (review High+) | | Risk acceptance approval | per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 | per RMF §9.7 | per RMF §9.7 | C | **A** for High+ | | Exception request and tracking | C | C | **R/A** Risk Register Owner | C | I | | Third-party and supply chain risk assessment | C | **R/A** Vendor Risk Analyst | C | C | I | ### 6.3 Governance and Assurance | **Process** | **ENG** | **RISK** | **GOV** | **OWNER** | **CISO** | |---|---|---|---|---|---| | Control evidence collection and curation | C | C | **R/A** Evidence Librarian | I | I | | Compliance posture tracking | C | C | **R/A** | I | I | | Audit and assessor liaison | C | C | **R/A** | I | C | | Metrics production and CISO dashboard | C | C | **R/A** | I | C | | Quarterly Cyber Oversight Group brief | C | C | **R** | I | **A** | | Document review-cycle management | C | C | **R/A** Policy & Standards Manager | I | I | | Maturity self-assessment | C | C | **R** Governance Pillar Leader | I | **A** | ### 6.4 Operations and Detection | **Process** | **ENG** | **RISK** | **GOV** | **OWNER** | **CISO** | |---|---|---|---|---|---| | Access provisioning and review | **R/A** Identity Engineer | C | C | C | I | | Detection content authoring and tuning | C | **R/A** Detection Engineer | I | I | I | | Logging and monitoring coverage | C | **R** Detection Engineer | **A** | I | I | | Incident detection handoff to the IR team | C | **R** | C | I | I | | Incident response operations | C (Engineering Lead) | C (Lead Investigator) | C (Governance Lead) | I | I | | Post-incident risk-register entry | I | C | **R/A** Risk Register Owner | I | I | > **Incident Response Is Supported, Not Owned** > > Section 6.4 shows incident response operations with CERG roles as Consulted, never Accountable. This is the boundary set by [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4. The standing IR team owns and runs the incident. CERG detects the incident, hands it off, supplies the Engineering Lead, Lead Investigator, and Governance Lead roles when the IR team calls for them, and afterward records the post-incident risk in the register. The Incident Commander, an Adjacent role, is Accountable for the incident itself, which is why no CERG column carries the A. --- ## 7. Role Descriptions A normalized one-paragraph description for each canonical role. These are the job-description stubs an adopting organization expands into full descriptions. Each names the role's accountability, its principal artifacts and processes from Sections 5 and 6, and its risk-acceptance authority where it has one. ### 7.1 Executive **Chief Information Security Officer (CISO).** Accountable for the cybersecurity program as a whole. Sets strategy, reports posture and material risk to executive leadership and the board, and holds final authority on High and Critical risk acceptance per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Accountable for the Cybersecurity Policy and the CERG Framework, and for the Quarterly Cyber Oversight Group brief. **Executive Sponsor.** The business voice in the program. Provides concurrence for Critical risk acceptance per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7, sits on the Cyber Oversight Group, and endorses the Cybersecurity Policy on behalf of the business. On a small team, provides the independent second view on risk acceptance where roles are otherwise consolidated. ### 7.2 Engineering **Engineering Pillar Leader.** Accountable for the Cyber Engineering pillar: project intake, reference architecture, and the secure build of the estate. Accountable for the technical standards authored by Engineering, including configuration, resilience, cryptography, secure development, asset management, network, endpoint, AI, and email security. Resolves software risk-tier disputes. **Cloud Security Engineer.** Owns cloud and SaaS platform security: infrastructure-as-code, cloud posture management, the landing zone, cloud network security, and the email and messaging platforms where they are SaaS. Responsible for shadow-IT and shadow-AI discovery through cloud signals. **Identity Engineer.** Owns identity and access engineering: the identity provider, multi-factor authentication, single sign-on, privileged access management, secrets management, and federation. Responsible for access provisioning and review and for the Access Management Runbook. **OT Security Engineer.** Owns operational technology security engineering: IT/OT convergence, the electronic security perimeter, the IT/OT boundary design, and BES Cyber System baselines. Responsible for OT-safe asset discovery and transient cyber asset control. **Application Security Engineer.** Owns application security: SAST, DAST, and SCA rulesets, threat modeling, secure-development gate content, and the security of in-house and embedded AI systems. Accountable for the Secure Software Development and the Artificial Intelligence Security standards. **Endpoint Engineer.** Owns endpoint and mobile security: endpoint and mobile baselines, the management and endpoint detection and response platforms, and the device posture signal consumed by the network and access standards. Accountable for the Endpoint and Mobile Security Standard. **Cryptography Engineer.** Owns cryptography and key management: the key management and secrets platforms, the certificate authority hierarchy, transport security posture, and FIPS compliance. Supports rotation of exposed secrets. **Pre-production Reviewer.** A rotated Engineering role. Owns the pre-production checklist and signs go-live readiness, confirming that pre-production findings are remediated or risk-accepted before a system goes live. ### 7.3 Risk **Risk Pillar Leader.** Accountable for the Cyber Risk pillar: the organization's exposure posture and the reporting of it. Holds Medium severity risk-acceptance authority per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. **Exposure Management Lead.** Operates the Exposure Management Procedure. Accountable for remediation SLAs and exposure posture metrics. **Adversarial Testing Lead.** Operates the Adversarial Validation Procedure: penetration testing, red team, and purple team exercises, and the tracking of their findings. **Threat Intelligence Analyst.** Owns threat-actor tracking, advisories, and the translation of intelligence into detection priorities. Disseminates intelligence to Engineering, Detection, and Governance. **Vendor Risk Analyst.** Operates the Third-Party and Supply Chain Risk Procedure: vendor tiering and assessment, supply chain coordination, and the assessment of third-party AI services. **OT Risk Analyst.** Owns OT-safe vulnerability assessment and industrial control system threat intelligence. **Identity Risk Analyst.** Owns identity-threat detection: user and entity behavior analytics, and OAuth and token risk. This is a mature-program specialization; in smaller teams the Detection Engineer or Risk Pillar Leader carries the work without deleting the role from the canonical architecture. **Detection Engineer.** Owns detection-rule authoring, ATT&CK coverage, and the tuning lifecycle. Responsible for logging and monitoring coverage and for handing detected incidents to the standing IR team. ### 7.4 Governance **Governance Pillar Leader.** Accountable for the Cyber Governance pillar: policy and standards, compliance, control evidence, the risk register, and audit response. Approves standards with CISO endorsement. Holds Low and Informational severity risk-acceptance authority per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Accountable for most governance instruments and operational packages. **NERC-CIP Compliance Manager.** Owns OT and BES Cyber System compliance posture and the NERC-CIP Operational Package. **CMMC / Federal Compliance Manager.** Owns CUI compliance posture, the System Security Plan and POA&M, and the CUI / CMMC Operational Package. **SOX ITGC Lead.** Owns IT general control evidence, audit coordination for SOX, and the SOX ITGC Operational Package. **Policy & Standards Manager.** Owns the document library: version control, review cycles, and naming-convention discipline. Responsible for the Document Catalog, the Implementation and Adaptation Guide, the Organization Adaptation Profile, and this instrument. **Risk Register Owner.** Operates the Risk Register and Exception Process. Curates the register, runs the Monthly Risk Register Review, and records post-incident risks. **Evidence Librarian.** Owns the cross-framework evidence library: collection, curation, and retention of control evidence for audit. ### 7.5 Adjacent (Incident Response team) **Incident Commander.** Single-decision authority during an active incident. An Incident Response team role, not a CERG role; included here because CERG processes hand off to it. **Lead Investigator.** The risk-side technical lead during an active incident. An Incident Response team role; CERG supplies practitioners into incident roles when the IR team calls for them. --- ## 8. The Scaling Map The canonical role roster is fixed at 27 roles. A small team does not delete roles; it assigns several roles to one person. This is the principle established in [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §6. This section makes the consolidation concrete so a small team can see exactly who holds what. ### 8.1 The Rule Every one of the 27 roles is held by someone. On a large team that is close to one role per person. On a small team one person holds many roles. The RACI in Sections 5 and 6 does not change when the team shrinks; only the map from role to person changes. A process with the Exposure Management Lead as R/A still has an R/A when that role is held by the same person who is also the Risk Pillar Leader. The work is still owned. ### 8.2 Reference Consolidation: Five-Person Team | **Person** | **Holds These Canonical Roles** | |---|---| | 1 | Chief Information Security Officer (CISO) | | 2 | Governance Pillar Leader; Policy & Standards Manager; Risk Register Owner; Evidence Librarian; and the applicable Compliance Manager roles for regulators in scope | | 3 | Risk Pillar Leader; Exposure Management Lead; Adversarial Testing Lead; Threat Intelligence Analyst; Vendor Risk Analyst; Detection Engineer; Identity Risk Analyst | | 4 | Engineering Pillar Leader; Cloud Security Engineer; Identity Engineer; Pre-production Reviewer | | 5 | Application Security Engineer; Endpoint Engineer; Cryptography Engineer; OT Security Engineer where OT is in scope | The Executive Sponsor is a business role, held by a business leader outside the security team in every team size. The Adjacent IR roles belong to the IR team. ### 8.3 The One Constraint That Does Not Scale Down Risk-acceptance authority does not consolidate freely. The separation of the person who assesses a risk from the person who accepts it holds at every team size, per [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Where consolidation would put assessment and acceptance of a High or Critical risk in the same person, the Executive Sponsor provides the independent acceptance. A small team consolidates work; it does not consolidate away the second set of eyes on consequential risk. > **A Consolidated Role Is Still an Owned Role** > > The point of the scaling map is that it changes nothing in the RACI. When person 3 on a five-person team holds six Risk roles, every process those six roles own still has exactly one Accountable role, and that role still has a name, and that name still maps to a person. The day the team hires a seventh person, a role lifts cleanly off person 3 and onto the new hire, because the role never stopped existing. This is why CERG consolidates roles and never deletes them. Deletion loses the work. Consolidation only stacks it, visibly, ready to be redistributed. --- ## 9. Maintaining This Instrument 1. **A new artifact is registered in CAT-001.** [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) is updated first because it is the inventory and lifecycle authority. Section 5 of this instrument is updated in the same change only when the new artifact creates a new stewardship pattern or changes accountability for an existing artifact family. 2. **A new process is added to Section 6.** When a new standing process is established by a standard or procedure, its RACI row is added to Section 6 unless the process is fully local to a single procedure and already covered by an existing standing-process row. 3. **A roster change flows from the Operating Model.** A role is never added, renamed, or retired here. That happens in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1, and this instrument is then updated to match. 4. **Subordinate documents conform to this instrument.** A standard or procedure whose local roles table disagrees with this instrument is corrected on its next revision, per the precedence rule in Section 1. 5. **The instrument is reviewed annually.** The review confirms every row still has exactly one A, every role is still canonical, and the scaling map still reflects the role roster. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-RAC-001 | | **Version** | 1.2 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the canonical role roster or the artifact catalog | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST CSF 2.0 (GOVERN); NIST 800-53r5 (PM, PS); ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-18 | Governance Pillar Leader | Clarified Identity Risk Analyst as a mature-program specialization carried by Detection Engineer or Risk Pillar Leader in smaller teams. | | 1.1 | 2026-06-18 | Governance Pillar Leader | Clarified that CAT-001 owns artifact inventory, lifecycle status, and document-type approval authority while RAC-001 owns role and process accountability. | | 1.0 | 2026-05-21 | Cyber Governance | Initial release. Consolidates the per-process RACI that CERG-GOV-OM-001 §9 deferred. Establishes RACI definitions and rules, a canonical role reference, a master RACI for document ownership, a master RACI for standing processes across engagement, risk, governance, and operations, normalized descriptions for all 27 canonical roles, and a scaling map showing role consolidation onto a five-person team. | ### Review Triggers - A new artifact registered in [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) that changes a stewardship pattern or artifact-family accountability - A new standing process established by a standard or procedure - Any change to the canonical role roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - A change to the risk-acceptance authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Authoritative canonical role roster; the sample RACI this instrument completes | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory, lifecycle status, review tier, and per-type approval authority | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk-acceptance authority that this instrument does not override | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Role-consolidation principle that the scaling map makes concrete | --- ## CONTROL EFFECTIVENESS FRAMEWORK ### Effectiveness Measurement · Failure Analysis · Rationalization · Adaptive Maturity Integration --- | | | |---|---| | **Document ID** | CERG-GOV-CEF-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-GOV-TRC-001`](CERG-GOV-TRC-001_Control_to_Procedure_Traceability_Matrix.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-PRC-LL-001`](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | | **Review Cycle** | Annual / On control baseline revision | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.IM, PROTECT all categories) · NIST 800-55 · ISO/IEC 27004 | | **Regulations** | Cross-cutting : applies to all CERG-supported frameworks | | **Environments** | All CERG-managed controls | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Why Implementation Is Not Effectiveness](#2-why-implementation-is-not-effectiveness) 3. [Effectiveness Measurement Model](#3-effectiveness-measurement-model) 4. [Control Family Effectiveness Metrics](#4-control-family-effectiveness-metrics) 5. [Control Failure Analysis](#5-control-failure-analysis) 6. [Control Rationalization](#6-control-rationalization) 7. [Integration with Maturity Assessment](#7-integration-with-maturity-assessment) 8. [Roles and Responsibilities](#8-roles-and-responsibilities) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope CERG's Unified Control Baseline (CB-001) tracks whether each control is Implemented, Partially Implemented, Inherited, Planned, Risk Accepted, or Not Applicable. That answers "is the control in place?" It does not answer "is the control working?" A control can be Implemented, baseline deployed, evidence collected, and yet be ineffective: poorly configured, bypassed in practice, defending against a threat vector that no longer applies, or generating alerts that nobody investigates. An organization that can only report implementation status is operating at Repeatable maturity. An organization that measures and acts on control effectiveness is operating at Adaptive maturity. This framework defines how CERG measures whether controls are working, analyzes why they fail, and rationalizes the control portfolio so that every control earns its place. > **The Assessor Test** > > An assessor asks: "Your access recertification control is Implemented. What percentage of recertifications result in access reduction?" If the answer is "We do not track that," the control may be rubber-stamping : present but not effective. If the answer is "12% of recertifications result in reduction, and we investigate when that falls below 5%," the control is being measured, not just checked. The difference is the gap between Repeatable and Adaptive. --- ## 2. Why Implementation Is Not Effectiveness ### 2.1 Four Ways an Implemented Control Can Be Ineffective | Failure Mode | Description | Example | |---|---|---| | **Design failure** | The control was designed for a threat that no longer applies, or was never correctly designed for the threat it was meant to address. | A WAF ruleset tuned for SQL injection in 2019 that does not cover the API-based attacks the organization now faces. | | **Implementation failure** | The control is correctly designed but was incorrectly deployed, configured, or scoped. | MFA is required by policy but was not enforced on the VPN gateway because the integration was misconfigured. | | **Operational failure** | The control is correctly designed and deployed but is not being operated : alerts are ignored, reviews are skipped, evidence is stale. | SIEM alerts fire for privileged account anomalies but the investigation queue has a 14-day backlog. | | **Coverage failure** | The control works where it is deployed but does not cover assets or environments that need it. | Endpoint EDR covers workstations but not the jump hosts used to access OT environments. | Each failure mode requires a different fix: redesign, re-implementation, operational discipline, or scope expansion. Knowing that a control is ineffective is not enough; the program must know why, so the fix addresses the root cause. ### 2.2 The Distinguishing Question For each control, the program must answer two questions: 1. **Implementation:** Is the control in place? (CB-001 answers this) 2. **Effectiveness:** Is the control producing its intended risk reduction? (This framework answers this) A control that cannot answer the second question is not yet at Adaptive maturity, regardless of its implementation status. --- ## 3. Effectiveness Measurement Model ### 3.1 Core Principle Every control family must have at least one effectiveness metric that is distinct from its implementation metric. The implementation metric confirms presence; the effectiveness metric confirms performance. ### 3.2 Metric Design Rules 1. **Effectiveness metrics are outcome-oriented.** "Access reviews completed on time" is an implementation metric. "Percentage of access reviews that resulted in access reduction" is an effectiveness metric : it measures whether the review is detecting and correcting real access creep. 2. **Effectiveness metrics have thresholds.** A metric without a threshold is a measurement without a decision. Each effectiveness metric defines green, amber, and red bands. 3. **Effectiveness metrics are trended.** A single-point effectiveness reading is nearly useless. Direction and rate of change tell the story. 4. **Effectiveness metrics trigger action.** When an effectiveness metric goes red, it triggers a control failure analysis (Section 5) and potentially an improvement register entry (IMPREG-001). > **The Signal-to-Noise Rule** > > An effectiveness metric that is always green is not measuring enough. An effectiveness metric that is always red is measuring too coarsely. The right metric produces a signal: it is green most of the time, amber when something needs attention, and red when the program must intervene. If the metric never moves, recalibrate the threshold. --- ## 4. Control Family Effectiveness Metrics For each control family in the baseline (CB-001 Section 3), the table below defines the effectiveness metric and distinguishes it from the implementation metric already tracked. ### 4.1 Access Control (AC) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | JML log present; recertification report exists; access reviews completed on schedule | **AC-EFF-001: Access Recertification Reduction Rate.** Percentage of recertification cycles where at least one access entitlement was reduced or removed per system. | If every recertification cycle confirms existing access without reduction, the review is confirming the status quo, not detecting access creep. Target: >= 70% of recertification cycles produce at least one reduction. | | Privileged account inventory maintained | **AC-EFF-002: Privileged Session Anomaly Investigation Rate.** Percentage of flagged privileged session anomalies that received investigation within SLA. | Alerts are implementation. Investigation is effectiveness. Target: >= 95% of flagged anomalies investigated within SLA. | ### 4.2 Configuration Management (CM) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | Baseline applied; drift rate reported | **CM-EFF-001: Mean Time to Remediate Drift.** Mean hours from drift detection to drift remediation, segmented by severity. | If drift is detected in 2 hours but remediated in 30 days, the baseline is present but not enforcing. Target: Critical drift remediated within 24 hours; High within 7 days. | | Change control records exist | **CM-EFF-002: Unauthorized Change Rate.** Percentage of detected changes that lacked a corresponding approved change record. | Measures whether the change control process actually controls changes. Target: < 2% unauthorized. | ### 4.3 Audit and Accountability (AU) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | SIEM source inventory; coverage report | **AU-EFF-001: Alert Investigation Rate.** Percentage of high-severity alerts that received investigation within SLA. | If alerts fire but nobody looks, detection is present but not effective. Target: >= 95% of high-severity alerts investigated within SLA. | | Log sources onboarded | **AU-EFF-002: Detection Gap Discovery Rate.** Number of incidents where a detection rule should have fired but did not, per quarter. | The best measure of log coverage is whether incidents are missed. Target: zero un-detected incidents per quarter; each one triggers a detection gap analysis. | ### 4.4 Risk Assessment (RA) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | Risk register exists; risks scored | **RA-EFF-001: Risk Treatment Effectiveness Rate.** Percentage of risks where the residual score decreased at the next review after treatment was applied. | If risks are documented and treated but residual scores never improve, the RMF is documenting, not managing. Target: >= 60% of treated risks show residual score decrease. | | Exceptions tracked | **RA-EFF-002: Exception Renewal Rate.** Percentage of expiring exceptions that are renewed vs. closed (remediated or accepted). | If every exception is renewed indefinitely, the exception process is a rubber stamp. Target: < 30% renewal rate. | ### 4.5 Contingency Planning (CP) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | Backup report; restore test exists | **CP-EFF-001: Restore Test RTO Compliance Rate.** Percentage of restore tests that met the defined RTO. | If tests pass but take longer than RTO, the plan is present but not viable. Target: >= 90% of restore tests meet RTO. | | DR plan documented | **CP-EFF-002: DR Plan Currency.** Percentage of DR plans updated within the review cycle (12 months). | An outdated DR plan is an untested assumption. Target: 100% current. | ### 4.6 Supply Chain Risk (SR, mapped to CERG TPRM domain) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | Vendor tiered; questionnaire on file | **SR-EFF-001: Vendor Event Blind-Spot Rate.** Percentage of Critical vendors where a reportable supply chain event occurred without CERG advance notice or within-SLA detection. | Measures whether vendor monitoring actually detects trouble before it impacts the organization. Target: 0%. | | SCCT defined | **SR-EFF-002: SCCT Activation Time.** Mean hours from trigger event to SCCT activation for Tier 1 vendors. | A supply chain crisis management team that takes 72 hours to convene is a paperwork exercise. Target: <= 4 hours. | ### 4.7 Incident Response Interface (IR) | Implementation Metric (exists) | Effectiveness Metric (new) | Rationale | |---|---|---| | IR plan exists; contact list current | **IR-EFF-001: IR Plan Exercise Coverage.** Percentage of IR plan scenarios exercised within 18 months. | An IR plan that has not been exercised is an untested document. Target: >= 80% of scenarios exercised within 18 months. | ### 4.8 System and Communications Protection (SC), System and Information Integrity (SI), Identification and Authentication (IA) These families map to multiple CERG standards (IT-001, NET-001, LM-001, CR-001, AC-001). Effectiveness metrics for these families are defined in their governing standards and reported through the metrics dashboard (MTR-001). This framework requires that each family have at least one effectiveness metric; the specific metric is defined in the standard that governs the family. ### 4.9 Cross-Family Effectiveness Summary | NIST Family | CERG Owner | Implementation Tracked In | Effectiveness Metric ID | Effectiveness Metric Name | |---|---|---|---|---| | AC | Engineering | CB-001 Section 6 | AC-EFF-001 | Access Recertification Reduction Rate | | AC | Engineering | CB-001 Section 6 | AC-EFF-002 | Privileged Session Anomaly Investigation Rate | | CM | Engineering | CB-001 Section 6 | CM-EFF-001 | Mean Time to Remediate Drift | | CM | Engineering | CB-001 Section 6 | CM-EFF-002 | Unauthorized Change Rate | | AU | Risk | CB-001 Section 6 | AU-EFF-001 | Alert Investigation Rate | | AU | Risk | CB-001 Section 6 | AU-EFF-002 | Detection Gap Discovery Rate | | RA | Governance | CB-001 Section 6 | RA-EFF-001 | Risk Treatment Effectiveness Rate | | RA | Governance | CB-001 Section 6 | RA-EFF-002 | Exception Renewal Rate | | CP | Engineering | CB-001 Section 6 | CP-EFF-001 | Restore Test RTO Compliance Rate | | CP | Engineering | CB-001 Section 6 | CP-EFF-002 | DR Plan Currency | | SR (TPRM) | Risk | CB-001 Section 6 | SR-EFF-001 | Vendor Event Blind-Spot Rate | | SR (TPRM) | Risk | CB-001 Section 6 | SR-EFF-002 | SCCT Activation Time | | IR | Risk (interface) | CB-001 Section 6 | IR-EFF-001 | IR Plan Exercise Coverage | Effectiveness metrics for AT, MA, MP, PE, PL, PM, PS, SA, SC, and SI families follow the same pattern: implementation tracked in CB-001 Section 6; effectiveness metric defined in the governing standard or this framework, to be populated as those standards mature. --- ## 5. Control Failure Analysis When a control that is marked Implemented in CB-001 fails to prevent or detect an incident, a Control Failure Analysis is required. The analysis determines whether the failure was in design, implementation, operation, or coverage : and therefore what kind of fix is needed. ### 5.1 Trigger Events A Control Failure Analysis is triggered by: - An incident that occurred despite a relevant control being marked Implemented - An adversarial validation finding that demonstrates a control bypass (PRC-AV-001) - An audit finding where the evidence shows the control was present but ineffective - An effectiveness metric in red for two consecutive reporting periods ### 5.2 Analysis Structure The accountable pillar leader conducts the analysis within 14 days of the trigger. The output is a structured analysis document containing: 1. **Which control failed?** Control ID from CB-001, implementation status, evidence on file. 2. **What was the failure mode?** Design / Implementation / Operational / Coverage (per Section 2.1). 3. **Why did it fail?** Root cause : not the symptom. "The WAF didn't block the attack" is the symptom. "The WAF ruleset was not updated to cover API-based attacks because there is no process for WAF rule lifecycle management" is the root cause. 4. **Was this a one-off or a systemic weakness?** Does the same root cause affect other controls? (Yes / Maybe / No, with rationale.) 5. **What is the corrective action?** If design failure: redesign the control. If implementation failure: fix the deployment. If operational failure: restore discipline, potentially with automation. If coverage failure: expand scope. 6. **What program change prevents recurrence?** Beyond fixing the immediate control, what standard, procedure, or tooling change prevents this class of failure from recurring elsewhere? This feeds into the improvement register (IMPREG-001). ### 5.3 Routing | Failure Mode | Corrective Action Owner | Program Change Routes To | |---|---|---| | Design | Pillar owner of the control | IMPREG-001 (control redesign) | | Implementation | Engineering Pillar Leader | Operational fix; if systemic, IMPREG-001 | | Operational | Procedure owner | Operational discipline restoration; if systemic, IMPREG-001 | | Coverage | Pillar owner of the control | IMPREG-001 (scope expansion) | ### 5.4 Analysis Registry A Control Failure Analysis Registry is maintained by the Governance Pillar Leader. It tracks: control ID, incident or trigger reference, failure mode, root cause, corrective action, program change IMPREG ID, and verification status. The registry is reviewed at the quarterly Lessons Aggregation Review (PRC-LL-001 Section 5). --- ## 6. Control Rationalization An Adaptive program does not only add controls. It removes controls that no longer reduce risk. Control bloat : the accumulation of controls added over years without corresponding retirement : creates compliance overhead without security benefit and dilutes attention from controls that matter. ### 6.1 Rationalization Cadence Control rationalization occurs annually as part of the control baseline review (GOV-CAL-001). The Governance Pillar Leader, with input from pillar leaders, reviews the entire control baseline for rationalization candidates. ### 6.2 Rationalization Criteria A control is a candidate for retirement if it meets any of these criteria: - **No trigger in 24 months.** The control has not been triggered, tested, or relevant to any incident, audit finding, or adversarial validation in 24 months. A control that never fires is either not needed or not being tested. - **Persistently low effectiveness.** The control's effectiveness metric has been red for 4+ consecutive quarters and attempts to improve effectiveness have failed. If the program cannot make the control work, the control may be the wrong design for the environment. - **Replaced by a superior control.** A new control, tool, or architecture makes the old control redundant. Example: a network segmentation rule that enforced separation between two environments that are now air-gapped at the physical layer. - **Threat vector no longer applicable.** The threat the control was designed to address no longer exists in the current threat landscape. Example: a control designed for a protocol the organization no longer uses. ### 6.3 Rationalization Process 1. **Candidate identification.** Governance Pillar Leader identifies candidates per the criteria above. 2. **Impact assessment.** For each candidate: what other controls, procedures, or evidence packages depend on it? What regulatory requirement does it satisfy? 3. **Pillar review.** Engineering and Risk pillar leaders confirm the candidate does not address a threat they are actively managing. 4. **CISO approval.** Control retirement requires CISO approval. 5. **Catalog amendment.** Retired controls are moved to Retired status in CB-001 and the catalog (CAT-001). The retirement rationale is documented. 6. **Improvement register entry.** Retirements are recorded in IMPREG-001 as program improvements (type: Retirement). > **Retirement Is Not Abandonment** > > A retired control is not deleted. It is moved to Retired status, the retirement rationale is documented, and the entry is retained for audit purposes. An assessor who asks "Why did you remove control X?" gets a documented answer with the date, rationale, and approver. A program that never retires a control is a program that has never critically examined its own portfolio. --- ## 7. Integration with Maturity Assessment The maturity self-assessment (MAT-001) currently scores domains based on evidence of process definition, execution, measurement, and review. This framework adds a control effectiveness dimension to the Adaptive tier. ### 7.1 MAT-001 Scoring Amendment For a domain to score Adaptive (Tier 4) in MAT-001, the following additional criteria apply: - At least one control in the domain has a defined effectiveness metric (from this framework) - The effectiveness metric has been measured for at least two consecutive quarters - At least one effectiveness-driven program change has been made (if warranted by the metric) and recorded in the improvement register (IMPREG-001) - A Control Failure Analysis has been completed for any control in the domain that failed to prevent or detect an incident (if such an incident occurred) ### 7.2 Evidence Requirements To substantiate an Adaptive score in a domain, the assessor should expect to see: - Effectiveness metric trend data (at least two quarters) - The improvement register entry resulting from an effectiveness metric signal - The Control Failure Analysis for any control failure in the domain (if applicable) - Verification evidence that the improvement had the intended effect --- ## 8. Roles and Responsibilities | Role | Responsibility | |---|---| | **Governance Pillar Leader** | Owns this framework. Maintains the Control Failure Analysis Registry. Conducts the annual control rationalization review. Updates effectiveness metrics in MTR-001. | | **Engineering Pillar Leader** | Defines and reports effectiveness metrics for Engineering-owned control families (AC, CM, CP, IA, MA, SC, SI). Conducts Control Failure Analyses for Engineering-owned controls. Participates in rationalization review. | | **Risk Pillar Leader** | Defines and reports effectiveness metrics for Risk-owned control families (AU, IR-interface, SR/TPRM). Conducts Control Failure Analyses for Risk-owned controls. Participates in rationalization review. | | **CISO** | Approves control retirements. Reviews the annual rationalization report. | | **Risk Register Owner** | Links control failure analyses to risk register entries when a control failure creates or changes a risk. | | **Adversarial Testing Lead** | Reports control bypass findings from adversarial validation as Control Failure Analysis triggers. | | **Policy & Standards Manager** | Executes catalog and CB-001 amendments for retired controls. Updates cross-references. | --- ## 9. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CEF-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / On control baseline revision | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST CSF 2.0 (ID.IM, PROTECT all categories); NIST 800-55; ISO/IEC 27004 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed controls | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-26 | Cyber Governance | Initial draft. Established the Control Effectiveness Framework: effectiveness metrics per control family, control failure analysis procedure, control rationalization process, and integration with the maturity self-assessment. Addresses NIST CSF Adaptive gap: measuring whether controls are working, not just whether they are in place. | --- ## CONTROL-TO-PROCEDURE TRACEABILITY MATRIX ### Control Baseline · Operational Procedure · Evidence · Gap Detection · Audit Routing --- | | | |---|---| | **Document ID** | CERG-GOV-TRC-001 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Control Baseline) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [`CERG-TMPL-AUD-001`](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) · [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | | **Review Cycle** | Annual / On control baseline, standard, procedure, or evidence model change | | **Frameworks** | NIST 800-53r5 · NIST 800-171r3 · NIST CSF 2.0 GOVERN · ISO/IEC 27001 | | **Regulations** | Cross-cutting; CMMC, NERC-CIP, SOX ITGC, privacy, customer assurance where applicable | | **Environments** | All in-scope CERG controls and evidence-producing processes | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How to Read the Matrix](#2-how-to-read-the-matrix) 3. [Traceability Rules](#3-traceability-rules) 4. [Baseline Control Traceability Matrix](#4-baseline-control-traceability-matrix) 5. [Overlay Traceability](#5-overlay-traceability) 6. [Gap Detection Rules](#6-gap-detection-rules) 7. [Maintenance Workflow](#7-maintenance-workflow) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope `CERG-GOV-CB-001` defines the unified control baseline and names evidence for each control. This matrix adds the missing operating layer: for each baseline control, it identifies the standard or procedure that operationalizes the control, the template or evidence package that proves operation, and the gap signal that should be raised when traceability is incomplete. This document complements the Unified Control Baseline. It does not replace it. The baseline remains the authoritative source for the control statement, owning pillar, evidence name, frequency, and regulatory crosswalk. This matrix is the operational routing map that tells a control owner, auditor, or AI agent where to go to run, test, or fix the control. > **Every Control Needs a Runbook or a Reason** > > A control baseline says what must be true. A procedure says how the organization makes it true. Evidence proves it happened. If a control has no procedure, no standard, and no evidence path, it is not really operational. This matrix is the gap detector. --- ## 2. How to Read the Matrix | **Column** | **Meaning** | |---|---| | Baseline Control | Control identifier and title from `CERG-GOV-CB-001` Section 6. | | Control Intent | Short operational purpose. The full statement remains in `CERG-GOV-CB-001`. | | Governing Standard | The standard that sets requirements or parameters. | | Operating Procedure / Plan | The procedure or plan that runs the control or review cycle. | | Evidence Template / Record | The canonical record type, template, or structured artifact expected for evidence production. | | Evidence Produced | The proof package, worksheet, register, or evidence output that supports testing. | | Primary Accountable Role | Canonical role accountable for traceability and operation. | | Gap Signal | What indicates that the control lacks operational coverage. | --- ## 3. Traceability Rules 1. Every baseline control must map to at least one governing standard or procedure. 2. Every baseline control must map to a canonical evidence template, record type, or structured artifact. 3. Every baseline control must map to named evidence. 4. Evidence must be testable through `CERG-PRC-AUD-001` or an approved regulated-scope audit procedure. 5. If a control is inherited, the inheritance evidence package from `CERG-GOV-CB-001` Section 5 must be linked. 6. If a control is partially implemented or planned, the POA&M and risk linkage must be present. 7. If no CERG procedure owns an operating step, the row is flagged as a gap for the Governance Pillar Leader. 8. This matrix is updated whenever a new standard, procedure, plan, template, or control baseline revision changes ownership or evidence flow. --- ## 4. Baseline Control Traceability Matrix | **Baseline Control** | **Control Intent** | **Governing Standard** | **Operating Procedure / Plan** | **Evidence Template / Record** | **Evidence Produced** | **Primary Accountable Role** | **Gap Signal** | |---|---|---|---|---|---|---|---| | AC-2 Account Management | Approved, owned, reviewed accounts. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | JML and access review execution through [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md); audit testing through [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). | Access Review Record; Evidence Index Entry; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md); System Control Profile Record where system-specific | JML log, access review evidence package, quarterly recertification report, [`CERG-TMPL-AUD-001`](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md). | Engineering Pillar Leader | Accounts without owner, recertification, reviewer authority, or JML evidence. | | AC-3 Access Enforcement | Approved authentication and authorization. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Architecture review through [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | Project Security Review Record; System Control Profile Record where system-specific | IdP / PAM policy export, architecture intake record. | Engineering Pillar Leader | Local, shared, hard-coded, or bypass access path. | | AC-6 Least Privilege | Role-bound and time-bound access. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Privileged access review and removal validation through [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md); exception workflow through [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | Access Review Record; Security Exception Record where needed; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md); System Control Profile Record | Privileged access review evidence package, PAM session logs, role inventory, exception register. | Engineering Pillar Leader | Privileged access without role basis, reviewer authority, expiration, removal validation, or review evidence. | | AC-7 Unsuccessful Logon Attempts | Identity attack resistance. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md), [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Detection coverage review through metrics and audit. | Detection Coverage Record; Reporting Metric Record; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | IdP policy export, detection rule, coverage report. | Risk Pillar Leader | Failed-login thresholds or detection rules missing. | | AC-17 Remote Access | Governed and logged remote access. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md), [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) | Architecture review, risk exception process for nonstandard paths. | Project Security Review Record; Security Exception Record; [TMPL-RM-002](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md); System Control Profile Record | Gateway logs, MFA policy export, exception request form. | Engineering Pillar Leader | Direct or undocumented remote access path. | | AC-19 Mobile / BYOD | Conditional-access controlled mobile access. | [`CERG-STD-EP-001`](../standards/CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md) | Device posture review and exception workflow. | Endpoint / Mobile Compliance Record; Security Exception Record; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | MDM compliance report, exception register. | Engineering Pillar Leader | Mobile access without enrollment or compliance signal. | | AU-2 Event Logging | Required events reach logging platform. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Logging coverage review and audit evidence process. | Detection Coverage Record; Evidence Index Entry; System Control Profile Record where system-specific | SIEM source inventory, gap report. | Risk Pillar Leader | Required source missing or unmonitored. | | AU-6 Audit Review | Alerts are reviewed and acted on. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Metrics reporting through [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). | Reporting Metric Record; Detection Coverage Record; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Detection coverage report, triage queue metrics. | Risk Pillar Leader | Alert queue lacks review, ownership, or tuning record. | | AU-9 Protection of Audit Information | Logs protected from alteration. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Audit test worksheet and evidence review. | Evidence Index Entry; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Storage policy, admin-action review. | Risk Pillar Leader | Logging admins can alter or delete evidence without oversight. | | AU-11 Audit Record Retention | Logs retained and retrievable. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence retrieval sampling. | Evidence Index Entry; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Retention policy, sample retrieval evidence. | Evidence Librarian | Required logs stale, unretrievable, or outside retention period. | | CM-2 Baseline Configuration | Secure baseline applied. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Security change management and audit testing. | Configuration Baseline Record; System Control Profile Record; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | DISH baseline catalog, scan report. | Engineering Pillar Leader | System lacks applicable baseline or scan evidence. | | CM-3 Change Control | Security-relevant changes governed. | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md), [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md). | Security Change Review Record; System Control Profile Record where system-specific | CAB minutes, change records, control-impact review. | Engineering Pillar Leader | Production change lacks approval or security review. | | CM-6 Configuration Settings | Drift detected and routed. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Exception workflow through [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | Configuration Baseline Record; Security Exception Record; System Control Profile Record | Drift report, exception register. | Engineering Pillar Leader | Drift exists without exception or remediation. | | CM-7 Least Functionality | Unneeded services disabled. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md), [`CERG-STD-EP-001`](../standards/CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md) | Vulnerability and configuration review. | Configuration Baseline Record; System Control Profile Record; [TMPL-SCP-001](../templates/CERG-TMPL-SCP-001_System_Control_Profile_Template.md) | Application allowlist, port-scan report. | Engineering Pillar Leader | Unauthorized service, port, or software persists. | | CM-8 System Component Inventory | Complete authoritative inventory. | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Monthly inventory reconciliation. | Asset Inventory Record; Asset Coverage Record; System Control Profile Record | Asset inventory export, reconciliation log. | Engineering Pillar Leader | Asset has no owner, class, lifecycle state, or source-of-truth record. | | CP-2 Contingency Plan | Current recovery plan exists. | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md). | Business Continuity Exercise Record or system recovery profile; System Control Profile Record | Plan document, BCP interface record. | Governance Pillar Leader | System lacks tiered recovery plan or BCP interface. | | CP-4 Contingency Plan Testing | Recovery plan tested. | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | DR exercise under [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md). | Business Continuity Exercise Record; Lessons Learned Record; [TMPL-AUD-001](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Test report, lessons learned, risk-register update. | Governance Pillar Leader | Recovery test overdue or lessons not tracked. | | CP-9 System Backup | Backups isolated and restorable. | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Backup assurance and DR testing. | Backup and Recovery Test Record; System Control Profile Record | Backup report, immutability evidence. | Engineering Pillar Leader | Backup lacks immutability, isolation, or restore evidence. | | CP-10 Information System Recovery | RTO/RPO proven. | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | DR exercise and recovery validation. | Backup and Recovery Test Record; Business Continuity Exercise Record; System Control Profile Record | Restoration test evidence. | Engineering Pillar Leader | Restore test cannot meet RTO or RPO. | | IA-2 Identification and Authentication | Phishing-resistant human identity. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Access review and exception workflow. | Access Review Record; Security Exception Record where needed; System Control Profile Record | IdP policy, exception register. | Engineering Pillar Leader | Legacy authentication or missing MFA exception. | | IA-3 Device Identification and Authentication | Device identity recognized. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md), [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) | Architecture and network review. | Asset Coverage Record; Project Security Review Record; System Control Profile Record | NAC / conditional-access policy. | Engineering Pillar Leader | Unknown device can access protected environment. | | IA-5 Authenticator Management | Secrets, keys, certificates governed. | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md), [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Security change management and audit test. | Configuration Baseline Record or certificate/secrets inventory record; System Control Profile Record | Secrets manager export, certificate inventory. | Engineering Pillar Leader | Secret or certificate exists outside approved lifecycle. | | RA-3 Risk Assessment | Risks identified, scored, treated. | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | Risk Register Entry; Risk Acceptance Record; [TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md); [TMPL-RM-004](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | Risk register, acceptance memo, exception request. | Risk Pillar Leader | Material issue exists outside risk register. | | RA-5 Vulnerability Monitoring and Scanning | Vulnerabilities assessed and prioritized. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). | Finding Record; Exposure Backlog Item; [TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Scan reports, SLA dashboard. | Risk Pillar Leader | Asset missing scanner coverage or alternative method. | | SI-2 Flaw Remediation | Findings remediated or accepted. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md), [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | Finding Record; Security Exception Record; Risk Acceptance Record; [TMPL-RM-002](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md); [TMPL-RM-004](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | SLA report, exception register, POA&M. | Risk Pillar Leader | Critical or High finding past SLA without approved treatment. | | SI-4 System Monitoring | Required monitoring covers system. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Detection coverage and metrics reporting. | Detection Coverage Record; Reporting Metric Record; System Control Profile Record | Coverage report, dashboard metric. | Risk Pillar Leader | Tool, source, or detection coverage gap not recorded. | | SR-2 Supply Chain Risk Management Plan | Vendors tiered and governed. | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). | Vendor Risk Assessment Record; [TMPL-TPRM-001](../templates/CERG-TMPL-TPRM-001_Vendor_Security_Questionnaire_and_Assessment_Template.md) | TPRM register, SCCT roster, questionnaire template. | Vendor Risk Analyst | Vendor lacks tier, evidence, contract requirement, or owner. | | SR-3 Supply Chain Controls and Processes | Country and supply-chain controls enforced. | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md), [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | Vendor Risk Assessment Record; Security Exception Record; [TMPL-TPRM-001](../templates/CERG-TMPL-TPRM-001_Vendor_Security_Questionnaire_and_Assessment_Template.md); [TMPL-RM-002](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) | Country-risk register, exception register. | Vendor Risk Analyst | International access or supply-chain exception lacks approval. | --- ## 5. Overlay Traceability | **Overlay** | **Operational Package / Standard** | **Evidence Route** | **Gap Signal** | |---|---|---|---| | High-Impact | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md), [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Baseline scan, monitoring coverage, vulnerability SLA report. | High-impact system lacks tightened parameters or evidence. | | CUI | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md), [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | SSP, POA&M, CUI evidence package, SPRS / CMMC readiness records. | CUI system lacks SSP, POA&M, or control implementation evidence. | | BES | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md), [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | CIP evidence package, ESP/EAP topology, recovery exercise, log retention evidence. | BES control lacks CIP-mapped evidence or review cadence. | | SOX ITGC | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md), [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | Access, change, operations, backup, interface, and report-control evidence. | SOX system lacks quarterly access review, change record, or operations evidence. | | OT Safety | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Engineering review, change window record, passive assessment evidence. | Safety-impacting OT change lacks engineering review or approved scan method. | | Privacy | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md), [`CERG-PLN-PRIV-001`](../plans/CERG-PLN-PRIV-001_Privacy_and_Data_Protection_Operational_Package.md) | DPIA support record, data inventory, deletion evidence, breach clock support record. | Personal data processing lacks inventory, DPIA, or retention evidence. | | ISO/IEC 27001 | [`CERG-PLN-ISO-001`](../plans/CERG-PLN-ISO-001_ISO_IEC_27001_Operational_Package.md) | ISMS scope, SoA, internal audit, management review. | ISO-scoped control lacks SoA rationale or audit evidence. | ### 5.1 Composite Trace: Regulated Architecture Review Regulated architecture review is a composite evidence path, not a single-control test. Use this trace when a new or materially changed system touches CUI, BES Cyber Systems, SOX-relevant financial systems, personal data at material scale, AI with regulated data, or another regulated scope. | Trace element | Required routing | Canonical records / evidence | Controls covered | |---|---|---|---| | Intake and scope | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) identifies business owner, system owner, environment, data classification, regulatory scope, go-live target, and review tier. | Project Security Review Record; intake form; scope statement; data classification decision. | AC-2, AC-3, AC-6, CM-3, CM-8, RA-3 | | Architecture and control design | Engineering reviews identity, network, logging, resilience, data handling, integration, and change path against applicable standards. | Architecture decision, design diagram, control conformance checklist, approved-pattern reference if used. | AC-3, AC-17, AU-2, AU-9, CM-2, CM-6, CP-9, SI-4 | | Threat and risk analysis | Risk performs threat model where required and opens risk entries for deferred or residual issues. | Threat Model Record; Risk Register Entry; Finding Record where pre-go-live issue is discovered. | RA-3, RA-5, SI-2, SR-2/SR-3 where vendor/integration exists | | Regulated overlay | Governance maps CUI, BES, SOX, privacy, or ISO obligations and required evidence package. | SSP / POA&M where CUI applies; CIP evidence reference where BES applies; SOX ITGC control mapping; Privacy Security Support Record where privacy applies. | Overlay-specific controls plus AC/AU/CM/CP/IA/RA/SI/SR baseline controls | | Pre-production closure | Required pre-go-live issues are remediated, exceptioned, or risk-accepted under RMF authority before release. | Closure checklist, remediation evidence, Security Exception Record, Risk Acceptance Record, go-live disposition. | CM-3, RA-3, SI-2 | | Handoff and evidence index | Evidence Librarian indexes the complete review package and links it to control, system, owner, period, and regulatory scope. | Evidence Index Entry; Project Security Review Record closure package; Reporting Metric Record where tracked. | AUD evidence path for all mapped controls | A regulated architecture review is incomplete if any required overlay has no named owner, no evidence location, or no disposition for deferred issues. Deferred issues that remain after go-live must appear as a Risk Register Entry, Security Exception Record, Risk Acceptance Record, or POA&M item as applicable. --- ## 6. Gap Detection Rules A traceability gap exists when any of the following is true: 1. the baseline names a control but no standard or procedure operationalizes it; 2. a control maps to evidence but no evidence owner is named; 3. a control maps to a procedure that is out of scope, retired, or missing from the catalog; 4. a control depends on inherited control evidence but the inheritance package is missing; 5. a control is partially implemented but has no POA&M item; 6. a control is risk accepted but lacks a Risk Register Entry, Risk Acceptance Record, or linked Security Exception Record where a control deviation exists; 7. a control has evidence, but the evidence cannot be retrieved within the audit retrieval window; 8. the catalog changes but this matrix is not reviewed. Traceability gaps are routed as follows: | **Gap Type** | **Route To** | **Required Action** | |---|---|---| | Missing standard or procedure | Governance Pillar Leader | Create planned artifact entry or amend artifact. | | Missing evidence owner | Evidence Librarian | Assign owner and evidence location. | | Missing risk or exception link | Risk Register Owner | Create or update risk, exception, or acceptance record. | | Missing implementation evidence | Responsible control owner | Produce evidence or open POA&M. | | Catalog mismatch | Governance Pillar Leader (Document Control) | Amend catalog or matrix. | --- ## 7. Maintenance Workflow This matrix is maintained annually and whenever one of these changes occurs: - `CERG-GOV-CB-001` adds, removes, or changes a control; - a standard, procedure, plan, or template is added or retired; - audit testing finds a control without an operational procedure; - evidence ownership changes; - regulatory scope changes; - CISO directs a traceability review. Maintenance steps: 1. compare the baseline control list to Section 4; 2. confirm each control still has a governing standard or procedure; 3. confirm each control has named evidence or inheritance package; 4. confirm each evidence path is testable through audit or assessment workflow; 5. update gap signals and routing where the operating model changed; 6. amend the catalog if this artifact or referenced artifacts changed status. --- ## 8. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-TRC-001 | | **Version** | 1.2 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Control Baseline) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on control baseline, standard, procedure, or evidence model change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-53r5; NIST 800-171r3; NIST CSF 2.0 GOVERN; ISO/IEC 27001 | | **Regulations** | Cross-cutting; CMMC, NERC-CIP, SOX ITGC, privacy, customer assurance where applicable | | **Environments** | All in-scope CERG controls and evidence-producing processes | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-20 | Governance Pillar Leader | Added Evidence Template / Record routing column and mapped baseline controls to canonical evidence records, templates, and System Control Profile records where system-specific proof is expected. | | 1.1 | 2026-06-18 | Governance Pillar Leader | Added PRC-AC-002 to AC-2 and AC-6 traces, added regulated architecture review composite trace, and aligned risk-acceptance evidence names to CAT-002. | | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes the control-to-procedure traceability matrix, overlay traceability, gap detection rules, and maintenance workflow. | ### Review Triggers - Control baseline changes - Standard, procedure, plan, or template added or retired - Audit finding related to control ownership or evidence traceability - Evidence model or owner changes - Regulatory scope change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Source of baseline controls and evidence names | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence and audit testing workflow | | Control Evidence and Test Worksheet | [`CERG-TMPL-AUD-001`](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Test worksheet for controls in this matrix | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory | --- ## DOCUMENT CATALOG AND NAMING CONVENTION ### Authoritative Inventory · ID Scheme · Roadmap --- | | | |---|---| | **Document ID** | CERG-GOV-CAT-001 | | **Version** | 1.45 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly - or upon any artifact add/retire | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | > **Catalog Sync Tool** > > The file `tools/cerg-catalog-sync.py` synchronises each document's metadata table `Status` field with the status recorded in this catalog's §5 authoritative listing. Run `python3 tools/cerg-catalog-sync.py --dry-run` to detect drift, `--write` to update CAT-001 from file frontmatter, or `--ci` (exit 1 on drift) for pre-commit validation. See the tool's header for full usage. --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Naming Convention](#2-naming-convention) 3. [Document Types](#3-document-types) 4. [Authority and Status Lifecycle](#4-authority-and-status-lifecycle) 5. [Authoritative Catalog (V1)](#5-authoritative-catalog-v1) 6. [Cross-Reference Rules](#6-cross-reference-rules) 7. [Artifact Roadmap (V1.x → V2)](#7-artifact-roadmap-v1x-to-v2) 8. [Document Control](#8-document-control) ## 1. Purpose and Scope [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) establishes a hierarchy of policy, standards, procedures, and guidelines. As the library grows, that hierarchy is only useful if there is a single, authoritative inventory of which artifacts exist, which are planned, which are authoritative, and which are exports of an authoritative artifact for a specific audience. This document is that inventory. It applies to every CERG-owned artifact, policy, standard, procedure, plan, guideline, template, and operational package, regardless of medium (Markdown source, exported Word/PDF, intranet page, or third-party portal entry). > **One Source, Many Exports** > > The authoritative source for every CERG document is the Markdown file in the CERG content repository. Everything else, Word exports, PDF deliverables, intranet pages, regulator portal uploads, is an export. Exports inherit the ID and version of the source. If the source and an export disagree, the source wins. --- ## 2. Naming Convention Every CERG artifact has a Document ID of the form: ``` CERG--- ``` Where: | **Element** | **Meaning** | **Examples** | |---|---|---| | `CERG` | Program prefix; never changes | - | | `` | Document type - see Section 3 | `POL`, `STD`, `PRC`, `PLN`, `GL`, `TMPL`, `GOV` | | `` | Two-to-four-letter domain code | `IT`, `OT`, `CUI`, `AC`, `RM`, `VM`, `CIP`, `LM` | | `` | Three-digit sequence within type+domain | `001`, `002` | Files are named `_.md` using underscore-separated title case (e.g., `CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md`). > **Stable ID Policy**: Document IDs are never reused. A retired ID remains reserved permanently. A superseding document identifies its predecessor. The machine-readable manifest preserves artifact history. Breaking changes to IDs, statuses, or role names are documented in the revision history. > **Convention, Not Bureaucracy** > > The ID format exists so that a person reading a control reference can tell at a glance what kind of artifact they're being pointed at. A reader who sees `CERG-STD-OT-001` knows it's a standard; a reader who sees `CERG-PRC-VM-001` knows it's a procedure they can execute. Anything that obscures that signal, clever domain codes, free-form titles in the ID, is a mistake. ### 2.1 Domain Codes (V1) | **Code** | **Domain** | |---|---| | `IT` | IT / cloud / SaaS | | `OT` | Operational technology / grid control systems | | `CUI` | Controlled Unclassified Information / [CMMC](https://dodcio.defense.gov/CMMC/) | | `AC` | Access management / identity | | `VM` | Exposure management | | `RM` | Risk management (register, exceptions, scoring) | | `IR` | Incident response (CERG-facing artifacts only) | | `CIP` | NERC-CIP | | `SOX` | Sarbanes-Oxley ITGC | | `LM` | Logging, monitoring, detection | | `CFG` | Secure configuration / hardening | | `RES` | Cyber resilience and backup | | `CR` | Cryptography and key management | | `AR` | Architecture review / project intake | | `TPRM` | Third-party / supply chain risk | | `AV` | Adversarial validation | | `MTR` | Metrics and reporting | | `OM` | Operating model | | `CAT` | Catalog / inventory | | `CB` | Control baseline | | `FRM` | Program-level framework narrative (e.g., the CERG Framework) | | `TAX` | Risk taxonomy | | `CMX` | Compliance matrix | | `RMF` | Risk Management Framework | | `IMP` | Implementation and adaptation guidance | | `VAR` | Organization adaptation / variable and token scheme | | `MAT` | Maturity self-assessment | | `RAC` | Roles, responsibilities, and RACI | | `SDL` | Secure software development / application security | | `AM` | Asset management and inventory | | `NET` | Network security and segmentation | | `EP` | Endpoint and mobile security | | `DG` | Data governance and classification | | `AI` | Artificial intelligence security | | `MSG` | Email and messaging security | | `TM` | Threat modeling | | `TI` | Threat intelligence | | `AUD` | Audit and evidence management | | `CHG` | Security change management | | `BC` | Business continuity and disaster recovery | | `ISO` | ISO/IEC 27001 operational package | | `PRIV` | Privacy and data protection | | `CAL` | Annual security and governance calendar | | `STY` | Document authoring and style guide | | `TRC` | Control-to-procedure traceability | | `LL` | Lessons learned and program improvement | | `IMPREG` | Program improvement register | | `CEF` | Control effectiveness | | `JA` | Job architecture and grade framework | | `JD` | Job descriptions | | `CMP` | Competency model and behavioral anchors | | `PERF` | Performance management and promotion framework | | `ONB` | Onboarding and integration program | | `WFP` | Workforce planning and capacity model | | `EDG` | Edge Register | | `TRN` | Training, development, and certification framework | | `SUCC` | Succession planning and talent review framework | | `CON` | Contractor and non-employee staff integration | | `JF` | Job Families and workforce architecture | | `FLOW` | Cross-pillar operational flows | | `CJ` | Crown jewels and loss-scenario library | | `SLC` | CERG service-level commitments (CERG-to-business) | | `GEN` | Cross-cutting reference material (glossary, term definitions, foundational index) | New domains are added only by amendment to this catalog. > **Domain codes reserved for workforce and operational flows:** `JF` (Job Families) and `FLOW` (Cross-Pillar Operational Flows) were added in CAT-001 v1.31 as part of the workforce architecture and operational flow build-out. > **Type-Code Discipline** > > Only the seven type codes defined in §3 are valid: `POL`, `STD`, `PRC`, `PLN`, `GL`, `TMPL`, `GOV`. Any document that uses a different type code (e.g., `PROC` instead of `PRC`) is mis-named; the correction is to rename, not to silently accept the variant. Forward references to non-existent or planned artifacts must follow §6.2 and §7. --- ## 3. Document Types | **Type Code** | **Type** | **Authority** | **What It Looks Like** | |---|---|---|---| | `POL` | Policy | CISO / Executive | Durable principles. Short. Rarely changes. One per program. | | `STD` | Standard | Governance Pillar Leader | Specific, measurable, technology-aware requirements that implement policy principles. | | `PRC` | Procedure | Pillar Owner | Step-by-step "how" - workflow, owner, evidence, frequency. | | `PLN` | Plan / Operational Package | Pillar Owner | Bundled procedure + templates + checklists for a regulated or assessor-facing program (e.g., CIP, CUI, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)). | | `GL` | Guideline | Pillar Owner | Recommendations and good practice, not mandatory. | | `TMPL` | Template | Pillar Owner | A blank artifact to be filled in (intake form, exception request, SSP). | | `GOV` | Governance Instrument | Governance Pillar Leader | Cross-cutting instruments that aren't a single policy/standard/procedure - catalogs, control baselines, operating model, metrics dictionary. | > **PLN vs. PRC** > > A `PRC` is a single procedure. A `PLN` is an operational package that bundles a procedure with templates, checklists, and registers because the regulator or auditor expects to see the bundle together (NERC-CIP, CUI/[CMMC](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)). When in doubt, prefer `PRC` and add templates as appendices. --- ## 4. Authority and Status Lifecycle | **Status** | **Meaning** | **In Catalog?** | |---|---|---| | `Planned` | Artifact has an ID and an owner but no draft yet. | Yes - Section 7. | | `Draft` | Work in progress. Not authoritative. | Yes - Section 5, flagged. | | `For Review` | Out for stakeholder/CISO review. | Yes - Section 5. | | `Approved` | Signed off and authoritative. | Yes - Section 5. | | `Retired` | Replaced or no longer in force. Retained for audit. | Yes - appendix to Section 5. | | `External Interface` | Artifact owned by an adjacent function (e.g., IR team). Included for cross-reference only. Not a CERG-governed document. | Yes — Section 5, flagged ⚠ | Approval authority follows [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) Section 7: - Policy (`POL`), CISO approves; Executive leadership endorses. - Standard (`STD`), Governance Pillar Leader approves; CISO endorses. - Procedure / Plan / Guideline (`PRC`, `PLN`, `GL`), Pillar Owner approves; Governance Pillar Leader endorses. - Template (`TMPL`), Pillar Owner approves. - Governance instrument (`GOV`), Governance Pillar Leader approves. --- ### 4.1 Review Cadence Tiers Not all documents require the same review frequency. Documents are assigned to one of three review tiers based on their criticality and change rate: | Tier | Review Cadence | Applies To | Review Depth | |------|---------------|-----------|-------------| | **Tier 1 — Critical** | Quarterly | POL-001, OM-001, RAC-001, RMF-001, CB-001, FLOW-001, CAT-001 | Full content review; verify all cross-references; confirm regulatory alignment | | **Tier 2 — Active** | Semi-Annual | All Standards (STD-*), all Procedures (PRC-*), JA-001, CMP-001, TRN-001, MTR-001, CMX-001, TAX-001 | Content review; verify key cross-references; update metrics and framework references | | **Tier 3 — Stable** | Annual | All Plans (PLN-*), all Templates (TMPL-*), remaining Governance documents (GOV-*), all per-role JD documents, family index documents | Light review; confirm currency; update owner if role changed; verify links | ### 4.2 CERG Source-of-Truth Model The CERG framework defines which system is authoritative for each type of operational data. If two systems disagree, the source of truth wins. | Data Type | Source of Truth | Notes | |-----------|----------------|-------| | Policy, standards, procedures, plans | CERG markdown repository | The .md files in this repo. Word/PDF exports are copies. If they disagree, the .md wins. | | Risk register entries, exception records | GRC system or designated spreadsheet | The risk register is the single authoritative record of organizational risk. Other systems (ticketing, spreadsheets) are views into it. | | Asset inventory | CMDB or asset management system | The authoritative inventory. If CERG asset-related content (e.g., F-03 evidence) disagrees with CMDB, investigate — do not assume either is correct. | | Access review population, identity source | IAM platform or HRIS | Identity data comes from the IdP and HRIS. Access review evidence from CERG should reference the source population. | | Log data | SIEM or data lake | Evidence of logging coverage comes from the SIEM, not from a policy document. | | Audit evidence | Evidence repository (as structured per IMP-003 §8) | The evidence library is the authoritative collection. GRC records reference files in the library. | | Control implementation status | CB-001 or GRC control catalog | Status is tracked near the control, not in a separate spreadsheet. | | Metrics and reporting | BI dashboard or reporting tool | Dashboards are views. The canonical metric definitions are in MTR-001. | ### 4.3 Record Naming Convention Operational records (risk register entries, exceptions, findings, etc.) use standard ID formats. These IDs are referenced in CERG artifacts and procedures. | Record Type | ID Format | Example | Source of Truth | |------------|-----------|---------|-----------------| | Risk Register Entry | RISK-YYYY-NNN | RISK-2026-001 | GRC system or risk register spreadsheet | | Exception | EXC-YYYY-NNN | EXC-2026-001 | GRC system or exception register spreadsheet | | Finding | FIND-YYYY-NNN | FIND-2026-001 | GRC system or exposure backlog spreadsheet | | Vulnerability | VULN-YYYY-NNN | VULN-2026-001 | GRC system or exposure backlog | | Vendor Assessment | VEN-YYYY-NNN | VEN-2026-001 | GRC system or vendor inventory spreadsheet | | Evidence Item | EVD-YYYY-NNN | EVD-2026-001 | Evidence library (per IMP-003 §8) | | Incident | IR-YYYY-NNN | IR-2026-001 | IR incident tracking system | | Decision Log Entry | DEC-YYYY-NNN | DEC-2026-001 | Decision log (per IMP-002 §4) | | Audit Request | AUD-YYYY-NNN | AUD-2026-001 | GRC system or audit evidence package | | Improvement Item | IMPG-YYYY-NNN | IMPG-2026-001 | Program improvement register | | Requirement (atomic) | CERG-REQ-DOC-NNN | CERG-REQ-AC-001 | machine-readable/ requirements YAML | ### 4.4 Document Retirement Policy Documents in the CERG corpus that are no longer authoritative follow a defined retirement process. Retirement is distinct from deprecation: a deprecated document still guides behaviour until replaced; a retired document is formally withdrawn and must not be relied upon for operations, audits, or compliance assertions. #### Retirement Criteria A document may be retired when any of the following conditions are met: | **Criterion** | **Description** | **Example** | |---|---|---| | **Superseded** | A new document replaces the artifact's function with broader scope, improved methodology, or updated framework alignment | A NERC-CIP operational package section superseded by a dedicated CIP standard | | **Regulatory scope removed** | The regulation or framework driving the document no longer applies to the organization's operations | CMMC scope contract expires; CUI-CMMC package sections no longer applicable | | **Framework retired** | The underlying framework or standard has been withdrawn by the issuing body and no replacement is adopted | NIST 800-53 Rev 5 entirely replaced by a future revision that CERG does not adopt | | **Merged into parent** | The document's content has been absorbed into a parent document and the standalone artifact is no longer needed | A standalone guideline merged into its parent standard | | **Decommissioned system scope** | The document governs a system, environment, or technology that has been decommissioned | OT-specific procedure for a decommissioned control system | | **Organisational restructuring** | The role, function, or pillar that owned the document no longer exists in the current operating model | A job description for a role eliminated in a reorganisation | #### 90-Day Notice Period When a document is identified for retirement: 1. **Notice published.** The Governance Pillar Leader (Document Control) publishes a retirement notice in the CERG communications channel (e.g., pillar sync, mailing list, or document catalog changelog) at least **90 calendar days** before the intended retirement effective date. 2. **Notice content.** The notice includes: - Document ID and title being retired - Retirement criteria met (from the table above) - Effective date of retirement - Superseding document (if any) — ID, title, location - Migration guidance (see §4.4.3) - Contact for questions or dispute 3. **Review period.** Interested stakeholders (pillar leaders, document owners, adopters) have 30 days from the notice date to raise objections, request extension, or propose alternatives. 4. **Exception window.** If a stakeholder demonstrates that the retirement would create a regulatory gap, audit finding, or operational disruption, the Governance Pillar Leader may extend the notice period by up to an additional 90 days. 5. **CISO escalation.** Unresolved disputes about retirement are escalated to the CISO for final decision. #### Migration Guide Every retirement notice must include a migration guide. The guide addresses: | **Migration Element** | **Required Content** | |---|---| | Superseding document | Full Document ID, title, file path, version | | Mapping of retired sections to superseding sections | Table: Retired §X → Superseding §Y, or "No direct replacement — see compensating guidance" | | Critical cross-reference updates | List of known documents that reference the retired document's ID or sections; recommended replacement references | | Evidence transition | Instructions for moving or re-referencing evidence artifacts that point to the retired document | | Training / awareness impact | If the retired document was part of onboarding or role-based training, what replaces it | | Timeline | Recommended date by which all references should be updated; default is 90 days from retirement effective date | #### Evidence Retention After Retirement Retired documents are **not deleted**. They are retained in the repository for the following purposes and durations: | **Retention Purpose** | **Minimum Retention Period** | **Disposition** | |---|---|---| | Audit trail — regulatory evidence that referenced the retired document | Longest applicable regulatory retention period (e.g., SOX: 7 years; NERC-CIP: 5 years; CMMC: 3 years) | Secure deletion after retention period; certificate of destruction | | Cross-reference integrity — documents that still link to the retired document | Until all referencing documents have been updated in a subsequent review cycle | Evaluation at next review cycle of the referencing document | | Historical record — program evolution | Indefinite (retired documents remain in the Git repository for historical reference) | Never deleted from Git history; only removed from active catalog | | Litigation hold | Per legal hold duration | Preservation until legal hold is formally released in writing | #### Crosswalk Freeze When a document is retired: 1. **Crosswalk status is frozen.** The retired document's entry in CAT-001 §5 is updated to `Retired` status but **not removed** from the catalog. The entry remains visible as a historical record. 2. **Cross-references are not removed.** Cross-references from other documents to the retired document are preserved but flagged. The validator (`cerg-validate.py`) treats references to Retired documents as a **warning**, not an error, with a configurable grace period (default: 180 days from retirement effective date). 3. **New references are prohibited.** After the retirement effective date, no new document may introduce a cross-reference to a Retired document. Existing cross-references are updated at the referencing document's next scheduled review. 4. **Catalog freeze entry.** The retired document's catalog row includes: - Status: `Retired` - Retirement effective date - Superseding document ID (if any) - Link to retirement notice 5. **Superseding documents identify their predecessor.** Any document that supersedes a retired artifact includes a note in its metadata or Document Control section: `Supersedes CERG-XXX-XXX-NNN (retired YYYY-MM-DD)`. #### Retirement Record in Revisions Each retirement event is recorded in the revision history of: - The retired document itself (final entry: "Document retired [date]") - CAT-001 (entry: "Retired [doc ID] — [reason]") - CERG-GOV-IMPREG-001 (Program Improvement Register), if applicable #### Reversal A retired document may be reactivated (returned to `Approved` status) only if: 1. A stakeholder demonstrates a regulatory or operational need that the superseding document does not satisfy. 2. The Governance Pillar Leader approves reactivation after a documented review. 3. The document's content is reviewed and updated to current standards before reactivation. 4. The `Retired` catalog entry is updated to `Approved` with a revision history note. ### 4.5 Ownership Delegation The Owner field in each document's metadata assigns accountability for review initiation and content accuracy. To prevent ownership concentration, the following delegation rules apply: - **Per-role JD documents** (CERG-GOV-JD-*): Owned by the Pillar Leader of the role's pillar, not by Governance Pillar Leader. Example: Cloud Security Engineer (SECENG-001) is owned by Engineering Pillar Leader. - **Family index documents** (CERG-GOV-JD-*-000): Owned by the Pillar Leader of the family's primary pillar. - **Machine-readable artifacts** (machine-readable/*.yaml): Governed collectively by METADATA.yaml. The Governance Pillar Leader (Document Control) owns the METADATA.yaml. Individual YAML files are regenerated from source — the source document owner is accountable for the content. - **Single-owner rule:** No individual may be listed as Owner of more than 15 Tier 1 or Tier 2 documents. If a role would exceed this threshold, delegate ownership to the relevant Pillar Leader or domain expert. Review initiation is the Owner's responsibility. If a scheduled review is missed by more than 30 days, the Document Control function creates a Finding Record and escalates to the Governance Pillar Leader. ## 5. Authoritative Catalog (V1) The V1 library is the set below. Every artifact listed has either an approved or for-review source in the CERG content repository. ### 5.1 Policy | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Cybersecurity Policy | CISO | Approved | ### 5.2 Framework, Operating Model, and Cross-Cutting Instruments | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | CERG Operating Model | CISO / Pillar Owners | Approved | | `CERG-GOV-CAT-001` | Document Catalog and Naming Convention | Governance Pillar Leader | Approved (this doc) | | [`CERG-GOV-CAT-002`](CERG-GOV-CAT-002_Record_Catalog.md) | Record Catalog | Governance Pillar Leader (Document Control) | Approved | | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Unified Control Baseline | Governance Pillar Leader | Approved | | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Metrics, Dashboard, and CISO/Board Reporting | Governance Pillar Leader | Approved | | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | CERG Framework (narrative) | CISO | Approved | | [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) | Framework System Map | Governance Pillar Leader | Approved | | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk Management Framework | Governance Pillar Leader | Approved | | [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) | Risk Taxonomy | Cyber Risk | Approved | | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) | Compliance Matrix | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Implementation and Adaptation Guide | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-002`](CERG-GOV-IMP-002_Adoption_Safety_Guide.md) | Adoption Safety Guide | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-003`](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) | Small Team Adoption Path | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-004`](CERG-GOV-IMP-004_Implementation_Cards.md) | Implementation Cards | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | Adoption Decision Tree and Dependency Matrix | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-006`](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) | Role-Based Implementation Checklists | Governance Pillar Leader | Approved | | [`CERG-GOV-IMP-007`](CERG-GOV-IMP-007_Role_Reader_Paths.md) | Role Reader Paths | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Organization Adaptation Profile | Governance Pillar Leader | Approved | | [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Maturity Self-Assessment and Scorecard | Governance Pillar Leader | Approved | | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Consolidated Roles, Responsibilities, and RACI Instrument | Governance Pillar Leader | Approved | | [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | Annual Security and Governance Calendar | Governance Pillar Leader | Approved | | [`CERG-GOV-STY-001`](CERG-GOV-STY-001_Document_Authoring_and_Style_Guide.md) | Document Authoring and Style Guide | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-STY-002`](CERG-GOV-STY-002_Style_Compliance_Tracker.md) | Style Compliance Tracker | Governance Pillar Leader (Document Control) | Approved | | [`CERG-GOV-TRC-001`](CERG-GOV-TRC-001_Control_to_Procedure_Traceability_Matrix.md) | Control-to-Procedure Traceability Matrix | Governance Pillar Leader (Control Baseline) | Approved | | [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | Program Improvement Register | Governance Pillar Leader | Approved | | [`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) | Control Effectiveness Framework | Governance Pillar Leader | Approved | | [`CERG-GOV-AUD-001`](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | Evidence Quality Standard | Governance Pillar Leader | Approved | | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Job Architecture and Grade Framework | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | CERG Job Descriptions | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Competency Model and Behavioral Anchors | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance Management and Promotion Framework | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | Onboarding and Integration Program | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-WFP-001`](CERG-GOV-WFP-001_Workforce_Planning_and_Capacity_Model.md) | Workforce Planning and Capacity Model | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Training, Development, and Certification Framework | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-SUCC-001`](CERG-GOV-SUCC-001_Succession_Planning_and_Talent_Review_Framework.md) | Succession Planning and Talent Review Framework | CISO | Approved | | [`CERG-GOV-CON-001`](CERG-GOV-CON-001_Contractor_and_Non-Employee_Staff_Integration_Guide.md) | Contractor and Non-Employee Staff Integration Guide | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-JF-001`](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) | Job Families Overview | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-JF-002`](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Workforce Framework Crosswalk | Governance Pillar Leader (Policy & Standards) | Approved | | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Cross-Pillar Operational Flows | Governance Pillar Leader | Approved | | [`CERG-GOV-GEN-001`](CERG-GOV-GEN-001_CERG_Glossary.md) | CERG Glossary | Governance Pillar Leader (Document Control) | Approved | | [`CERG-GOV-EDG-001`](CERG-GOV-EDG-001_Edge_Register.md) | Edge Register | Governance Pillar Leader / Vendor Risk Analyst | Approved | | [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md) | Crown Jewel Register and Loss Scenario Library | Risk Pillar Leader / Governance Pillar Leader | Approved | | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) | CERG Service-Level Commitments | CISO | Approved | | [`CERG-GOV-CAL-002`](CERG-GOV-CAL-002_Calibration_Checklist.md) | Calibration Checklist | Governance Pillar Leader | Approved | ### 5.3 Standards | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | IT / Cloud / SaaS Security Standard | Cyber Governance - IT/Cloud | Approved | | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Grid Control Systems Security Standard | Cyber Governance - OT | Approved | | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | CUI Handling Standard | Cyber Governance - CUI/CMMC | Approved | | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Access Management Standard | Cyber Governance - Identity | Approved | | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Secure Configuration Baseline Standard (DISH) | Cyber Engineering - Platforms | Approved | | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Logging, Monitoring, and Detection Standard | Cyber Risk - Detection | Approved | | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Cyber Resilience and Backup Standard | Cyber Engineering - Resilience | Approved | | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Cryptography and Key Management Standard | Cyber Engineering - Platforms | Approved | | [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Secure Software Development and Application Security Standard | Cyber Engineering - Application Security | Approved | | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Asset Management and Inventory Standard | Cyber Engineering - Platforms | Approved | | [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) | Network Security and Segmentation Standard | Cyber Engineering - Platforms | Approved | | [`CERG-STD-EP-001`](../standards/CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md) | Endpoint and Mobile Security Standard | Cyber Engineering - Endpoint | Approved | | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Data Governance and Classification Standard | Cyber Governance - Policy & Standards | Approved | | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Artificial Intelligence Security Standard | Cyber Engineering - Application Security | Approved | | [`CERG-STD-MSG-001`](../standards/CERG-STD-MSG-001_Email_and_Messaging_Security_Standard.md) | Email and Messaging Security Standard | Cyber Engineering - Platforms | Approved | ### 5.4 Procedures | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Exposure Management Procedure | Cyber Risk | Approved | | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk Register and Exception Process | Cyber Governance - Risk Register | Approved | | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Architecture Review and Project Intake Procedure | Cyber Engineering | Approved | | [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Access Management Runbook | Identity Engineer (or IAM team if external) | Approved | | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Third-Party and Supply Chain Risk Procedure | Cyber Risk - Vendor Risk | Approved | | [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Adversarial Validation Procedure | Cyber Risk - Offensive Security | Approved | | [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | Incident Response Playbook Set ⚠ ADJACENT — owned by standing IR team; included for cross-reference only | Standing IR Team / Incident Commander | External Interface | | [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Threat Modeling Procedure | Cyber Risk | Approved | | [`CERG-PRC-TI-001`](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) | Threat Intelligence Procedure | Cyber Risk - Threat Intelligence | Approved | | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Audit and Evidence Management Procedure | Cyber Governance | Approved | | [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) | Security Change Management Procedure | Cyber Engineering | Approved | | [`CERG-PRC-LL-001`](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) | Lessons Learned and Program Improvement Procedure | Governance Pillar Leader | Approved | > **Numbering note: CERG-PRC-AC-001.** The Access Management Runbook is identifier `CERG-PRC-AC-002` rather than `-001` because the original `-001` slot was reserved for a planned standalone Access Review Runbook that has not been authored; the work was folded into the parent standard [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) §9. The `-002` ID is preserved to avoid renumbering existing references. The `-001` slot is reserved for future use. ### 5.5 Plans / Operational Packages | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Incident Response Plan ⚠ ADJACENT — owned by standing IR team; included for cross-reference only | Standing IR Team / Incident Commander | External Interface | | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | CUI / CMMC Operational Package | Cyber Governance - CUI/CMMC | Approved | | [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | NERC-CIP Operational Package | Cyber Governance - OT | Approved | | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | SOX ITGC Operational Package | Cyber Governance - SOX | Approved | | [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) | Business Continuity and Disaster Recovery Plan | Governance Pillar Leader | Approved | | [`CERG-PLN-ISO-001`](../plans/CERG-PLN-ISO-001_ISO_IEC_27001_Operational_Package.md) | ISO/IEC 27001 Operational Package | Governance Pillar Leader | Approved | | [`CERG-PLN-PRIV-001`](../plans/CERG-PLN-PRIV-001_Privacy_and_Data_Protection_Operational_Package.md) | Privacy and Data Protection Operational Package | Governance Pillar Leader | Approved | ### 5.6 Templates | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Risk Register Templates and Reporting | Cyber Governance - Risk Register | Approved | | [`CERG-TMPL-CUI-001`](../templates/CERG-TMPL-CUI-001_System_Security_Plan_Template.md) | System Security Plan Template | CMMC / Federal Compliance Manager | Approved | | [`CERG-TMPL-CUI-002`](../templates/CERG-TMPL-CUI-002_POAM_Template.md) | Plan of Action and Milestones Template | CMMC / Federal Compliance Manager | Approved | | [`CERG-TMPL-RM-002`](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) | Security Exception Request Form | Risk Register Owner | Approved | | [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) | Architecture and Project Intake Form | Engineering Pillar Leader | Approved | | [`CERG-TMPL-TPRM-001`](../templates/CERG-TMPL-TPRM-001_Vendor_Security_Questionnaire_and_Assessment_Template.md) | Vendor Security Questionnaire and TPRM Assessment Template | Vendor Risk Analyst | Approved | | [`CERG-TMPL-RM-003`](../templates/CERG-TMPL-RM-003_Risk_Acceptance_Memo_Template.md) | Risk Acceptance Memo Template | Risk Pillar Leader | Approved | | [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | Risk Acceptance Request Form | Risk Register Owner | Approved | | [`CERG-TMPL-SCP-001`](../templates/CERG-TMPL-SCP-001_System_Control_Profile_Template.md) | System Control Profile Template | Engineering Pillar Leader | Approved | | [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | AI Intake and Sanctioning Template | Governance Pillar Leader | Approved | | [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) | Sanctioned AI Tools Register Template | Governance Pillar Leader | Approved | | [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | AI System and Model Register Template | Application Security Engineer | Approved | | [`CERG-TMPL-AUD-001`](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | Control Evidence and Test Worksheet | Evidence Librarian | Approved | | [`CERG-TMPL-MTR-001`](../templates/CERG-TMPL-MTR-001_Board_and_CISO_Reporting_Deck_Template.md) | Board and CISO Reporting Deck Template | Governance Pillar Leader | Approved | | [`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md) | Stakeholder Perception Survey | Governance Pillar Leader | Approved | | [`CERG-TMPL-SAAS-001`](../templates/CERG-TMPL-SAAS-001_SaaS_Evidence_Collection_Checklist.md) | SaaS Evidence Collection Checklist | Governance Pillar Leader | Approved | | [`CERG-TMPL-SBOM-001`](../templates/CERG-TMPL-SBOM-001_SBOM_Evidence_Collection_Checklist.md) | SBOM Evidence Collection Checklist | Vendor Risk Analyst | Approved | Other templates remain embedded as appendices of their parent procedure or plan unless they have independent reuse outside that artifact. The Document Catalog references the parent. --- ### 5.7 Job Descriptions (Per-Role) | **ID** | **Title** | **Owner** | **Status** | |---|---|---|---| | `CERG-GOV-JD-SECENG-001` | Cloud Security Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-002` | Identity Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-003` | OT Security Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-004` | Application Security Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-005` | Endpoint Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-006` | Cryptography Engineer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-007` | Engineering Pillar Leader | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-008` | Pre-production Reviewer | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-001` | Exposure Management Lead | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-002` | Adversarial Testing Lead | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-003` | Threat Intelligence Analyst | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-004` | Detection Engineer | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-005` | OT Risk Analyst | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-006` | Identity Risk Analyst | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-007` | Vendor Risk Analyst | Risk Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-008` | Risk Pillar Leader | Risk Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-001` | NERC-CIP Compliance Manager | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-002` | CMMC / Federal Compliance Manager | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-003` | SOX ITGC Lead | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-004` | Policy & Standards Manager | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-005` | Risk Register Owner | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-006` | Evidence Librarian | Governance Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-007` | Governance Pillar Leader | Governance Pillar Leader | Approved | | `CERG-GOV-JD-EXEC-001` | Chief Information Security Officer (CISO) | CISO | Approved | | `CERG-GOV-JD-EXEC-002` | Executive Sponsor | CISO | Approved | | `CERG-GOV-JD-ADJUNCT-001` | Incident Commander | Governance Pillar Leader | Approved | | `CERG-GOV-JD-ADJUNCT-002` | Lead Investigator | Governance Pillar Leader | Approved | | `CERG-GOV-JD-SECENG-000` | Security Engineering Family Index | Engineering Pillar Leader | Approved | | `CERG-GOV-JD-RISKOPS-000` | Risk Operations Family Index | Risk Pillar Leader | Approved | | `CERG-GOV-JD-GOVCOMP-000` | Governance & Compliance Family Index | Governance Pillar Leader | Approved | | `CERG-GOV-JD-EXEC-000` | Executive Leadership Family Index | CISO | Approved | | `CERG-GOV-JD-ADJUNCT-000` | Incident Response Family Index | Governance Pillar Leader | Approved | ### 5.8 Machine-Readable Artifacts The `machine-readable/` directory contains YAML specifications generated from the CERG corpus for LLM and automation consumption. These are derived artifacts, not independently authored documents. See `machine-readable/README.md` for the complete inventory. Key artifacts include: - `cerg-llm-index.json` — Full local Markdown corpus index for LLM/agent consumption - `cerg-manifest.yaml` — Canonical manifest of governed source artifacts - `cerg-publication-manifest.yaml` — Publication eligibility separate from lifecycle approval status - `cerg-requirements.yaml` — Pilot atomic requirements extracted from 8 normative source documents - `cerg-flows.yaml` — Cross-pillar operational flow specifications (7 flows) - `cerg-record-schemas.yaml` — Core operational record schemas - Companion schema files for runtime model, evidence, metrics, crown jewels, vulnerability priority, IR interface, vendor kill switch, identity, segmentation, AI intake, workforce capacity, and decision logging ### 5.9 Examples The `examples/` directory contains narrative walkthroughs and adoption profiles. These are not authoritative documents and do not appear in the V1 catalog. They show how V1 artifacts are used together during real work, and they are the recommended first stop for leaders and SMEs trying to understand how the program operates. | Example | Purpose | Format | |---|---|---| | `examples/day-in-the-life/README.md` | Narrative walkthroughs of how the three pillars produce outcomes together — intake, vulnerability, audit, cloud launch, access review, third-party incident, AI rollout, CERG Lite exposure triage, control-intent implementation, new-CISO onboarding, and OT maintenance-window patch deferral | Markdown stories with step tables and operational output lists | | `examples/regulated-utility-profile/` | A filled-in sample of [CERG-GOV-VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) for a regulated utility sector organization | Adapted profile | Examples are illustrative, not normative. They may be updated outside the V1 review cycle and may reference planned V1.x documents with explicit `(Planned)` markers. ## 6. Cross-Reference Rules These rules govern every "Related Documents" table, every footnote reference, and every link in a CERG artifact. 1. **Link only to artifacts that appear in this catalog.** If the artifact does not appear in Section 5 or Section 7, do not reference it. 2. **Distinguish approved from planned.** When a Related Documents table includes a Planned artifact, mark it `(Planned, V1.x)` or `(Planned, V2)` so the reader knows it does not yet exist. 3. **Use the Document ID, not the file name.** File names change; IDs do not. 4. **Avoid forward references to TMPL artifacts that live inside a parent.** Cite the parent and the appendix (`CERG-PRC-AR-001 Appendix B, Security Project Intake Form`). 5. **External standards (NIST, CIS, IEC, ISO) are cited by short form**, `NIST 800-53r5 AC-2`, `CIS Benchmark Windows Server 2022 L1`, `IEC 62443-3-3 SR 1.1`. Each artifact's metadata table lists the framework set in scope. > **The Reference Discipline Test** > > A new CERG team member opens any artifact, follows a reference, and arrives at exactly the document the reference named, at the version the catalog records, with no dead links and no surprises. If that holds for every reference in the library, the catalog is doing its job. If it does not, the catalog, not the citing document, is the artifact that needs the fix. --- ## 7. Artifact Roadmap (V1.x to V2) This section is the authoritative list of planned artifacts. Per Cross-Reference Rule 1, a planned artifact may be referenced by another artifact only if it appears here, and the reference is marked `(Planned, V1.x)` or `(Planned, V2)`. An artifact moves from this section to Section 5 when it is authored and reaches `Draft` or above. An artifact in this section has an ID reserved and an owner assigned but is not yet authoritative and must not be relied upon. ### 7.1 Status of the V1.x Build The V1.x build extends the original V1 library along six tracks: the adoption layer, the Engineering-pillar standards, the governance glue, the missing procedures, the missing operational packages, and the standalone template library. As of this version of the catalog, the adoption layer (`IMP`, `VAR`, `MAT`), the seven Engineering and data standards (`SDL`, `AM`, `NET`, `EP`, `DG`, `AI`, `MSG`), the consolidated RACI instrument (`RAC`), the Group C in-scope procedures (`IR-002`, `TM`, `TI`, `AUD`, `CHG`), the Group D operational packages (`BC`, `ISO`, `PRIV`), the Group E standalone templates, and the F2-F4 governance instruments (`CAL`, `STY`, `TRC`) are authored and registered in Section 5. The artifacts below remain planned. ### 7.2 Planned Procedures | [`CERG-PRC-AC-001`]() | Access Review Runbook (reserved) | Identity Engineer | Planned, V1.x | No in-scope Group C procedures remain planned in V1.x. Security Awareness and Training and SOC / Forensics operations are intentionally out of CERG scope and are not reserved here. ### 7.3 Planned Plans and Operational Packages No Group D operational packages remain planned. Business Continuity and Disaster Recovery, ISO/IEC 27001, and Privacy and Data Protection packages are authored and registered in Section 5.5. ### 7.4 Planned Templates No Group E standalone templates remain planned. The System Security Plan, POA&M, security exception request, architecture and project intake form, vendor security questionnaire, risk acceptance memo, control evidence worksheet, and Board / CISO reporting deck templates are authored and registered in Section 5.6. The incident report and post-incident review template remains embedded in the incident response plan and playbook set unless promoted by a future amendment. ### 7.5 Planned Governance Instruments | [`CERG-GOV-CIP-001`]() | NERC-CIP Governance Instrument (reserved) | OT Security Engineer | Planned, V1.x | | [`CERG-GL-OT-001`]() | OT Security Guideline (reserved) | OT Security Engineer | Planned, V1.x | | [`CERG-TMPL-CIP-001`]() | NERC-CIP Template (reserved) | NERC-CIP Compliance Manager | Planned, V1.x | No F2-F4 governance instruments remain planned. The Annual Security and Governance Calendar, Document Authoring and Style Guide, and Control-to-Procedure Traceability Matrix are authored and registered in Section 5.2. > **The Roadmap Is a Commitment, Not a Wishlist** > > An ID in this section is a reserved identifier with a named owner. It is not a vague intention. When an artifact is listed here, a citing document is permitted to forward-reference it, which means readers will encounter the reference before the artifact exists. That is only safe if this section is honest: every entry has a real owner and a real target, and an entry that is no longer intended is removed by amendment, not left to mislead. --- ## 8. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CAT-001 | | **Version** | 1.45 | | **Status** | Approved | | **Effective Date** | 2026-06-18 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly, or upon any artifact add or retire | | **Next Scheduled Review** | 2026-09-17 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.45 | 2026-06-20 | Governance Pillar Leader | Registered `CERG-TMPL-SCP-001` System Control Profile Template in §5.6 as the structured per-system control implementation, evidence, validation, and review record. | | 1.44 | 2026-06-18 | Governance Pillar Leader | Registered domain code `GEN` (cross-cutting reference material) in §2.1. Registered `CERG-GOV-GEN-001` (CERG Glossary) in §5.2 as the canonical reference for CERG terms, record types, conversion rules, and role names. Glossary content extracted from FLOW-001 §2 (Operating Principles, Record Type Definitions) and from CB-001, RMF-001, OM-001, and roles/ cross-references. | | 1.43 | 2026-06-18 | Governance Pillar Leader | Registered `CERG-GOV-IMP-007` (Role Reader Paths) in §5.2 as the sequenced 30-35 minute reading order for the CISO, Risk Lead, and Engineering Lead roles. | | 1.42 | 2026-06-18 | Governance Pillar Leader | Added §5.9 Examples subsection. Authorizes the `examples/` directory in the catalog and clarifies that examples are illustrative, not normative. Cross-reference rule 1 in §6 continues to govern which artifacts may be referenced from examples, with `(Planned, V1.x)` markers required for any forward references. | | 1.41 | 2026-06-18 | Governance Pillar Leader | Expanded §4.4 from Document Deprecation Policy to full Document Retirement Policy with criteria, 90-day notice period, migration guide, evidence retention, crosswalk freeze, and reversal provisions. Added catalog sync tool reference after metadata table. | | 1.40 | 2026-06-17 | Governance Pillar Leader | Reconciled concurrent catalog revision history and updated the next scheduled review date after AI and SaaS/SBOM additions. | | 1.39 | 2026-06-17 | Governance Pillar Leader | Removed the hardcoded machine-readable manifest artifact count so the catalog does not drift when templates are added. | | 1.38 | 2026-06-17 | Governance Pillar Leader | Registered CERG-TMPL-AI-003 as the AI system and model register template. | | 1.37 | 2026-06-17 | Governance Pillar Leader | Registered CERG-TMPL-AI-002 as the sanctioned AI tools register template. | | 1.36 | 2026-06-17 | Governance Pillar Leader | Registered CERG-TMPL-AI-001 as the standalone AI intake and sanctioning template. | | 1.35 | 2026-06-14 | Governance Pillar Leader | Removed duplicate Table of Contents entries after the machine-readable artifact update. | | 1.34 | 2026-06-14 | Governance Pillar Leader | Updated machine-readable artifact inventory language to reflect regenerated local manifests, canonical paths, and the full LLM index. | | 1.33 | 2026-06-14 | Governance Pillar Leader | Status taxonomy cleanup. Replaced Published and Active catalog statuses with Approved; publication eligibility remains tracked separately in the publication manifest. | | 1.32 | 2026-06-13 | Governance Pillar Leader | Adoption usability amendment. Added FRM-002 Framework System Map, CAT-002 Record Catalog, IMP-005 Adoption Decision Tree and Dependency Matrix, and IMP-006 Role-Based Implementation Checklists to Section 5.2. | | 1.0 | 2026-05-01 | Cyber Governance | Initial release. Established the naming convention, document types, the authority and status lifecycle, the V1 authoritative catalog, and the cross-reference rules. | | 1.21 | 2026-05-01 | Cyber Governance | Catalog maintenance release aligning artifact versions across the V1 library. | | 1.22 | 2026-05-21 | Cyber Governance | Registered the adoption-layer domains `IMP`, `VAR`, and `MAT` in Section 2.1 and added `CERG-GOV-IMP-001`, `CERG-GOV-VAR-001`, and `CERG-GOV-MAT-001` to Section 5.2. | | 1.23 | 2026-05-21 | Cyber Governance | Registered domains `RAC`, `SDL`, `AM`, `NET`, `EP`, `DG`, `AI`, and `MSG`. Added `CERG-GOV-RAC-001` to Section 5.2 and seven standards to Section 5.3. Set `CERG-GOV-RAC-001` and the seven new standards to `Approved` on CISO sign-off. Restored the document to its full structure: completed the Section 6 Reference Discipline Test callout, and authored Section 7 (Artifact Roadmap) and Section 8 (Document Control), which had been absent. | | 1.24 | 2026-05-22 | Cyber Governance | Registered domains `TM`, `TI`, `AUD`, and `CHG`; added `CERG-PRC-IR-002`, `CERG-PRC-TM-001`, `CERG-PRC-TI-001`, `CERG-PRC-AUD-001`, and `CERG-PRC-CHG-001` to Section 5.4 as Draft; removed the now-authored Group C procedure reservations from Section 7.2; noted that Security Awareness and Training and SOC / Forensics operations are intentionally out of CERG scope. | | 1.25 | 2026-05-22 | Cyber Governance | Registered domains `BC`, `ISO`, and `PRIV`; added `CERG-PLN-BC-001`, `CERG-PLN-ISO-001`, and `CERG-PLN-PRIV-001` to Section 5.5 as Draft; removed the now-authored Group D operational package reservations from Section 7.3. | | 1.26 | 2026-05-22 | Cyber Governance | Added eight standalone Group E templates to Section 5.6 as Draft: `CERG-TMPL-CUI-001`, `CERG-TMPL-CUI-002`, `CERG-TMPL-RM-002`, `CERG-TMPL-AR-001`, `CERG-TMPL-TPRM-001`, `CERG-TMPL-RM-003`, `CERG-TMPL-AUD-001`, and `CERG-TMPL-MTR-001`; updated Section 7.4 to state that no Group E standalone templates remain planned. | | 1.27 | 2026-05-22 | Cyber Governance | Registered domains `CAL`, `STY`, and `TRC`; added `CERG-GOV-CAL-001`, `CERG-GOV-STY-001`, and `CERG-GOV-TRC-001` to Section 5.2 as Draft; updated Section 7.5 to state that no F2-F4 governance instruments remain planned. | | 1.30 | 2026-05-27 | Cyber Governance | HR program build-out amendment. Registered domains `CMP`, `PERF`, `ONB`, `WFP`, `TRN`, `SUCC`, `CON`, and `EDG`. Added to Section 5.2: `CERG-GOV-CMP-001` (Competency Model and Behavioral Anchors), `CERG-GOV-PERF-001` (Performance Management and Promotion Framework), `CERG-GOV-ONB-001` (Onboarding and Integration Program), `CERG-GOV-WFP-001` (Workforce Planning and Capacity Model), `CERG-GOV-TRN-001` (Training, Development, and Certification Framework), `CERG-GOV-SUCC-001` (Succession Planning and Talent Review Framework), and `CERG-GOV-CON-001` (Contractor and Non-Employee Staff Integration Guide). Extended `CERG-GOV-IMP-001` to v1.1 with Employer Brand and Talent Attraction section. | | 1.32 | 2026-06-18 | Governance Pillar Leader | Registered CERG-TMPL-RM-004 (Risk Acceptance Request Form) in §5.6 as the distinct Business Owner + RMF-001 authority risk acceptance workflow, separate from the Security Exception Request Form (TMPL-RM-002). | | 1.31 | 2026-06-11 | Governance Pillar Leader | Workforce architecture and cross-pillar flows amendment. Registered domains `JF` and `FLOW`. Added JF-001 (Job Families Overview), JF-002 (NICE Crosswalk), and FLOW-001 (Cross-Pillar Operational Flows) to §5.2. Added §5.7 (Job Descriptions — 27 per-role documents across five job families) and §5.8 (Machine-Readable Artifacts). Rewrote JD-001 as family-level index. Modified RAC-001, JA-001, CMP-001, TRN-001, PERF-001, and OM-001 with NICE and Job Family cross-references. | | 1.29 | 2026-05-27 | Cyber Governance | Job architecture and human capital amendment. Registered domains `JA` and `JD`. Added to Section 5.2: `CERG-GOV-JA-001` (Job Architecture and Grade Framework) and `CERG-GOV-JD-001` (CERG Job Descriptions). The JA-001 establishes the two-track grade structure (SME: Specialist through Sr. Advisor; Management: Manager through Director), leveling dimensions, span-of-control guidelines, and compensation philosophy. The JD-001 provides full job descriptions for all 25 canonical CERG roles. | | 1.28 | 2026-05-26 | Cyber Governance | NIST CSF Adaptive gap closure amendment. Registered domains `LL`, `IMPREG`, and `CEF`. Added to Section 5.2: `CERG-GOV-IMPREG-001` (Program Improvement Register) and `CERG-GOV-CEF-001` (Control Effectiveness Framework). Added to Section 5.4: `CERG-PRC-LL-001` (Lessons Learned and Program Improvement Procedure). Added to Section 5.6: `CERG-TMPL-GOV-001` (Stakeholder Perception Survey). Noted extended artifacts: PRC-TI-001 v1.1, MTR-001 v1.3, PRC-AV-001 v1.2, RMF-001 v1.3, MAT-001 v1.1, OM-001 v1.22. | ### Review Triggers - Any artifact added to, or retired from, the CERG library - Any new domain or type code required by a new artifact - A change to the naming convention or the cross-reference rules - A planned artifact in Section 7 reaching `Draft` or above, which moves it to Section 5 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Document Control) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy; establishes the document hierarchy this catalog inventories | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines the roles cited as artifact owners | | Consolidated Roles, Responsibilities, and RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Master RACI for ownership of every artifact in this catalog | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Adoption sequencing; instructs adopters to keep this catalog current | --- ## MATURITY SELF-ASSESSMENT AND SCORECARD ### Tier Self-Scoring · Pillar Domains · Gap Output · Re-Measurement --- | | | |---|---| | **Document ID** | CERG-GOV-MAT-001 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) · [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | | **Review Cycle** | Annual / On any change to the V1 library | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · NIST 800-55 · ISO/IEC 27004 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How the Assessment Works](#2-how-the-assessment-works) 3. [The Tier Scale](#3-the-tier-scale) 4. [Scoring Rules](#4-scoring-rules) 5. [The Assessment: Governance Domains](#5-the-assessment-governance-domains) 6. [The Assessment: Engineering Domains](#6-the-assessment-engineering-domains) 7. [The Assessment: Risk Domains](#7-the-assessment-risk-domains) 8. [The Assessment: Cross-Pillar Domains](#8-the-assessment-cross-pillar-domains) 9. [Scoring the Result](#9-scoring-the-result) 10. [The Scorecard Output](#10-the-scorecard-output) 11. [Turning Gaps Into Work](#11-turning-gaps-into-work) 12. [Quarterly Gap Checkpoint](#12-quarterly-gap-checkpoint) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §6 sets the target: the CERG model is designed to produce NIST CSF Adaptive-tier behavior. That is the aspiration. This document supplies the missing instrument: a way for an adopter to measure where the program actually sits today, and what stands between today and Adaptive. It is a self-assessment. An organization scores itself against 24 domains, each tied to real CERG artifacts and observable evidence. The output is a tier per domain, a tier per pillar, an overall tier, and a ranked list of the gaps worth closing first. It applies program-wide. It is run at day 1 of adoption to set a baseline, at day 90 to measure first-quarter movement (see [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §5), and annually after that. > **A Self-Assessment Is Only Useful If It Is Honest** > > The temptation in any self-scoring exercise is to score the intention rather than the evidence. CERG maturity scoring has one rule above all others: a domain scores at a tier only if the organization can produce the evidence named for that tier. Not "we do that," but "here is the artifact." A maturity score that cannot survive an auditor reading it is worth nothing. Score what you can show. --- ## 2. How the Assessment Works The assessment has four moving parts. 1. **Domains.** 25 assessment domains, grouped by pillar (Governance, Engineering, Risk) plus a Cross-Pillar group. Each domain is a coherent slice of the program tied to specific CERG artifacts. 2. **The tier scale.** Each domain is scored against the four NIST CSF tiers: Partial, Informed, Repeatable, Adaptive. Section 3 defines them. 3. **Evidence anchors.** Each domain lists what the organization must be able to show to claim each tier. Scoring is anchored to evidence, not opinion. 4. **The scorecard.** Domain scores roll up to pillar scores and an overall score, and the lowest-scoring domains become the gap list. The assessment is run by the Governance Pillar Leader, scored with the pillar leaders, and reviewed by the CISO. It is not run by one person in a room. A domain tier is agreed by the pillar that owns the work, and challenged by Governance. > **This Maps to the Same Tiers the Framework Uses** > > The four tiers here are exactly the four tiers in [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §6.1. This is deliberate. The framework says where CERG aims; this assessment says where you are on the same ruler. The gap between them is your roadmap. --- ## 3. The Tier Scale | **Tier** | **Score** | **What It Means for a Domain** | |---|---|---| | **Partial** | 1 | Ad hoc. The work happens reactively or not at all. No adopted CERG artifact governs it. Evidence is absent or accidental. | | **Informed** | 2 | The relevant CERG artifact is adopted and adapted, but practice is inconsistent. The work happens in some places, by some people, some of the time. Evidence is partial. | | **Repeatable** | 3 | The artifact is adopted and the practice is consistent. The work happens on its defined cadence, by the named role, every time. Evidence is collected systematically and is current. | | **Adaptive** | 4 | Repeatable, plus the domain improves itself. Metrics drive change, lessons and intelligence feed back in, and the practice is reviewed and tuned. Evidence shows a trend, not just a snapshot. | A domain never scores above the evidence. If a domain has consistent practice but no metric driving improvement, it is Repeatable, not Adaptive, no matter how well it runs. --- ## 4. Scoring Rules 1. **Score to the evidence floor.** A domain scores at the highest tier for which every evidence anchor at that tier and below can be produced. One missing anchor caps the domain at the tier below. 2. **A domain with no adopted artifact is Partial.** Tier 2 and above require the governing CERG artifact to be adopted. An un-adopted domain is Partial by definition, score 1. 3. **Partial implementation counts as half.** Where a domain is genuinely between two tiers, score the lower tier. Do not round up. This mirrors the anti-shallow-metrics discipline in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §8. 4. **Score the domain, not the document.** A standard can be beautifully written and score Partial because no one follows it. The score reflects practice and evidence, not prose. 5. **One scorer cannot self-clear.** The pillar that owns the work proposes the tier; Governance challenges it; the CISO accepts the final score. A domain tier is never set by a single unchallenged voice. 6. **Record the evidence.** Every domain score is recorded with the specific artifact, register, or report that supports it. A score with no recorded evidence is not a score. --- ## 5. The Assessment: Governance Domains Score each domain 1 to 4 against the tier scale. The evidence column names what supports the Repeatable (3) tier; Adaptive (4) additionally requires a metric or review loop driving improvement. | **#** | **Domain** | **Governing Artifact(s)** | **Repeatable-Tier Evidence** | **Score** | |---|---|---|---|---| | G1 | Policy and accountability | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Signed policy; named CISO; named Executive Sponsor; review date current. | | | G2 | Document control and catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Catalog matches the live library; every artifact has an ID, owner, and status. | | | G3 | Operating model and roles | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical roles assigned to named people; decision rights understood. | | | G4 | Control baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control set adopted; each control has a named evidence owner. | | | G5 | Risk management framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk scored and treated per the RMF; approval authority table applied. | | | G6 | Risk register operation | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Live register; Monthly Risk Register Review held; exceptions tracked. | | | G7 | Metrics and CISO reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | CISO dashboard published on cadence; metrics defined with bands. | | | G8 | Compliance and audit posture | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md), applicable `CERG-PLN` packages | Compliance matrix maintained; per-regulator package adopted for each regulator in scope. | | --- ## 6. The Assessment: Engineering Domains | **#** | **Domain** | **Governing Artifact(s)** | **Repeatable-Tier Evidence** | **Score** | |---|---|---|---|---| | E1 | Architecture review and project intake | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Projects routed through intake; pre-production reviews recorded. | | | E2 | Secure configuration and hardening | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Baselines defined and deployed; drift detected and corrected. | | | E3 | Identity and access management | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md), [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Access provisioned and reviewed per the runbook; MFA and PAM in force. | | | E4 | Cryptography and key management | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Cipher and key lifecycle managed; certificate inventory current. | | | E5 | Cyber resilience and backup | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | RTO/RPO defined; backups verified; recovery tested. | | | E6 | IT, cloud, and SaaS security | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Cloud and SaaS controls applied; landing-zone posture enforced. | | | E7 | OT and control systems security | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT controls applied where OT exists; IT/OT boundary defined. Score `N/A` if no OT. | | | E8 | Pre-production go-live readiness | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Pre-production checklist owned and signed before go-live; findings remediated or risk-accepted. | | --- ## 7. The Assessment: Risk Domains | **#** | **Domain** | **Governing Artifact(s)** | **Repeatable-Tier Evidence** | **Score** | |---|---|---|---|---| | R1 | Exposure management | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Scanning runs on cadence; remediation SLAs tracked and met. | | | R2 | Adversarial validation | [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Pen test, red team, or purple team exercises run and findings tracked. | | | R3 | Third-party and supply chain risk | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendors tiered and assessed; supply chain risks in the register. | | | R4 | Logging, monitoring, and detection | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Log sources defined; retention enforced; detection coverage mapped. | | | R5 | Risk taxonomy and exposure posture | [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) | Risks categorized to the taxonomy; exposure posture reported. | | | R6 | Threat intelligence | [`CERG-PRC-TI-001`](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) | Intelligence collected and distributed to Engineering, Detection, and Governance. | | | R7 | Pre-production versus post-production risk discipline | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §4.3 | Pre-production findings handled as engineering inputs; post-production findings as managed risks. | | | R8 | Crown-jewel scenario defense coverage | [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md) | Crown-jewel register maintained; named loss scenarios pressure-tested on cadence; chain-breaking controls verified Implemented and Effective; gaps generate Finding Records. | | --- ## 8. The Assessment: Cross-Pillar Domains These domains measure how well the pillars work as one program. They are where the CERG model either delivers on its premise or does not. | **#** | **Domain** | **Governing Artifact(s)** | **Repeatable-Tier Evidence** | **Score** | |---|---|---|---|---| | X1 | Pillar handoffs | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | The structured handoffs in the README lifecycle table happen, with no work dropped between pillars. | | | X2 | Coordination cadence | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | The standing coordination cadence is held; cross-pillar blockers are surfaced. | | | X3 | Incident response liaison | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | CERG feeds detection, vulnerability, and asset data to the IR team; liaison roles are named. | | | X4 | Adoption and adaptation discipline | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md), [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Corpus adapted via the render tool; one profile file; catalog kept current. | | | X5 | Single-point-of-failure resilience | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6 | Critical roles are backstopped; no role is held by exactly one person with no cover. | | --- ## 9. Scoring the Result ### 9.1 Domain to Pillar For each pillar, average its domain scores. Exclude any domain scored `N/A` (for example, E7 OT for an organization with no operational technology) from both the sum and the count. ``` Pillar score = sum of in-scope domain scores / count of in-scope domains ``` ### 9.2 Pillar to Overall The overall program tier is the average of the four group scores (Governance, Engineering, Risk, Cross-Pillar), then mapped: | **Average** | **Overall Tier** | |---|---| | 1.00 to 1.74 | Partial | | 1.75 to 2.49 | Informed | | 2.50 to 3.49 | Repeatable | | 3.50 to 4.00 | Adaptive | ### 9.3 The Honesty Check Before the score is accepted, the CISO applies one test: the **weakest-link read**. If any single domain is scored Partial, the program is not Repeatable overall in practice, regardless of the average. A Partial domain is a hole, and an average cannot fill a hole. The CISO records the overall tier *and* the count of Partial domains. Both numbers are reported. > **The Average Can Lie. The Partial Count Cannot.** > > An organization with twenty Repeatable domains and four Partial ones averages out near Repeatable. But those four Partial domains are four places the program does not function. CERG reports the average and the Partial count side by side, exactly as the metrics standard reports score-sum alongside raw count. A program is only as mature as its weakest in-scope domain. --- ## 10. The Scorecard Output The assessment produces a one-page scorecard. It is the artifact the CISO carries into the Cyber Oversight Group brief. ### 10.1 Scorecard Layout ``` CERG MATURITY SCORECARD Organization: {{ORG_NAME}} Assessment date: {{ADOPTION_DATE}} Assessed by: Governance Pillar Leader Accepted by: CISO OVERALL TIER: [ Partial | Informed | Repeatable | Adaptive ] Overall average: X.XX Partial domains: N PILLAR SCORES Governance X.XX [tier] Engineering X.XX [tier] Risk X.XX [tier] Cross-Pillar X.XX [tier] DOMAIN RADAR A four-axis radar (one axis per group) or a 24-spoke radar (one spoke per domain), each axis plotted 1 to 4. The shape shows concentration of weakness at a glance. THIS ASSESSMENT vs LAST Per pillar: arrow up / flat / down, with the delta. TOP FIVE GAPS The five lowest-scoring in-scope domains, lowest first, each with its governing artifact and the tier it needs to reach. ``` ### 10.2 Radar Specification The radar is the headline visual. Plot one axis per assessment domain (24 spokes) or, for a board-altitude view, one axis per group (4 spokes). Each axis runs 1 (center) to 4 (edge). The current assessment is one filled shape; the prior assessment is an outline overlaid on top. A program moving toward Adaptive grows the shape outward over successive assessments. A dent in the shape is a gap, visible without reading a number. This pairs with the trend-over-snapshot principle in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §2: the radar is only fully useful from the second assessment onward, when it carries an overlay. ### 10.3 Cadence | **Assessment** | **When** | **Purpose** | |---|---|---| | Baseline | Day 1 of adoption | Set the starting tier; seed the risk register with Partial domains. | | First-quarter | Day 90 of adoption | Measure first-cycle movement per [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §5.3. | | Annual | Every 12 months | Track the trend toward Adaptive; reset the gap list. | | Triggered | After a major incident, audit finding, or org change | Re-score the affected domains. | --- ## 11. Turning Gaps Into Work A scorecard that is filed and forgotten is vanity. The assessment is only finished when its gaps become tracked work. 1. **Every Partial domain becomes a risk register entry.** A domain scored Partial is an accepted gap until it is closed. It goes in the register per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), with an owner and a target tier. 2. **The top five gaps get named owners and dates.** The lowest five in-scope domains are the program's improvement backlog for the period. Each gets a pillar leader as owner and a target date. 3. **The next assessment measures the close.** A gap is closed when the domain re-scores at its target tier with evidence. The radar overlay shows it. 4. **Adaptive is a destination, not a checkbox.** A domain reaches Adaptive only when a metric or review loop is demonstrably driving its improvement. Closing gaps to Repeatable is the bulk of the work; reaching Adaptive is the last and hardest step, and it is what [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §6 describes. > **The Assessment Is Not the Goal** > > Scoring the program is half a day of work. Closing the gaps it finds is a year of work. An organization that runs the assessment, files the scorecard, and changes nothing has measured its program without improving it. The deliverable of this document is not a tier. It is the next five things the program will fix. --- ## 12. Quarterly Gap Checkpoint Between annual full assessments, the program operates with a 12-month blind spot. If a gap remediation stalls in month 3, the organization does not discover it until month 12. An Adaptive program runs lightweight quarterly checkpoints to verify that the top gaps are closing on schedule. ### 12.1 Cadence and Ownership Quarterly, aligned with the CERG leadership review (GOV-CAL-001 Section 5), the Governance Pillar Leader runs a gap remediation checkpoint. This is NOT a full re-score : domains are not re-evaluated. Only the in-progress gap remediation actions from the most recent full assessment are reviewed. ### 12.2 Checkpoint Questions For each open gap committed after the last full assessment, the checkpoint answers four questions: | Question | Response Options | Action | |---|---|---| | **Is the remediation on track to meet the target date?** | Yes / At Risk / No | At Risk: flagged for attention. No: escalated to CISO. | | **Has the evidence changed since the last checkpoint?** | New evidence exists / Same as last checkpoint / Evidence degraded | Degraded: the gap has gotten worse. Treat as a new finding. | | **Is this still a top-five gap, or has it been displaced?** | Still top-five / Displaced by new concern | If displaced, the new gap is assessed immediately rather than waiting for the next annual assessment. | | **Is the target tier still appropriate?** | Yes / No : should be raised / No : should be lowered | If changed, the target is adjusted and the owner is notified. | ### 12.3 Escalation Rules - Any gap marked "At Risk" for two consecutive checkpoints is escalated to the CISO with a remediation demand. - Any gap marked "No" (off track) is escalated to the CISO immediately. - Any domain where evidence has degraded since the last assessment is treated as a new gap and entered into the improvement register (IMPREG-001) with the source "Maturity Checkpoint QN YYYY." ### 12.4 Output The checkpoint produces a one-page Gap Checkpoint Summary, appended to the quarterly CISO brief (MTR-001). It shows: | Open Gap | Domain | Current Tier | Target Tier | Owner | Status | Target Date | Next Step | |---|---|---|---|---|---|---|---| ### 12.5 Annual Assessment Integration The quarterly checkpoint feeds the annual full assessment in two ways: 1. **Evidence currency.** By checking evidence quarterly, the annual assessment runs against evidence that is at most 90 days old, rather than scrambling to collect 12 months of evidence at assessment time. 2. **Gap transition.** Gaps that transition from simple remediation to complex multi-domain program changes may be moved from MAT-001 tracking to the improvement register (IMPREG-001). The checkpoint is the decision point where a gap owner may request this transition. The annual assessment remains the authoritative tier re-score. The quarterly checkpoint is a progress review, not a re-score. --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-MAT-001 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the V1 library | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST CSF 2.0 (GOVERN); NIST 800-55; ISO/IEC 27004 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-21 | Cyber Governance | Initial release. Establishes the four-tier self-assessment, 24 assessment domains across Governance, Engineering, Risk, and Cross-Pillar groups, evidence-anchored scoring rules, the domain-to-pillar-to-overall rollup with the weakest-link honesty check, the one-page scorecard and radar output specification, the assessment cadence, and the gaps-into-work discipline. | | 1.1 Draft | 2026-05-26 | Cyber Governance | Added Section 12 Quarterly Gap Checkpoint: quarterly remediation progress review with four checkpoint questions, escalation rules for at-risk and off-track gaps, one-page output format, and annual assessment integration. Renumbered Document Control to Section 13. Updated supporting documents to reference IMPREG-001 and CAL-001. | ### Review Triggers - Any artifact added to or retired from the V1 library, which changes the domain set - A standalone threat intelligence procedure is added to the catalog (updates domain R6) - Material change to the tier definitions in [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §6 - Adopter feedback indicating a domain is missing or mis-scoped - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Document Control) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory; the domain set tracks the catalog | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Defines the four tiers and the Adaptive target this assessment measures against | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Schedules the baseline and day-90 assessments | | Organization Adaptation Profile | [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Supplies the tokens used in the scorecard layout | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical roles that own domain scores | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control set assessed by domain G4 | | Metrics, Dashboard, and Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Shares the trend-over-snapshot and score-sum reporting discipline | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Where Partial domains are tracked as accepted gaps | --- ## METRICS, DASHBOARD, AND CISO / BOARD REPORTING ### Metrics Dictionary · KRI/KPI Data Source Map · CISO Dashboard · Brief and Report Templates --- | | | |---|---| | **Document ID** | CERG-GOV-MTR-001 | | **Version** | 1.32 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Reporting) | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) · [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) · [CERG-GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) · [CERG-PRC-LL-001](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) · [CERG-GOV-IMPREG-001](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) · [CERG-GOV-CEF-001](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) | | **Review Cycle** | Annual / On metrics-platform change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · NIST 800-55 · ISO/IEC 27004 | | **Regulations** | All - board reporting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Reporting Principles](#2-reporting-principles) 3. [Metrics Dictionary](#3-metrics-dictionary) 4. [KRI / KPI Data Source Map](#4-kri--kpi-data-source-map) 5. [CISO Risk and Posture Dashboard](#5-ciso-risk-and-posture-dashboard) 6. [Quarterly Cyber Oversight Group Brief Template](#6-quarterly-cyber-oversight-group-brief-template) 7. [Monthly CERG Leadership Report Template](#7-monthly-cerg-leadership-report-template) 8. [Anti-Shallow-Metrics Guardrails](#8-anti-shallow-metrics-guardrails) 9. [Cadence and Ownership](#9-cadence-and-ownership) 10. [Threshold Calibration](#10-threshold-calibration) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) commits the CISO to reporting compliance posture and material risk to executive leadership and the board. The Operating Model defines maturity indicators; the RMF defines KRIs and escalation triggers; the VM and Risk procedures define standing metrics. This document closes the gap between those conceptual metrics and the operational reporting the CISO actually publishes. It applies to every CERG-produced metric and every CERG-produced report consumed by the Cyber Oversight Group (CISO's reporting line, operating unit leadership, executives, or board depending on org structure), executive leadership, and the board. --- ## 2. Reporting Principles Five principles govern how CERG reports, in order of priority: 1. **Trend over snapshot.** A single-point metric tells the consumer almost nothing. Every CISO-facing visual shows direction and rate of change. 2. **Heat-map over count.** The consumer wants to know *where* concentration is, not the totalled number. Bands and concentration over raw counts. 3. **Score sum over volume.** Closing 200 Lows while 4 Criticals sit is worse than closing 8 Criticals. CERG reports residual-score weighted sums first, raw counts second. 4. **Compare, then explain.** Operating units against each other; this period against last; us against peer benchmarks where credible. Narrative memos are reserved for the board's specific questions. 5. **Audience-appropriate altitude.** The CISO sees comparison and trend. The Cyber Oversight Group sees the same plus a narrative. The board sees the top five risks and one strategic chart per pillar. > **What the CISO Does Not Care About** > > The CISO does not care that the team scanned 14,000 assets last month. The CISO cares which OU is worse than the others, where the concentration is, whether it's getting better, and what's blocking it. Metrics that don't answer one of those four questions don't reach the dashboard. --- ## 3. Metrics Dictionary The dictionary is the source-of-truth definition for every CERG metric. Each entry has: ID · Name · Definition · Formula · Source · Owner · Refresh · Threshold (Green/Amber/Red) · Trend Direction · Reported In. ### 3.1 Risk-Side Metrics (Owner: Cyber Risk + Risk Register Owner) | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | 1.31 | 2026-06-14 | Governance Pillar Leader | Moved orphan anti-vanity and program-quality metric sections under §8 so metadata remains at the top of the document and section numbering is deterministic. | | RM-001 | Open Critical+High Residual Risks | Count of `Status ∈ {Open, In Treatment}` with residual band ≥ High | Risk register | Daily | ≤ 10 / 11–25 / > 25 | CISO Dashboard, COG Brief | | RM-002 | Residual Risk Score (Sum) | Σ residual score over open risks | Risk register | Daily | ≤ baseline−10% / ±10% / > baseline+10% | CISO Dashboard, Trend Lines | | RM-003 | Mean Time to Close (High+) | Mean days from `Open` → `Closed/Accepted` for High and Critical | Risk register | Monthly | ≤ 60d / 61–120d / > 120d | CISO Dashboard | | RM-004 | Exception Backlog | Open exceptions count | Exception register | Weekly | ≤ 25 / 26–60 / > 60 | CISO Dashboard | | RM-005 | Exception Aging | % of open exceptions older than 12 months | Exception register | Monthly | ≤ 5% / 6–15% / > 15% | CISO Dashboard, COG Brief | | RM-006 | OU Risk Concentration Index | Std deviation of OU residual-score weighted sums | Risk register | Monthly | ≤ baseline / ±10% / > baseline+10% | CISO Dashboard | | RM-007 | Scenario Defense Coverage | % of named loss scenarios ([`CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)) where every chain-breaking control is Implemented (CB-001) AND Effective (CEF-001) | CJ-001 + CB-001 + CEF-001 | Quarterly | ≥ 90% / 75–90% / < 75% | CISO Dashboard, COG Brief, Board | ### 3.2 Exposure Management Metrics (Owner: Cyber Risk) These metrics measure exposure reduction, not scanner activity. They track the pipeline from observation to verified closure. | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | EM-001 | Confirmed Reachable Critical Exposure | Count of exposures in "Confirmed Exposure" or "Material Risk" state with Internet-facing reachability | Exposure pipeline | Daily | 0 / 1–3 / > 3 | CISO Dashboard | | EM-002 | Observations Awaiting Triage | Count of observations in "Observed" state past their validation SLA | Exposure pipeline | Daily | ≤ 5% / 6–15% / > 15% | CISO Dashboard | | EM-003 | Critical Observations Downgraded | % of Critical/High CVSS observations reclassified to Hygiene Debt or lower after context validation | Exposure pipeline | Monthly | Informational; no control target | CISO Dashboard | | EM-004 | KEV with Reachable Path | Count of KEV-matched observations in "Exposure Confirmed" or "Material Risk" state | Exposure pipeline + KEV catalog | Daily | 0 / 1–5 / > 5 | CISO Dashboard | | EM-005 | KEV Blocked by Verified Control | Count of KEV-matched observations classified as "Confirmed Flaw, Not Exposed" due to verified compensating controls | Exposure pipeline + KEV catalog | Weekly | Watchlist; no control target | CISO Dashboard | | EM-006 | Exposures on Crown Jewels | Count of confirmed exposures on crown-jewel-classified assets | Exposure pipeline + CJ-001 crown-jewel register | Daily | 0 / 1–2 / > 2 | CISO Dashboard | | EM-007 | SLA Misses with Compensating Controls | Exposures past SLA where a verified compensating control exists | Exposure pipeline | Weekly | ≤ 5 / 6–15 / > 15 | CISO Dashboard | | EM-008 | SLA Misses with No Controls | Exposures past SLA with no compensating control | Exposure pipeline | Weekly | 0 / 1–3 / > 3 | CISO Dashboard, COG Brief | | EM-009 | Observation-to-Decision Time | Median days from observation intake to classification | Exposure pipeline | Monthly | ≤ 3d / 4–7d / > 7d | COG Brief | | EM-010 | Decision-to-Treatment Time | Median days from classification to treatment selection | Exposure pipeline | Monthly | ≤ 2d / 3–5d / > 5d | COG Brief | ### 3.2a Patch Hygiene Metrics (Owner: Cyber Engineering: Platforms) Patch hygiene is a maintenance function distinct from exposure reduction. These track platform currency, not risk. | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | PH-001 | Patch Currency Rate | % of assets within their platform-class patch cadence window per [PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §10 | Patch management tool | Weekly | ≥ 95% / 85–95% / < 85% | COG Brief | | PH-002 | Hygiene Debt by Platform | Count of Hygiene Debt observations, grouped by platform class | Exposure pipeline | Monthly | Trend-only; no control target | COG Brief | | PH-003 | End-of-Support Count | Assets running software past vendor end-of-support date | Asset inventory | Monthly | 0 / 1–10 / > 10 | COG Brief | ### 3.2b Detection Metrics (Owner: Cyber Risk) ### 3.3 Engineering / Configuration Metrics (Owner: Cyber Engineering) | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | CM-001 | Baseline Drift Rate | % of assets failing DISH baseline | DISH scan | Daily | ≤ 2% / 3–8% / > 8% | CISO Dashboard | | CM-002 | Architecture Reviews Completed Pre-Production | % of in-scope projects with completed AR before go-live | AR log | Monthly | ≥ 95% / 85–95% / < 85% | CISO Dashboard, COG Brief | | CM-003 | Citizen-Dev Platforms with Guardrails | % of approved citizen-dev platforms with documented guardrails | Platform register | Quarterly | 100% / 90–100% / < 90% | COG Brief | | CM-004 | Backup Success Rate (Critical Systems) | % of Critical-tier backups completed successfully | Backup tool | Daily | ≥ 99% / 95–99% / < 95% | CISO Dashboard | | CM-005 | Restoration Test Currency | % of Tier-1 systems with current restoration test evidence | Resilience register | Quarterly | ≥ 95% / 80–95% / < 80% | CISO Dashboard | ### 3.4 Identity Metrics (Owner: Cyber Engineering: Identity) | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | ID-001 | Phishing-Resistant MFA Coverage (Privileged) | % of privileged accounts with phishing-resistant MFA | IdP | Daily | 100% / 95–100% / < 95% | CISO Dashboard | | ID-002 | Access Recertification Currency | % of in-scope systems with current recert | IGA | Monthly | ≥ 95% / 85–95% / < 85% | CISO Dashboard | | ID-003 | Dormant Privileged Accounts | Count of privileged accounts with no use in 60 days | PAM | Weekly | 0 / 1–10 / > 10 | CISO Dashboard | | ID-004 | Break-Glass Account Hygiene | % of break-glass accounts within rotation policy | PAM | Monthly | 100% / 90–100% / < 90% | CISO Dashboard | ### 3.5 Third-Party / Supply Chain Metrics (Owner: Cyber Risk: TPRM) | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | TP-001 | Tier 1 Vendors with Current Attestation | % | TPRM tool | Monthly | ≥ 95% / 85–95% / < 85% | CISO Dashboard | | TP-002 | SCCT Activations (Trailing 12m) | Count of SCCT activations | TPRM tool | Monthly | n/a - informational | COG Brief | | TP-003 | International Access Exceptions | Open international-access exceptions | Exception register | Monthly | ≤ baseline / ±20% / > baseline+20% | CISO Dashboard | | TP-004 | SBOM Coverage (Tier 1 Software) | % of Tier 1 software products with SBOM on file | TPRM tool | Quarterly | ≥ 90% / 75–90% / < 75% | COG Brief | ### 3.6 Governance / Regulatory Metrics (Owner: Cyber Governance) | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | GV-001 | CUI Practices Implemented ([CMMC L2](https://dodcio.defense.gov/CMMC/)) | % of in-scope 800-171 practices `Implemented` (Partial = 0.5) | CUI register | Monthly | 100% / 95–100% / < 95% | CISO Dashboard, Reg Posture | | GV-002 | Open POA&M Items (CUI) | Count + age of open POA&M | POA&M | Monthly | n/a - age-weighted | Reg Posture | | GV-003 | NERC-CIP Evidence Library Currency | % of CIP requirements with current evidence ≤ cycle | OT GRC | Monthly | ≥ 98% / 90–98% / < 90% | Reg Posture | | GV-004 | CIP Deviations Open | Count of approved deviations + average days open | OT GRC | Monthly | n/a | Reg Posture | | GV-005 | SOX ITGC Control Pass Rate | % of in-scope SOX ITGC tests passed in cycle | SOX program | Quarterly | 100% / 95–100% / < 95% | Reg Posture | | GV-006 | Policy/Standard Currency | % of CERG-managed artifacts within review cycle | Document Catalog | Monthly | >= 95% / 85-95% / < 85% | CISO Dashboard | ### 3.6a Control Effectiveness Metrics (Owner: Risk + Governance) These metrics measure whether controls are actually effective, not just present. They bridge the Control Effectiveness Framework ([`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md)) to the metrics dashboard. All three reference the control baseline ([`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md)) statuses and CEF-001 testing cadence. | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | CE-001 | Controls with Current Operating Effectiveness Test | % of `Implemented` controls with a current operating effectiveness test per CEF-001 cadence | CEF-001 testing schedule + CB-001 status | Monthly | >= 90% / 75-90% / < 75% | CISO Dashboard, COG Brief | | CE-002 | Critical/High Overlay Controls with E3 Evidence | % of Critical/High overlay controls (§8 of CB-001) that have E3 evidence (independent verification per AUD-001) | CB-001 overlay matrix + AUD-001 evidence tier mapping | Monthly | 100% / 90-100% / < 90% | CISO Dashboard, Reg Posture | | CE-003 | Control Testing Completion vs. Annual Plan | % of planned control tests completed within the current testing cycle per CEF-001 annual plan | CEF-001 testing plan + execution log | Quarterly | >= 95% / 80-95% / < 80% | COG Brief | > **CE Metrics Depend on CB-001 Status Accuracy.** CE-001 and CE-002 are only as meaningful as the control statuses recorded in CB-001 §4. A control marked `Implemented` without current evidence (or marked `Partially Implemented` when it should be `Implemented`) produces misleading CE scores. The annual Security Control Assessment (SCA) and the quarterly control effectiveness review serve as cross-checks on status accuracy. ### 3.7 Predictive and Leading Indicators (Owner: Governance Pillar Leader, with Risk and Engineering inputs) The metrics above are lagging indicators : they tell you what already happened. An Adaptive program also tracks predictive indicators that warn of trouble before it materializes. The following leading indicators complement the lagging dictionary. When any leading indicator breaches its defined threshold, it triggers a review at the quarterly Lessons Aggregation Review (PRC-LL-001 Section 5). | **ID** | **Name** | **Formula** | **Why Predictive** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---|---| | PL-001 | Mean Time to Exploit vs. Patch Velocity | (Avg days from CVE publication to known exploit) / (Avg days from CVE publication to patch deployment) | When ratio > 1.0, attackers are faster than patching. Trend direction predicts incident probability. | Exposure pipeline + threat intelligence | Monthly | <= 0.5 / 0.5-1.0 / > 1.0 | CISO Dashboard, COG Brief | | PL-002 | Attack Surface Change Rate | (New externally-facing assets + decommissioned assets + changed services this month) / total externally-facing assets | Rapid surface expansion without corresponding review capacity predicts exposure gaps. | Asset inventory + CMDB | Monthly | <= 5% / 5-15% / > 15% | CISO Dashboard | | PL-003 | Near-Miss Rate (Trailing Quarter) | Count of events that met detection thresholds but were contained before impact, per quarter | Rising near-miss rate can predict an incident when controls fatigue or coverage gaps align. A flat or falling rate after mitigations confirms effectiveness. | Near-miss log (PRC-LL-001) | Quarterly | n/a: informational; trend is the signal | COG Brief | | PL-004 | Threat-Intelligence-Tilted Risk Score | Sum of (risk score x TI confidence x sector targeting relevance) for top 20 risks | Incorporates whether threat actors are actively targeting the sector with TTPs relevant to each risk. Higher tilt = stronger alignment between risk register and threat landscape. | Risk register + TI assessment | Quarterly | n/a: informational; rising tilt demands attention | COG Brief | | PL-005 | Control Coverage vs. Threat Coverage | % of top 10 MITRE ATT&CK techniques for the sector that map to an operational CERG control | A falling percentage means threat evolution is outpacing control evolution : a predictive gap signal. | TRC-001 + ATT&CK mapping | Quarterly | >= 80% / 60-80% / < 60% | COG Brief | | PL-006 | Unpatched Vulns with Known Exploit | Count of open vulnerabilities where CISA KEV or vendor confirms active exploitation, regardless of CVSS score | More predictive than raw vulnerability count: these are the vulnerabilities attackers are actually using in the wild. | Exposure pipeline + CISA KEV | Daily | 0 / 1-5 / > 5 | CISO Dashboard | | PL-007 | Privileged Account Anomaly Rate | % of privileged sessions flagged as anomalous by UEBA or behavioral rules | Rising anomaly rate without corresponding investigation capacity predicts credential misuse incidents. | PAM / UEBA tool | Weekly | <= 2% / 2-5% / > 5% | CISO Dashboard | > **Leading Indicators Are Early Warning, Not Precision Instruments** > > A leading indicator does not need to be precise to be useful. It needs to change direction before the lagging indicator it predicts, and it needs to produce a signal the program can act on. PL-003 (near-miss rate) rising over three consecutive quarters is a signal even if the exact incident probability is unknown. The program that waits for precision misses the window to act. #### Minimum Viable Data Pipelines for PL Metrics Each predictive indicator requires correlation across multiple data sources. The following MVP pipelines define the automated data path that makes each metric continuously producible, not reliant on manual quarterly analysis: | Metric | MVP Pipeline | Automation Level | Manual Fallback | |--------|-------------|-----------------|-----------------| | **PL-001** (MTTE vs Patch Velocity) | CISA KEV feed → vulnerability scanner API → patch management API → daily ratio calculation | Full (API-driven) | Monthly CISA KEV download + manual spreadsheet ratio | | **PL-002** (Attack Surface Change Rate) | CMDB/asset API → daily snapshot → delta comparison vs prior day | Full (API-driven) | Monthly manual asset export + spreadsheet delta | | **PL-003** (Near-Miss Rate) | Near-miss log (PRC-LL-001) → metrics platform → quarterly aggregation | Partial (log capture automated; classification manual) | Quarterly manual review of incident log | | **PL-004** (TI-Tilted Risk Score) | Risk register API + TI platform feed → weighted score calculation | Partial (risk data automated; TI confidence manual) | Quarterly Risk + TI lead workshop | | **PL-005** (Control vs Threat Coverage) | ATT&CK mapping file (maintained by Detection Engineer) + detection rule registry → quarterly coverage % | Partial (registry automated; mapping manual) | Quarterly ATT&CK mapping review | | **PL-006** (Unpatched Vulns with Known Exploit) | CISA KEV feed + vulnerability scanner API → daily intersection (KEV ∩ open vulns) | Full (API-driven) | Weekly CISA KEV check + manual scanner query | | **PL-007** (Privileged Account Anomaly Rate) | PAM/UEBA tool API → weekly anomaly % calculation | Full (API-driven) | Monthly PAM report export + manual percentage | > **MVP Pipeline Priority.** Implement PL-006 (CISA KEV intersection) first — it has the highest automation potential and the clearest operational value. PL-001 and PL-004 follow. PL-003 and PL-005 can remain partially manual until maturity warrants automation investment. ### 3.8 Knowledge Management Metrics (Owner: Governance Pillar Leader) Knowledge "in the system" means knowledge that survives when the person who holds it is unavailable. These metrics measure whether critical knowledge is documented and transferable. | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | KM-001 | Procedure Documentation Currency | % of critical processes with current (<= 12 month) procedure documentation. "Critical" means the procedure supports a control marked Implemented in CB-001. | Document Catalog + procedure review dates | Quarterly | >= 95% / 85-95% / < 85% | CISO Dashboard | | KM-002 | Role Backup Currency | % of canonical roles (OM-001 Section 6.1) with a documented secondary or backup who has performed the role in an exercise or real event within 18 months | Cross-training log | Annual | >= 90% / 75-90% / < 75% | COG Brief | | KM-003 | Cross-Training Hours per Team Member | Mean cross-pillar knowledge activity hours per CERG team member per quarter. Target: >= 4 hours per quarter (OM-001 Section 10.4). | Cross-training log | Quarterly | >= 4.0 / 2.0-4.0 / < 2.0 | CISO Dashboard | ### 3.9 CERG Service Responsiveness Metrics (Owner: CISO / Pillar Leaders) These metrics hold CERG accountable to its own service-level commitments ([`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md)). They are reported alongside, and with equal weight to, the discipline metrics that measure the business. Targets reference the SLC-001 commitment values, which are preliminary defaults until organizationally calibrated. | **ID** | **Name** | **Formula** | **Source** | **Refresh** | **G / A / R** | **Reported In** | |---|---|---|---|---|---|---| | SR-001 | Architecture Review Turnaround | Median business days from complete AR intake to disposition, by project tier | AR log / intake system | Monthly | <= SLC target / 1-2x target / > 2x target | CISO Dashboard, COG Brief | | SR-002 | Advisory Response Time | Median business days from advisory request to substantive written response | Intake system | Monthly | <= 3d / 4-7d / > 7d | CISO Dashboard | | SR-003 | Intake Disposition Time | Median business days from project / SaaS intake to security disposition | Intake system | Monthly | <= SLC target / 1-2x target / > 2x target | CISO Dashboard, COG Brief | | SR-004 | SLC Commitment Adherence | % of CERG requests answered within the published SLC-001 commitment | Intake system | Monthly | >= 90% / 75-90% / < 75% | CISO Dashboard, COG Brief, Board | | SR-005 | Time-to-Coverage | Median days from asset go-live to exposure-management / CSPM coverage | Exposure pipeline + asset inventory | Monthly | <= 5d / 6-15d / > 15d | COG Brief | #### Adoption-Phase SLA Targets New adopters have no baseline. SR metrics are reported with phase context so that Red during initial adoption is understood as transitional, not program failure. SR-004 (SLC Commitment Adherence) uses the phase-adjusted target, not the mature target, for its G/A/R band. | Phase | Architecture Review (SR-001) | Advisory Response (SR-002) | Intake Disposition (SR-003) | Time-to-Coverage (SR-005) | |-------|----------------------------|---------------------------|----------------------------|--------------------------| | **Gate 1 (Spine, 0–90 days)** | 15 business days | 10 business days | 15 business days | 15 business days | | **Gate 2 (Operating, 90–180 days)** | 10 business days | 5 business days | 10 business days | 10 business days | | **Gate 3+ (Governed / Adaptive)** | Per SLC-001 §3.1 | Per SLC-001 §3.3 (3 business days) | Per SLC-001 §3.1 / §3.3 | Per SLC-001 §3.2 (5 business days) | > **Phase-Context Reporting.** The CISO Dashboard reports SR metrics with a phase-context indicator (e.g., "Gate 1 — transitional target"). The COG Brief includes the phase label in the SR-001 through SR-005 tiles. Phase advancement is recorded in the adoption gates document ([`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md)). --- ## 4. KRI / KPI Data Source Map The data source map tells the reporting team where each metric's underlying data comes from, who keeps it healthy, and what happens when it breaks. | **Metric IDs** | **Primary System of Record** | **Owning Role** | **Refresh Path** | **Failure Mode** | |---|---|---|---|---| | RM-001 – RM-006 | Risk register tool | Risk Register Owner | Nightly extract → metrics platform | Stale ETL: hold the day's CISO Dashboard, raise an Amber data-quality flag. | | EM-001 – EM-010 | Exposure pipeline (scanner, CSPM, SSPM, SCA, KEV, reachability context) | Exposure Management Lead | Hourly API / pipeline export → metrics platform | Source outage: fall back to last-known-good snapshot with timestamp banner. | | DT-001 – DT-003 | SIEM + detection coverage tool | Cyber Risk - Detection | Nightly source inventory + detection registry export | Missing source: detection coverage shown as Red. | | CM-001 – CM-005 | Configuration / VM / Backup tools | Cyber Engineering - Platforms / Resilience | Nightly aggregation | Backup tool outage: pull from job log; flag as Amber. | | ID-001 – ID-004 | IdP / IGA / PAM | Identity Engineer | Nightly export | Source change: re-baseline before publishing. | | TP-001 – TP-004 | TPRM tool | Cyber Risk - TPRM | Daily/weekly export | - | || GV-001 – GV-006 | CUI register / OT GRC / SOX program / Document Catalog | Cyber Governance - domain owners | Monthly publish | - | || PL-001 – PL-007 | See §3.7 MVP pipelines: CISA KEV feed, vulnerability scanner API, patch management API, CMDB, near-miss log, risk register, TI platform, ATT&CK mapping, PAM/UEBA | Governance Pillar Leader (aggregation) + Risk (data sources) | Daily (PL-001, PL-006); Weekly (PL-002, PL-007); Quarterly (PL-003, PL-004, PL-005) | Source API outage: fall back to manual fallback per §3.7 MVP table; flag as Amber data-quality | > **One Source per Metric** > > Each metric has exactly one system of record. Where two systems disagree, the system named here is authoritative and the other is reconciled. Reports that average two disagreeing sources hide the truth. --- ## 5. CISO Risk and Posture Dashboard The CISO dashboard is the single page that opens every monthly review. It is laid out around the five standing views defined in [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) Section 7, plus the regulatory posture strip. ``` ┌────────────────────────────────────────────────────────────────────────┐ │ CISO RISK & POSTURE - │ ├────────────────────────────────────────────────────────────────────────┤ │ TREND LINES (13-mo rolling) │ │ · Residual Score Sum (RM-002) ▁▂▃▄▄▅▆▇▆▅▄▄▃ ↓ │ │ · Critical+High Open Count (RM-001) ▆▆▅▅▄▄▄▃▃▃▃▂▂ ↓ │ │ · Mean Time to Close H+ (RM-003) ▂▃▄▅▅▄▃▃▃▂▂▂▂ ↓ │ ├────────────────────────────────────────────────────────────────────────┤ │ OU SCORECARD (residual-score weighted, ranked) │ │ OU │ Crit │ High │ Σ │ Δ vs prior │ Trend │ Exc │ SLA breach│ │ Gen Ops │ 2 │ 8 │ 184 │ -12 │ ↓ │ 6 │ 1 │ │ Trans Ops │ 1 │ 5 │ 121 │ +4 │ ↑ │ 3 │ 2 │ │ Dist Ops │ 0 │ 4 │ 98 │ -3 │ → │ 4 │ 0 │ │ Corp IT │ 1 │ 3 │ 85 │ -7 │ ↓ │ 9 │ 0 │ │ CUI Enclave│ 0 │ 2 │ 46 │ -2 │ → │ 1 │ 0 │ ├────────────────────────────────────────────────────────────────────────┤ │ OU × FAMILY HEAT MAP (Critical+High concentration) │ │ AC AU CM CP IA RA SC SI SR │ │ Gen Ops . . ▓▓ . ▓ . ▓▓ ▓ . │ │ Trans . . ▓ . . . ▓▓ ▓ . │ │ ... │ ├────────────────────────────────────────────────────────────────────────┤ │ TOP 10 RISKS │ │ ID │ OU │ Score │ Age │ Owner │ Next Milestone │ │ R-2026-0048│ Gen Ops │ 12 │ 91d │ Gen Ops Dir │ MFA wave 1 - Q3 │ │ ... │ ├────────────────────────────────────────────────────────────────────────┤ │ REGULATORY POSTURE │ │ CUI/CMMC L2 │ Practices: 92% POA&M open: 18 (mean 67d) Assessor: H1│ │ NERC-CIP │ Evidence currency: 96% Deviations open: 3 │ │ SOX ITGC │ Test pass rate: 98% Open deficiencies: 1 │ └────────────────────────────────────────────────────────────────────────┘ ``` The dashboard is published from the metrics platform; the ASCII above is the layout reference for designers and dashboard builders. Color rules follow Section 3 Green/Amber/Red bands. --- ## 6. Quarterly Cyber Oversight Group Brief Template The Cyber Oversight Group is whoever the CISO reports to, depending on org structure, it is IT and OU leadership, executive leadership, or the board itself. The brief is identical in structure regardless of audience; depth is calibrated by audience. ``` QUARTERLY CYBER OVERSIGHT GROUP BRIEF - Q 1. EXECUTIVE TAKEAWAY (1 page max) · Are we more or less exposed than last quarter? Why? · The one decision the group needs to make this quarter. 2. STATE OF RISK · Trend Lines slide (RM-002, RM-001, RM-003) · OU Scorecard · Top 10 Risks with one-line status per risk 3. STATE OF THE PROGRAM · Maturity indicators against [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) targets · CERG capability deltas this quarter (people, tooling, scope expansion) 4. REGULATORY POSTURE · CUI / NERC-CIP / SOX one-line state each · Upcoming assessments / audits with dates and gating issues 5. INCIDENTS AND NEAR-MISSES (CERG-facing summary; full IR report separate) · Material events this quarter; lessons learned actioned 6. ASKS · Decisions, funding, scope, or organizational moves required from the group 7. APPENDIX · OU × Family Heat Map · Standing dashboard exports · Risk register changes since last brief ``` The brief is published five business days before the meeting. Slides are read-ahead; the meeting is for discussion of the Asks. ### 6.1 Control Funding Decision Brief Pattern Use this one-page pattern when a control gap, repeated metric miss, overdue treatment, or risk acceptance requires a business funding or prioritization decision. The brief is a decision aid, not a replacement for the risk register, control baseline, or acceptance form. | **Field** | **Content** | |---|---| | Decision Needed | `[Fund / defer / reduce scope / accept residual risk / retire service / other]` | | Control or Risk Link | `[CB-001 control ID, risk ID, finding ID, or metric ID]` | | Business Capability Affected | `[System, process, customer obligation, regulatory scope]` | | Current Exposure | `[Plain-language consequence and residual rating]` | | Recommended Treatment | `[Control, project, staffing, tool, vendor, process change]` | | Funding / Capacity Ask | `[Amount, FTE, team capacity, vendor spend, schedule slot]` | | Options Considered | `[Option A/B/C with risk and cost tradeoff]` | | Decision Deadline | `[Date and reason: SLA, audit date, contract, threat activity, go-live]` | | If Approved | `[Expected risk reduction, metric movement, evidence produced]` | | If Deferred or Declined | `[Risk acceptance required? expiration? escalation?]` | | Named Owners | `[Business Owner, treatment owner, CERG reviewer]` | If the decision is to defer treatment while residual risk remains, route the resulting acceptance through [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) and [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md). Funding denial is not itself a risk acceptance; the Business Owner or required RMF-001 authority must explicitly accept the consequence. --- ## 7. Monthly CERG Leadership Report Template The internal CERG leadership report is consumed by Engineering / Risk / Governance pillar owners and the CISO. It is operational where the CISO Dashboard is comparative. ``` MONTHLY CERG LEADERSHIP REPORT - A. SCORECARD vs. METRIC TARGETS · Full Section 3 dictionary, this month, with G/A/R indicator and 3-month spark B. THIS MONTH'S DELTAS · Metrics that moved out of Green · Metrics that recovered into Green · Net new risks ≥ High and exceptions opened C. PILLAR HIGHLIGHTS (one paragraph each) · Engineering - projects intaken, ARs completed, baselines deployed · Risk - VM trends, vendor activity, adversarial validation results · Governance - policy/standard changes, regulatory milestones, audit interactions D. CROSS-PILLAR ITEMS · Items where ownership is unclear or work is blocked across pillars E. NEXT MONTH · Top three deliverables and named owner ``` --- ## 8. Anti-Shallow-Metrics Guardrails The guardrails below define how CERG avoids vanity metrics and program-health blind spots. ### 8.1 Metrics That Should Not Be Used Alone The following metrics are commonly reported but are easily gamed, misinterpreted, or disconnected from actual risk reduction. If you report them, pair them with a companion metric that provides context. | Vanity Metric | Why It Misleads | Pair With | |--------------|----------------|-----------| | Number of vulnerabilities closed | Rewards volume over severity. A team closing 100 Low findings looks better than a team closing 3 Criticals. | Exposure age by asset criticality; % of Critical/High findings past SLA | | Number of phishing emails blocked | Your email gateway blocks 99% of phishing — the 1% that gets through is what matters. | Phishing simulation click rate; time from phish report to containment | | Number of policies published | Publishing policies is not implementing controls. | % of controls with current evidence (E2+) | | Number of alerts generated | Alert volume is noise. Signal is what matters. | Detection signal-to-noise ratio; % of alerts resulting in validated incidents | | Number of vendors reviewed | A checkbox review of 100 vendors is worse than a thorough review of 10 high-risk vendors. | % of high-risk vendors with current assessment; vendor risk concentration | | Percent compliant without evidence quality | "95% compliant" based on policy existence, not control operation. | % of controls with E3 evidence; % of evidence current | | Training completion rate | Completion proves attendance, not comprehension or behavior change. | Phishing simulation results; incident root causes tracing to human error | ### 8.2 Program Quality Metrics These metrics measure whether the CERG program itself is healthy — not whether individual controls are operating. | Metric | What It Measures | Target | |--------|-----------------|--------| | % of risks with named business owner (not security) | Business accountability for risk | >90% | | % of exceptions with expiration date | Exception discipline | 100% | | % of control evidence current (within freshness window) | Evidence freshness | >85% | | % of Tier 0/Tier 1 assets with tested recovery | Resilience readiness | >95% | | % of high-risk vendors reviewed on schedule | Vendor risk currency | >90% | | % of adopted documents reviewed on schedule | Document governance | >80% | | Number of "Approved" documents with "Pending" approver | Governance hygiene | 0 | | Number of unresolved template values in approved documents | Operational readiness | 0 in adopted documents | | % of findings with a named owner assigned within SLA | Accountability timeliness | >90% | | % of accepted risks past expiration without review | Risk acceptance discipline | 0% | | % of recurring findings (same vulnerability, same system, >2 times) | Remediation effectiveness | <10% of total findings | | Average time from finding identification to owner assignment | Triage responsiveness | **A Metric That Can't Show "Worse" Should Not Be Reported** > If a metric is structured such that good operating units always look good and bad ones can hide, it's vanity. CERG either reframes the metric to expose the gap or removes it from the dashboard. --- ## 9. Cadence and Ownership | **Metric Group** | **Owner** | **Cadence** | **Audience** | |---|---|---|---| | RM-001 through RM-006 (Risk) | Risk Register Owner | Risk posture review: weekly for High/Critical; monthly for full register | CISO, Risk Pillar Leader | | EM-001 through EM-010 (Exposure Management) | Exposure Management Lead | Daily dashboard update; monthly trend report | CISO, Risk Pillar Leader | | DT-001 through DT-003 (Detection) | Detection Engineer | Monthly | Risk Pillar Leader, CISO | | CM-001 through CM-005 (Engineering) | Engineering Pillar Leader | Daily for CM-001, CM-004; monthly for others; quarterly for CM-003, CM-005 | CISO, Engineering Pillar Leader | | ID-001 through ID-004 (Identity) | Identity Engineer | Daily for ID-001; weekly for ID-003; monthly for ID-002, ID-004 | CISO, Identity Engineer | | TP-001 through TP-004 (Third-Party) | Vendor Risk Analyst | Monthly; quarterly for TP-004 | Risk Pillar Leader, CISO | | GV-001 through GV-006 (Governance) | Governance Pillar Leader | Monthly; quarterly for GV-005 | CISO, Governance Pillar Leader | || PL-001 – PL-007 (Predictive) | Governance Pillar Leader, with Risk and Engineering inputs | Monthly for PL-001, PL-002, PL-006; weekly for PL-007; quarterly for PL-003, PL-004, PL-005 | CISO, COG Brief | || CE-001 – CE-003 (Control Effectiveness) | Risk Pillar Leader + Governance Pillar Leader | Monthly for CE-001, CE-002; quarterly for CE-003 | CISO, COG Brief | The Governance Pillar Leader owns the metrics program overall and is accountable for dashboard accuracy, timely publication, and threshold governance. --- ## 10. Threshold Calibration The metric thresholds in Section 3 are not permanent. An Adaptive program adjusts its own measurement yardstick as the program matures, the threat landscape shifts, and risk appetite changes. Thresholds that were appropriate for an Informed program may be too loose for a Repeatable program and too tight for a newly adopted one. ### 10.1 Calibration Cadence Thresholds are reviewed: - **Annually**, aligned with the risk appetite review (GOV-RMF-001) - **When triggered** by any of the conditions in Section 10.2 ### 10.2 Calibration Triggers | Trigger | Condition | Action | |---|---|---| | **Green drift** | A metric has been green for 6+ consecutive months | Tighten the threshold to drive improvement. Exception: the metric has reached its theoretical maximum (e.g., 100% MFA coverage). | | **Red stall** | A metric has been red for 3+ consecutive months and no improvement actions are in progress | Either escalate to the CISO with a remediation demand, or recalibrate if the threshold was set unrealistically. A metric that is permanently red without program response is noise, not measurement. | | **Risk appetite change** | Risk appetite tightens or loosens in a domain (per RMF-001) | Corresponding metric thresholds tighten or loosen proportionally. | | **Maturity improvement** | The maturity scorecard (MAT-001) shows domain improvement (e.g., Partial to Repeatable) | Relevant metric thresholds are reviewed for tightening. A domain that has matured should be held to a higher standard. | | **External benchmark** | Peer benchmarking data (PRC-TI-001 Section 10.2) shows a significant gap | Threshold is reviewed against the peer norm. | ### 10.3 Calibration Rules 1. **Tighten, do not loosen without cause.** The default direction is tighter. A threshold is only loosened when: the metric was set unrealistically and cannot be met after documented good-faith effort, or risk appetite explicitly relaxes in the domain. 2. **One change at a time.** When multiple calibration triggers fire simultaneously, change one threshold per domain per quarter. Changing multiple thresholds simultaneously makes it impossible to determine which change drove which outcome. 3. **Communicate before enforcing.** When a threshold changes, the affected metric owners and the CISO are notified before the new threshold takes effect. The next reporting period shows both the old and new threshold for transition. ### 10.4 Threshold Change Log The Governance Pillar Leader maintains a threshold change log. Every change records: | Field | Example | |---|---| | Metric ID | EM-001 | | Date changed | 2026-09-01 | | Old threshold (Red) | > 5 | | New threshold (Red) | > 2 | | Trigger | Green drift : metric was green for 8 consecutive months | | Rationale | The program has consistently met the original threshold; tightening drives further improvement | | Approver | Governance Pillar Leader | The change log is reviewed at the annual metrics program review and is available to auditors as evidence of program evolution. ### 10.5 Integration Threshold changes are recorded as improvement register entries (IMPREG-001, type: Metric or threshold change) when they represent a deliberate program improvement, not just a routine calibration. A threshold tightened due to green drift is a program improvement; a threshold corrected because it was set incorrectly from the start is a bug fix. Both are documented; only the former is an improvement. --- ## 11. Document Control | | | |---|---| | **Document ID** | CERG-GOV-MTR-001 | | **Version** | 1.32 | | **Approved By** | CISO | | **Next Review** | Annual / metrics-platform change | | **Change Log** | 1.0 - Initial publication. Establishes dictionary, source map, CISO dashboard, briefs, and anti-shallow guardrails. · 1.1 - Added Section 3.7 Predictive and Leading Indicators (PL-001 through PL-007). · 1.2 - Restored Section 9 Cadence and Ownership. · 1.3 - Added Section 10 Threshold Calibration: cadence, triggers, rules, change log, and improvement register integration. · 1.32 - Added §6.1 Control Funding Decision Brief pattern for business funding/prioritization decisions tied to control gaps and risk treatments. | --- ## RECORD CATALOG ### Authoritative Record Types · Required Fields · Evidence Value --- | | | |---|---| | **Document ID** | CERG-GOV-CAT-002 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly / Upon new procedure or record type | | **Frameworks** | NIST CSF 2.0 (GOVERN) · NIST 800-53r5 CA, PL, PM | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed records and evidence stores | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Record Principles](#2-record-principles) 3. [Minimum Required Fields](#3-minimum-required-fields) 4. [Authoritative Record Catalog](#4-authoritative-record-catalog) 5. [Minimum Viable Evidence Library](#5-minimum-viable-evidence-library) 6. [Record Storage and Tooling Patterns](#6-record-storage-and-tooling-patterns) 7. [Record Quality Checks](#7-record-quality-checks) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope CERG procedures create records. Records become evidence. Evidence supports metrics, oversight, audits, and risk decisions. This catalog defines the canonical record types a CERG implementation should maintain. It prevents a common adoption failure: performing security work but losing the proof, ownership, decision trail, or closure evidence. This document applies to all CERG adopters. Small teams may maintain these records in spreadsheets. Larger teams may maintain them in GRC platforms, ticketing systems, CMDBs, repositories, or evidence platforms. The tool may change. The required record attributes do not. --- ## 2. Record Principles 1. **Every record has an owner.** Shared awareness is not ownership. 2. **Every record has a state.** Open, approved, accepted, closed, superseded, or retired must be visible. 2a. **Canonical names win over local aliases.** Teams may use local ticket names, queue names, or tool object names, but reporting, evidence indexes, and cross-references must map those aliases back to the canonical record types in §4. 3. **Every record has evidence.** The evidence may be lightweight, but it must exist. 4. **Every risk decision is explicit.** Silence is not acceptance. 5. **Every exception expires.** Permanent exceptions are risk acceptances or control changes. 6. **Every record can be traced.** A record should link to the policy, standard, procedure, control, system, asset, or decision that caused it. 7. **Every metric has a source record.** Dashboard values must be reproducible from records. --- ## 3. Minimum Required Fields Every CERG record should include these fields unless the source procedure explicitly narrows them. | Field | Purpose | |---|---| | Record ID | Stable identifier unique within the record type | | Record type | One of the catalog types in §4; aliases must map back to this value | | Title | Human-readable summary | | Description | What happened, what is required, or what decision is needed | | Owner | Role accountable for action or decision | | Supporting roles | Roles that must provide input or evidence | | Pillar | Engineering, Risk, Governance, CISO, or cross-pillar | | Related asset / system / vendor / project | Scope anchor | | Related control / standard / procedure | Governance anchor | | Severity / priority | Triage value where applicable | | Status | Current lifecycle state | | Open date | When the record was created | | Due date / review date | When action, review, or expiration is required | | Decision | Approved, rejected, accepted, deferred, remediated, or not applicable where applicable | | Decision date | Date the current decision was recorded where a decision is required | | Evidence link | Pointer to supporting evidence | | Last validated date | Date the record was last validated against operational reality, evidence, owner, and control/risk state | | Closure rationale | Why the record is closed or no longer active | | Last updated | Date of most recent material change | --- ## 4. Authoritative Record Catalog The record names in this section are authoritative. Other CERG documents may use local operational wording such as "ticket," "case," "register entry," "memo," "worksheet," or "backlog item," but those terms are aliases unless they appear as a canonical record type below. When a procedure, flow, template, example, or tool uses an alias, it must preserve the CAT-002 canonical record type in metadata, tags, evidence index, or cross-reference. ### 4.0 Common Alias Map | Canonical record type | Common aliases / local names | Alias rule | |---|---|---| | Control Implementation Record | Control Change Record, control implementation row, control status record, control snapshot | Use canonical name for control-baseline evidence and reporting. | | Evidence Index Entry | Evidence record, evidence library row, evidence package index | The artifact may be evidence; the index entry is the cataloged record. | | Program Improvement Record | Improvement Record, improvement backlog item, lessons-learned action | Use Program Improvement Record when the item changes CERG process, control, metric, or cadence. | | Risk Register Entry | Risk Record, risk register row, risk item | `Risk Record` is allowed as shorthand in flows; evidence indexes should map it to Risk Register Entry. | | Security Exception Record | Exception Record, deviation record, waiver ticket | `Waiver` and `deviation` are local aliases only; the canonical CERG record is Security Exception Record. | | Risk Acceptance Record | Risk acceptance memo, accepted-risk entry, acceptance request | `TMPL-RM-004` is the required acceptance form; `TMPL-RM-003` may support it but does not replace it. | | Finding Record | Finding ticket, vulnerability ticket, exposure item, audit finding | Raw scanner output becomes a Finding Record only after triage/validation. | | Exposure Backlog Item | Vulnerability backlog row, scanner observation, exposure ticket | Use for PRC-VM exposure workflow; promote to Finding Record or Risk Register Entry when criteria are met. | | Project Security Review Record | Project Intake Record, Architecture Review Record, security review ticket | Intake and architecture-review tools may split the workflow; the evidence package maps to this canonical record. | | Security Change Review Record | Change Record, security impact assessment, release security review | `Change Record` is acceptable shorthand where the change system is the source of truth. | | Asset Inventory Record | Asset Record, CMDB item, system inventory row | Local CMDB object names must preserve owner, classification, criticality, and coverage status. | | System Control Profile Record | SCP, system control profile, per-system control profile, SSP control implementation extract | Use for per-system or per-system-class control implementation, evidence, validation, and review state. It supports but does not replace regulated SSPs, POA&Ms, or CIP evidence packages. | | Incident Record | IR ticket, incident case, security incident record | Owned by the standing IR team; CERG support evidence links to, but does not replace, this record. | | Lessons Learned Record | Post-incident action, after-action item, PIR finding | Use Program Improvement Record when the lesson changes the CERG program. | ### 4.1 Governance and program records | Record type | Primary owner | Created by | Required when | Evidence value | |---|---|---|---|---| | Organization Adaptation Profile | Governance Pillar Leader | [VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | First adoption and material organizational change | Proves scope, regulators, tailoring decisions, and role consolidation | | Role Assignment Map | CISO / Governance Pillar Leader | [OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md), [RAC-001](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | First adoption and role change | Proves accountability for canonical CERG roles | | Document Catalog Entry | Governance Pillar Leader | [CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | New, changed, retired, or superseded artifact | Proves document authority and status | | Control Implementation Record | Governance Pillar Leader | [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md), FLOW F-01 | Control baseline adoption or control change | Proves implementation status, owner, inheritance, and evidence | | Evidence Index Entry | Evidence Librarian | [AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md), [PRC-AUD-001](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence is collected or refreshed | Proves evidence location, quality tier, source, and period | | Program Improvement Record | Governance Pillar Leader | [IMPREG-001](CERG-GOV-IMPREG-001_Program_Improvement_Register.md), FLOW F-07 | Lesson, metric miss, audit issue, maturity gap, or recurring failure | Proves the program learns and changes | | Oversight Decision Record | CISO / COG Chair | [MTR-001](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Board, CISO, or COG decision | Proves executive risk and resource decisions | | Maturity Assessment Record | Governance Pillar Leader | [MAT-001](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Annual assessment or quarterly checkpoint | Proves maturity tier, gaps, and resulting work | ### 4.2 Risk records | Record type | Primary owner | Created by | Required when | Evidence value | |---|---|---|---|---| | Risk Register Entry | Risk Register Owner | [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Material cybersecurity risk is identified | Proves risk statement, scoring, treatment, owner, and status | | Security Exception Record | Risk Register Owner | [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), [TMPL-RM-002](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) | Temporary deviation from a policy, standard, or control | Proves temporary approval, compensating controls, expiration, and owner | | Risk Acceptance Record | Business Owner / Executive Sponsor with Risk Register Owner | [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), [TMPL-RM-004](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | Residual risk is formally accepted under RMF-001 §9.7 | Proves explicit business consequence acceptance, CISO approval where required, conditions, expiration, and review cadence | | Finding Record | Exposure Management Lead / relevant Risk owner | FLOW F-04, [PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Vulnerability, audit issue, test result, control gap, or observation is validated | Proves triage, severity, ownership, and disposition | | Exposure Backlog Item | Exposure Management Lead | [PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Vulnerability requires tracking to remediation or exception | Proves remediation status and SLA performance | | Threat Intelligence Record | Threat Intelligence Analyst | [PRC-TI-001](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) | Intelligence changes risk, detection, or prioritization | Proves source, relevance, action, and disposition | | Adversarial Validation Record | Adversarial Testing Lead | [PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Penetration test, red team, purple team, or validation exercise occurs | Proves test scope, findings, detection results, and remediation | | Vendor Risk Assessment Record | Vendor Risk Analyst | [PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor, SaaS, MSP, subprocessors, or supply-chain dependency is assessed | Proves tiering, security review, contractual requirements, and decision | | Edge Register Entry | Vendor Risk Analyst / Governance Pillar Leader | [EDG-001](CERG-GOV-EDG-001_Edge_Register.md) | Boundary exists where third-party control can affect posture | Proves external dependency, owner, monitoring, and control path | | Crown Jewel Scenario Record | Risk Pillar Leader | [CJ-001](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md) | Crown jewel or material loss scenario is identified | Proves top-down risk context and scenario-driven prioritization | ### 4.3 Engineering records | Record type | Primary owner | Created by | Required when | Evidence value | |---|---|---|---|---| | Project Security Review Record | Pre-production Reviewer / Security Architecture | [PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md), FLOW F-02 | New project, material change, SaaS adoption, cloud workload, app, or OT change | Proves review tier, requirements, decision, and handoff | | Approved Pattern Record | Engineering Pillar Leader / pattern owner | [PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) §4.5 | Reference architecture, IaC module, service-catalog template, SaaS configuration, citizen-dev guardrail, or pipeline profile is approved for reuse | Proves approved scope, required controls, evidence, limitations, review date, and triggers for re-review | | Threat Model Record | Risk / Engineering jointly | [PRC-TM-001](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Review tier requires threat modeling | Proves threats, misuse cases, mitigations, and residual risk | | Asset Inventory Record | Asset owner / Engineering | [STD-AM-001](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md), FLOW F-03 | Asset enters, changes, or leaves scope | Proves asset existence, classification, owner, and lifecycle | | Asset Coverage Record | Engineering Pillar Leader | FLOW F-03 | Asset needs coverage for logging, scanning, backup, endpoint, identity, or monitoring | Proves required security coverage exists or is exceptioned | | System Control Profile Record | System Owner / Engineering Pillar Leader | [TMPL-SCP-001](../templates/CERG-TMPL-SCP-001_System_Control_Profile_Template.md), [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md), [TRC-001](CERG-GOV-TRC-001_Control_to_Procedure_Traceability_Matrix.md) | A system or system class needs a consolidated control implementation, evidence, last-validation, and next-review profile | Proves per-system control implementation, evidence linkage, residual condition, and review state; supports SSP, NERC-CIP, SOX, and audit assertions | | Configuration Baseline Record | Platform / Endpoint / Cloud Engineer | [STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Baseline is created, changed, tested, or applied | Proves approved configuration and drift management | | Security Change Review Record | Engineering Pillar Leader | [PRC-CHG-001](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md), FLOW F-05 | Change may affect security posture | Proves security review, decision, and release condition | | Access Review Record | Identity Engineer / Governance | [STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md), [PRC-AC-002](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Scheduled recertification or privileged access review occurs | Proves entitlement review and corrective actions | | Backup and Recovery Test Record | Engineering / Resilience owner | [STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md), [PLN-BC-001](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) | Backup, restore, DR, or cyber recovery test occurs | Proves recoverability and restoration evidence | | Detection Coverage Record | Detection Engineer | [STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | New detection, data source, or ATT&CK coverage claim is created | Proves monitoring coverage and validation status | ### 4.4 Incident and continuity records | Record type | Primary owner | Created by | Required when | Evidence value | |---|---|---|---|---| | Incident Record | Incident Commander | [PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Security incident is declared | Proves timeline, decisions, containment, eradication, and recovery | | Incident Action Log | Incident Commander | [PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md), [PRC-IR-002](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | Incident response is active | Proves actions, owners, timestamps, and communications | | Lessons Learned Record | Governance Pillar Leader | [PRC-LL-001](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md), FLOW F-06 | Incident, tabletop, audit, test, or failed control produces learning | Proves cause, corrective action, owner, and program feedback | | Business Continuity Exercise Record | Business Continuity owner / Governance | [PLN-BC-001](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) | BCDR exercise or tabletop occurs | Proves resilience exercise and improvement actions | ### 4.5 Regulatory package records | Record type | Primary owner | Created by | Required when | Evidence value | |---|---|---|---|---| | System Security Plan | CMMC / Federal Compliance Manager | [PLN-CUI-001](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md), [TMPL-CUI-001](../templates/CERG-TMPL-CUI-001_System_Security_Plan_Template.md) | CUI / FCI environment is in scope | Proves system boundary, control implementation, and inheritance | | POA&M Item | CMMC / Federal Compliance Manager | [TMPL-CUI-002](../templates/CERG-TMPL-CUI-002_POAM_Template.md) | CUI control gap requires tracked correction | Proves remediation plan and status | | NERC-CIP Evidence Record | NERC-CIP Compliance Manager | [PLN-CIP-001](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | NERC-CIP requirement applies | Proves requirement-specific compliance evidence | | SOX ITGC Test Record | SOX ITGC Lead | [PLN-SOX-001](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | SOX-relevant control is tested | Proves test design, sample, exception, and conclusion | | ISO ISMS Record | Governance Pillar Leader | [PLN-ISO-001](../plans/CERG-PLN-ISO-001_ISO_IEC_27001_Operational_Package.md) | ISO 27001 readiness or certification is in scope | Proves ISMS scope, control applicability, and management review | | Privacy Security Support Record | Governance / Privacy interface owner | [PLN-PRIV-001](../plans/CERG-PLN-PRIV-001_Privacy_and_Data_Protection_Operational_Package.md) | Privacy, data protection, or data-subject process needs security support | Proves security contribution to privacy obligations | --- ## 5. Minimum Viable Evidence Library ### 5.1 CERG Lite A small-team implementation should be able to produce at least: 1. Signed cybersecurity policy. 2. Organization Adaptation Profile. 3. Role Assignment Map. 4. Asset inventory extract. 5. Initial top risks in the risk register. 6. Exposure backlog. 7. Exception register, even if empty. 8. Evidence index. 9. Control implementation snapshot. 10. Regulatory applicability decision. 11. First 30-day improvement backlog. 12. Access review evidence for the highest-risk identity groups. 13. Backup or restore test evidence for the most critical system. ### 5.2 CERG Standard A standard implementation adds: - Project security review records. - Vendor risk assessment records. - Security change review records. - Configuration baseline records. - Detection coverage records. - Quarterly metrics dashboard. - Quarterly oversight decision records. - Annual maturity assessment record. ### 5.3 CERG Regulated A regulated implementation adds the applicable package records: - SSP and POA&M for CUI / CMMC. - NERC-CIP evidence records for applicable requirements. - SOX ITGC test records for SOX-relevant systems. - ISO ISMS records for ISO certification or readiness. - Privacy security support records where privacy obligations apply. --- ## 6. Record Storage and Tooling Patterns | Pattern | Acceptable for | Minimum condition | |---|---|---| | Spreadsheet | CERG Lite, first 90 days, low-complexity teams | Stable IDs, owners, dates, status, evidence links, access control | | Ticketing system | Findings, vulnerabilities, exceptions, changes, improvements | Required fields preserved and reports exportable | | GRC platform | Controls, risks, evidence, regulatory packages | Cross-links preserved between controls, risks, evidence, and owners | | Git repository | Policies, standards, procedures, templates, decision records | Version history, review workflow, and sensitive evidence kept out of public repos | | Evidence platform / document library | Audit evidence and recurring exports | Retention, access control, period labeling, and source integrity | Tool choice must not remove required CERG fields. If the tool cannot represent a required field, the implementation must add a custom field, tag, linked record, or evidence note. --- ## 7. Record Quality Checks A record is not complete unless it passes these checks: | Check | Question | |---|---| | Ownership | Is one role accountable? | | Scope | Is the affected system, asset, vendor, project, control, or process clear? | | Decision | Is the decision explicit where one is required? | | Evidence | Is supporting evidence linked and readable? | | Date discipline | Are open date, due date, expiration date, or review date present? | | Traceability | Can the record be traced to the relevant policy, standard, procedure, or flow? | | Closure | If closed, is the closure rationale documented? | | Metric impact | If the record feeds a metric, can the metric be recalculated from the record? | --- ## 8. Document Control | | | |---|---| | **Document ID** | CERG-GOV-CAT-002 | | **Version** | 1.2 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Governance Pillar Leader (Document Control) | | **Next Review** | Quarterly / Upon new procedure or record type | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.2 | 2026-06-20 | Governance Pillar Leader | Added System Control Profile Record, minimum decision/validation fields supporting Definition of Done, and SCP alias discipline. | | 1.1 | 2026-06-18 | Governance Pillar Leader | Added canonical record-name and alias discipline, common alias map, and aligned risk acceptance records to RMF-001 §9.7 and TMPL-RM-004. | | 1.0 | 2026-06-13 | Governance Pillar Leader | Initial publication. Establishes the authoritative CERG record catalog, minimum required fields, and minimum viable evidence library. | ### Review Triggers - New procedure creates or retires a record type. - New operational package creates regulatory records. - Audit feedback identifies missing or inconsistent records. - Metrics cannot be reproduced from source records. - Tooling migration changes record storage. ### Related Documents - [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) - Document Catalog and Naming Convention - [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) - Cross-Pillar Operational Flows - [CERG-GOV-AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) - Evidence Quality Standard - [CERG-PRC-AUD-001](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) - Audit and Evidence Management Procedure - [CERG-GOV-MTR-001](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) - Metrics and Reporting --- ## UNIFIED CONTROL BASELINE ### Organizational Baseline · Overlay Matrix · Implementation, Evidence, and Inheritance Model --- | | | |---|---| | **Document ID** | CERG-GOV-CB-001 | | **Version** | 2.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Control Baseline) | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-STD-AI-001](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | | **Review Cycle** | Annual - and on framework version change ([NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) rev, [CMMC](https://dodcio.defense.gov/CMMC/) rev, NERC-CIP version, AI governance framework change) | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · CIS Controls v8 · ISO/IEC 27001 A.5–A.8 · CSA CCM v4 · NIST AI RMF 100-1 · ISO/IEC 42001 | | **Regulations** | NERC-CIP v7 (and CIP-015 draft) · [CMMC L2](https://dodcio.defense.gov/CMMC/) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT, CUI, AI-enabled systems | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Design Principles](#2-design-principles) 3. [The CERG Control Family Spine](#3-the-cerg-control-family-spine) 4. [Implementation Statuses](#4-implementation-statuses) 5. [Inheritance Model](#5-inheritance-model) 6. [Organizational Baseline (Core)](#6-organizational-baseline-core) 7. [Control Status Decision Tree](#7-control-status-decision-tree) 8. [Overlay Matrix](#8-overlay-matrix) 9. [Control-to-Evidence Mapping](#9-control-to-evidence-mapping) 10. [Regulatory Crosswalks](#10-regulatory-crosswalks) 11. [Governance, Change, and Versioning](#11-governance-change-and-versioning) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The Unified Control Baseline turns the principles in [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md), the requirements in subordinate standards, and the philosophy in the [CERG Risk Management Framework](CERG-GOV-RMF-001_Risk_Management_Framework.md) into an implementation-ready control set. It is the document a control owner, an internal auditor, a [CMMC](https://dodcio.defense.gov/CMMC/) C3PAO, a NERC-CIP auditor, or a [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) auditor opens first. It applies to every in-scope asset and every CERG-owned control. Where a subordinate standard imposes a more specific requirement, the standard controls and is referenced from the relevant entry here. > **One Baseline, Many Audiences** > > Most programs maintain a separate control library per regulator, one for NIST, one for [CMMC](https://dodcio.defense.gov/CMMC/), one for NERC-CIP, one for [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), and then spend a quarter of every audit reconciling them. CERG inverts that: one baseline is implemented once and evidenced once. The crosswalks in Section 9 translate the same evidence into the language each regulator expects. --- ## 2. Design Principles The baseline is built on five non-negotiable principles. Anything that violates them is not in the baseline. 1. **NIST is the spine.** [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) control families are the organizing structure. CERG-native controls are layered onto that spine, never the reverse. When a NIST family fully covers an intent, CERG inherits the NIST language and identifier rather than coining a new one. 2. **Each control has one accountable CERG pillar.** Engineering, Risk, or Governance, never "shared." Supporting roles are listed separately. Accountability without ambiguity is the prerequisite to evidence. 3. **Each control has named evidence.** A control without a named evidence artifact is a control without proof; it does not enter the baseline. 4. **Overlays add, they do not redefine.** CUI, BES, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), and Safety overlays add controls or tighten parameters of base controls. They never silently relax the base. 5. **Inheritance is documented or it does not exist.** Inheritance from cloud/SaaS providers requires the artifact named in Section 5. "We assume the provider handles it" is not inheritance. --- ## 3. The CERG Control Family Spine CERG uses [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) control families as the top-level grouping. Each family has a one-line CERG intent and a primary owning pillar. | **Family** | **NIST Code** | **CERG Intent (one line)** | **Primary Owner** | |---|---|---|---| | Access Control | AC | Identity-bound, least-privilege access enforced consistently across IT, cloud, SaaS, OT, and CUI. | Engineering | | Awareness and Training | AT | Role-relevant security training; CERG defines the cyber content, Awareness function delivers. | Governance (content) | | Audit and Accountability | AU | Log every consequential action; protect, retain, and review the logs. | Risk (detection) | | Assessment, Authorization, and Monitoring | CA | Continuous, evidence-driven assurance that controls operate as intended. | Governance | | Configuration Management | CM | Approved baselines, change control, and drift detection across every platform. | Engineering | | Contingency Planning | CP | Cyber recovery and backup that survive ransomware, region failure, and OT event. | Engineering (cyber side) | | Identification and Authentication | IA | Strong, phishing-resistant identity for humans and machines. | Engineering | | Incident Response | IR | CERG-side requirements that IR depends on (telemetry, identity, baselines, recovery, evidence). | Risk (interface) | | Maintenance | MA | Controlled, evidenced maintenance; tighter in OT and BES scope. | Engineering | | Media Protection | MP | CUI and Restricted-data media handling. | Governance | | Physical and Environmental | PE | Cyber dependency on physical controls (data center, OT, CUI work area). | Governance (interface) | | Planning | PL | SSPs, security plans, authorization packages, architecture documentation. | Engineering / Governance | | Personnel Security | PS | Screening and access-tied personnel controls. | Governance (interface to HR) | | Risk Assessment | RA | Continuous risk identification, scoring, and treatment. | Risk | | System and Services Acquisition | SA | Security in procurement, vendor risk, SBOMs, secure SDLC. | Risk (TPRM) / Engineering (SDLC) | | System and Communications Protection | SC | Network segmentation, cryptography, OT boundary protection. | Engineering | | System and Information Integrity | SI | Vulnerability, malware, monitoring, advisories, integrity. | Risk | | Supply Chain Risk Management | SR | Software, hardware, and service supply chain integrity. | Risk (TPRM) | | Program Management | PM | The CERG program itself - policy, metrics, board reporting. | Governance | --- ## 4. Implementation Statuses Every control entry in the baseline carries one of the following statuses. The set is intentionally small, it survives audits in every framework CERG must support. | **Status** | Published | **Evidence Expected** | |---|---|---| | `Implemented` | Control is in place, tested, and operating as designed. | Named evidence artifact for the current cycle. | | `Partially Implemented` | Control is in place for some scope or is operating at reduced effectiveness. | Evidence of what is in place plus a POA&M entry. | | `Inherited` | Implementation is provided by another party - cloud provider, SaaS provider, parent enterprise control, IAM team. | Inheritance Evidence Package (Section 5). | | `Planned` | Control is planned with an owner and target date. | POA&M entry with date and owner. | | `Risk Accepted` | Deviation is approved and tracked via [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) Section 7. | Risk register entry, exception ID, approver. | | `Not Applicable` | Control does not apply to this scope. | Documented N/A rationale (system type, no in-scope data, etc.). | > **What's Not on the List** > > "In Progress," "Undetermined," "Working On It," and "Vendor Says Yes" are not statuses. Every entry in the baseline maps to one of the six above. Honesty about Partially Implemented and Planned is worth far more than optimism about Implemented. --- ## 5. Inheritance Model `Inherited` is the most-abused status in cloud-era control libraries. CERG requires the following Inheritance Evidence Package for any control marked `Inherited`. Without it, the status defaults to `Not Implemented` and a finding is opened. The package has six elements: 1. **Provider attestation**, current SOC 2 Type II / ISO 27001 / FedRAMP / PCI report containing the inherited control. 2. **Shared responsibility mapping**, the section of the provider's shared responsibility matrix that names this control as the provider's. 3. **Customer-side evidence of configuration**, proof the customer-side prerequisites are configured (e.g., logging enabled, region selected, IAM lockdown applied) that allow the inherited control to actually protect the customer's tenancy. 4. **Sub-service organization carve-outs**, explicit notation if the inherited control depends on a sub-service organization (e.g., AWS underlying Snowflake) and how that dependency is covered. 5. **Currency check**, attestation expiry date and the calendar entry that re-runs this check. 6. **Re-papering trigger**, what would cause CERG to re-evaluate inheritance (provider control failure, attestation lapse, scope change, customer-side prerequisite drift). This package is the basis of every "we inherit it from AWS / Azure / GCP / M365 / Salesforce / ServiceNow / our [CMMC](https://dodcio.defense.gov/CMMC/) enclave provider" claim CERG makes. --- ## 6. Organizational Baseline (Core) The organizational baseline applies to every in-scope asset. Overlays in Section 7 add or tighten controls for High-Impact, CUI, BES, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), and OT Safety scopes. The full implementation-ready control set is captured by family in the sections that follow. Each entry has: Control ID · Action Statement · System Applicability · Owning Pillar · Named Evidence · Frequency · Subordinate Standard. System Applicability uses one or more of the following values: Hardware, Software, Network, Cloud, Data, Process. Section 6 entries below are organized by family and reference the subordinate standard for parameter detail. Where parameter detail differs by environment (IT/cloud/SaaS, OT, CUI), the subordinate standard is authoritative; the baseline names the control once. ### 6.1 Access Control (AC) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ----------- | --------------------------------- | ---------------------- | ----------------------- | | AC-2 Account Management | Make sure every account used with your system has an approved request, named owner, defined access level, and current JML record; update or remove access when roles change or access is no longer needed. | Hardware, Software, Network, Cloud, Data, Process | Engineering | JML log, quarterly recert report | Continuous / Quarterly | STD-AC-001 | | AC-3 Access Enforcement | Make sure your system uses approved authentication and authorization controls for all access, and that local, shared, hard-coded, or static credentials cannot bypass them. | Hardware, Software, Network, Cloud, Data | Engineering | IdP/PAM policy export | Annual | STD-AC-001 | | AC-6 Least Privilege | Grant users, administrators, services, and vendors only the access needed for their role; make privileged access time-bound, just-in-time where supported, and recorded. | Hardware, Software, Network, Cloud, Data, Process | Engineering | PAM session logs, role inventory | Quarterly | STD-AC-001 | | AC-7 Unsuccessful Logon Attempts | Configure failed-login thresholds, lockouts, and identity-attack alerts according to STD-AC-001 and verify they are operating. | Hardware, Software, Network, Cloud | Engineering | IdP policy export, detection rule | Annual | STD-AC-001 / STD-LM-001 | | AC-17 Remote Access | Make sure remote access to your system uses approved gateways, MFA, and session logging; do not create direct or undocumented remote access paths. Access outside of the US will need documented exceptions. | Network, Cloud | Engineering | Gateway logs, MFA policy export | Continuous | STD-AC-001 | | AC-19 Mobile / BYOD | Allow mobile or BYOD access only when the device is enrolled, compliant, and approved by conditional-access policy. | Hardware | Engineering | MDM compliance report | Quarterly | STD-AC-001 | ### 6.2 Audit and Accountability (AU) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | --------- | ----------------------------------------------- | ------------ | ---------- | | AU-2 Event Logging | Make sure your system sends required security, administrative, authentication, and activity logs to the SIEM or approved OT one-way collection point. | Hardware, Software, Network, Cloud, Data | Risk | SIEM source inventory, gap report | Monthly | STD-LM-001 | | AU-6 Audit Review | Review and respond to alerts generated from your system logs, and correct coverage or tuning gaps identified by Risk. | Hardware, Software, Network, Cloud, Data, Process | Risk | Detection coverage report, triage queue metrics | Continuous | STD-LM-001 | | AU-9 Protection of Audit Information | Protect your system's audit logs from alteration or deletion, and make sure administrative changes to logging are also logged. | Software, Cloud, Data, Process | Risk | Storage policy, admin-action review | Quarterly | STD-LM-001 | | AU-11 Audit Record Retention | Keep audit records for the required retention period, including 13 months hot / 7 years cold by default and BES minimums when applicable; verify a sample can be retrieved. | Hardware, Software, Network, Cloud, Data, Process | Risk | Retention policy, sample retrieval | Annual | STD-LM-001 | | AU-12 Audit Record Generation | Configure systems to generate the required security, administrative, authentication, and privileged-activity audit records; verify sample events are produced and parsable. | Hardware, Software, Network, Cloud, Data | Risk | Log generation configuration, sample event test | Annual | STD-LM-001 | ### 6.3 Configuration Management (CM) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------ | ------------------------------------------ | ------------ | ----------------------- | | CM-2 Baseline Configuration | Apply the correct DISH baseline for your platform class and keep evidence showing the baseline was applied. | Hardware, Software, Network, Cloud | Engineering | DISH baseline catalog, scan report | Continuous | STD-CFG-001 | | CM-3 Change Control | Submit production changes through change management before implementation and include security review when required. | Hardware, Software, Network, Cloud, Data, Process | Engineering | CAB minutes, change records | Continuous | STD-IT-001 / STD-OT-001 | | CM-5 Access Restrictions for Change | Restrict who can make production changes or modify approved baselines; review elevated change authority and emergency-change use for appropriateness. | Hardware, Software, Network, Cloud, Data, Process | Engineering | Change-authority roster, emergency-change review | Quarterly | STD-CFG-001 / PRC-CHG-001 | | CM-6 Configuration Settings | Create and confirm a system baseline so cyber can detect and remediate drift; document and route exceptions through Section 4. | Hardware, Software, Network, Cloud | Engineering | Drift report, exception register | Continuous | STD-CFG-001 | | CM-7 Least Functionality | Disable unnecessary services and ports, and make sure only approved software is installed. | Hardware, Software, Network, Cloud | Engineering | App allowlist, port scan report | Quarterly | STD-CFG-001 | | CM-8 System Component Inventory | Make sure your hardware, software, cloud resources, network devices, data stores, and process owners are recorded in the correct CMDB or authoritative inventory with all applicable fields complete. | Hardware, Software, Network, Cloud, Data, Process | Engineering / Risk | Asset inventory export, reconciliation log | Monthly | STD-IT-001 / STD-OT-001 | ### 6.4 Contingency Planning (CP) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ----------- | -------------------------------------------- | --------------------------- | ----------- | | CP-2 Contingency Plan | Make sure your system has a current cyber recovery plan mapped to its tier and coordinated with enterprise BCP requirements. | Hardware, Software, Network, Cloud, Data, Process | Engineering | Plan document, BCP interface record | Annual | STD-RES-001 | | CP-4 Contingency Plan Testing | Test the recovery plan on the required cadence, document lessons learned, and update RTO/RPO assumptions when results show gaps. | Hardware, Software, Network, Cloud, Data, Process | Engineering | Test report, lessons learned, register entry | Annual / BES Annual | STD-RES-001 | | CP-9 System Backup | Make sure backups for your system and data are immutable, isolated, and restorable; for OT, include configurations, firmware, logic, and historian data. | Hardware, Software, Network, Cloud, Data | Engineering | Backup report, immutability evidence | Continuous / Annual restore | STD-RES-001 | | CP-10 Information System Recovery | Run recovery tests that prove your system can meet its defined RTO and RPO, and retain restoration evidence. | Hardware, Software, Network, Cloud, Data, Process | Engineering | Restoration test evidence | Annual | STD-RES-001 | ### 6.5 Identification and Authentication (IA) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ----------- | ------------------------------- | ------------ | ----------------------- | | IA-2 Identification and Authentication (Organizational Users) | Make sure all interactive human access to your system requires phishing-resistant MFA and does not allow legacy authentication. | Hardware, Software, Network, Cloud, Data | Engineering | IdP policy, exception register | Quarterly | STD-AC-001 | | IA-3 Device Identification and Authentication | Make sure your system, device, or service presents the identifiers needed for IdP, NAC, CAP, or other network controls to recognize it where supported. | Hardware, Network, Cloud | Engineering | NAC / conditional-access policy | Annual | STD-AC-001 | | IA-5 Authenticator Management | Store and rotate credentials, secrets, API keys, and certificates in approved tools and follow the STD-CR-001 lifecycle. | Hardware, Software, Network, Cloud, Data, Process | Engineering | Secrets manager, cert inventory | Continuous | STD-CR-001 / STD-AC-001 | ### 6.6 Risk Assessment, System and Information Integrity, Supply Chain (RA / SI / SR) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------ | ----------------------------------------- | ------------ | ------------------------ | | RA-3 Risk Assessment | Identify risks for your system, data, or process; document impact and likelihood; assign treatment; and keep the risk register current. | Hardware, Software, Network, Cloud, Data, Process | Risk / Governance | Risk register | Continuous | PRC-RM-001 | | RA-5 Vulnerability Monitoring and Scanning | Make sure your system is assessed on the required cadence using authenticated scanning and the applicable DISH profile, or an approved passive/alternative method where active scanning is not allowed. | Hardware, Software, Network, Cloud | Risk | Scan reports, SLA dashboard | Continuous | PRC-VM-001 / STD-CFG-001 | | SI-2 Flaw Remediation | Remediate Critical and High findings within SLA, or document an approved exception or risk acceptance before the SLA is missed. | Hardware, Software, Network, Cloud, Process | Risk / Engineering | SLA report, exception register | Continuous | PRC-VM-001 | | SI-4 System Monitoring | Make sure the required monitoring tools for your environment cover your system and that SIEM, EDR, NDR, CSPM/SSPM, or OT-passive monitoring gaps are documented. | Hardware, Software, Network, Cloud, Data | Risk | Coverage report | Continuous | STD-LM-001 | | SR-2 Supply Chain Risk Management Plan | Make sure each vendor or service supporting your system or process is tiered, tier-specific evidence requirements are understood, contract clauses match the tier, and required SCCT information is collected. | Hardware, Software, Network, Cloud, Data, Process | Risk (TPRM) | TPRM register, SCCT roster | Continuous | PRC-TPRM-001 | | SR-3 Supply Chain Controls and Processes | Do not allow international access unless the country-risk exception is approved and documented. | Software, Network, Cloud, Data, Process | Risk (TPRM) | Country-risk register, exception register | Quarterly | PRC-TPRM-001 | ### 6.7 System and Communications Protection (SC) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | SC-7 Boundary Protection | Make sure network boundaries, cloud security groups, OT ESP/EAP boundaries, and inter-zone paths are explicitly defined, approved, filtered, logged, and reviewed; direct bypass paths are prohibited. | Network, Cloud, Data, Process | Engineering | Segmentation diagram, firewall rule review, cloud security group export | Quarterly / On change | STD-NET-001 / STD-OT-001 | | SC-8 Transmission Confidentiality and Integrity | Protect sensitive data and administrative traffic in transit with approved cryptographic protocols; prohibit cleartext protocols for Restricted, CUI, and administrative paths unless formally risk accepted. | Network, Cloud, Data | Engineering | TLS / certificate scan, exception register | Continuous / Annual | STD-CR-001 / STD-CUI-001 | | SC-28 Protection of Information at Rest | Encrypt Restricted, CUI, backup, and crown-jewel data at rest using approved platform controls or customer-managed keys where required; document inheritance when provider encryption is used. | Hardware, Software, Cloud, Data | Engineering | Encryption configuration export, KMS key inventory, inheritance package | Quarterly | STD-CR-001 / STD-DG-001 / STD-CUI-001 | ### 6.8 Assessment, Authorization, and Monitoring (CA) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | CA-2 Control Assessment | Assess implemented controls on the defined cadence using self-assessment, evidence review, and independent validation where required; record findings, owners, and remediation due dates. | Hardware, Software, Network, Cloud, Data, Process | Governance / Risk | Maturity scorecard, control test worksheet, findings register | Annual / Quarterly high-risk | GOV-MAT-001 / TMPL-AUD-001 | | CA-8 Penetration Testing | Conduct adversarial validation for in-scope systems per risk tier; document scope, rules of engagement, findings, remediation ownership, and validation retest. | Hardware, Software, Network, Cloud, Data, Process | Risk | Test plan, findings report, retest evidence | Annual / After material change | PRC-AV-001 | ### 6.9 Awareness and Training (AT) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | AT-2 Literacy Training and Awareness | Make sure workforce members with cyber-relevant access complete role-appropriate security training before access and on the required refresh cadence; track exceptions to closure. | Process, Data, Cloud, Software | Governance | Training completion report, role curriculum mapping | Annual / On role assignment | GOV-TRN-001 / GOV-ONB-001 | ### 6.10 Incident Response (IR) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | IR-2 Incident Response Training | Train incident-response participants and CERG support roles on escalation, evidence handling, communications, and playbook execution before they are assigned incident duties. | Process, Data, Cloud, Network | Risk / Governance | Exercise attendance, role training completion | Annual / Per exercise | PLN-IR-001 / PRC-IR-002 | | IR-4 Incident Handling | Triage, contain, investigate, eradicate, recover, and communicate incidents using approved playbooks while preserving evidence and recording decisions. | Hardware, Software, Network, Cloud, Data, Process | Risk | Incident case record, timeline, evidence package | Continuous | PLN-IR-001 / PRC-IR-002 | | IR-8 Incident Response Plan | Maintain an approved incident-response plan, playbook set, contacts, severity model, and escalation path; update after exercises, material incidents, or organizational changes. | Process, Data, Cloud, Network | Risk / Governance | Approved IR plan, playbook review, after-action report | Annual / After material incident | PLN-IR-001 / PRC-IR-002 | ### 6.11 Physical and Environmental Protection (PE) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | PE-2 Physical Access Authorizations | Maintain authorized physical access lists for cyber-relevant facilities, OT PSPs, and CUI work areas; grant and remove physical access through an approved workflow. | Hardware, Network, Data, Process | Governance / Engineering | Badge access roster, PSP access list | Quarterly | STD-OT-001 / PLN-CIP-001 | | PE-3 Physical Access Control | Enforce, log, and review physical entry to cyber-relevant facilities; require visitor escort and investigate unauthorized or anomalous access attempts. | Hardware, Network, Data, Process | Governance / Engineering | Badge logs, visitor logs, PSP inspection record | Monthly / Quarterly | STD-OT-001 / PLN-CIP-001 | ### 6.12 Planning (PL) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | PL-1 Policy and Procedures | Maintain the approved policy, standard, procedure, plan, and template hierarchy with named owners, review cycles, status, and change history. | Process | Governance | Document catalog, review record, approval history | Annual / On major change | GOV-CAT-001 / GOV-STY-001 | ### 6.13 Program Management (PM) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | PM-1 Information Security Program Plan | Maintain the CERG operating model, program scope, accountable pillars, service commitments, and reporting model so leadership can understand how the program is run. | Process | Governance | Operating model, service commitments, board report | Quarterly | GOV-OM-001 / GOV-MTR-001 / GOV-SLC-001 | | PM-9 Risk Management Strategy | Maintain the risk management strategy, taxonomy, appetite/tolerance guidance, and treatment workflow; ensure risk decisions are visible to accountable leadership. | Process, Data, Cloud, Network | Governance / Risk | RMF, risk taxonomy, risk register summary | Annual / Quarterly | GOV-RMF-001 / GOV-TAX-001 / PRC-RM-001 | | PM-14 Testing, Training, and Monitoring | Maintain an integrated calendar for control tests, evidence refresh, training, assessments, reporting, and regulatory milestones; track overdue actions to closure. | Process | Governance | Annual calendar, completion tracker, compliance review minutes | Monthly / Annual planning | GOV-CAL-001 / GOV-MTR-001 | ### 6.14 Personnel Security (PS) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | PS-2 Position Risk Designation | Designate role and position risk based on privileged access, CUI/BES scope, regulatory responsibility, and crown-jewel impact; verify required screening and authorization before access. | Process, Data, Cloud, Network | Governance | Role risk designation matrix, access precondition record | Annual / Before access | GOV-JA-001 / GOV-ONB-001 | ### 6.15 System and Services Acquisition (SA) | **Control** | **Statement** | **System Applicability** | **Owner** | **Evidence** | **Min Freq** | **Std** | |---|---|---|---|---|---|---| | SA-9 External System Services | Make sure external systems and service providers meet documented security requirements, shared-responsibility obligations, evidence requirements, incident-notification terms, and flow-down clauses before use. | Software, Network, Cloud, Data, Process | Risk (TPRM) | Contract security clauses, vendor assessment, shared responsibility matrix | Continuous / Annual reassessment | PRC-TPRM-001 | ## 7. Control Status Decision Tree Use this decision tree to assign honest control implementation statuses. Optimistic status inflation is the most common control failure mode — marking a control "Implemented" without evidence hides the gap from everyone, including yourself. ``` Is the control applicable to your environment? ├─ No → Not Applicable (document rationale) └─ Yes → Is the control fully designed? ├─ No → Planned (design in progress) or Not Implemented (no design) └─ Yes → Is it operating consistently? ├─ No → Partially Implemented (operating gap) └─ Yes → Is there current evidence of operation? ├─ No → Partially Implemented (evidence gap) └─ Yes → Implemented ``` ### Status Definitions | Status | Definition | When to Use | |--------|-----------|-------------| | **Not Applicable** | The control does not apply to your environment. | Document the rationale. Example: "OT-specific controls are not applicable — no OT environment exists." | | **Not Implemented** | No design exists. The control is not in place. | Be honest. A gap you acknowledge is manageable. A gap you hide is not. | | **Planned** | Design exists or is in progress. Not yet operating. | Use when there is a committed implementation plan with a target date and owner. | | **Partially Implemented** | Designed and operating, but with gaps. | Specify the gap: evidence missing, inconsistent operation, incomplete scope, or inherited without verification. | | **Implemented** | Designed, operating, and evidenced. | Evidence must meet the tier required for this control (E2 minimum per AUD-001). | | **Inherited** | Relies on a provider, partner, or parent organization. | Requires provider evidence (SOC 2, ISO cert, etc.) AND organization-side complementary controls. See §7.1. | ### 7.1 Control Inheritance and Shared Responsibility Cloud, SaaS, MSP, and OT vendor relationships create shared control environments. "Inherited" is not a free pass — it requires provider evidence AND your own complementary controls. | Responsibility | Who Does What | Evidence Required | |---------------|--------------|-------------------| | **Provider-Only** | The provider is fully responsible. The customer cannot influence the control. | Provider attestation (SOC 2, ISO 27001, FedRAMP). Customer verifies scope covers their environment. | | **Customer-Only** | The customer is fully responsible. The provider has no role. | Customer-produced evidence per this standard. | | **Shared** | Both provider and customer have responsibilities. Failure by either party constitutes a control gap. | Provider evidence + customer evidence for customer-side controls. Document the shared responsibility matrix. | #### Inheritance Examples | Scenario | Inherited? | What You Still Need | |----------|-----------|---------------------| | Physical security of cloud data center | Yes — provider attestation acceptable | Confirm data center scope covers your region. SOC 2 physical security control testing. | | Logging for SaaS application | No — platform logging capability is inherited, but you must configure, collect, and monitor | Enable audit logging in the SaaS app. Configure log export to your SIEM. Verify logs are flowing. | | MFA for SaaS application | Maybe — if IdP enforces and app trusts IdP | Verify IdP policy enforces MFA. Verify app is configured to require IdP authentication. Check for bypass paths (local accounts, API keys). | | Backup for SaaS data | Maybe — platform availability backup is inherited, but customer-level recovery may not be | Review SaaS provider's backup SLA. Export critical data to customer-controlled backup. Test restore. | | Encryption at rest for cloud storage | Maybe — provider manages infrastructure encryption, but key ownership and configuration vary | Confirm encryption is enabled. Determine who controls the keys. If provider-managed, document the shared responsibility. | | Patch management for PaaS | Yes — provider patches the platform | Verify the PaaS SLA covers patching. Monitor for CVEs in the platform. Plan for migration if the provider's patch SLA is insufficient. | | OT vendor remote access | No — you control the access path and monitoring | Require MFA. Log all sessions. Approve access per session. Disable when not in use. The vendor's security posture is an input, not a substitute. | #### Shared Responsibility Decision Table For every control that crosses an organizational boundary, complete this table and retain it with the control evidence: | Field | Value | |-------|-------| | Control ID | [From CB-001] | | Provider/Vendor | [Name] | | Provider Responsibility | [What the provider does] | | Provider Evidence | [SOC 2 report reference, contract clause, architecture doc] | | Customer Responsibility | [What you must do] | | Customer Evidence | [Your evidence of customer-side controls] | | Residual Risk If Provider Evidence Is Unavailable | [What risk remains] | | Reviewed By | [Name] | | Review Date | [Date] | #### Provider Evidence Gap Workflow When provider attestation is missing, expired, or does not cover the customer's scope, follow this workflow: | Step | Action | Owner | Output | SLA | |------|--------|-------|--------|-----| | 1. **Document the gap** | Describe what evidence is missing: control ID, provider, date expected vs. received, scope gap. | Control Owner / Risk (TPRM) | Gap record in Shared Responsibility Decision Table | Within 5 business days of discovering the gap | | 2. **Assess residual risk** | If provider evidence is unavailable, how does the control gap affect the customer environment? Quantify the exposure using FAIR-aligned risk statement format per RMF-001 §9.2. | Risk Pillar Leader | Risk assessment with LEF/LM bands | Within 10 business days of step 1 | | 3. **Select treatment path** | Choose one: Compensating control (customer-side control achieving same objective), Risk acceptance (per RMF-001 §9.7), or Provider remediation (contractual timeline). | Control Owner + Risk Pillar Leader | Treatment decision documented in risk register | Within 10 business days of step 2 | | 4. **Set re-evaluation trigger** | Define the event that will trigger gap re-evaluation: contract renewal, attestation expiry, scope change, or provider breach notification. | Governance Pillar Leader | Re-evaluation trigger entry in evidence index | Within 5 business days of step 3 | | 5. **Escalate if Critical/High** | If the gap affects a Critical or High overlay control (per §8), escalate to the CISO within 24 hours of step 2. CISO determines whether an immediate compensating control is required or whether the gap is being tracked through the risk register. | Risk Pillar Leader | CISO notification and disposition | 24 hours (Critical/High) | > **Provider Evidence Gap vs. Control Finding.** A provider evidence gap is not automatically a control failure. It means the inheritance claim cannot be verified. The control status should be `Partially Implemented` (evidence gap) or `Inherited — Unverified` until the workflow is resolved. If the gap persists beyond the re-evaluation trigger without a documented compensating control or risk acceptance, the control defaults to `Not Implemented`. ## 8. Overlay Matrix Overlays add to the organizational baseline. They never silently relax it. | **Overlay** | **Applies To** | **Adds / Tightens** | **Source Standard** | |---|---|---|---| | **High-Impact** | Systems whose loss would materially impact the business or safety | Tighter remediation SLAs, CIS L2 baseline, expanded monitoring, MFA for all non-human identities. | STD-CFG-001 + STD-LM-001 | | **CUI** | Any system that stores/processes/transmits CUI | [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) controls; SSP + POA&M + SPRS; FIPS-validated cryptography; DFARS flow-down; [CMMC L2](https://dodcio.defense.gov/CMMC/) assessment readiness. | STD-CUI-001 + PLN-CUI-001 | | **BES** | Medium/High Impact BES Cyber Systems | NERC-CIP v7 controls including CIP-007, CIP-010, CIP-013; ESP/EAP topology; 90-day searchable / 12-month total log retention; annual recovery exercise; CIP-015 INSM where applicable. | STD-OT-001 + PLN-CIP-001 | | **SOX ITGC** | Systems supporting financial reporting | Access, change, operations, backup, interface, and report ITGC controls; quarterly SoD review; SOC 1 reuse for hosted financial systems. | STD-IT-001 + PLN-SOX-001 | | **OT Safety** | OT systems whose disruption can cause safety impact | Stricter change/maintenance windows, no active scanning, mandatory engineering review for any policy/standard parameter relaxation. | STD-OT-001 | | **Crown-Jewel** | Tier 0 / Tier 1 crown-jewel assets (per [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md)) | Verified minimum control profile: tested recovery with backup outside the blast radius, phishing-resistant identity, enumerated segmentation, ATT&CK-mapped day-one detection, and adversarial validation at enhanced frequency. Verified, not assumed. | CJ-001 §3.3 | | **AI** | Consumed AI services, AI-enabled vendor features, embedded AI, built AI systems, AI agents, model-serving platforms, and retrieval-augmented systems | AI intake and sanctioning; maximum approved data classification; sanctioned-tools register; model/system inventory; model provenance; prompt/data egress controls; human oversight; AI-specific threat modeling; agency and least-privilege boundaries; vendor reassessment on AI feature changes. | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) + [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) / [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) / [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | > **Multiple Overlays at Once** > > A given system may sit under more than one overlay (a BES system that also processes CUI; a financial system in a CUI enclave). When overlays overlap, the most stringent parameter wins for each individual control. Overlays do not "average." --- ## 9. Control-to-Evidence Mapping Every control entry in §6 names an evidence artifact in its `Evidence` column. This section consolidates those artifacts into a single mapping with the repository where the evidence lives, the refresh cadence, and the owning pillar. It is the lookup an auditor opens first. The discipline rule is unchanged from §2: a control without a named evidence artifact does not enter the baseline; an evidence artifact without a named repository does not satisfy the control. "It's in someone's email" is not an evidence repository. ### 9.1 Evidence Catalog | **Control** | **Evidence Artifact** | **Repository / Tool** | **Refresh Cadence** | **Owner** | |---|---|---|---|---| | AC-2 Account Management | JML log, quarterly recertification report | IGA / IdP audit log + Governance access-review portal | Continuous (JML); Quarterly (recert) | Engineering (Identity) | | AC-3 Access Enforcement | IdP / PAM policy export | IdP + PAM admin export | Annual | Engineering (Identity) | | AC-6 Least Privilege | PAM session logs; role inventory | PAM platform; IGA role catalog | Continuous (sessions); Quarterly (role inventory) | Engineering (Identity) | | AC-7 Unsuccessful Logon Attempts | IdP policy export; identity-attack detection rule | IdP admin export; SIEM detection inventory | Annual | Engineering (Identity) | | AC-17 Remote Access | Gateway logs; MFA policy export | Remote-access gateway logs in SIEM; IdP policy export | Continuous (logs); Annual (policy) | Engineering (Network + Identity) | | AC-19 Mobile / BYOD | MDM compliance report | MDM admin console export | Quarterly | Engineering (Endpoint) | | AU-2 Event Logging | SIEM source inventory; coverage gap report | SIEM / detection-eng inventory | Monthly | Risk (Detection) | | AU-6 Audit Review | Detection coverage report; triage queue metrics | MTR-001 DT-001 dashboard; SOC ticketing | Continuous | Risk (Detection) | | AU-9 Protection of Audit Information | Storage policy; admin-action review | SIEM admin audit log; storage configuration export | Quarterly | Risk (Detection) | | AU-11 Audit Record Retention | Retention policy; sample retrieval evidence | Storage configuration export; quarterly sample-retrieval ticket | Annual | Risk (Detection) | | AU-12 Audit Record Generation | Log generation configuration; sample event test | System logging configuration; SIEM sample event evidence | Annual; Continuous monitoring | Risk (Detection) | | CM-2 Baseline Configuration | DISH baseline catalog; DISH scan report | CERG-STD-CFG-001 baseline catalog; DISH scan results in CMDB | Continuous (scan); Annual (baseline review) | Engineering (Platforms) | | CM-3 Change Control | CAB minutes; change records | Change-management system export | Continuous | Engineering | | CM-5 Access Restrictions for Change | Change-authority roster; emergency-change review | Change-management system; IGA / PAM role export | Quarterly | Engineering | | CM-6 Configuration Settings | Drift report; exception register | DISH drift detection; CERG-TMPL-RM-001 exception register | Continuous | Engineering (Platforms) | | CM-7 Least Functionality | Application allowlist; port-scan report | EDR / allowlist platform; vuln scanner port view | Quarterly | Engineering | | CM-8 System Component Inventory | Asset inventory export; reconciliation log | CMDB / authoritative inventory; reconciliation tickets | Monthly | Engineering / Risk | | CP-2 Contingency Plan | Plan document; BCP interface record | CERG-STD-RES-001 plan template; enterprise BCP register | Annual | Engineering (Resilience) | | CP-4 Contingency Plan Testing | Test report; lessons learned; register entry | Recovery-test ticket; CERG-PRC-RM-001 register | Annual; BES per CIP-009 R2.1 (15 months) | Engineering (Resilience) | | CP-9 System Backup | Backup report; immutability evidence | Backup platform admin export | Continuous (operations); Quarterly (immutability spot-check) | Engineering (Resilience) | | CP-10 Information System Recovery | Restoration test evidence | Recovery-test ticket package | Annual | Engineering (Resilience) | | IA-2 Identification and Authentication | IdP policy; exception register | IdP admin export; CERG-PRC-RM-001 exception register | Quarterly | Engineering (Identity) | | IA-3 Device Identification and Authentication | NAC / conditional-access policy | NAC admin export; IdP conditional-access export | Annual | Engineering (Identity) | | IA-5 Authenticator Management | Secrets manager export; cert inventory | KMS / secrets manager; certificate inventory | Continuous | Engineering (Cryptography) | | RA-3 Risk Assessment | Risk register | CERG-PRC-RM-001 risk register (per CERG-TMPL-RM-001 schema) | Continuous | Risk / Governance | | RA-5 Vulnerability Monitoring and Scanning | Scan reports; SLA dashboard | Vulnerability scanner; MTR-001 VM-001 / VM-002 dashboard | Continuous | Risk (Exposure Management) | | SI-2 Flaw Remediation | SLA report; exception register | MTR-001 dashboard; CERG-PRC-RM-001 exception register | Continuous | Risk / Engineering | | SI-4 System Monitoring | Coverage report | MTR-001 DT-001 ATT&CK coverage report | Continuous | Risk (Detection) | | SR-2 Supply Chain Risk Management Plan | TPRM register; SCCT roster | CERG-PRC-TPRM-001 register; SCCT membership roster | Continuous | Risk (TPRM) | | SR-3 Supply Chain Controls and Processes | Country-risk register; exception register | CERG-PRC-TPRM-001 §10 register; CERG-PRC-RM-001 exception register | Quarterly | Risk (TPRM) | | SC-7 Boundary Protection | Segmentation diagram; firewall rule review; cloud security group export | Network management platform; cloud control plane; OT ESP/EAP evidence repository | Quarterly; On change | Engineering (Network / OT) | | SC-8 Transmission Confidentiality and Integrity | TLS / certificate scan; exception register | Certificate inventory; scanner output; CERG-PRC-RM-001 exception register | Continuous; Annual validation | Engineering (Cryptography / Network) | | SC-28 Protection of Information at Rest | Encryption configuration export; KMS key inventory; inheritance package | Cloud console export; KMS / HSM; Inheritance Evidence Package | Quarterly | Engineering (Cryptography / Data) | | CA-2 Control Assessment | Maturity scorecard; control test worksheet; findings register | CERG-GOV-MAT-001 scorecard; CERG-TMPL-AUD-001 worksheet; findings tracker | Annual; Quarterly high-risk | Governance / Risk | | CA-8 Penetration Testing | Test plan; findings report; retest evidence | CERG-PRC-AV-001 engagement package; findings tracker | Annual; After material change | Risk (Adversarial Validation) | | AT-2 Literacy Training and Awareness | Training completion report; role curriculum mapping | LMS export; onboarding record; role reader path | Annual; On role assignment | Governance (Training) | | IR-2 Incident Response Training | Exercise attendance; role training completion | Exercise roster; LMS / onboarding record | Annual; Per exercise | Risk / Governance | | IR-4 Incident Handling | Incident case record; timeline; evidence package | Case-management platform; evidence repository | Continuous | Risk (Incident Interface) | | IR-8 Incident Response Plan | Approved IR plan; playbook review; after-action report | CERG-PLN-IR-001; CERG-PRC-IR-002; exercise repository | Annual; After material incident | Risk / Governance | | PE-2 Physical Access Authorizations | Badge access roster; PSP access list | Badge system; NERC-CIP evidence repository | Quarterly | Governance / Engineering | | PE-3 Physical Access Control | Badge logs; visitor logs; PSP inspection record | Badge system; visitor-management system; NERC-CIP evidence repository | Monthly; Quarterly review | Governance / Engineering | | PL-1 Policy and Procedures | Document catalog; review record; approval history | CERG-GOV-CAT-001; document repository; approval workflow | Annual; On major change | Governance (Document Control) | | PM-1 Information Security Program Plan | Operating model; service commitments; board report | CERG-GOV-OM-001; CERG-GOV-SLC-001; reporting deck | Quarterly | Governance | | PM-9 Risk Management Strategy | RMF; risk taxonomy; risk register summary | CERG-GOV-RMF-001; CERG-GOV-TAX-001; risk register | Annual; Quarterly review | Governance / Risk | | PM-14 Testing, Training, and Monitoring | Annual calendar; completion tracker; compliance review minutes | CERG-GOV-CAL-001; CERG-GOV-MTR-001; governance review minutes | Monthly; Annual planning | Governance | | PS-2 Position Risk Designation | Role risk designation matrix; access precondition record | Job architecture; onboarding record; access approval workflow | Annual; Before access | Governance / HR interface | | SA-9 External System Services | Contract security clauses; vendor assessment; shared responsibility matrix | TPRM platform; contract repository; SCCT register | Continuous; Annual reassessment | Risk (TPRM) | ### 9.2 Evidence Discipline Three rules apply to every entry above: 1. **Currency (Adoption-Gate Tiered).** Evidence captured in the prior refresh cycle is current. Evidence older than **one refresh cycle plus 30 days** is stale; staleness is a finding in its own right and routes to the owning pillar for action. Examples per cadence: - **Annual controls** (e.g., CP-4 annual test, CM-3 annual review): evidence is current for 13 months; stale at 13 months + 1 day. - **Quarterly controls** (e.g., CM-7 least functionality, AC-6 role inventory): evidence is current for 4 months; stale at 4 months + 1 day. - **Continuous controls** (e.g., AU-2 event logging, CM-6 drift detection): evidence is current for 30 days; stale at 31 days. 2. **Attribution.** Every evidence artifact carries the named owning role from the canonical roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. "Owned by the team" is not attribution. 3. **Retrievability (Adoption-Gate Tiered).** Evidence shall be retrievable within the following SLA, tiered by adoption gate: - **Gate 1 (Spine, 0–90 days):** Within 15 business days of an auditor request. Manual collection is acceptable. - **Gate 2 (Operating, 90–180 days):** Within 10 business days. Structured evidence index required. - **Gate 3 (Governed, 180+ days):** Within 5 business days. Tool-supported evidence pipeline. - **Gate 4 (Adaptive, mature):** Within 2 business days. Automated evidence pipeline. Anything that takes longer than the applicable gate SLA is a process finding regardless of whether the underlying control is operating. > **Inheritance Evidence** > > Controls marked `Inherited` in §6 use the Inheritance Evidence Package defined in §5 rather than the artifacts above. The Inheritance Evidence Package replaces - it does not supplement - the customer-side evidence artifact for the inherited portion of the control. --- ## 10. Regulatory Crosswalks This section translates each baseline control into the regulator-facing identifier or expectation. It is the read-once map for cross-framework audits: NERC-CIP auditors, CMMC C3PAOs, and SOX external auditors each look at the same controls under different names. The [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) Compliance Matrix is the broader cross-regulator map (intent-level); the table below is the implementation-level crosswalk, control-by-control. Where the two disagree, the Compliance Matrix governs intent and this baseline governs implementation. ### 10.1 NIST 800-53 → 800-171 r3 / NERC-CIP / CMMC L2 / SOX ITGC | **Baseline Control** | **NIST 800-171 r3** | **NERC-CIP** | **CMMC L2** | **SOX ITGC** | |---|---|---|---|---| | AC-2 Account Management | 03.01.01, 03.01.02 | CIP-004 R4, CIP-007 R5 | AC.L1-3.1.1, AC.L2-3.1.5 | Access | | AC-3 Access Enforcement | 03.01.01, 03.01.05 | CIP-005 R1, CIP-007 R5 | AC.L1-3.1.1 | Access | | AC-6 Least Privilege | 03.01.05, 03.01.06 | CIP-004 R4, CIP-007 R5 | AC.L2-3.1.5 | Access | | AC-7 Unsuccessful Logon Attempts | 03.01.08 | CIP-007 R5.7 | AC.L2-3.1.8 | n/a | | AC-17 Remote Access | 03.01.12, 03.13.07 | CIP-005 R2 | AC.L2-3.1.12 | Access | | AC-19 Mobile / BYOD | 03.01.18, 03.01.19 | n/a | AC.L2-3.1.18 | n/a | | AU-2 Event Logging | 03.03.01, 03.03.02 | CIP-007 R4 | AU.L2-3.3.1, AU.L2-3.3.2 | Operations | | AU-6 Audit Review | 03.03.03 | CIP-007 R4 | AU.L2-3.3.5 | Operations | | AU-9 Protection of Audit Information | 03.03.05, 03.03.06 | CIP-007 R4 | AU.L2-3.3.8, AU.L2-3.3.9 | Operations | | AU-11 Audit Record Retention | 03.03.04 | CIP-007 R4.3 | AU.L2-3.3.4 | Operations | | AU-12 Audit Record Generation | 03.03.01, 03.03.02 | CIP-007 R4 | AU.L2-3.3.1, AU.L2-3.3.2 | Operations | | CM-2 Baseline Configuration | 03.04.01, 03.04.02 | CIP-010 R1 | CM.L2-3.4.1, CM.L2-3.4.2 | Change | | CM-3 Change Control | 03.04.03 | CIP-010 R1, R2 | CM.L2-3.4.3 | Change | | CM-5 Access Restrictions for Change | 03.04.05 | CIP-010 R1, R2 | CM.L2-3.4.5 | Change | | CM-6 Configuration Settings | 03.04.06 | CIP-010 R1 | CM.L2-3.4.6 | Change | | CM-7 Least Functionality | 03.04.06, 03.04.07 | CIP-007 R1 | CM.L2-3.4.7 | n/a | | CM-8 System Component Inventory | 03.04.10 | CIP-002, CIP-010 R1 | CM.L2-3.4.10 | Operations | | CP-2 Contingency Plan | 03.06.01, 03.06.02 | CIP-008, CIP-009 R1 | IR.L2-3.6.1 | Operations | | CP-4 Contingency Plan Testing | 03.06.03 | CIP-009 R2 | IR.L2-3.6.3 | Operations | | CP-9 System Backup | 03.08.09 | CIP-009 R1 | MP.L2-3.8.9 | Operations | | CP-10 Information System Recovery | 03.06.02, 03.06.03 | CIP-009 R2, R3 | IR.L2-3.6.2 | Operations | | IR-2 Incident Response Training | 03.06.02 | CIP-008 R2 | IR.L2-3.6.2 | Operations | | IR-4 Incident Handling | 03.06.01, 03.06.03 | CIP-008 R1, R2, R3 | IR.L2-3.6.1, IR.L2-3.6.3 | Operations | | IR-8 Incident Response Plan | 03.06.01 | CIP-008 R1 | IR.L2-3.6.1 | Operations | | IA-2 Identification and Authentication | 03.05.03, 03.05.04 | CIP-005 R2.3, CIP-007 R5 | IA.L1-3.5.1, IA.L1-3.5.2, IA.L2-3.5.3 | Access | | IA-3 Device Identification and Authentication | 03.05.02 | CIP-005, CIP-007 | IA.L2-3.5.5 | n/a | | IA-5 Authenticator Management | 03.05.07-03.05.12 | CIP-007 R5 | IA.L2-3.5.7 through IA.L2-3.5.10 | Access | | RA-3 Risk Assessment | 03.11.01 | CIP-003, CIP-014 | RA.L2-3.11.1 | n/a | | CA-2 Control Assessment | 03.12.01, 03.12.02 | CIP-003, CIP-010 R3 | CA.L2-3.12.1, CA.L2-3.12.2 | Operations | | CA-8 Penetration Testing | 03.12.01, 03.11.02 | CIP-007 R2, CIP-010 R3 | CA.L2-3.12.1 | n/a | | RA-5 Vulnerability Monitoring and Scanning | 03.11.02, 03.11.03 | CIP-007 R2, CIP-010 R3 | RA.L2-3.11.2, RA.L2-3.11.3 | n/a | | SI-2 Flaw Remediation | 03.14.01 | CIP-007 R2 | SI.L1-3.14.1 | Change | | SI-4 System Monitoring | 03.14.06, 03.14.07 | CIP-007 R4 | SI.L2-3.14.6, SI.L2-3.14.7 | n/a | | SR-2 Supply Chain Risk Management Plan | 03.17.01 | CIP-013 R1 | SR.L2 family | n/a | | SR-3 Supply Chain Controls and Processes | 03.17.02, 03.17.03 | CIP-013 R2 | SR.L2 family | n/a | | SA-9 External System Services | 03.16.01, 03.16.02, 03.16.03 | CIP-013 R1 | SR.L2 family | Vendor / SOC report reliance | | SC-7 Boundary Protection | 03.13.01, 03.13.05 | CIP-005 R1, R2 | SC.L2-3.13.1, SC.L2-3.13.5 | Network / Access | | SC-8 Transmission Confidentiality and Integrity | 03.13.08 | CIP-005 R2, CIP-011 R1 | SC.L2-3.13.8 | n/a | | SC-28 Protection of Information at Rest | 03.13.16 | CIP-011 R1 | SC.L2-3.13.16 | n/a | | AT-2 Literacy Training and Awareness | 03.02.01, 03.02.02 | CIP-004 R2 | AT.L2-3.2.1, AT.L2-3.2.2 | n/a | | PE-2 Physical Access Authorizations | 03.10.01 | CIP-006 R1 | PE.L1-3.10.1 | Data center / facility access | | PE-3 Physical Access Control | 03.10.01, 03.10.03 | CIP-006 R1, R2 | PE.L1-3.10.1, PE.L2-3.10.3 | Data center / facility access | | PL-1 Policy and Procedures | 03.12.04 | CIP-003 R1 | CA.L2-3.12.4 | Policy / governance | | PM-1 Information Security Program Plan | Organization-defined | CIP-003 R1 | CA.L2-3.12.4 | Entity-level control | | PM-9 Risk Management Strategy | 03.11.01 | CIP-003, CIP-014 | RA.L2-3.11.1 | Entity-level risk | | PM-14 Testing, Training, and Monitoring | 03.12.01, 03.12.03 | CIP-003, CIP-004, CIP-010 | CA.L2-3.12.1, CA.L2-3.12.3 | Compliance monitoring | | PS-2 Position Risk Designation | 03.09.01 | CIP-004 R3, R4 | PS.L2-3.9.1 | n/a | > **Reading the Crosswalk** > > A cell marked `n/a` means the regulator does not have an explicit identifier for the intent; it does **not** mean the regulator is uninterested. SOX auditors do not have a numbered identifier for unsuccessful-logon thresholds, but they will absolutely ask about brute-force protections on financial-system access. The crosswalk maps named controls, not audit scope. ### 10.2 Overlay-to-Regulator Mapping The §8 overlays carry additional crosswalks. Subordinate operational packages own the detail; the table below is the entry point. | **Overlay** | **Primary Regulator Lens** | **Operational Package** | |---|---|---| | High-Impact | NIST 800-53 High baseline; tightened DISH | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) + [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | CUI | NIST 800-171 r3; DFARS 252.204-7012; CMMC L2 | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) + [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | | BES | NERC-CIP v7 (CIP-002 through CIP-014; CIP-015 INSM where applicable) | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) + [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | | SOX ITGC | SOX §404 ITGC (Access, Change, Operations) | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | | OT Safety | IEC 62443; NIST 800-82r3 | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | | AI | NIST AI RMF 100-1; ISO/IEC 42001; privacy, CMMC, SOX, and sector obligations where AI processes regulated data or supports regulated decisions | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) + [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) / [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) / [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | --- ### 10.3 Compliance Matrix Intent-to-Control Bridge [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) (the Compliance Matrix) is organized by 22 cross-regulator **intents** ("Know what you own," "Manage vendor risk," etc.). This baseline is organized by **controls** (AC-2, AC-3, CM-8, etc.). The table below resolves each Compliance Matrix intent to the §6 controls that implement it. Where an intent is implemented outside the §6 control set, the table names the authoritative subordinate document instead. | **CMX Intent** | **Title** | **CB-001 §6 Controls** | **Where Else Implementation Lives** | |---|---|---|---| | 1 | Know what you own: authoritative asset inventory | CM-8 | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md); [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) (CIP-002 categorization) | | 2 | Identify and remediate vulnerabilities on schedule | RA-5, SI-2 | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5.2 (canonical SLAs) | | 3 | Control who can access what: least privilege | AC-2, AC-3, AC-6, AC-7, AC-19 | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | | 4 | Authenticate users and systems | IA-2, IA-3, IA-5 | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md); [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) (authenticators) | | 5 | Harden systems | CM-2, CM-6, CM-7 | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) (DISH baselines) | | 6 | Protect data in transit and at rest | SC-8, SC-28, IA-5 | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md); [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md); [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | | 7 | Segment networks | SC-7, AC-17 | [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md); [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) (ESP/EAP) | | 8 | Manage vendor and third-party risk | SA-9, SR-2, SR-3 | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | 9 | Control and log privileged / remote access | AC-6, AC-17, AU-2, AU-6, AU-12 | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md); [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | 10 | Conduct adversarial testing | CA-8, RA-5 | [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | | 11 | Train and background-check personnel | AT-2, PS-2 | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md); [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | | 12 | Write and maintain policies | PL-1, PM-1 | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md); [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md); [`CERG-GOV-STY-001`](CERG-GOV-STY-001_Document_Authoring_and_Style_Guide.md) | | 13 | Manage configuration changes | CM-3, CM-5 | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md); [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md); [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | | 14 | Collect, protect, and retain audit evidence | AU-2, AU-6, AU-9, AU-11, AU-12; this doc §9 evidence catalog | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) (retention) | | 15 | Assess your own security posture | CA-2, RA-3 | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md); [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md); [`CERG-TMPL-AUD-001`](../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md) | | 16 | Manage risk formally | RA-3, PM-9, SI-2 (exception register) | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md); [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md); [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 | | 17 | Protect physical access | PE-2, PE-3 | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) (CIP-006 PSP); [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | | 18 | Monitor threats continuously | SI-4, AU-6, IR-4 | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) (Day-One Detection Set; 70% ATT&CK target) | | 19 | Plan and practice incident response | IR-2, IR-4, IR-8 | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md); [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | | 20 | Manage recovery | CP-2, CP-4, CP-9, CP-10 | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | | 21 | Manage accounts through lifecycle | AC-2, AC-7, IA-2, IA-5 | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md); [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) (JML runbook) | | 22 | Define and enforce a compliance calendar | PM-14, PM-9, CA-2 | [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md); [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md); [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | > **Reading the Bridge** > > The bridge is intentionally implementation-oriented. Every Compliance Matrix intent now points to at least one §6 baseline control row, and the final column points to the documents that carry the deeper operational parameters. ### 10.4 Family Coverage Note The CERG control family spine in §3 lists 19 NIST 800-53 families. §6 now includes explicit baseline rows for every family needed by the 22 Compliance Matrix intents, while still keeping environment-specific parameter depth in subordinate standards and procedures. | **Family** | **Baseline Role in §6** | **Authoritative Implementation Detail** | |---|---|---| | AC, IA | Identity, access enforcement, least privilege, remote access, account lifecycle, and authenticators. | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md); [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | | AT, PS | Training and position-risk designation are baseline controls because access and CUI/BES scope depend on them. | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md); [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | | AU, SI | Logging, audit review, retention, event generation, monitoring, and flaw remediation. | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md); [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | | CA, RA | Control assessment, adversarial validation, risk assessment, and exposure management. | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md); [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md); [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | CM | Baselines, configuration settings, change control, change authority, least functionality, and inventories. | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md); [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) | | CP, IR | Recovery planning, backup, restoration, incident handling, training, and playbooks. | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md); [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md); [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | | PE | Physical access authorization and control for cyber-relevant facilities, PSPs, and CUI spaces. | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md); [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | | PL, PM | Policy hierarchy, operating model, risk strategy, calendar, metrics, testing, training, and monitoring. | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md); [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md); [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | | SA, SR | External services, supply chain risk management, third-party evidence, and country-risk controls. | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md); [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | | SC | Boundary protection, cryptographic protection in transit, and data-at-rest protection. | [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md); [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md); [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | > **Baseline vs. Parameter Detail** > > §6 names the auditable control, owner, evidence, cadence, and implementation document. Subordinate standards and procedures carry the detailed parameter values, workflows, and environment-specific exceptions. If there is a conflict, the stricter requirement applies unless Governance approves a documented exception. ## 11. Governance, Change, and Versioning ### 11.1 Ownership The Governance Pillar Leader owns this baseline. Material changes (additions, removals, parameter changes that affect remediation SLAs or evidence requirements) require CISO approval; non-material changes (clarifications, typo fixes, additional implementation notes) require Governance Pillar Leader approval. Pillar leaders may propose changes at any time. The Governance Pillar Leader runs an open intake at the monthly Compliance Pulse forum (per [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §7). ### 11.2 Change Triggers The baseline is reviewed and updated upon any of the following: - **Framework version change.** A new version of NIST 800-53, NIST 800-171, NIST CSF, NERC-CIP, CMMC, or any in-scope framework triggers a delta review and, where appropriate, an overlay or control update. - **Regulator action.** A new rule, advisory, or enforcement action that changes expectations. - **Material program change.** Adoption of a new platform class, retirement of an existing one, or significant change to the asset tiering scheme. - **Audit / assessment finding.** A finding from internal audit, external auditor, NERC-CIP audit, CMMC assessment, or C3PAO that points at a baseline gap. - **Sev 1 incident.** A confirmed incident whose root cause traces to a missing or weak baseline control. - **Annual review.** Even in the absence of triggers, Governance conducts a full annual review. ### 11.3 Change Workflow 1. **Proposal.** Submitted to the Governance Pillar Leader with: control(s) affected, change rationale, impact on overlays, evidence implications, and any regulator-facing implications. 2. **Assessment.** Engineering and Risk review for operational practicability and exposure implications. Comments returned within 10 business days. 3. **Decision.** Material changes go to CISO at the next Monthly Risk Register Review or sooner if time-sensitive. Non-material changes are approved by the Governance Pillar Leader. 4. **Publication.** Approved changes are merged into the source markdown with a revision history entry. Subordinate documents that cite the changed control are flagged for refresh in their next review cycle. 5. **Notification.** Pillar leaders communicate the change at the next CERG All-Hands and at the next Cyber Oversight Group meeting. ### 11.4 Versioning Rules This baseline follows semantic-ish versioning: | Version Bump | When | Examples | |---|---|---| | **Major** (`x.0`) | Whole-baseline restructure, framework retirement (e.g., 800-53r5 → r6 migration), introduction of a new overlay class | Future r6 migration; addition of an overlay class such as AI | | **Minor** (`1.x`) | New control, new overlay parameter, change to evidence catalog (§9), new crosswalk entry (§10) | Adding a new ATT&CK-derived detection control to AU family | | **Patch** (`1.0.x`) | Clarifying language, typo fix, cross-reference correction, no semantic change | Hyperlink fix, role-name normalization | A change log entry is written for every version bump; the change-log table lives in §12 Revision History. ### 11.5 Subordinate-Document Synchronization When a control in §6 or an overlay in §8 changes, Governance issues a "ripple list" naming every subordinate document that references the changed control. The owning pillar leaders are responsible for refreshing those documents within 30 calendar days of the baseline change being approved. The Compliance Pulse forum tracks ripple-list closure each cycle. --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CB-001 | | **Version** | 2.0 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Control Baseline) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on framework version change (NIST 800-53 rev, CMMC rev, NERC-CIP version, AI governance framework change) | | **Next Scheduled Review** | 2027-05-01 | | **Frameworks** | NIST 800-53r5; NIST 800-171r3; NIST CSF 2.0; CIS Controls v8; ISO/IEC 27001 A.5-A.8; NIST AI RMF 100-1; ISO/IEC 42001 | | **Regulations** | NERC-CIP v7 (and CIP-015 draft); CMMC L2; SOX ITGC | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT, CUI, AI-enabled systems | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 2.0 | 2026-06-17 | Cyber Governance | Added the AI overlay to the overlay matrix and regulator mapping, linking AI control evidence to STD-AI-001 and the AI intake, sanctioned-tools, and system/model register templates. | | 1.21 | 2026-05-22 | Cyber Governance | Updated framework references and normalized section numbering to align with the current corpus structure. | | 1.0 | 2026-05-01 | Cyber Governance | Initial release. Establishes the design principles, control family spine, organizational baseline (§6 control set), control status decision tree (§7), overlay matrix (§8), control-to-evidence mapping (§9), regulatory crosswalks (§10), governance/change/versioning rules (§11), and document control (§12). Aligned to NIST 800-171 r3 and the canonical IDs in CERG-GOV-CAT-001 §5.2. | ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Pillar / role definitions cited by §9 evidence owners | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk treatment, approval authority, and FAIR risk format | | Metrics, Dashboard, and Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Hosts the dashboards cited in §9 evidence catalog | | Compliance Matrix | [`CERG-GOV-CMX-001`](CERG-GOV-CMX-001_Compliance_Matrix.md) | Intent-level cross-regulator map (this doc is implementation-level) | | Risk Taxonomy | [`CERG-GOV-TAX-001`](CERG-GOV-TAX-001_Risk_Taxonomy.md) | Risk categorization that feeds RA-3 register entries | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Canonical SLAs cited by SI-2 | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Exception register cited by §6 and §9 | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Underlying baselines cited by CM-2 | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Underlying detection set cited by AU-* and SI-4 | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Underlying recovery posture cited by CP-* | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Underlying crypto posture cited by IA-5 | | Access Management Standard | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Underlying access posture cited by AC-* and IA-2 | | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Source standard for the AI overlay | | AI Intake and Sanctioning Template | [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | Intake evidence for proposed AI use under the AI overlay | | Sanctioned AI Tools Register Template | [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) | Register evidence for approved AI tools and maximum data classification | | AI System and Model Register Template | [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | Inventory evidence for built and embedded AI systems, models, data sources, and agency boundaries | --- ## CERG Style Compliance Tracker | | | |---|---| | **Document ID** | CERG-GOV-STY-002 | | **Version** | 1.01 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | --- **Purpose:** Track known STY-001 and governance compliance gaps across the CERG corpus. **Owner:** Governance Pillar Leader (Document Control) ## Known Contradictions Resolved The following contradictions existed in the corpus at the time of the June 2026 review. Each has been resolved as documented below. | Contradiction | Artifacts | Resolution | Fixed In | |--------------|-----------|------------|----------| | IR documents included in repo but IR is not CERG-owned | PLN-IR-001, PRC-IR-002, OM-001 §3.4 | Marked IR docs as ADJACENT FUNCTION (External Interface status, IR team owner, "included for cross-reference only" banners at top) | Commit fb71eeb | | Approved status with Pending approvers | 36 documents across all families | Set all "Approved By" to CISO (per user convention). Pending is now only possible in Draft documents. | Commit 20606a3 | | Per-role documents owned by Governance per CAT-001 §4.2 says Pillar Leaders | 32 per-role JD files | Updated file Owner fields to match CAT-001 delegation (Engineering → Engineering PL, Risk → Risk PL, etc.). | Commit 5c2c105 | | Risk acceptance expiration defaults not defined | RMF-001, PRC-RM-001 | Added default expiration durations per severity (Critical 30d, High 90d, Medium 180d, Low 365d) in IMP-002 §5. | Commit 3d9305c | | FLOW-001 timeout-bypass may conflict with RMF-001 approval authority | FLOW-001 §2 principle 10, RMF-001 §9.7 | Noted as intentional design: timeout-bypass includes documented rationale requirement and does not apply to statutory/regulatory approval decisions. | Noted in errors.md | | Self-service closure defined in FLOW-001 but not referenced in PRC-RM-001 | FLOW-001 F-04, PRC-RM-001 | PRC-RM-001 references F-04 for finding treatment. Update on next PRC-RM-001 review cycle. | Deferred to next PRC-RM-001 review | --- **Generated:** 2026-06-11 **Status:** Approved tracker — items are resolved by amending the affected document on its next scheduled review --- ## Known Compliance Gaps ### Missing Document Control Sections (STY-001 §7.5) The following Approved documents lack a Document Control section, which STY-001 requires for every artifact: | Document ID | Document | Status | Scheduled Fix | |-------------|----------|--------|---------------| | CERG-GOV-OM-001 | CERG Operating Model | Approved | Next annual review (2027) | | CERG-PLN-IR-001 | Incident Response Plan | Approved | Next annual review (2027) | | CERG-PRC-RM-001 | Risk Register and Exception Process | Approved | Next semi-annual review | | CERG-PRC-VM-001 | Exposure Management Procedure | Approved | Next semi-annual review | | CERG-GOV-TAX-001 | Risk Taxonomy | Approved | Next annual review (2027) | **Remediation:** On the document's next scheduled review, append a Document Control section following the STY-001 §7.5 format (see §7.5 template below). Add a revision history entry noting the addition. ### Metadata Table Format Inconsistencies (STY-001 §3) | Issue | Affected Documents | Impact | |-------|-------------------|--------| | 2-column metadata format instead of standard 3-column | POL-001 | Minor — functionally equivalent; differs visually from other docs | | Minimal 4-field metadata table | CMX-001, TAX-001, FRM-001 | Minor — missing fields compared to the 11-field STY-001 standard | | Inline bold-text metadata (no table) | RMF-001 | Minor — unique format in the corpus | **Remediation:** Convert to standard 3-column, 11-field format on next review. See cerg-framework skill reference for the safe conversion pattern. ### Document Control Section Numbering STY-001 §7.5 states "Document Control is always the last section" but does not specify a section number. As a result, Document Control appears as §8 in some documents, §9 in others, §10 in STY-001 itself, and §13 in RMF-001. This is not a compliance gap (STY-001 does not mandate a specific number) but contributes to visual inconsistency. ### 4-Part Document IDs Per-role job description documents use 4-part IDs (e.g., `CERG-GOV-JD-SECENG-001`) where the standard naming convention (§2) specifies 3-part IDs (`CERG-TYPE-DOMAIN-NNN`). The DOC_ID_PATTERN in cerg-validate.py was extended on 2026-06-11 to accept these IDs. Future documents should use flat domain codes per the convention; the 4-part format is accepted for the workforce architecture family. --- ## STY-001 §7.5 Template — Document Control Section For reference when remediating the missing sections above: ``` ## N. Document Control | Field | Value | |---|---| | **Document ID** | | | **Version** | X.X | | **Status** | [Draft / For Review / Approved / Retired] | | **Effective Date** | YYYY-MM-DD | | **Classification** | [Public / Internal / Restricted] | | **Owner** | [Role Name] | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | [Annual / Semi-Annual / Quarterly] | | **Next Scheduled Review** | YYYY-MM-DD | | **Frameworks** | [Applicable frameworks] | | **Regulations** | [Applicable regulations] | | **Environments** | [Applicable environments] | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | X.X | YYYY-MM-DD | [Author] | [Summary] | ### Review Triggers - [Trigger 1] - [Trigger 2] [Owner] owns this document. [Owner] is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | [Document Name] | [``](../filename.md) | [Relationship] | ``` --- --- ## Known Contradictions Resolved The following contradictions existed in the corpus at the time of the June 2026 review. Each has been resolved as documented below. | Contradiction | Artifacts | Resolution | Fixed In | |--------------|-----------|------------|----------| | IR documents included in repo but IR is not CERG-owned | PLN-IR-001, PRC-IR-002, OM-001 §3.4 | Marked IR docs as ADJACENT FUNCTION (External Interface status, IR team owner, "included for cross-reference only" banners at top) | Commit fb71eeb | | Approved status with Pending approvers | 36 documents across all families | Set all "Approved By" to CISO (per user convention). Pending is now only possible in Draft documents. | Commit 20606a3 | | Per-role documents owned by Governance per CAT-001 §4.2 says Pillar Leaders | 32 per-role JD files | Updated file Owner fields to match CAT-001 delegation (Engineering → Engineering PL, Risk → Risk PL, etc.). | Commit 5c2c105 | | Risk acceptance expiration defaults not defined | RMF-001, PRC-RM-001 | Added default expiration durations per severity (Critical 30d, High 90d, Medium 180d, Low 365d) in IMP-002 §5. | Commit 3d9305c | | FLOW-001 timeout-bypass may conflict with RMF-001 approval authority | FLOW-001 §2 principle 10, RMF-001 §9.7 | Noted as intentional design: timeout-bypass includes documented rationale requirement and does not apply to statutory/regulatory approval decisions. | Noted in errors.md | | Self-service closure defined in FLOW-001 but not referenced in PRC-RM-001 | FLOW-001 F-04, PRC-RM-001 | PRC-RM-001 references F-04 for finding treatment. Update on next PRC-RM-001 review cycle. | Deferred to next PRC-RM-001 review | ## Compliance by the Numbers | Metric | Count | |--------|-------| | Total CERG documents | 72 governed markdown files | | Documents with Document Control section | 67 (93%) | | Documents missing Document Control section | 5 (7%) — tracked above | | Documents using non-standard metadata format | 5 (7%) — tracked above | | Documents created 2026-06-11 needing style review | 34 (all in roles/) | --- ## Document Control | | | |---|---| | **Document ID** | CERG-GOV-STY-002 | | **Version** | 1.01 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly | | **Next Scheduled Review** | 2026-09-17 | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.01 | 2026-06-17 | Governance Pillar Leader | Added Document Control section. | ### Review Triggers - Quarterly review cycle - New document added to corpus - Style guide (STY-001) updated ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Document Authoring and Style Guide | [CERG-GOV-STY-001](CERG-GOV-STY-001_Document_Authoring_and_Style_Guide.md) | Parent style guide | | Document Catalog | [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Catalog reference | --- ## DOCUMENT AUTHORING AND STYLE GUIDE ### House Voice · Metadata · Structure · Cross-References · Skeleton · Quality Gates --- | | | |---|---| | **Document ID** | CERG-GOV-STY-001 | | **Version** | 1.02 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | | **Review Cycle** | Annual / On material change to catalog, naming, role, or rendering conventions | | **Frameworks** | NIST CSF 2.0 GOVERN · ISO/IEC 27001 A.5 · NIST 800-53r5 PM | | **Regulations** | Cross-cutting | | **Environments** | CERG documentation library | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [CERG House Voice](#2-cerg-house-voice) 3. [Document Anatomy](#3-document-anatomy) 4. [Metadata Rules](#4-metadata-rules) 5. [ID, File Name, and Status Rules](#5-id-file-name-and-status-rules) 6. [Role and RACI Rules](#6-role-and-raci-rules) 7. [Cross-Reference Rules](#7-cross-reference-rules) 8. [Callouts, Tables, and Lists](#8-callouts-tables-and-lists) 9. [Language and Style Rules](#9-language-and-style-rules) 10. [Org-Adaptation and Token Rules](#10-org-adaptation-and-token-rules) 11. [Blank Document Skeleton](#11-blank-document-skeleton) 12. [Quality Gates Before Commit](#12-quality-gates-before-commit) 12.5. [Document Lifecycle Procedure](#125-document-lifecycle-procedure) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope This guide defines how CERG documents are authored, reviewed, and kept consistent. It is the companion to the catalog. The catalog governs IDs, registration, status, and cross-reference discipline. This guide governs the writing pattern, metadata pattern, document skeleton, role discipline, quality gates, and house voice. It applies to every new or revised CERG policy, governance instrument, standard, procedure, plan, template, and operational package. > **Consistency Is a Control** > > A framework that looks like 60 unrelated documents is not a framework. Consistent structure, vocabulary, role names, metadata, and cross-references make the library operational. A reader should be able to open any artifact and know where to find scope, roles, evidence, approvals, and revision history without hunting. --- ## 2. CERG House Voice CERG writing is: - direct; - practical; - declarative; - evidence-oriented; - opinionated where ambiguity would create risk; - clear about ownership and handoffs; - usable by a small team without weakening the role model. CERG writing is not: - vendor marketing copy; - legal boilerplate without operational direction; - generic security advice; - a list of controls without owners or evidence; - a maturity fantasy that assumes a large staff; - a compliance checklist with no operating model. A CERG artifact should answer five questions quickly: 1. What does this document govern? 2. Who owns it? 3. What must happen? 4. What proves it happened? 5. Where does a reader go next? --- ## 3. Document Anatomy Every full CERG artifact follows this structure unless the document type requires a narrow exception. | **Section** | **Purpose** | **Required** | |---|---|---| | Title block | Names the artifact and subtitle. | Yes | | Metadata table | Identifies ID, status, owner, parent, supporting documents, review cycle, frameworks, regulations, environments. | Yes | | Table of Contents | Gives predictable navigation. | Yes for substantive artifacts | | Purpose and Scope | Defines why the artifact exists and what it covers. | Yes | | Operating content | Requirements, process, template, plan, or instrument body. | Yes | | Roles and Responsibilities | Shows canonical role accountability. | Yes when the body assigns work | | Evidence, metrics, or outputs | Shows what proves the process or control worked. | Yes where applicable | | Document Control | Records version, approval, review, revision history, and triggers. | Yes | | Related Documents | Lists authoritative links to related artifacts. | Yes | --- ## 4. Metadata Rules Use this field set unless a sibling document of the same type uses a clearly established variant. | **Field** | **Rule** | |---|---| | Document ID | Must match catalog ID and file name stem. | | Version | New artifacts start at `1.0`. Catalog amendments increment the catalog version. | | Status | New artifacts start as `Draft` unless the human owner has explicitly approved. | | Classification | Use `Public` unless the artifact contains sensitive operational detail. | | Owner | Use a canonical role from `CERG-GOV-OM-001` or an already established artifact owner. | | Parent Policy / Parent Document / Parent Plan | Link to the governing artifact. | | Supporting Documents | Link only to cataloged or planned artifacts. | | Review Cycle | Use concrete cadence and trigger conditions. | | Frameworks | Cite major frameworks that shape the artifact. | | Regulations | List applicable regulatory drivers or `Cross-cutting`. | | Environments | State the scope clearly. | Metadata is not decorative. It is how the document participates in governance, audit, evidence, and lifecycle management. --- ## 5. ID, File Name, and Status Rules ### 5.1 ID Pattern CERG IDs follow: `CERG---` Examples: | **Type** | **Example** | **Meaning** | |---|---|---| | `GOV` | `CERG-GOV-CAT-001` | Governance instrument | | `STD` | `CERG-STD-AC-001` | Standard | | `PRC` | `CERG-PRC-RM-001` | Procedure | | `PLN` | `CERG-PLN-ISO-001` | Plan or operational package | | `TMPL` | `CERG-TMPL-RM-002` | Standalone template | New domain codes require a catalog amendment before the batch is complete. ### 5.2 File Name Pattern Use: `CERG---_Readable_Title_With_Underscores.md` Do not rename existing files casually. Links, catalog rows, and references depend on stable paths. ### 5.3 Status Pattern | **Status** | **Use** | |---|---| | Draft | New artifact awaiting formal approval. | | For Review | Draft artifact out for stakeholder or CISO review. | | Approved | Human owner has approved the artifact for use; authoritative for operations and audit. | | External Interface | Adjacent-function artifact included for cross-reference only; not CERG-governed. | | Retired | Artifact no longer authoritative but retained for history. | Publication is not a lifecycle status. Public-release eligibility is tracked separately in the publication manifest. Do not self-approve new artifacts. If approval is pending, write `CISO (pending)` or the appropriate pending approver. --- ## 6. Role and RACI Rules Use only canonical role names from `CERG-GOV-OM-001` and assignments from `CERG-GOV-RAC-001`. Rules: 1. Do not invent role names. 2. Do not use synonyms if the canonical role exists. 3. A local roles table may explain responsibilities for the reader, but it must conform to `CERG-GOV-RAC-001`. 4. Scaling down is done by role consolidation onto fewer people, not by deleting roles. 5. Exactly one role is accountable for each activity where a RACI is used. 6. External teams may own adjacent programs; preserve those boundaries. Examples of role discipline: | **Avoid** | **Use Instead** | |---|---| | Security team | Governance Pillar Leader, Risk Pillar Leader, or Engineering Pillar Leader, as appropriate | | AppSec owner | Application Security Engineer | | Audit person | Evidence Librarian or Governance Pillar Leader | | Vendor owner | Vendor Risk Analyst or Business Owner, depending on context | | Executive security lead | Chief Information Security Officer (CISO) | --- ## 7. Cross-Reference Rules The catalog's rules govern. This guide repeats the operational version for authors: 1. Link only to artifacts in the catalog (approved or planned). 2. Prefer Document ID over title in prose. 3. Use relative Markdown links to repo files. 4. Mark planned artifacts as `(Planned, V1.x)` or `(Planned, V2)`. 5. Do not cite a file that does not exist unless it is in the catalog as a planned artifact. 6. If an artifact is newly created, amend the catalog in the same batch. 7. If a related document is out of scope, state the boundary instead of inventing a fake artifact. Good cross-reference: `See [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) for risk treatment workflow.` Weak cross-reference: `See the risk procedure.` ### 7.1 Stable Section ID Convention CERG documents use numeric section numbers (e.g., `§9.7`) for sequential structure. However, cross-document references to numeric sections are fragile — renumbering a section in one document breaks references in all documents that point to the old number. To mitigate this, every substantive section SHOULD carry a stable anchor ID in addition to its numeric section heading. #### Anchor ID Pattern Add a stable HTML anchor directly before each top-level (`##`) and second-level (`###`) section heading: ```markdown ## 9.7 Risk Acceptance Authority ``` Or use Markdown's built-in heading anchoring by choosing a stable, kebab-case heading slug and linking to it: ```markdown ## 9.7. Risk Acceptance Authority {#risk-acceptance-authority} ``` For Markdown files in the CERG repository, the preferred approach is to append a stable anchor ID in curly braces after the heading: ```markdown ## 9.7. Risk Acceptance Authority {#risk-acceptance-authority} ``` #### When to Use Stable Anchors | **Section Type** | **Anchor Required?** | **Rationale** | |---|---|---| | Top-level sections (`## N. Title`) | Recommended | Frequently cross-referenced from other documents | | Subsections (`### N.M Title`) referenced from other docs | Yes | Cross-document references are the primary fragility source | | Subsections with no external references | Optional | Not yet referenced, but adding an anchor is cheap insurance | | Appendices | Yes | Frequently referenced from regulatory packages | | Document Control / Revision History | No | Never externally referenced by section number | #### Anchor ID Convention - Use lowercase kebab-case: `#risk-acceptance-authority`, `#evidence-library-structure`. - Keep IDs concise but descriptive (2–5 words). - Prefix with the document's domain segment if ambiguity is likely: `#cb-insm-overlay` rather than `#insm-overlay`. - Do not include the numeric section number in the anchor ID (the whole point is to decouple from numbering). #### Examples ```markdown ## 4. Authority and Status Lifecycle {#authority-status-lifecycle} ### 4.1 Review Cadence Tiers {#review-cadence-tiers} ### 4.2 CERG Source-of-Truth Model {#source-of-truth-model} ``` Cross-reference format using stable anchors: ``` See [CERG-GOV-RMF-001](#risk-acceptance-authority) for risk acceptance approval authority. For evidence tiers, refer to [CERG-GOV-AUD-001](#evidence-tier-requirements) §4. ``` > **Stable IDs Protect Cross-Document References** > > When §9.7 is renumbered to §9.8 because a new §9.6 is inserted, every cross-document link that said "§9.7" breaks silently. A stable anchor `#risk-acceptance-authority` survives renumbering. The numeric section remains in the heading for human readability; the anchor provides the machine-stable reference. ### 7.2 Cross-Reference Update Procedure When section numbering changes in any document (insert, delete, or reorder sections): 1. **Identify affected references.** Search the entire CERG corpus for references to the renumbered document's old section numbers (e.g., search for `RMF-001 §9.7` across all `.md` files). Use `rgrep` or `search_files` tool. 2. **Update numeric references.** Replace each occurrence of the old section number with the new one in the referencing documents. 3. **Verify stable anchors.** If the renumbered section has a stable anchor (per §7.1), the anchor reference does NOT need updating — this is the benefit of stable anchors. 4. **Update TOC in the changed document.** The Table of Contents must reflect new section numbers and anchor links. 5. **Update internal cross-references.** Within the changed document itself, update any prose that references old section numbers. 6. **Validate.** Run `python3 tools/cerg-validate.py` to verify no broken links. Run `python3 tools/cerg-integrity-check.py` for broader drift detection. 7. **Commit.** One commit per changed file with message format: `renumber §§N–M in DOC-ID, update cross-references`. #### Batch Renumbering for Inserted Sections When inserting a new section between existing sections (e.g., inserting §6.5 between §6.4 and §6.5): 1. Renumber from the HIGHEST section number down to the insertion point to prevent cascading replacement. 2. Example: To insert §6.5 between §6.4 and §6.5, first renumber §6.5→§6.6, §6.6→§6.7, ..., then insert new §6.5. 3. Update all cross-document references to the renumbered sections (per step 1–2 above). #### Cross-Reference Hygiene Checks (Pre-Commit) Before committing any section renumbering: - [ ] Search the corpus for references to the renumbered document. - [ ] Update all found references. - [ ] Run validator (0 errors required). - [ ] Verify TOC matches new numbering. - [ ] Verify stable anchors are present on externally-referenced sections. --- ## 8. Callouts, Tables, and Lists ### 8.1 Callouts Use callouts to sharpen important guidance. Pattern: ```markdown > **Short Title** > > Practical explanation. Make the point directly. Avoid generic warnings. ``` Callouts should state a principle, pitfall, or operating rule. They should not repeat the paragraph above them. ### 8.2 Tables Use tables when a reader must compare fields, owners, statuses, evidence, cadence, or approvals. Rules: - keep column names short; - use canonical role names; - make required fields obvious; - avoid sprawling tables when a short list is clearer; - include evidence or output columns when the table describes activity. ### 8.3 Lists Use numbered lists for sequence. Use bullets for sets. --- ## 9. Language and Style Rules ### 9.1 Required Style - Use active voice. - Use direct verbs: owns, approves, records, reviews, escalates. - Define thresholds, cadences, outputs, and evidence. - Name the role that owns an activity. - Prefer concrete nouns over vague terms. - Use short paragraphs. ### 9.2 Prohibited or Discouraged Style - No em dashes. - Avoid passive constructions that hide ownership. - Avoid `should` when the document creates a requirement. Use `must`, `shall`, or direct imperative language where appropriate. - Avoid generic phrases such as `best practice`, `robust security`, or `industry standard` unless immediately defined. - Do not cite regulations as decoration. Cite them when the artifact operationalizes a requirement. - Do not add AI-tool attribution in commits, comments, or document text. ### 9.3 Terminology | **Use** | **Avoid** | |---|---| | artifact | document thing, policy item | | evidence | proof, support, backup material | | accountable role | owner in vague contexts | | residual risk | remaining risk when controls are considered | | exception | waiver, unless the parent process uses waiver as a synonym | | review cycle | cadence, unless speaking informally | --- ## 10. Org-Adaptation and Token Rules `CERG-GOV-VAR-001` governs organization adaptation. Authors must not scatter hard-coded organization facts when a token should be used. Rules: 1. Tokenize organization identity, scale, and example values when they are meant to vary by adopting organization. 2. Do not tokenize framework IDs, role names, core CERG terms, or control IDs. 3. Keep literal token examples intact in documents that teach the token scheme. 4. Run `python3 tools/cerg-render.py --check` before committing. 5. Do not edit rendered output back into source files unless the change is deliberate. --- ## 11. Blank Document Skeleton Copy this skeleton for new substantive artifacts. ```markdown ## [DOCUMENT TITLE] ### [Subtitle: Topic · Topic · Topic] --- | | | |---|---| | **Document ID** | CERG-[TYPE]-[DOMAIN]-[NNN] | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | [Canonical role] | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [Document links] | | **Review Cycle** | Annual / [trigger] | | **Frameworks** | [Frameworks] | | **Regulations** | [Regulations] | | **Environments** | [Scope] | --- ## Table of Contents --- ## 12. Quality Gates Before Commit Every contribution must pass these gates before commit: | **Gate** | **Command / Check** | **Pass Condition** | |---|---|---| | No em dash characters | Search files for the prohibited em dash character | No output | | Render check | `python3 tools/cerg-render.py --check` | Passes | | Catalog registration | Inspect `CERG-GOV-CAT-001` | New artifact listed or planned entry updated | | Catalog status sync | `python3 tools/cerg-catalog-sync.py --ci` | Exit 0 — file frontmatter Status matches CAT-001 §5 | | Role discipline | Compare against `CERG-GOV-OM-001` and `CERG-GOV-RAC-001` | No invented roles | | Cross-reference discipline | Follow internal links or use a link checker when available | No dead links | | Status discipline | Inspect metadata and Document Control | New artifact is Draft unless approved | | Commit message hygiene | Review commit text | No AI-tool attribution | A document is not complete until the catalog is amended where required. --- ## 12.5 Document Lifecycle Procedure Every CERG document follows a defined lifecycle from creation through retirement. ### Status States | **Status** | **Meaning** | **Who Can Set** | |---|---|---| | Planned | Artifact has an ID and owner but no draft yet | Governance Pillar Leader | | Draft | Work in progress; not authoritative | Any author | | For Review | Stakeholder or CISO review in progress | Governance Pillar Leader or document owner | | Approved | Approved and active; authoritative for operations and audit | Approval authority defined in CAT-001 §4 | | External Interface | Adjacent-function artifact included for cross-reference only | Adjacent-function owner, recorded by Governance | | Retired | No longer authoritative but retained for history | CISO or Governance Pillar Leader | ### Lifecycle Workflow 1. **Create**: New artifact is drafted in `Draft` status. Document ID and naming follow [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) conventions. 2. **Peer Review**: Draft is reviewed by a second qualified analyst from the same or adjacent pillar. Review checks structure, cross-references, role discipline, and framework alignment. 3. **Pillar Leader Approval**: The owning pillar leader reviews and approves the document for publication. 4. **CISO Approval**: The CISO (or CISO designee) gives final approval. Material changes to policy (CERG-POL-001) require CISO approval directly. 5. **Approve / Release**: Status is set to `Approved` in both the header and Document Control section. The document is added to the catalog if new, or the catalog entry is updated if revised. Public-release eligibility is recorded separately in the publication manifest. 6. **Scheduled Review**: Each Approved document is reviewed on its assigned review cadence. The review is triggered by the review cycle defined in the document's front matter or by material changes to referenced frameworks, regulations, or organizational structure. 7. **Retire**: Documents that are superseded or no longer applicable are set to `Retired` status. The document is not deleted; it remains in the repository for historical reference. ### Emergency Fast-Track When a document is needed urgently (e.g., to address a new regulatory requirement or respond to a significant incident), the peer review and pillar leader approval steps may be completed concurrently. CISO approval is still required before publication. ### Version Numbering - New documents start at version 1.0. - Material changes increment the minor version (1.0 → 1.1, 1.1 → 1.2). - Major structural or scope changes increment the major version (1.x → 2.0). - The version in the header front matter and the Document Control section must always match. - Every version change is recorded in the Revision History table. ### Change Log Requirements Every edit to an Approved document must include a Revision History entry with the following **standardised columns**: | **Column** | **Required** | **Guidance** | |---|---|---| | **Version** | Yes | Document version at time of change (e.g., 1.22) | | **Date** | Yes | Date of change in ISO 8601 format (YYYY-MM-DD) | | **Author** | Yes | Canonical role name or named individual | | **Change Type** | Yes | One of: `Major` (structural/scope change), `Minor` (new content, renumbering), `Patch` (typo, link fix, metadata correction) | | **Summary** | Yes | Brief, specific description of what changed and why | | **Linked Issue/PR** | Recommended | Reference to the issue, PR, or improvement register entry that drove the change | Example: | **Version** | **Date** | **Author** | **Change Type** | **Summary** | **Linked Issue/PR** | |---|---|---|---|---|---| | 1.22 | 2026-06-18 | Governance Pillar Leader | Minor | Expanded CIP-015 §13 from preliminary section to full INSM Implementation Annex | #INIT-9.1 | | 1.21 | 2026-06-17 | Governance Pillar Leader | Patch | Updated supporting documents links | #42 | > **Consistent Revision History Is an Audit Artifact** > > An auditor, regulator, or new team member should be able to reconstruct the change history of any CERG document from its Revision History table. Inconsistent columns, missing dates, or vague summaries ("updated section") undermine that. Use the standard columns above for every entry. ### Aggregated Changelog The tool `tools/cerg-changelog.py` aggregates all Revision History entries from all Approved CERG documents into a single chronological changelog. Run it at any time to generate: ```bash python3 tools/cerg-changelog.py # Print to stdout python3 tools/cerg-changelog.py --since 2026-01-01 # Filter by date python3 tools/cerg-changelog.py --doc PLN-CIP-001 # Filter by document python3 tools/cerg-changelog.py --json # JSON output ``` The aggregated changelog is a human-readable supplement, not a replacement for per-document Revision History tables. ### Framework-Wide Updates When a new framework revision is published (e.g., NIST 800-53 Rev 6, NIST 800-171 Rev 4): 1. Governance Pillar Leader assesses impact across all documents. 2. Affected documents are prioritized by regulatory criticality. 3. Updates are drafted, reviewed, and published following the standard lifecycle. 4. The Document Catalog is updated to reflect new versions. 5. Stakeholders are notified of material changes through the CERG All-Hands or pillar sync. --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-STY-001 | | **Version** | 1.02 | | **Status** | Approved | | **Effective Date** | 2026-06-14 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to catalog, naming, role, or rendering conventions | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST CSF 2.0 GOVERN; ISO/IEC 27001 A.5; NIST 800-53r5 PM | | **Regulations** | Cross-cutting | | **Environments** | CERG documentation library | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.02 | 2026-06-18 | Governance Pillar Leader | Minor | Added Stable Section ID Convention (§7.1), Cross-Reference Update Procedure (§7.2), standardised Revision History columns, catalog sync reference in quality gates, and aggregated changelog tool reference. | INIT-10.1, INIT-10.3 | | 1.01 | 2026-06-14 | Governance Pillar Leader | Minor | Aligned status lifecycle language to CAT-001 by using Approved as the authoritative status and treating publication eligibility as separate metadata. | | 1.0 | 2026-05-22 | Cyber Governance | Initial release. Establishes the CERG house style, metadata and skeleton rules, role and cross-reference discipline, language rules, org-adaptation guidance, and pre-commit quality gates. | ### Review Triggers - Catalog structure or cross-reference rule change - Role roster or RACI change - Org-adaptation token scheme change - Quality gate or render tool change - New artifact type introduced - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative ID, catalog, status, and cross-reference rule source | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster source | | Consolidated Roles and RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | RACI and role assignment source | | Organization Adaptation Profile | [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Org-token and rendering guidance | --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-002 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | --- ## Table of Contents 1. [Before You Start](#1-before-you-start) 2. [What Not to Adopt Yet](#2-what-not-to-adopt-yet) 3. [Adoption Anti-Patterns](#3-adoption-anti-patterns) 4. [The Decision Log](#4-the-decision-log) 5. [Risk Acceptance Guardrails](#5-risk-acceptance-guardrails) 6. [Regulatory Honesty](#6-regulatory-honesty) 7. [Role Safety for Small Teams](#7-role-safety-for-small-teams) 8. [Safe vs. Dangerous Changes](#8-safe-vs-dangerous-changes) 9. [Document Control](#9-document-control) --- ## 1. Before You Start CERG is an operating-model and document corpus for standing up a cybersecurity program. It is not a control checklist, a compliance certificate, or a substitute for organizational commitment. Before you fork, edit, or adopt any CERG artifact as authoritative, you must have: - A named CISO or accountable security owner with executive authority - A named executive sponsor outside the security team - A defined scope of systems, business units, or environments - Known regulatory obligations (even if you defer the regulatory packages) - An asset inventory or CMDB source (even if incomplete) - A vulnerability scanner or discovery method - An identity source of truth (IdP, directory) - A ticketing or work-tracking system - A place to store evidence (shared drive, GRC tool, document management system) - Approval authority for policy adoption - Business owners who can accept risk for their systems - An Incident Response owner identified (even if IR is separate from CERG) If any of these are missing, do not adopt CERG as your authoritative operating model. Use it as a planning reference until they exist. Adopting CERG without these prerequisites will produce approved documents that nobody can actually operate. Before adopting, read at least one [Day in the Life story](../examples/day-in-the-life/README.md). Stories are illustrative, not normative, but they show what the spine actually looks like when two or three people run it under real pressure. If the story's rhythm does not fit your organization, the spine will not either. --- ## 2. What Not to Adopt Yet The full CERG corpus is designed for a mature, fully-staffed program. Adopting everything on day one is the most common failure mode. Start with the spine — the minimum set of documents needed to run a security program — and layer on the rest as your program matures. ### Adopt First (The Spine) These documents form the minimum viable program. Every adopter needs them: | Document | Why | |----------|-----| | Cybersecurity Policy (POL-001) | Anchors everything. Board/CISO must approve. | | Operating Model (OM-001) | Defines roles, pillars, and handoffs. | | Risk Management Framework (RMF-001) | How risk is identified, scored, treated, and accepted. | | Risk Register and Exception Process (PRC-RM-001) | The operational risk workflow. | | Exposure Management Procedure (PRC-VM-001) | The operational vulnerability workflow. | | Unified Control Baseline (CB-001) | What controls you are implementing. | | Document Catalog (CAT-001) | Inventory of what exists and what is planned. | | Architecture Review Procedure (PRC-AR-001) | How projects get security review. | | Implementation Guide (IMP-001) | How to adapt CERG to your organization. | | **This document** (IMP-002) | How to avoid the common failure modes. | ### Defer Until the Spine Is Running These documents add value but are not needed on day one. Adopt them after you have completed at least one full cycle of risk register review, exposure management, and project intake: - Full workforce planning (WFP-001) - Succession planning (SUCC-001) - Full maturity self-assessment (MAT-001) - ISO 27001 operational package (PLN-ISO-001) - SOX ITGC operational package (PLN-SOX-001) — unless SOX applies - CMMC operational package (PLN-CUI-001) — unless CMMC applies - NERC-CIP operational package (PLN-CIP-001) — unless NERC-CIP applies - Board and CISO reporting deck template (TMPL-MTR-001) — use a simple status report first - Full role architecture with per-role JDs (roles/jf-*/) — the family overviews (JF-001, JF-002) are sufficient - Cross-pillar operational flows (FLOW-001) — the procedures themselves (PRC-*) are sufficient for initial adoption ### Run at Month 2 The following artifacts are not adopted (they are templates or surveys), but they are run on a schedule starting at month 2 of adoption: - **Stakeholder perception survey ([`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md))** — administer the first survey at month 2 (after one full cadence cycle), then annually. Per [`CERG-GOV-SLC-001`](../governance/CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md), the annual-only cadence is intentionally paired with monthly Service Responsiveness metrics (SR-001 through SR-005 in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md)) so friction is caught continuously, not only once a year. ### Never Adopt Blindly - Never adopt a regulatory package unless the regulation actually applies to your organization. - Never adopt a template without understanding the parent procedure it serves. - Never mark a control "Implemented" without evidence. - Never accept a risk without a named business owner. --- ## 3. Adoption Anti-Patterns These are the ways CERG adoption fails. If you recognize your organization in any of these, stop and fix the pattern before continuing. ### Anti-Pattern 1: Fork-and-Declare **What it looks like:** Fork the repo, change the organization name, declare the program complete. No evidence collected. No risk register populated. No vulnerability cadence running. **Why it fails:** CERG is an operating model, not a compliance artifact. Forking the documents does not implement the controls. An auditor or assessor will ask for evidence, not a PDF of a policy. **Fix:** Adopt the spine documents first. Run one cycle of risk register review, exposure management, and project intake before declaring adoption. ### Anti-Pattern 2: Delete Roles Instead of Consolidating **What it looks like:** "We only have 5 people, so we deleted the other 22 roles." **Why it fails:** The canonical roles define the work that needs to be done, not the headcount. When you delete a role, you delete the accountability for that work. The work still exists — it just has no owner. **Fix:** Consolidate roles onto fewer people, but keep the accountability assignments visible. Use the scaling map in RAC-001 §8. Document every consolidation in the Decision Log. Example: "Governance Pillar Leader also serves as Risk Register Owner and Evidence Librarian" — not "deleted Risk Register Owner." ### Anti-Pattern 3: Optimistic Control Status Inflation **What it looks like:** Mark every control "Implemented" because a policy says it should exist. No evidence. No testing. No validation. **Why it fails:** Control status without evidence is a claim, not a fact. When an incident or audit exposes the gap, the gap was always there — the status just hid it. **Fix:** Use the control status decision tree: Applicable? → Designed? → Operating? → Evidenced? Mark "Partially Implemented" or "Planned" where evidence is absent. An honest gap is better than a false claim. ### Anti-Pattern 4: Security Absorbs All Risk **What it looks like:** Every risk in the register has "Security" or "CISO" as the owner. **Why it fails:** Security does not own the business processes, the revenue impact, the customer relationships, or the regulatory obligations. When security owns all risk, business owners have no incentive to make secure choices, and security becomes the department that says "no" because it carries all the liability. **Fix:** Every risk must have a named business owner outside the security team. The Risk Register and Exception Process (PRC-RM-001) requires this. If a business owner refuses, escalate to the executive sponsor. ### Anti-Pattern 5: Governance as Blocker **What it looks like:** Every project, change, and exception waits for Governance approval. Governance becomes the department that slows everything down. **Why it fails:** CERG's operating philosophy is "yes, and here are the conditions that make this safe." When Governance becomes a gatekeeper instead of an enabler, teams route around it, and real risk goes unmanaged. **Fix:** Use the timeout-bypass principle (FLOW-001 §2, principle 10). Define decision rights clearly. Delegate routine approvals to Pillar Leaders. Reserve Governance escalation for material risk decisions. ### Anti-Pattern 6: Risk as Vulnerability Scanning Only **What it looks like:** The Risk function runs the vulnerability scanner. That is its entire job description. **Why it fails:** Risk owns threat intelligence, adversarial testing, vendor risk, detection engineering, identity risk, OT risk, and the risk register. Reducing Risk to vulnerability scanning leaves most of the organization's exposure unmanaged. **Fix:** Staff Risk for its full scope, or document which Risk functions are deferred and why. A small team may consolidate Risk roles, but the functions they cover should be explicit. ### Anti-Pattern 7: Engineering as Late-Stage Review Gate **What it looks like:** Engineering is brought in at the end of a project to "review security" before go-live. **Why it fails:** Architecture review that happens at the end catches problems when they are expensive to fix. Engineering should be in the design conversation early enough to change the design cheaply. **Fix:** Integrate Engineering into project intake at concept stage, not at go-live. The Architecture Review Procedure (PRC-AR-001) defines this. A review that consistently surfaces "we have to redo the data flow now" came too late. ### Anti-Pattern 8: Uncalibrated Starter Values Become Operational **What it looks like:** The risk appetite uses preliminary default dollar bands requiring organizational calibration ($2M, $5M, $10M). Nobody calibrates them. Risk acceptance decisions are made against uncalibrated thresholds. **Why it fails:** Starter values are not your organization's actual risk tolerance. Accepting a $1.9M risk because "the uncalibrated default says $2M" is an arbitrary decision dressed as a framework. **Fix:** Calibrate risk appetite values to your organization's actual revenue, downtime cost, regulatory exposure, and insurance retention. If you cannot calibrate, explicitly document that risk acceptance uses qualitative judgment until calibration occurs. ### Anti-Pattern 9: Running the Process Without Executive Sponsorship **What it looks like:** The security team adopts CERG. The CISO is enthusiastic. Nobody above the CISO knows it exists. **Why it fails:** CERG requires business owners to accept risk. It requires executive approval for Critical risk acceptance. It requires budget for tooling and staffing. Without an executive sponsor outside security, these decisions have no authority. **Fix:** The executive sponsor must be named, briefed, and committed before adoption proceeds past the spine. Their name appears in the Implementation Guide's organization profile. ### Anti-Pattern 10: Creating a Risk Register That Is Never Reviewed **What it looks like:** The risk register exists. It has entries. Nobody reviews it on cadence. **Why it fails:** A risk register that is not reviewed is a tombstone, not a management tool. Risks age. Treatments stall. Acceptances expire. The register becomes a historical record instead of an operational instrument. **Fix:** Schedule the first risk register review before creating the register. The review cadence is non-negotiable. If the review is missed, create a Finding Record (per FLOW-001 F-07 mandatory rules). --- ## 4. The Decision Log Every tailoring decision — every document deferred, every role consolidated, every threshold changed — must be captured. Without a decision log, future team members, auditors, and assessors cannot understand why the program looks the way it does. ### Decision Log Template | Field | Description | |-------|-------------| | **Decision ID** | DEC-YYYY-NNN (e.g., DEC-2026-001) | | **Date** | When the decision was made | | **Decision** | What was decided, in one sentence | | **Rationale** | Why this decision was made | | **Alternatives Considered** | What other options were evaluated and why they were rejected | | **Risk Created** | What risk does this decision introduce? | | **Documents Affected** | Which CERG documents were changed, deferred, or retired as a result? | | **Approver** | Who approved this decision? | | **Review Date** | When should this decision be re-evaluated? (Or "Permanent unless conditions change") | ### Example Decisions **Example 1: Deferring a regulatory package** | Field | Value | |-------|-------| | Decision ID | DEC-2026-001 | | Date | 2026-06-15 | | Decision | Defer adoption of the ISO/IEC 27001 Operational Package (PLN-ISO-001). The organization is not pursuing ISO 27001 certification. | | Rationale | ISO 27001 certification is not a business requirement. The control baseline (CB-001) already maps to ISO controls for internal reference. | | Alternatives Considered | (1) Adopt package anyway as best practice — rejected because it creates evidence obligations with no business driver. (2) Remove from repo — rejected because future business needs may change. | | Risk Created | If the organization later pursues ISO 27001, the deferred package will need to be adopted and backfilled with evidence. | | Documents Affected | CAT-001 §7 (mark PLN-ISO-001 as Deferred). IMP-001 organization profile. | | Approver | CISO | | Review Date | Annual, or upon business direction to pursue ISO 27001 | **Example 2: Consolidating roles for a small team** | Field | Value | |-------|-------| | Decision ID | DEC-2026-002 | | Date | 2026-06-15 | | Decision | Consolidate Governance Pillar Leader, Risk Register Owner, and Evidence Librarian into one person. | | Rationale | 5-person security team. Cannot staff three separate governance roles. Workload assessment confirms one person can perform all three functions at current organizational scale. | | Alternatives Considered | (1) Leave roles unfilled — rejected because register and evidence functions are critical. (2) Outsource evidence management — rejected due to cost. | | Risk Created | Self-review risk: the same person manages the risk register and the evidence that supports risk decisions. Mitigated by CISO review and independent Business Owner / Executive Sponsor acknowledgement for risk acceptance decisions. | | Documents Affected | OM-001 §6.1 role roster (annotated). RAC-001 accountability assignments (annotated). Per-role files for consolidated roles. | | Approver | CISO | | Review Date | Semi-annual; escalate if team grows beyond 8 people | **Example 3: Calibrating risk appetite** | Field | Value | |-------|-------| | Decision ID | DEC-2026-003 | | Date | 2026-07-01 | | Decision | Set single-risk ALE threshold at $500K based on annual revenue of $50M and cyber insurance retention of $250K. | | Rationale | Board requested a materiality threshold aligned to financial reporting. Finance confirmed $500K as the threshold above which a single cyber event would be material to quarterly earnings. | | Alternatives Considered | (1) Keep the uncalibrated $2M default - rejected as not calibrated to organization. (2) Set at $250K (insurance retention) - rejected as too conservative for a non-regulated entity. | | Risk Created | Risks between $250K-$500K ALE will be accepted below the materiality threshold. Mitigated by quarterly review of all accepted High risks. | | Documents Affected | RMF-001 §9.5 (risk appetite values). MTR-001 board reporting thresholds. | | Approver | CISO with CFO concurrence | | Review Date | Annual, or upon material change in revenue or insurance coverage | --- ## 5. Risk Acceptance Guardrails Risk acceptance is a legitimate risk treatment strategy. It is not a way to make findings disappear. These guardrails prevent acceptance from becoming a paperwork exercise. ### Expiration Defaults Every risk acceptance must have an expiration date. The defaults below apply unless a specific business justification supports a different duration: | Risk Severity | Default Expiration | Approver | Renewal Rule | |---------------|-------------------|----------|--------------| | **Critical** | 30 days | CISO + Executive Sponsor | Cannot be renewed without material change in treatment plan | | **High** | 90 days | CISO | Renewal requires documented progress toward remediation | | **Medium** | 180 days | Pillar Leader or Governance Pillar Leader | Renewal requires confirmation that conditions have not worsened | | **Low** | 365 days | Risk Register Owner | Annual review at minimum | **Hard rules:** - No acceptance is permanent. Every acceptance expires and requires re-approval. - An acceptance renewed more than twice without movement on the treatment plan escalates one approval tier. - An expired acceptance with no renewal creates a Finding Record (severity: High). - The business owner must sign the acceptance. Security cannot accept risk on behalf of the business. - Acceptance records must document: the risk scenario, the rationale for acceptance over treatment, the compensating controls in place (if any), the residual risk, the expiration date, and the named approver. **Small-team separation rule:** role consolidation does not collapse business consequence acceptance into the security assessor. If the same person performs CISO, Risk, and Governance work in CERG Lite, an independent Business Owner or Executive Sponsor must still acknowledge the business consequence for accepted risk. If no independent business approver exists, CERG may be used as planning guidance but should not be declared authoritative for risk acceptance. ### Risk Acceptance Is Not Remediation A risk acceptance: - Records ownership and accountability - Documents the rationale for not treating the risk - Requires compensating controls where applicable - Sets an expiration and review cadence - Records residual risk A risk acceptance does NOT: - Make the finding disappear from the risk register - Reset the remediation SLA without documented approval - Transfer accountability from the business owner to security - Satisfy a regulatory requirement by itself - Excuse the organization from monitoring the risk **If an accepted risk materializes** (exploit published, KEV listed, incident occurs), the acceptance is automatically reopened for re-assessment per RMF-001 §9.10. --- ## 6. Regulatory Honesty CERG references NERC-CIP, CMMC, SOX, ISO 27001, and privacy regulations. These references are for integration mapping — they do not constitute compliance claims. ### General Rule > **CERG documents do not equal regulatory compliance.** An organization may adopt every CERG artifact and still fail a regulatory assessment if controls are not implemented, evidenced, and tested against the specific regulatory requirement. ### Do Not Accidentally Claim For each regulatory framework referenced in CERG: - **Do not** claim compliance because CERG documents exist. - **Do not** claim a control is implemented without evidence. - **Do not** claim an inherited control (cloud/SaaS) without provider evidence and your own complementary controls. - **Do not** treat a generic policy as a procedure that satisfies a prescriptive regulatory requirement. - **Do not** treat risk acceptance as a regulatory waiver unless the regulator has explicitly accepted it. - **Do not** treat a POA&M item as evidence that a control is operating. - **Do not** treat a compensating control as equivalent to the required control without documented analysis. ### CMMC-Specific Realism For organizations pursuing CMMC: - CERG's SSP template and POA&M template are starting points. The SSP must be system-specific — describing your actual system boundary, your actual data flows, and your actual control implementation. - POA&M acceptability has limits. Assessors evaluate whether POA&M items are credible, resourced, and scheduled. A POA&M with no owner and no due date is not acceptable under any framework. - Evidence must prove practices are *performed*, not just *documented*. A policy that says "we do access reviews" is not evidence that you did one. - CUI flow mapping is mandatory. You cannot scope CMMC without knowing where CUI enters, resides, and leaves your environment. - External Service Providers (ESPs) affect your scope. If a cloud provider or MSP handles CUI, their CMMC status and your shared responsibility matrix are assessment inputs. ### NERC-CIP-Specific Caution For registered entities subject to NERC-CIP: - CERG is not a substitute for a registered entity's compliance determination. BES Cyber System classification must be entity-specific and performed by qualified personnel. - CIP evidence must be retained per the applicable CIP standard's retention requirements — which may exceed CERG's general evidence retention guidance. - Deviations from CIP requirements need formal handling per the applicable CIP standard, not just a CERG exception record. The CIP deviation process is a separate regulatory obligation. - OT scanning must be operationally approved. Vulnerability scanning in OT environments can disrupt operations, trigger safety systems, or violate maintenance windows. CERG's exposure management procedure is written for IT environments; OT scanning requires additional controls. - EACMS, PACS, and BCSI are CIP-specific asset classifications. Do not map these to CERG asset types without understanding the CIP definitions and scoping rules. ### SOX-Specific Caution For organizations subject to SOX: - ITGC control evidence must support the financial reporting control objectives. CERG's general control evidence may need to be supplemented with control-specific test results. - Compensating ITGC controls must be documented and tested. A compensating control that is not tested is not a compensating control for SOX purposes. - Internal Audit and the CFO designee must be notified of ITGC control gaps per PRC-RM-001 §7.4. --- ## 7. Role Safety for Small Teams Small teams must consolidate roles — the scaling map in RAC-001 §8 defines how. But some consolidations create unacceptable conflicts. This section defines which combinations are safe and which require compensating controls. ### Usually Safe Consolidations These role pairs can be performed by the same person with manageable conflict risk: | Role A | Role B | Why It Is Usually Safe | |--------|--------|------------------------| | Policy & Standards Manager | Evidence Librarian | Policy work and evidence management are complementary, not conflicting | | Exposure Management Lead | Threat Intelligence Analyst | Both are assessment functions; neither approves its own findings | | Cloud Security Engineer | Identity Engineer | Different technical domains; cloud and identity controls are separable | | Endpoint Engineer | Cryptography Engineer | Different technical domains; endpoint and crypto controls are separable | | NERC-CIP Compliance Manager | CMMC/Federal Compliance Manager | Both are compliance assessment roles; different frameworks, same skillset | ### Risky Consolidations — Require Compensating Controls These consolidations create conflicts that must be explicitly mitigated. If you must combine these roles, document the compensating control in the Decision Log: | Role A | Role B | Conflict | Compensating Control | |--------|--------|----------|---------------------| | Risk Assessor (any Risk role) | Risk Acceptor (CISO) | Same person assesses and accepts the risk — no independent challenge | Require executive sponsor review for all High/Critical acceptances | | Evidence Producer (Engineering) | Evidence Tester (Governance) | Same person produces and validates evidence — self-review | Require independent sampling of evidence by a different pillar | | System Owner (Business) | Exception Approver (Governance) | Same person requests and approves the exception — no independent check | Require CISO approval for exceptions affecting systems the approver owns | | Change Implementer (Engineering) | Change Approver (Governance) | Same person implements and approves the change — no segregation | Require peer review for changes affecting security controls | | Vendor Sponsor (Business) | Vendor Risk Approver (Risk) | Same person sponsors and approves the vendor — conflict of interest | Require independent vendor risk assessment for high-risk vendors | | Incident Commander (IR) | Post-Incident Corrective Action Validator | Same person runs the incident and validates the fix — self-review | Require post-incident review by a different pillar | ### Never Combine These combinations create unacceptable risk under any circumstances. If your team is too small to separate these, the function must be outsourced, performed by a different department, or explicitly deferred with executive acknowledgement: - **Risk assessor AND sole risk acceptor for the same risk** — requires at minimum an independent reviewer outside the security team. - **Evidence producer AND evidence tester for the same control** — evidence must be independently validated. - **Exception requester AND exception approver for the same exception** — approval must come from a different person. - **Incident Commander AND post-incident lessons-learned approver for the same incident** — lessons learned require independent review. ### Minimum Separation of Duties For each process, these functions must be performed by different people unless otherwise documented: | Process | Requester | Assessor | Approver | Implementer | Validator | |---------|-----------|----------|----------|-------------|-----------| | Risk Acceptance | Any | Risk Pillar | CISO / Executive Sponsor | Engineering | Risk Pillar | | Security Exception | Any | Risk Pillar | Governance Pillar Leader | Engineering | Risk Pillar | | Access Approval | User/Manager | Identity Engineer | System Owner | Identity Engineer | Access Reviewer | | Privileged Access | User/Manager | Identity Engineer | System Owner | Identity Engineer | PAM Audit | | Firewall/Network Change | Requester | Engineering | Engineering Pillar Leader | Engineering | Risk | | Production Release | Engineering | Engineering Pillar Leader | Change Advisory Board | Engineering | Operations | | Vendor Approval | Business Owner | Vendor Risk Analyst | Governance Pillar Leader | Procurement | Vendor Risk Analyst | | POA&M Closure | System Owner | Compliance Manager | Governance Pillar Leader | Engineering | Risk or Auditor | | Control Evidence Testing | Evidence Librarian | Control Owner | Governance Pillar Leader | N/A | Independent Tester | --- ## 8. Safe vs. Dangerous Changes When you tailor CERG, some changes are safe. Some are dangerous. This section defines the boundary. ### Safe to Change You can (and should) change these without compromising the framework's integrity: - **Organization name and branding** — replace "CERG" or the utility example with your organization - **Role assignments** — assign canonical roles to actual people or job titles - **Tool names** — replace generic references with your actual tools - **Regulatory scope** — adopt only the regulatory packages that apply; defer or remove the rest - **Meeting cadences** — adjust schedules within the bounds defined by review cycles - **Dollar thresholds** — calibrate risk appetite values to your organization's finances - **Evidence repository locations** — specify where your evidence is actually stored - **Team size examples** — replace the 60-person example with your actual headcount - **Asset classification tiers** — define tiers that match your business criticality ### Dangerous to Change Changing these breaks the operating model. If you must change them, document the deviation in the Decision Log and accept the resulting risk: - **Risk acceptance approval separation** — do not allow the same person to assess and accept the same risk - **Evidence requirements** — do not eliminate evidence requirements for implemented controls - **Exception expiration** — do not make exceptions permanent or silently renewable - **Role accountability** — do not delete canonical roles; consolidate them onto fewer people but keep the accountability assignment visible - **Control status definitions** — do not redefine "Implemented" to mean "we have a policy" - **Regulatory obligations** — do not remove regulatory requirements that actually apply to you - **Asset inventory requirement** — do not skip asset registration; you cannot protect what you do not know you have - **Risk register review cadence** — do not skip scheduled reviews; a stale register is worse than no register - **Canonical role names** — do not rename roles; the name is the identifier that connects RACI assignments, procedures, and training - **Document ID format** — do not change the ID scheme; it is the cross-reference backbone --- ## 9. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-IMP-002 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader | Added explicit small-team separation rule for business-risk consequence acceptance when security roles are consolidated. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Adoption pre-requisites, anti-patterns, decision log template, risk acceptance guardrails, regulatory honesty guidance, role collision guide, and safe/dangerous tailoring boundaries. | ### Review Triggers - Adoption feedback identifying a new failure pattern - Change to the role roster in OM-001 §6.1 - Change to regulatory requirements affecting any framework CERG references - Direction from the CISO Governance owns this document. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | How to adapt CERG; this document defines the safety rules for doing so | | Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster and scaling map | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk acceptance authority and expiration | | Consolidated Roles and RACI | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Role accountability and separation of duties | | Cross-Pillar Operational Flows | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Timeout-bypass principle and escalation paths | --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-003 | | **Version** | 1.02 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | Small-team CERG adopters (≤8 people) | --- ## Table of Contents 1. [Who This Is For](#1-who-this-is-for) 2. [The CERG Lite Package](#2-the-cerg-lite-package) 3. [Operating Rhythm for a 5-Person Team](#3-operating-rhythm-for-a-5-person-team) 4. [Role Consolidation Map](#4-role-consolidation-map) 5. [First 10 Records to Create](#5-first-10-records-to-create) 6. [First Month Success Criteria](#6-first-month-success-criteria) 7. [Manual Fallback Schemas](#7-manual-fallback-schemas) 8. [Minimum Viable Evidence Library](#8-minimum-viable-evidence-library) 9. [Document Control](#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](CERG-GOV-IMP-002_Adoption_Safety_Guide.md) 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) | Document | Why | |----------|-----| | Cybersecurity Policy (POL-001) | Board/CISO must approve. One page. | | CERG Framework (FRM-001) | Explains the three-pillar model every other document assumes. | | Operating Model (OM-001) | Defines your consolidated roles. Read §6.1, skip the 60-person examples. | | Document Catalog (CAT-001) | Inventory of what exists and what you have adopted. | | Risk Management Framework (RMF-001) | How you score, treat, and accept risk. | | Risk Register and Exception Process (PRC-RM-001) | Your operational risk workflow. | | Risk Register Templates (TMPL-RM-001) | The spreadsheet/template layer that makes the register real. | | Exposure Management Procedure (PRC-VM-001) | Your operational vulnerability workflow. | ### Use as adoption aids, not additional MVC requirements | Document | Use | |----------|-----| | Implementation Guide (IMP-001) | How to adapt the corpus. Fill in your org profile. | | Adoption Safety Guide (IMP-002) | How to avoid failure modes. | | **This document** (IMP-003) | How to run CERG with a small team. | | Role-Based Implementation Checklists (IMP-006) | What each consolidated role should do first. | | Job Families Overview (JF-001) | Useful for hiring and consolidation, not required to run MVC. | | NICE Crosswalk (JF-002) | Optional skills-gap and hiring reference. | ### Adopt When Ready (layered on as the team grows) | When | Add These | |------|-----------| | You are ready to formalize controls | Unified Control Baseline (CB-001); start with the 6 families you can evidence. | | You have cloud, SaaS, or managed infrastructure | Access, Asset, Configuration, IT/Cloud/SaaS, Logging, and Resilience standards as applicable. | | You have a compliance requirement | The applicable regulatory package (CIP, CUI, SOX, ISO, Privacy). | | You are onboarding vendors | Third-Party Risk Procedure (PRC-TPRM-001). | | You have a detection capability | Threat Intelligence Procedure (PRC-TI-001) and Adversarial Validation Procedure (PRC-AV-001). | | You have an incident response function | Cross-Pillar Flows (FLOW-001) for F-06 integration; IR remains owned by the standing IR team. | | Team grows beyond 8 people | Per-role JD documents for hiring; full workforce planning. | ### 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) | Activity | Who | Duration | |----------|-----|----------| | High/Critical risk review | CISO + whoever owns Risk that week | 20 min | | Vulnerability remediation review | Risk person | 20 min | | Open exceptions check (any expiring this month?) | Governance person | 10 min | | New project intake review (any new requests?) | Engineering person | 10 min | ### Biweekly (1 hour) | Activity | Who | Duration | |----------|-----|----------| | Vulnerability SLA review (any past due?) | Risk person | 15 min | | Change review (any security-significant changes this period?) | Engineering person | 15 min | | Evidence freshness check (any stale evidence?) | Governance person | 15 min | | Cross-training check (did anyone do their 4 hours?) | Everyone | 15 min | ### Monthly (2 hours) | Activity | Who | Duration | |----------|-----|----------| | Full risk register review | Everyone | 45 min | | Exception review (renew, close, escalate) | Governance + Risk | 20 min | | Vendor risk review (any new vendors? any expiring assessments?) | Risk person | 15 min | | Metrics collection for monthly report | Governance person | 20 min | | Improvement backlog review | Everyone | 20 min | ### Quarterly (half day) | Activity | Who | Duration | |----------|-----|----------| | Executive risk brief preparation | CISO | 1 hour | | Control evidence refresh (pick 2-3 control families) | Governance + Engineering | 1 hour | | Access review (sample of privileged accounts) | Identity person | 1 hour | | Policy/standards review (any changes needed?) | Governance | 30 min | | Lessons learned from incidents or near-misses | Everyone | 30 min | ### Semi-Annual (1 day) | Activity | Who | Duration | |----------|-----|----------| | Full access review | Identity person + system owners | 3 hours | | Backup restore test (pick 2 critical systems) | Engineering person | 2 hours | | Tabletop exercise (pick 1 scenario) | Everyone | 2 hours | | Policy review and update | Governance | 1 hour | ### Annual (2-3 days) | Activity | Who | Duration | |----------|-----|----------| | Full maturity self-assessment (optional for small teams) | Governance | 2 hours | | Risk appetite calibration | CISO + executive sponsor | 1 hour | | Full policy/standards review cycle | Governance | 4 hours | | Annual report to executive leadership | CISO | 2 hours | | Budget and resource planning | CISO | 2 hours | | Team training and development planning | Everyone | 1 hour | --- ## 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. | Person | Canonical Roles Consolidated | Primary Family | |--------|------------------------------|----------------| | **Person 1 — CISO / Governance Lead** | CISO, Governance Pillar Leader, Policy & Standards Manager, Risk Register Owner, Evidence Librarian | JF-EXEC / JF-GOVCOMP | | **Person 2 — Risk Lead** | Risk Pillar Leader, Exposure Management Lead, Threat Intelligence Analyst, Detection Engineer, Vendor Risk Analyst | JF-RISKOPS | | **Person 3 — Engineering Lead** | Engineering Pillar Leader, Cloud Security Engineer, Identity Engineer, Endpoint Engineer | JF-SECENG | | **Person 4 — Security Engineer** | Application Security Engineer, Cryptography Engineer, OT Security Engineer (if applicable), Pre-production Reviewer | JF-SECENG | | **Person 5 — Compliance / IR Liaison** | NERC-CIP Compliance Manager, CMMC/Federal Compliance Manager, SOX ITGC Lead, IR liaison (Incident Commander and Lead Investigator remain with standing IR team) | JF-GOVCOMP / JF-ADJUNCT | **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: | Person | Canonical Roles | Email | |--------|----------------|-------| | Jane Smith | CISO, Governance Pillar Leader | jane@example.com | | Alex Chen | Risk Pillar Leader, Exposure Management Lead, Threat Intel | alex@example.com | ### 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. | Asset | Type | Owner | Classification | Criticality | In Scope? | |-------|------|-------|---------------|-------------|-----------| | ExampleApp | SaaS | Jane Smith | Internal | High | Yes | 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. | Risk ID | Risk Statement | Inherent | Residual | Owner | Treatment | Due | |---------|---------------|----------|----------|-------|-----------|-----| | RISK-2026-001 | Unpatched internet-facing systems could enable ransomware | High | Medium | Alex Chen | Remediate — patch cycle | 2026-07-15 | ### Record 5: Exposure Backlog Export your vulnerability scanner results. Prioritize by severity and asset criticality. Assign the top 20 to owners. | Finding ID | CVE/ID | Severity | Asset | Owner | Due | |-----------|--------|----------|-------|-------|-----| | FIND-2026-001 | CVE-2026-12345 | Critical | ExampleApp | Alex Chen | 2026-06-13 | ### Record 6: Exception Register (starts empty) Create the structure. It will populate as you find things you cannot fix on schedule. | Exception ID | Control | Rationale | Compensating Controls | Approver | Expires | |-------------|---------|-----------|----------------------|----------|---------| ### Record 7: Evidence Index Create the folder structure (see §8). Add one entry for each piece of evidence you already have. | Evidence ID | Control | Description | Date | Source | Stored At | |------------|---------|-------------|------|--------|-----------| ### 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. | Control ID | Status | Evidence? | Notes | |-----------|--------|-----------|-------| | AC-2 | Partially Implemented | JML log collected | Access review not yet performed | | IA-2 | Implemented | MFA enforced via IdP policy | Evidence: IdP config export 2026-06-01 | ### Record 9: Regulatory Applicability Decision For each regulatory framework referenced in CERG, decide: Applicable? Deferred? Not applicable? | Framework | Applies? | Decision | Rationale | |-----------|---------|----------|-----------| | NERC-CIP | No | Not applicable | Not a registered entity | | CMMC | Yes | Deferred | Will adopt CUI package in Q3 | | SOX | Yes | Applicable | Public company — ITGC scope defined | ### Record 10: 30-Day Improvement Backlog Five things you will fix in the first 30 days. Be specific. | ID | Action | Owner | Due | |----|--------|-------|-----| | IMP-001 | Complete asset inventory for cloud environments | Engineering Lead | 2026-07-11 | | IMP-002 | Run first access review for privileged accounts | Identity person | 2026-07-11 | --- ## 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 | Column | Example | Notes | |--------|---------|-------| | Risk ID | RISK-2026-001 | Use the format RISK-YYYY-NNN | | Risk Statement | Unpatched internet-facing systems... | FAIR-aligned: threat actor, action, asset, effect, impact | | Inherent Likelihood | 4 | 1-5 scale per RMF-001 | | Inherent Impact | 4 | 1-5 scale per RMF-001 | | Inherent Score | 16 | Likelihood × Impact | | Residual Likelihood | 2 | After treatment | | Residual Impact | 3 | After treatment | | Residual Score | 6 | Residual Likelihood × Impact | | Severity | Medium | Per RMF-001 §9.5 bands | | Treatment Strategy | Mitigate | Avoid / Mitigate / Transfer / Accept | | Treatment Plan | Implement WAF by Q3 | Specific, actionable | | Business Owner | Jane Smith | Must be outside security | | Risk Owner (Security) | Alex Chen | Security point of contact | | Date Identified | 2026-06-15 | | | Treatment Due | 2026-09-15 | | | Status | In Treatment | New / In Treatment / Accepted / Closed | | Last Reviewed | 2026-07-01 | | | Next Review | 2026-08-01 | | ### Exception Register Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Exception ID | EXC-2026-001 | Format EXC-YYYY-NNN | | Control ID | AC-2 | From CB-001 | | Requirement | Quarterly access review for all systems | What is not being met | | Affected Assets | ExampleApp, ExampleDB | | | Business Justification | Access review tool not yet deployed | Why the exception is needed | | Compensating Controls | Manual review of privileged accounts monthly | What is in place instead | | Residual Risk | Medium | | | Business Owner | Jane Smith | | | Approver | CISO | | | Approval Date | 2026-06-15 | | | Expiration Date | 2026-09-15 | | | Monitoring Cadence | Monthly | | | Status | Active | Active / Expired / Closed | ### Evidence Index Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Evidence ID | EVD-2026-001 | Format EVD-YYYY-NNN | | Control ID | AC-2 | From CB-001 | | Control Name | Account Management | | | Evidence Description | JML log export for June 2026 | What the evidence shows | | Evidence Tier | E2 | E1/E2/E3 per FLOW-001 §17 | | Source System | Azure AD / HRIS feed | Where the evidence came from | | Generated Date | 2026-06-30 | When the evidence was produced | | Collected Date | 2026-07-01 | When it was added to the library | | Collection Method | Automated export | How it was obtained | | Period Covered | June 2026 | What time period the evidence covers | | Stored At | /evidence/02-access/jml-2026-06.csv | File path or URL | | Retention | 3 years | | | Expiration/Freshness | Refresh monthly | When this evidence becomes stale | | Quality Status | Accepted | Pending / Accepted / Rejected / Stale | | Reviewed By | Governance Lead | | ### Exposure Backlog Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Finding ID | FIND-2026-001 | Format FIND-YYYY-NNN | | CVE / ID | CVE-2026-12345 | | | CVSS Score | 9.8 | | | KEV Listed? | No | Check CISA KEV catalog | | Severity | Critical | Critical / High / Medium / Low | | Asset | ExampleApp (public-facing) | | | Asset Tier | Tier 1 | Per criticality model | | Exploitability | Network-exploitable, no auth required | | | Discovered Date | 2026-06-15 | | | Triage Date | 2026-06-15 | | | Triage SLA Met? | Yes | | | Assigned To | Alex Chen | | | Treatment | Patch to version 2.4.1 | | | Due Date | 2026-06-17 | Critical = 48 hours | | Closure Date | | | | Validation Method | Authenticated re-scan | | | Validated By | | | | SLA Met? | | | | Status | In Remediation | | ### Asset Inventory Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Asset ID | AST-001 | | | Asset Name | ExampleApp | | | Asset Type | SaaS Application | | | Asset Class | Persistent | Persistent / Dynamic / Ephemeral | | Environment | Production | | | Business Owner | Jane Smith | | | Technical Owner | Engineering Lead | | | Data Classification | Internal | | | Regulatory Scope | SOX | | | Criticality | High | | | Internet-Exposed? | Yes | | | Scan Coverage | Yes — Tenable scan configured | | | Logging Source | Yes — Splunk integration | | | Backup Required? | Yes — vendor-managed | | | Access Review Required? | Yes — quarterly | | | Status | Fully Covered | | ### Vendor Inventory Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Vendor ID | VEN-001 | | | Vendor Name | ExampleVendor Inc. | | | Service Provided | Cloud hosting | | | Data Accessed | Customer PII | | | Data Classification | Confidential | | | Criticality | High | | | Risk Rating | Medium | | | SOC 2 Available? | Yes — expires 2026-09 | | | Contractual Security Requirements | MFA, encryption, incident notification 24h | | | Last Assessment Date | 2026-03-15 | | | Next Assessment Due | 2026-09-15 | | | Business Owner | Jane Smith | | | Status | Active | | ### Decision Log Spreadsheet | Column | Example | Notes | |--------|---------|-------| | Decision ID | DEC-2026-001 | | | Date | 2026-06-15 | | | Decision | Defer ISO 27001 package | One sentence | | Rationale | Not pursuing ISO certification | | | Alternatives Considered | Adopt anyway — rejected | | | Risk Created | Future ISO pursuit requires backfill | | | Documents Affected | CAT-001, IMP-001 | | | Approver | CISO | | | Review Date | 2027-06-15 | | --- ## 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 | Field | Value | |---|---| | **Document ID** | CERG-GOV-IMP-003 | | **Version** | 1.02 | | **Status** | Approved | | **Effective Date** | 2026-06-14 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | Small-team CERG adopters (≤8 people) | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.02 | 2026-06-18 | Governance Pillar Leader | Added authority guardrail requiring independent Business Owner or Executive Sponsor acknowledgement for accepted residual risk in small-team role consolidations. | | 1.01 | 2026-06-14 | Governance Pillar Leader | Aligned the CERG Lite package to the eight-document MVC and separated adoption aids from immediate requirements. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. CERG Lite package, reduced operating rhythm for 5-person teams, role consolidation map, first 10 records, first month criteria, spreadsheet schemas for 7 record types, minimum viable evidence library structure. | ### Review Triggers - Feedback from small-team adopters - Change to the canonical role roster - Change to the control baseline - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | How to adapt CERG | | Adoption Safety Guide | [`CERG-GOV-IMP-002`](CERG-GOV-IMP-002_Adoption_Safety_Guide.md) | Prerequisites and safety rules | | Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical roles and scaling map | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk scoring and treatment | | Cross-Pillar Operational Flows | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Evidence tiers and automation | --- ## ADOPTION DECISION TREE AND DEPENDENCY MATRIX ### Scope Selection · Safe Tailoring · Required Companion Artifacts --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-005 | | **Version** | 1.02 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly / Upon adoption path or catalog change | | **Frameworks** | NIST CSF 2.0 (GOVERN) | | **Regulations** | NERC-CIP · CMMC L2 · SOX ITGC · ISO/IEC 27001 | | **Environments** | All CERG adoption paths | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Adoption Decision Tree](#2-adoption-decision-tree) 3. [Safe Tailoring Rules](#3-safe-tailoring-rules) 4. [Dependency Matrix](#4-dependency-matrix) 5. [Required, Conditional, Recommended, and Example Labels](#5-required-conditional-recommended-and-example-labels) 6. [Adoption Gates](#6-adoption-gates) 7. [Document Control](#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: | Question | If no | |---|---| | Is there a named person accountable for security? | Do not adopt CERG yet. Establish ownership first. | | Does leadership support guardrails, decisions, and evidence, not only tooling? | Use NIST CSF or CIS Controls until sponsorship exists. | | Can the organization name its systems, business units, and regulators? | Complete basic scoping before adopting documents. | | Will the organization track versions, decisions, records, and evidence? | CERG will become shelfware. Fix evidence discipline first. | If all answers are yes, continue. ### 2.2 Path selection ```text 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 | Question | If yes, add | |---|---| | Do you handle CUI or FCI for federal contracts? | CUI standard, CUI/CMMC operational package, SSP, POA&M, CUI evidence matrix | | Are you subject to NERC-CIP or responsible for BES Cyber Systems? | OT standard, NERC-CIP operational package, access, logging, segmentation, recovery evidence | | Are systems in scope for SOX financial reporting? | SOX ITGC operational package, access/change/evidence procedures, SOX system register | | Are you pursuing ISO/IEC 27001 certification or readiness? | ISO operational package, ISMS scope, statement of applicability support, management review records | | Do privacy or data protection obligations apply? | Data governance standard, privacy operational package, security support records | | Do you build or operate customer-facing software? | Secure SDLC standard, threat modeling procedure, architecture intake, vulnerability disclosure considerations | | Do you operate OT but not NERC-CIP? | OT standard, network segmentation standard, incident/recovery plan, OT-safe evidence and testing | | Do you use AI tools, AI-enabled SaaS, or build AI features? | AI security standard, data governance standard, vendor risk assessment updates, AI intake template, sanctioned AI tools register, AI system/model register where built or embedded AI exists | --- ## 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 | If adopting | Also adopt | Why | |---|---|---| | Cybersecurity Policy | Framework, Operating Model | Policy needs an operating structure. | | CERG Framework | Operating Model, RMF | The conceptual model needs roles and risk mechanics. | | Operating Model | RACI Instrument, Cross-Pillar Flows | Roles need decision rights and handoffs. | | RMF | Risk Register Procedure, Risk Register Templates | Risk model needs executable records. | | Unified Control Baseline | Evidence Quality Standard, Control-to-Procedure Traceability Matrix | Controls need evidence and procedures. | | Metrics and Reporting | Record Catalog, Evidence Quality Standard | Metrics must be reproducible from records. | | Maturity Assessment | Program Improvement Register | Gaps must become owned improvement work. | ### 4.2 Procedure dependencies | If adopting | Also adopt | Why | |---|---|---| | Exposure Management Procedure | Asset Standard, RMF, Risk Register Procedure | Findings need assets, scoring, ownership, treatment, and exceptions. | | Architecture Review Procedure | Architecture Intake Template, Threat Modeling Procedure, Flow F-02 | Reviews need intake data, threat reasoning, and disposition records. | | Third-Party Risk Procedure | Vendor Questionnaire, Edge Register, Data Governance Standard | Vendor risk depends on data, access, external control, and assessment evidence. | | Security Change Management Procedure | Configuration Standard, Architecture Review Procedure | Changes need baseline impact and review routing. | | Audit and Evidence Procedure | Evidence Quality Standard, Control Baseline, Record Catalog | Audit response needs evidence criteria, control mapping, and source records. | | Lessons Learned Procedure | Program Improvement Register, Incident Response Plan | Lessons must become tracked improvements. | | Threat Intelligence Procedure | Logging and Detection Standard, Adversarial Validation Procedure | Intelligence should drive detection and validation priorities. | | Threat Modeling Procedure | Architecture Review Procedure, Secure SDLC Standard | Threat modeling needs project context and design-stage action. | ### 4.3 Standard dependencies | If adopting | Also adopt | Why | |---|---|---| | Access Standard | Access Runbook, Evidence Quality Standard, Metrics | Access controls require operational review and evidence. | | Asset Standard | Asset Coverage flow, Exposure Management Procedure | Asset data feeds scanning, logging, backup, and ownership. | | IT / Cloud / SaaS Standard | Architecture Review, TPRM, Access, Logging, Configuration | Cloud/SaaS risk crosses identity, vendor, logging, and baseline control. | | OT Standard | NERC-CIP package if applicable, Network, Access, Logging, Resilience | OT security depends on segmentation, privileged access, visibility, and recovery. | | CUI Standard | CUI Operational Package, SSP, POA&M, Access, Configuration, Logging | CUI compliance requires boundary, control, and remediation evidence. | | Logging and Detection Standard | Threat Intelligence, Adversarial Validation, Incident Response | Detection must be threat-informed, tested, and usable in response. | | Secure SDLC Standard | Architecture Review, Threat Modeling, Exposure Management | Application security requires design, build, test, and finding workflows. | | AI Security Standard | Data Governance, TPRM, Secure SDLC, Access, AI Intake, Sanctioned AI Tools Register, AI System/Model Register where applicable | AI risk includes data, vendor features, product development, privilege, sanctioned-use decisions, and model inventory. | | Resilience and Backup Standard | BCDR Plan, Incident Response Plan, Asset Coverage | Recovery controls need scope, tests, and incident integration. | ### 4.4 Regulated package dependencies | If adopting | Also adopt | Why | |---|---|---| | CUI / CMMC Package | CUI Standard, SSP, POA&M, Evidence Quality, Access, Asset, Config, Logging | Assessment readiness requires system boundary, controls, gaps, and evidence. | | NERC-CIP Package | OT Standard, Access, Logging, Network, Incident, Recovery | CIP evidence depends on OT control operation and documented records. | | SOX ITGC Package | Access, Change, Evidence, Asset/System Register | SOX control testing needs population, access/change records, and evidence. | | ISO Package | Control Baseline, Metrics, Maturity, Evidence, Improvement | ISMS operation requires scope, controls, monitoring, management review, and improvement. | | Privacy Package | Data Governance, TPRM, Access, Incident Response | Privacy support depends on data classification, vendors, access, and incident coordination. | --- ## 5. Required, Conditional, Recommended, and Example Labels CERG adopters should label adopted artifacts in their local catalog using these values. | Label | Meaning | |---|---| | Required-Core | Required for every CERG implementation. | | Required-Path | Required for the selected adoption path. | | Conditional-Regulatory | Required only when a regulator, contract, or certification applies. | | Conditional-Environment | Required only when the environment exists, such as OT, cloud, SaaS, or AI. | | Recommended | Useful but deferrable without breaking the operating model. | | Example | Illustrative only. Not a requirement until adopted locally. | | Deferred | Not currently adopted. Deferral rationale must be recorded. | | Not Applicable | Does not apply to the organization. Basis must be recorded. | ### 5.1 Preliminary default labels | Artifact group | Default label | |---|---| | Policy, Framework, Operating Model, RMF, Catalog, Risk Register, Exposure Management | Required-Core | | Record Catalog, Framework System Map, Role-Based Checklists, Decision Tree | Recommended for all, Required-Path for first adoption projects | | Access, Asset, Configuration, IT/Cloud where applicable, Logging, Resilience | Required-Path for Standard and Regulated | | Cryptography and Key Management | Recommended for Standard; Required-Path where managed keys, certificates, encryption controls, CUI, OT, SOX, or other regulated scope applies | | OT, CUI, SOX, ISO, Privacy packages | Conditional-Regulatory or Conditional-Environment | | AI standard and AI operational templates | Conditional-Environment when AI tools, AI-enabled SaaS, embedded AI, or built AI exists | | Workforce architecture documents | Recommended for Standard, Required-Path for large teams or formal hiring model | | Example profiles | Example | --- ## 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`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), 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: | **Condition** | **Minimum Evidence** | |---|---| | Risk cadence is real | Two completed risk register reviews, or three where monthly cadence is already established. | | Exposure cadence is measurable | Two exposure or vulnerability cycles with SLA performance, backlog trend, and exception handling visible. | | Intake path works | One architecture or project intake disposition, or a tabletop disposition if no qualifying project occurred. | | Evidence can be found | Evidence index links the MVC records needed to explain risk, exposure, ownership, decisions, and exceptions. | | Pillars are operating | Engineering, Risk, and Governance have each produced at least one record or decision in their accountability area. | | Adoption plan exists | Standard-layer adoption plan identifies which core standards, procedures, and overlays are next, with owners and target dates. | 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 | | | |---|---| | **Document ID** | CERG-GOV-IMP-005 | | **Version** | 1.02 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Governance Pillar Leader | | **Next Review** | Quarterly / Upon adoption path or catalog change | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.02 | 2026-06-17 | Governance Pillar Leader | Added AI operational templates and registers to adoption selector, dependency matrix, and default labels. | | 1.01 | 2026-06-14 | Governance Pillar Leader | Aligned Lite path sizing and core-standard labels with README, START-HERE, IMP-001, and IMP-003. | | 1.0 | 2026-06-13 | Governance Pillar Leader | Initial publication. Adds adoption decision tree, safe tailoring rules, dependency matrix, artifact labels, and adoption gates. | ### 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](../START-HERE.md) - First 48 hours guide - [CERG-GOV-IMP-001](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) - Implementation and Adaptation Guide - [CERG-GOV-IMP-002](CERG-GOV-IMP-002_Adoption_Safety_Guide.md) - Adoption Safety Guide - [CERG-GOV-IMP-003](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) - Small Team Adoption Path - [CERG-GOV-VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) - Organization Adaptation Profile - [CERG-GOV-CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) - Record Catalog - [CERG-STD-AI-001](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard - [CERG-TMPL-AI-001](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) - AI Intake and Sanctioning Template - [CERG-TMPL-AI-002](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) - Sanctioned AI Tools Register Template - [CERG-TMPL-AI-003](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) - AI System and Model Register Template --- ## IMPLEMENTATION AND ADAPTATION GUIDE ### The On-Ramp: Fork, Adapt, Run · Talent Brand · Interview Guide --- > **Not Legal or Regulatory Advice.** CERG provides a framework and sample operating artifacts. It does not determine legal obligations, registered-entity status, contract scope, or certification readiness. Organizations must validate regulatory applicability with qualified counsel, compliance leadership, and assessors. References to NERC-CIP, CMMC, SOX, ISO 27001, and privacy regulations are for integration mapping — they do not constitute compliance claims. | | | |---|---| | **Document ID** | CERG-GOV-IMP-001 | | **Version** | 1.11 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) · [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | | **Review Cycle** | Annual / On any change to the V1 library | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Before You Start](#2-before-you-start) 3. [The Adoption Model](#3-the-adoption-model) 4. [Minimum Viable CERG](#4-minimum-viable-cerg) 5. [The 30/60/90-Day Rollout](#5-the-306090-day-rollout) 6. [Scaling the Model: 5 People to 60](#6-scaling-the-model-5-people-to-60) 7. [Adapting the Documents](#7-adapting-the-documents) 8. [First-Adoption Sign-Off Workflow](#8-first-adoption-sign-off-workflow) 9. [Common Adoption Pitfalls](#9-common-adoption-pitfalls) 10. [Employer Brand and Talent Attraction](#10-employer-brand-and-talent-attraction) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope CERG is a cybersecurity operating model starter kit — the spine, artifacts, workflows, and evidence model to run a program. What it has needed is a clear on-ramp: a single document that tells an organization which has just forked the repository what to do on Monday morning. This is that document. It is the first thing a new adopter should read after the [README](../README.md) and the [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) framework narrative. It applies to any organization adopting CERG, whether that organization is standing up a security function for the first time, replacing a pile of disconnected policies, or formalizing a program that has run on tribal knowledge. It does not assume a large team, a big budget, or an existing document library. > **What This Guide Is Not** > > This is not a maturity model and it is not a control catalog. The maturity self-assessment is [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md); the control set is [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md). This guide is the sequencing layer that tells you the order to do things in. Read it once, then keep it open during the first 90 days. --- ## 2. Before You Start CERG adoption needs four things in place. None of them is a tool or a budget line. | **Prerequisite** | **Why It Matters** | **Minimum Bar** | |---|---|---| | A named accountable owner | Someone has to own the program. Ambiguous ownership is the failure mode CERG exists to fix. | One person carries the **Chief Information Security Officer (CISO)** role, even part-time, even if the title is informal. | | Executive endorsement | The "yes, and..." operating model only works if leadership backs the guardrails. | One **Executive Sponsor** who will sign the adopted Cybersecurity Policy. | | A content repository | CERG is Markdown. It needs a home where versions are tracked. | A Git repository, a wiki with history, or a controlled document store. | | Honest scope | You cannot protect what you have not named. | A rough list of systems, business units, and regulators in scope. | If any of the four is missing, fix that first. Adopting the documents on top of an absent owner or an absent repository produces a library, not a program. > **The Owner Comes First** > > The most common adoption failure is treating CERG as a documentation exercise. It is not. Before a single file is edited, one person must hold the CISO role and one Executive Sponsor must agree to endorse the policy. Everything else in this guide assumes those two seats are filled. --- ## 3. The Adoption Model CERG adoption has three moves. They are deliberately simple. ### 3.1 Fork Take a copy of the entire V1 library. Do not cherry-pick individual files on day one. The documents are interconnected; a standard cites a procedure, a procedure cites the operating model, the operating model cites the policy. A partial fork breaks cross-references and produces exactly the fragmentation CERG was built to remove. Fork the whole thing. Decide what to defer later, in the open, as a recorded decision. ### 3.2 Adapt Adaptation is mechanical, not creative. Every place the documents name an organization, a headcount, a regulator, or an example is a variable. [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) defines the full token scheme and ships a render tool that turns the generic corpus into an organization-specific one. Use it. Do not hand-edit 28 documents. What you do change by hand is judgment: which optional standards apply, which regulators are in scope, where the team structure consolidates. Section 6 and Section 7 cover both. ### 3.3 Run A program runs when work is happening on the cadence the documents describe: intake reviews, risk register updates, vulnerability SLAs, metrics reporting. Adoption is complete not when the files are edited but when the first cycle of that cadence has been completed and reported. Section 5 sequences the first cycle. > **One Source, Many Exports** > > The authoritative copy of every adopted CERG document is the Markdown file in your repository. Word exports, PDF deliverables, intranet pages, and regulator uploads are exports. This rule is inherited from [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) and it matters from day one. If you start editing a Word copy, you have already lost version control. --- ## 4. Minimum Viable CERG You do not adopt 28 documents in week one. You adopt the spine first. Minimum Viable CERG (MVC) is the smallest set of artifacts that constitutes a real program. Everything else is layered on after. ### 4.1 The MVC Set | **Order** | **Artifact** | **ID** | **Why It Is in the Spine** | |---|---|---|---| | 1 | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | The durable principles everything else hangs from. Nothing is authoritative until this is signed. | | 2 | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Explains the three-pillar model the rest of the library assumes. | | 3 | Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines pillars, decision rights, and the canonical role roster. | | 4 | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Your authoritative inventory. Update it as you adopt. | | 5 | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | How risk is identified, scored, treated, and accepted. | | 6 | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | The first procedure that produces running work. | | 7 | Risk Register Templates | [`CERG-TMPL-RM-001`](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | The fill-in artifact that makes the register real. | | 8 | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | The second source of running work, and the one auditors look for first. | Eight artifacts. A policy, three governance instruments, a framework, two procedures, and a template. That is a program. It has an owner, a way to record risk, and a way to drive remediation. ### 4.2 What MVC Deliberately Defers The standards (Access Management, Logging, Cryptography, and the rest), the operational packages (NERC-CIP, CUI/CMMC, SOX), and the remaining procedures are layered in after the spine runs one full cycle. They are not optional in the long run. They are sequenced. > **Resist the Big-Bang Adoption** > > The temptation is to adapt all 28 documents, approve them in one meeting, and announce the program. That adoption never runs. The team drowns in review and the cadence never starts. Adopt the eight-artifact spine, run it for 30 days, prove the cadence works, then layer. A small program that runs beats a complete program that sits. --- ## 5. The 30/60/90-Day Rollout This is the sequence for a first adoption. Dates are guidance; the order is not. ### 5.1 Days 1 to 30: Stand Up the Spine | **Step** | **Action** | **Lead Role** | |---|---|---| | 1 | Fork the full V1 library into your content repository. | Governance Pillar Leader | | 2 | Build the organization profile and run the render tool per [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md). | Policy & Standards Manager | | 3 | Review and adapt the eight MVC artifacts (Section 4.1). | Governance Pillar Leader | | 4 | Baseline current maturity using [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md). | CISO | | 5 | CISO signs the Cybersecurity Policy; Executive Sponsor endorses. | CISO | | 6 | Stand up the risk register; load known risks from the maturity baseline. | Risk Register Owner | | 7 | Run the first Monthly Risk Register Review. | Risk Register Owner | By day 30 the program has a signed policy, a populated risk register, a maturity baseline, and one completed review cycle. That is the floor. ### 5.2 Days 31 to 60: Add the Operating Layer | **Step** | **Action** | **Lead Role** | |---|---|---| | 8 | Adopt the standards that match your environment (Section 7.2). | Governance Pillar Leader | | 9 | Adopt the Architecture Review and Project Intake Procedure [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | Engineering Pillar Leader | | 10 | Stand up exposure management against [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) SLAs. | Exposure Management Lead | | 11 | Adopt the Access Management Standard [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) and its runbook [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md). | Identity Engineer | | 12 | Route the first real project through architecture review. | Engineering Pillar Leader | ### 5.3 Days 61 to 90: Close the Loop | **Step** | **Action** | **Lead Role** | |---|---|---| | 13 | Adopt [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md); publish the first CISO dashboard. | Governance Pillar Leader | | 14 | Adopt the operational package for each regulator in scope (Section 7.3). | Governance Pillar Leader | | 15 | Adopt remaining procedures: third-party risk, adversarial validation. | Risk Pillar Leader | | 16 | Run the first Quarterly Cyber Oversight Group brief. | CISO | | 17 | Re-run [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md); compare to the day-1 baseline. | CISO | By day 90 every pillar is producing work, the CISO is reporting on a cadence, and the maturity score has moved. That is a running program. > **The 90-Day Test** > > At day 90, ask one question: if an auditor walked in, could you show them a signed policy, a current risk register, vulnerability SLAs being met, and a CISO report with a trend line? If yes, CERG is running. If no, find the step that did not happen and finish it before adopting anything new. > **Gate 2→3 Transition Criteria** > > Day-90 readiness is a necessary condition for full adoption but not sufficient. Before layering on standards, operational packages, and remaining procedures, the organization should demonstrate stable operating cadence defined in [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) §6 Gate 2→3 Transition Test: consistent risk register reviews, measurable vulnerability SLA performance, at least one completed architecture or project intake disposition, and a standard-layer adoption plan with owners and target dates. --- ## 6. Scaling the Model: 5 People to 60 The README promises a five-person team runs the same model as a sixty-person team. This section shows how. The mechanism is role consolidation, not document deletion. ### 6.1 The Principle The canonical role roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 lists every role CERG names. A small team does not delete roles. It assigns several roles to one person. The documents do not change; the **assignment map** changes. One person can hold the CISO role, the Governance Pillar Leader role, and the Risk Register Owner role at once. The work of each role still happens; it happens in one head. > **Consolidate Roles, Never Delete Them** > > When a role is deleted, the work it owned silently stops. When a role is consolidated onto a person already carrying three others, the work is still owned, still visible, and still re-assignable the day a fourth person is hired. Always consolidate. The role roster is fixed; only the assignment map scales. ### 6.2 Reference Assignment Maps These are starting points, not mandates. Adjust to the skills you actually have. **Five-person team.** Every person carries a pillar plus shared duties. | **Person** | **Holds These Canonical Roles** | |---|---| | 1 | CISO; Executive Sponsor liaison | | 2 | Governance Pillar Leader; Policy & Standards Manager; Risk Register Owner; Evidence Librarian | | 3 | Risk Pillar Leader; Exposure Management Lead; Threat Intelligence Analyst | | 4 | Engineering Pillar Leader; Cloud Security Engineer; Identity Engineer; Pre-production Reviewer | | 5 | Application Security Engineer; Endpoint Engineer; Cryptography Engineer; Detection Engineer | **Fifteen-person team.** Pillar leaders are dedicated; senior practitioners own a domain each; the rest are individual contributors. Compliance manager roles are assigned only for regulators in scope. **Sixty-person team.** The full roster maps roughly one role to one person, with sub-role domain qualifiers (for example, Engineering Pillar Leader - Cloud and Engineering Pillar Leader - OT) split out as described in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. ### 6.3 What Does Not Scale Down Two things hold regardless of headcount. 1. **Separation of approval authority.** The person who accepts a risk cannot be the only person who assessed it. Even on a five-person team, risk acceptance follows the authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. If one person genuinely holds every role, the Executive Sponsor provides the second set of eyes on High and Critical acceptance. 2. **The cadence.** A five-person team still runs the Monthly Risk Register Review and the Quarterly Cyber Oversight Group brief. The meetings are shorter. They are not skipped. --- ## 7. Adapting the Documents ### 7.1 Mechanical Adaptation Names, headcounts, regulators, and illustrative examples are variables. They are adapted with the token scheme and render tool defined in [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md). Do not hand-edit. Build the organization profile once, render the corpus, review the output. ### 7.2 Choosing Standards Adopt every standard whose environment you operate. Skip none that apply. | **Standard** | **ID** | **Adopt If** | |---|---|---| | IT / Cloud / SaaS Security | [`CERG-STD-IT-001`](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | You run any cloud or SaaS. Nearly everyone. | | Grid Control Systems Security | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | You operate operational technology or industrial control systems. | | CUI Handling | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | You handle Controlled Unclassified Information or pursue CMMC. | | Access Management | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Required-Path for Standard and Regulated. Every organization has identities. | | Asset Management and Inventory | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Required-Path for Standard and Regulated. Exposure management and evidence depend on owned assets. | | Secure Configuration Baseline | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Required-Path for Standard and Regulated. Every organization has systems to harden. | | Logging, Monitoring, and Detection | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Required-Path for Standard and Regulated. | | Cyber Resilience and Backup | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Required-Path for Standard and Regulated. | | Cryptography and Key Management | [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Recommended for Standard; required where managed keys, certificates, encryption controls, CUI, OT, SOX, or other regulated scope applies. | If you defer an applicable standard, record the decision and a target adoption date in the risk register. A deferred applicable standard is an accepted risk, not a silent gap. ### 7.3 Choosing Operational Packages Operational packages are adopted per regulator. Adopt only what applies to you. | **Package** | **ID** | **Adopt If** | |---|---|---| | NERC-CIP | [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | You are a registered entity under NERC-CIP. | | CUI / CMMC | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | You are pursuing CMMC certification. | | SOX ITGC | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | You are a public company subject to SOX. | | Incident Response Plan | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Ensure a standing IR plan exists for every implementation. This plan is owned by the standing IR team, not by CERG; see [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4. | ### 7.4 Keep the Catalog Honest Every adoption decision updates your copy of [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md). An artifact you adopted is `Approved` in your catalog. An artifact you deferred is `Planned`. The catalog is the one place anyone can see what your program actually consists of. Letting it drift is the first sign the program is becoming a library again. --- ## 8. First-Adoption Sign-Off Workflow A first adoption is approved once, as a package. After that, individual documents follow the per-type approval authority in [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) §4. | **Step** | **What Happens** | **Authority** | |---|---|---| | 1 | Governance Pillar Leader confirms the MVC spine is adapted and the render output reviewed. | Governance Pillar Leader | | 2 | Each pillar leader confirms the artifacts assigned to their pillar are accurate for the organization. | Engineering / Risk / Governance Pillar Leaders | | 3 | CISO reviews the maturity baseline and the adoption scope, including every deferred artifact. | CISO | | 4 | CISO approves the Cybersecurity Policy. Executive Sponsor endorses it. | CISO; Executive Sponsor | | 5 | Governance Pillar Leader records the adoption in the catalog revision history and sets each artifact status. | Governance Pillar Leader | The adoption is complete when step 5 is recorded. Not before. --- ## 9. Common Adoption Pitfalls | **Pitfall** | **Why It Happens** | **The Fix** | |---|---|---| | Big-bang adoption | The library looks complete, so the team tries to approve all of it at once. | Adopt the MVC spine. Layer the rest. Section 4. | | Editing exports | Someone opens a Word copy and edits it. | The Markdown source is authoritative. Exports are downstream. Section 3.3. | | Inventing roles | The team writes a role name that feels natural instead of using the roster. | Use only canonical roles from [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. Consolidate, never invent. | | Deleting roles to "fit" a small team | The roster looks too big for five people. | Consolidate roles onto people. The roster is fixed. Section 6.1. | | Skipping the cadence | The reviews feel like overhead before the program is "ready." | The cadence is the program. A short review is still a review. Section 6.3. | | Silent gaps | A standard is deferred and never recorded. | Every deferral is a risk register entry with a target date. Section 7.2. | | Catalog drift | The catalog is not updated as documents are adopted. | The catalog is updated at sign-off and on every later change. Section 7.4. | | Treating CERG as documentation | Files get adapted; no work starts. | Adoption completes when the first cadence cycle is reported, not when files are edited. Section 3.3. | --- ## 10. Employer Brand and Talent Attraction ### 10.1 The Talent Problem CERG Solves The cybersecurity talent market is brutal. Organizations that cannot articulate why someone should work there lose candidates to organizations that can. CERG's structure is a genuine differentiator. Most candidates have never heard of it. The organization's job is to make them hear it and want it. CERG's employee value proposition is not "competitive salary and benefits." Every organization says that. CERG's EVP is that a CERG-structured team is a better place to practice cybersecurity than a traditionally structured team. This section articulates why, provides role-specific candidate messaging, and includes a structured interview guide aligned to the competency model. ### 10.2 The CERG Employee Value Proposition Working in a CERG-structured team means: **You are a generalist who specializes.** In a traditional security organization, a Cloud Security Engineer reviews architectures and never sees a risk register. A Threat Intelligence Analyst writes threat reports and never touches an architecture diagram. In CERG, the left-right knowledge model means every practitioner understands the full lifecycle. You specialize in your domain, but you are not confined to it. After three years in a CERG Engineering team, you can credibly discuss risk methodology with a Risk practitioner and compliance requirements with a Governance practitioner. That breadth makes you more valuable than a specialist who has done one thing for five years. **You see the impact of your work.** A CERG architect's design decision is visible in the Risk pillar's posture report two quarters later. A CERG threat analyst's intelligence brief drives Engineering's next quarter of control improvements. The pillars are not silos; they are feedback loops. When you do your job well, the other two pillars get better. When they do their jobs well, you get better. The work you do on Tuesday is visible in the organization's security posture on Friday. **Your career path is defined, not discovered.** JA-001 defines exactly what each grade expects across five dimensions. CMP-001 defines the specific behaviors at each level. PERF-001 defines how you are evaluated and promoted. You do not need to guess what it takes to reach the next level or hope your manager advocates for you loudly enough. The path is documented, and the promotion process is designed to be consistent regardless of which manager you report to. **The best idea wins, regardless of who brings it.** CERG's "yes, and" operating philosophy and its three-pillar structure create an environment where a Specialist's well-reasoned finding carries as much weight as a Sr. Advisor's, and a Risk analyst can tell an Engineering director that a control design has a flaw without political consequence. The structure rewards rigor, not rank. Iron sharpens iron. **You are building a program, not running a tool.** Many cybersecurity roles are tool-operating jobs. The organization bought a scanner; you run the scanner. The organization bought a SIEM; you stare at the SIEM. CERG roles are program-building roles. You design how the function works, not just execute it. You improve procedures, author standards, mentor incoming practitioners, and shape the organization's security posture. If you want to be told what to do, CERG is not for you. If you want to define how it is done, CERG is. ### 10.3 Role-Specific Candidate Messaging The EVP above applies to every CERG role. Each role family adds specific messaging for candidates: **Engineering candidates:** "You will not just review architectures; you will own reference architectures. You will not just configure security tools; you will design how the organization secures its cloud, identity, and application platforms. You will work with Risk to understand how your controls perform under attack and with Governance to ensure your designs are audit-ready by design, not retrofit." **Risk candidates:** "You will not just triage alerts; you will shape how the organization understands and responds to its exposure. Your threat assessments will drive Engineering's control priorities. Your risk judgments will inform executive decisions. You will work with Engineering to design controls that address the root cause of findings, not just ticket the symptoms." **Governance candidates:** "You will not just manage evidence binders; you will design the compliance program that makes audit findings rare. You will translate between regulatory language and technical reality, ensuring standards are both compliant and implementable. You will work with Engineering and Risk to build compliance into the operating model, not bolt it on after the fact." ### 10.4 Structured Interview Guide The interview process assesses candidates against the CMP-001 competency domains. The guide below provides question banks for each domain, calibrated to the target grade. Use it to design interview panels that evaluate every candidate against the same dimensions. #### Interview Structure | Round | Focus | Interviewers | Duration | |---|---|---|---| | **Screening** | Role fit, communication, basic domain knowledge | Hiring manager | 30-45 min | | **Technical** | Technical Depth assessment calibrated to target grade | 1-2 senior practitioners from the candidate's pillar | 60-90 min | | **Cross-Pillar** | Cross-Pillar Fluency, Risk Judgment, Communication | 1 practitioner from each of the other two pillars | 60 min | | **Leadership / Final** | Influence, Operational Discipline, Continuous Learning; culture fit | Pillar leader or CISO | 45-60 min | #### Technical Depth Questions by Grade **S1-S2 (Specialist / Sr. Specialist):** - Walk me through a technical problem you solved recently in your domain. What was the problem, how did you diagnose it, what was the solution? - Describe a time you followed a procedure and discovered it needed improvement. What did you change, and why? - [Role-specific technical scenario, e.g., for Cloud Security Engineer: "A development team wants to deploy a new microservice that will store PII. Walk me through your security review."] **S3-S4 (Advisor / Sr. Advisor):** - Describe the hardest technical decision you have influenced in your current or previous role. Who disagreed with you, how did you resolve it, and what was the outcome? - You are evaluating a new technology or platform for organizational adoption. Walk me through your evaluation framework. - A junior team member has made a technical recommendation you believe is wrong. It is not dangerously wrong; it is suboptimal. How do you handle it? #### Cross-Pillar Fluency Questions - Describe a time you worked with a function outside your immediate team to solve a security problem. What made the collaboration effective or difficult? - [For Engineering candidates]: A Risk analyst has rated a finding Critical. You believe compensating controls reduce the actual risk to Medium. Walk me through how you would handle that disagreement. - [For Risk candidates]: An Engineering team tells you they cannot remediate a High finding within your SLA due to architectural constraints. How do you respond? - [For Governance candidates]: An Engineering team tells you a compliance requirement is technically impossible to implement as written. What do you do? #### Risk Judgment Questions - Describe the most significant security risk you have identified that others did not see. Why did they miss it? What did you do about it? - You have limited resources and two findings: a Critical vulnerability in an internet-facing system with compensating controls, and a High vulnerability in an internal system with a known exploitation path. Which do you address first? Why? - Tell me about a time you were wrong about a risk assessment. What did you miss, and what did you change about your approach afterward? #### Communication Questions - Describe a time you had to explain a technical security issue to a non-technical audience. How did you structure your explanation? What was the result? - You are briefing an executive on a material risk. They have five minutes before their next meeting. What do you say? - You have identified a significant security gap that requires budget to address. Write (or describe) the first three paragraphs of the business case you would present. #### Influence and Mentorship Questions - Tell me about someone you mentored or developed. What did they need, what did you do, and where are they now? - Describe a time you changed how your team or organization approached a security problem, without formal authority to mandate the change. - A peer is consistently producing work that is technically correct but poorly documented. Their evidence would not survive an audit. How do you address it? #### Operational Discipline Questions - Walk me through how you manage your work. How do you prioritize, how do you track what is done and what is pending, how do you handle interruptions? - Describe a time you discovered that something you thought was done was not actually done. What had you missed, and what did you change to prevent it from happening again? - How do you ensure your work is defensible under audit or regulatory scrutiny? #### Continuous Learning Questions - What is the last thing you learned about cybersecurity that changed how you think about your work? - What are you currently learning or working on improving? - If you had an annual professional development budget and time to use it, what would you invest in and why? ### 10.5 Candidate Evaluation Rubric Interviewers rate candidates on each assessed dimension using a four-point scale: | Rating | Definition | |---|---| | **Strong Yes** | The candidate's response demonstrates clear, specific evidence of the competency at or above the target grade. I would be confident putting them in front of the organization's stakeholders. | | **Yes** | The candidate demonstrates the competency at the target level. Minor gaps that onboarding will close. | | **No** | The candidate does not demonstrate the competency at the target level. The gap is material and would require significant development to close. | | **Strong No** | The candidate's response raises a red flag: dismissive of process, inability to explain their own work, or concerning judgment. | A "Strong No" from any interviewer on any dimension should trigger a panel discussion before proceeding. A "No" on a dimension that is critical to the role (e.g., Technical Depth for an S3 Engineer, Risk Judgment for an S3 Risk Analyst) should also trigger discussion. ### 10.6 Careers Page Guidance Organizations adopting CERG should consider adding a "Working in Our CERG Team" section to their careers page. The section should: 1. Explain what CERG is in one paragraph (plain language, no jargon) 2. Articulate what makes working in a CERG-structured team different (the EVP from §10.2, adapted for the organization's voice) 3. List the role families (Engineering, Risk, Governance) and what kind of person thrives in each 4. Link to the public CERG Framework so candidates can understand what they are signing up for 5. Include the structured interview process so candidates know what to expect > **The Framework Itself Is the Brand** > > A candidate who reads the CERG Framework, the Job Architecture, the Competency Model, and the job description for their role before they apply has self-selected. They understand the structure, they want to work in it, and they arrive with a mental model of how the organization operates. The careers page does not need to sell CERG. It needs to surface CERG, make it understandable, and let the framework do the selling. --- ## 11. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-IMP-001 | | **Version** | 1.11 | | **Status** | Approved | | **Effective Date** | 2026-06-14 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the V1 library | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.12 | 2026-06-18 | Governance Pillar Leader | Added Gate 2→3 transition criteria reference at §5.3 linking to CERG-GOV-IMP-005 §6 Gate 2→3 Transition Test as prerequisite before standard-layer adoption. | | 1.11 | 2026-06-14 | Governance Pillar Leader | Aligned core-standard guidance with the adoption decision tree and clarified that the IR plan is an adjacent-function requirement, not a CERG-owned package. | | 1.1 | 2026-05-27 | Cyber Governance | Added §10 Employer Brand and Talent Attraction: CERG employee value proposition, role-specific candidate messaging, structured interview guide aligned to CMP-001 competency domains, candidate evaluation rubric, and careers page guidance. Updated supporting documents to reference JA-001, CMP-001, and JD-001. | | 1.0 Draft | 2026-05-21 | Cyber Governance | Initial release. Establishes the adoption model (fork, adapt, run), the Minimum Viable CERG spine, the 30/60/90-day rollout, the role-consolidation approach to scaling, document-adaptation guidance, the first-adoption sign-off workflow, and the adoption pitfalls register. | ### Review Triggers - Any artifact added to or retired from the V1 library - Material change to the canonical role roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Material change to the token scheme in [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) - Adopter feedback indicating a sequencing or scaling gap - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Document Control) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory; adoption updates the catalog | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster used by the scaling guidance | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Narrative framework an adopter reads before this guide | | Organization Adaptation Profile | [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Token scheme and render tool used in mechanical adaptation | | Maturity Self-Assessment and Scorecard | [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Day-1 baseline and day-90 re-measurement | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk acceptance authority cited by the scaling guidance | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | The control set layered in after the MVC spine | --- ## IMPLEMENTATION CARDS ### For Every Security Intent · Minimum Viable to Full Implementation · Who Does What --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-004 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-GOV-CMX-001](CERG-GOV-CMX-001_Compliance_Matrix.md) · [CERG-PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Review Cycle** | Annual / On material change to control baseline | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 · NIST 800-171r3 | | **Regulations** | NERC-CIP · CMMC L2 · SOX ITGC | | **Environments** | All in-scope | --- ## Table of Contents 1. [Intent 1: Know What You Own](#1--know-what-you-own) 2. [Intent 2: Identify and Remediate Vulnerabilities](#2--identify-and-remediate-vulnerabilities) 3. [Intent 3: Enforce Least Privilege](#3--enforce-least-privilege) 4. [Intent 4: Verify Identity Before Granting Access](#4--verify-identity-before-granting-access) 5. [Intent 5: Harden Systems](#5--harden-systems) 6. [Intent 6: Protect Data — Encryption as Baseline](#6--protect-data--encryption-as-baseline) 7. [Intent 7: Segment Networks](#7--segment-networks) 8. [Intent 8: Manage Vendor and Third-Party Risk](#8--manage-vendor-and-third-party-risk) 9. [Intent 9: Control and Log Privileged Access](#9--control-and-log-privileged-access) 10. [Intent 10: Conduct Adversarial Testing](#10--conduct-adversarial-testing) 11. [Intent 11: Train and Background-Check Personnel](#11--train-and-background-check-personnel) 12. [Intent 12: Write and Maintain Policies](#12--write-and-maintain-policies) 13. [Intent 13: Manage Configuration Changes](#13--manage-configuration-changes) 14. [Intent 14: Collect, Protect, and Retain Audit Evidence](#14--collect-protect-and-retain-audit-evidence) 15. [Intent 15: Assess Your Own Security Posture](#15--assess-your-own-security-posture) 16. [Intent 16: Manage Risk Formally](#16--manage-risk-formally) 17. [Intent 17: Protect Physical Access](#17--protect-physical-access) 18. [Intent 18: Monitor Threats Continuously](#18--monitor-threats-continuously) 19. [Intent 19: Plan and Practice Incident Response](#19--plan-and-practice-incident-response) 20. [Intent 20: Manage Recovery and Lessons Learned](#20--manage-recovery-and-lessons-learned) 21. [Intent 21: Manage Accounts Throughout Their Lifecycle](#21--manage-accounts-throughout-their-lifecycle) 22. [Intent 22: Define and Enforce a Compliance Calendar](#22--define-and-enforce-a-compliance-calendar) 23. [Document Control](#23--document-control) --- > **How to use these cards:** Each card translates a security intent from [CMX-001](CERG-GOV-CMX-001_Compliance_Matrix.md) into actionable implementation guidance. Start with the minimum viable column; layer toward the good column as the program matures. Every card names the pillar responsible, the evidence to produce, the most common failure mode, and the exception path when the standard cannot be met. > > **Maturity lens:** Treat each card as a staged adoption path, not a binary checklist. Minimum Viable usually corresponds to an Informed or early Repeatable practice in [MAT-001](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md). Good Implementation corresponds to Repeatable or Adaptive practice when evidence, metrics, and improvement feedback are operating. Do not rename CERG controls or intents locally just to fit another model; preserve CERG IDs and use the card to decide the next maturity move. --- ## 1 — Know What You Own **Intent:** Maintain an authoritative asset inventory. [CMX-001 §1](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | One authoritative inventory with owner, data class, environment, regulatory flag | Inventory reconciled against cloud, endpoint, IdP, scanner, SaaS, and procurement | | **Evidence** | CMDB export, owner attestation | Reconciliation report, coverage dashboard, unowned-asset count trending downward | | **Failure Mode** | Unknown Internet-facing asset; orphaned SaaS tenant; vendor-owned admin path without organizational visibility | | **Exception Path** | Governance exception if field missing from inventory record; Risk escalation if unknown asset is confirmed exposed | | **Engineering Role** | Asset onboarding pattern; project-handoff inventory entry | | **Risk Role** | Coverage validation — scan coverage % vs inventory | | **Governance Role** | Evidence and control mapping; ownership attestation cadence | --- ## 2 — Identify and Remediate Vulnerabilities **Intent:** Identify and remediate known vulnerabilities on a defined schedule. [CMX-001 §2](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Authenticated scan of production systems; CVSS-based SLA for Critical/High | Exposure management pipeline: observe → validate → assess reachability → classify → treat → verify (per [VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)) | | **Evidence** | Scan reports, remediation tickets, SLA tracking | Exposure pipeline state log, KEV triage records, compensating control validation | | **Failure Mode** | Scanner report treated as the vulnerability program; CVSS 9.9 on a service that isn't running; "false positive" used as catch-all | | **Exception Path** | Risk acceptance per [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7; compensating controls documented and verified | | **Engineering Role** | Treatment execution; configuration changes; compensating control implementation | | **Risk Role** | Pipeline operation; observation triage; exposure confirmation; KEV monitoring | | **Governance Role** | SLA tracking; exception documentation; POA&M entries for CUI environments | --- ## 3 — Enforce Least Privilege **Intent:** Control who can access what — enforce least privilege. [CMX-001 §3](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Role-based access groups; quarterly access review of privileged accounts | JIT access for all privileged operations; attribute-based access control; automated de-provisioning on role change | | **Evidence** | Access review records, privileged group membership | PAM session logs, elevation justification records, access recertification status | | **Failure Mode** | Standing admin access justified as "operational necessity"; access review becomes rubber-stamp exercise; service accounts with interactive login | | **Exception Path** | Governance exception with documented compensating control and expiration; no standing global admin without CISO approval | | **Engineering Role** | PAM deployment; directory structure; access automation | | **Risk Role** | Privileged access monitoring; anomalous access detection | | **Governance Role** | Access review cadence; recertification enforcement; exception tracking | --- ## 4 — Verify Identity Before Granting Access **Intent:** Authenticate users and systems — verify identity before granting access. [CMX-001 §4](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | MFA for all remote access and privileged accounts | Phishing-resistant MFA for all accounts; passwordless where feasible; FIDO2/WebAuthn for privileged | | **Evidence** | IdP configuration, MFA enrollment reports | Phishing-resistant MFA coverage %, authentication method distribution | | **Failure Mode** | SMS/phone-call MFA treated as equivalent to phishing-resistant; service accounts bypassing MFA; federation trust not reviewed | | **Exception Path** | Governance exception for systems that cannot support MFA; compensating controls required (network restriction, session monitoring) | | **Engineering Role** | IdP architecture; federation trust review; authentication method deployment | | **Risk Role** | Authentication anomaly detection; credential theft monitoring | | **Governance Role** | MFA policy enforcement; exception tracking; coverage reporting | --- ## 5 — Harden Systems **Intent:** Remove what isn't needed, lock down what is. [CMX-001 §5](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | CIS Level 1 baseline deployed; monthly drift scan | CIS Level 2 for High-Impact/CUI; DISH profile per [STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md); automated drift remediation | | **Evidence** | DISH scan results, baseline coverage report | Drift detection alerts, automated remediation logs, baseline exception register | | **Failure Mode** | Baseline deployed once and never re-validated; drift accepted as normal; "hardening breaks the application" used to avoid baselines | | **Exception Path** | Governance exception with compensating controls; baseline deviation documented per asset; re-evaluated quarterly | | **Engineering Role** | Baseline authoring; drift detection; automated remediation | | **Risk Role** | Drift monitoring; exposure assessment of unhardened assets | | **Governance Role** | Baseline policy; exception register; coverage reporting | --- ## 6 — Protect Data — Encryption as Baseline **Intent:** Protect data in transit and at rest. [CMX-001 §6](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | TLS 1.2+ for all external services; encryption at rest for regulated data | TLS 1.3 only; CMK/BYOK for cloud; FIPS 140-2/3 validated modules for CUI; certificate lifecycle automation | | **Evidence** | TLS configuration scan, encryption-at-rest configuration | Certificate inventory, cipher suite audit, key management audit log | | **Failure Mode** | Internal traffic unencrypted because "it's inside the firewall"; expired certificates in production; weak cipher suites accepted | | **Exception Path** | Governance exception for legacy systems with documented retirement plan; compensating controls per [STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | | **Engineering Role** | Cryptography deployment; certificate management; key lifecycle | | **Risk Role** | Cipher suite validation; certificate expiry monitoring | | **Governance Role** | Encryption policy; FIPS compliance tracking; exception register | --- ## 7 — Segment Networks **Intent:** Limit lateral movement and blast radius. [CMX-001 §7](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | IT/OT separation; production/non-production separation; Internet-facing DMZ | Microsegmentation; zero-trust network architecture; identity-aware proxies; OT Purdue-model-aligned segmentation | | **Evidence** | Network diagram, firewall rule review, segmentation test results | Microsegmentation policy coverage, lateral movement test results, OT zone-boundary monitoring | | **Failure Mode** | Flat network with "the firewall will catch it"; OT/IT boundary documented but not enforced; "temporary" cross-zone rules become permanent | | **Exception Path** | Governance exception with compensating controls; cross-zone paths reviewed quarterly; auto-expiring firewall rules | | **Engineering Role** | Network architecture; segmentation design; firewall/ACL management | | **Risk Role** | Segmentation validation; lateral movement testing; exposed interface discovery | | **Governance Role** | Segmentation policy; exception tracking; zone-boundary review cadence | --- ## 8 — Manage Vendor and Third-Party Risk **Intent:** Extend controls beyond the organizational perimeter. [CMX-001 §8](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Vendor inventory with tier assignment; critical vendors assessed annually | Full TPRM pipeline per [TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md): evidence by tier, shared responsibility matrices, SBOM, kill-switch testing, SCCT activation | | **Evidence** | Vendor register, assessment records for Tier 1-2 | SOC 2/ISO 27001 evidence, shared responsibility matrix, kill-switch test log, SBOM repository | | **Failure Mode** | Questionnaire-only assessment; vendor risk accepted because "we've always used them"; MSP with standing global admin | | **Exception Path** | Risk acceptance per RMF-001 §9.7; compensating monitoring for opaque-dependency vendors per [EDG-001](CERG-GOV-EDG-001_Edge_Register.md) | | **Engineering Role** | Vendor access architecture; kill-switch implementation; PAM integration | | **Risk Role** | Vendor assessment; evidence collection; SCCT operation; continuous monitoring | | **Governance Role** | Contract clause library; Approved Provider Catalog; regulatory evidence package | --- ## 9 — Control and Log Privileged Access **Intent:** Know who did what, when. [CMX-001 §9](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Privileged session logging; admin action audit trail retained 90 days | Full session recording; just-in-time elevation; real-time anomaly detection on privileged actions; SIEM correlation | | **Evidence** | Privileged access logs, session records | PAM session video/keystroke logs, elevation justification records, anomalous-access alerts | | **Failure Mode** | Shared admin accounts; "break-glass" used as routine access path; logs stored where admins can delete them | | **Exception Path** | Governance exception for emergency access; post-hoc review within 24 hours; break-glass activations reviewed quarterly | | **Engineering Role** | PAM deployment; session recording; log integrity | | **Risk Role** | Anomalous access detection; privileged user behavior analytics | | **Governance Role** | Access logging policy; break-glass register; audit evidence retention | --- ## 10 — Conduct Adversarial Testing **Intent:** Find what scanners miss. [CMX-001 §10](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Annual external penetration test | Continuous adversarial validation: internal/external pen tests, cloud red-team, application pen tests, OT-specific assessment, purple-team detection validation | | **Evidence** | Pen test report, finding remediation records | Adversarial validation schedule, finding-to-closure pipeline, detection rule validation results | | **Failure Mode** | Pen test treated as annual compliance checkbox; findings accepted without remediation; only external surface tested | | **Exception Path** | Risk acceptance for findings that cannot be remediated within SLA; compensating controls verified before acceptance | | **Engineering Role** | Remediation of adversarial findings; control improvement | | **Risk Role** | Engagement scoping and execution; finding triage and tracking | | **Governance Role** | Schedule enforcement; evidence collection; board reporting | --- ## 11 — Train and Background-Check Personnel **Intent:** Ensure personnel with access to sensitive systems are vetted and trained. [CMX-001 §11](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Background check for privileged users; annual security awareness training | Role-specific training paths; phishing simulation program; certification tracking per [TRN-001](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | | **Evidence** | Training completion records, background check status | Training matrix by role, phishing simulation results, certification register | | **Failure Mode** | Training treated as annual video-compliance exercise; background checks not re-run; contractors exempted | | **Exception Path** | Conditional access for pre-cleared individuals awaiting background check; supervision required | | **Engineering Role** | Training platform integration; access tied to training status | | **Risk Role** | Phishing simulation; insider threat indicators | | **Governance Role** | Training policy; background check policy; compliance tracking | --- ## 12 — Write and Maintain Policies **Intent:** Define what good looks like. [CMX-001 §12](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Cybersecurity policy signed by Executive Sponsor; annual review | Full policy hierarchy: policy → standards → procedures → templates; version-controlled; tokenized adaptation per [VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | | **Evidence** | Signed policy, review records | Policy repository with version history, review cadence tracker, exception register | | **Failure Mode** | Policy exists as PDF on intranet, never read; review cycle missed for years; policy contradicts operational reality | | **Exception Path** | Policy exception process per [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md); exceptions tracked with expiration | | **Engineering Role** | Technical input to standards; architecture alignment with policy | | **Risk Role** | Risk input to policy appetite statements | | **Governance Role** | Policy authorship; review cadence; version control; exception workflow | --- ## 13 — Manage Configuration Changes **Intent:** Track drift, prevent unauthorized changes. [CMX-001 §13](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Change management process for production systems; CAB for security-significant changes | Automated change detection; drift alerts; pre-approved change patterns; CI/CD-integrated security gates | | **Evidence** | Change records, CAB minutes, approval evidence | Drift detection alerts, automated compliance checks, change-to-baseline reconciliation | | **Failure Mode** | Emergency changes bypassing process become routine; drift accumulates silently; change records don't match reality | | **Exception Path** | Emergency change path with post-hoc review within 24 hours; repeated emergency changes on same system trigger finding | | **Engineering Role** | Change automation; CI/CD security gates; drift remediation | | **Risk Role** | Drift impact assessment; unauthorized change detection | | **Governance Role** | Change policy; CAB operation; evidence collection for audit | --- ## 14 — Collect, Protect, and Retain Audit Evidence **Intent:** Prove controls are working. [CMX-001 §14](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Evidence collected for each control; stored securely; retained per regulatory requirement | Evidence library with automated collection; evidence linked to control baseline per [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md); freshness tracking | | **Evidence** | Evidence library index, sample evidence artifacts | Evidence freshness dashboard, control-to-evidence traceability matrix, auditor access log | | **Failure Mode** | Evidence scramble before audit; evidence exists but isn't linked to specific controls; evidence stale (collected once, never refreshed) | | **Exception Path** | Missing evidence documented as control gap; POA&M entry for CUI environments | | **Engineering Role** | Evidence-producing automation; tooling integration | | **Risk Role** | Evidence validation; sampling-based quality checks | | **Governance Role** | Evidence library management; retention policy; audit response coordination | --- ## 15 — Assess Your Own Security Posture **Intent:** Periodic internal evaluation — don't wait for auditors. [CMX-001 §15](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Annual self-assessment against control baseline | Continuous control monitoring; quarterly maturity assessment per [MAT-001](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md); automated control testing | | **Evidence** | Self-assessment results, remediation plans | Control effectiveness ratings, maturity scorecard, continuous monitoring dashboard | | **Failure Mode** | Self-assessment becomes self-congratulation; no independent validation; findings not tracked to closure | | **Exception Path** | Assessment findings enter risk register per PRC-RM-001; treatment tracked per RMF-001 | | **Engineering Role** | Control implementation evidence; technical validation | | **Risk Role** | Independent control testing; adversarial validation of controls | | **Governance Role** | Assessment methodology; scoring rubric; finding tracking | --- ## 16 — Manage Risk Formally **Intent:** Document, accept, or treat identified risks. [CMX-001 §16](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Risk register with owner, severity, treatment, and review date per [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Quantitative risk scoring (LEF × LM); risk appetite calibration; board-level risk reporting; business-owner acceptance at every tier per [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 | | **Evidence** | Risk register, treatment plans, acceptance records | Risk appetite statement, quantitative ALE dashboard, acceptance authority log | | **Failure Mode** | Risk register as parking lot — risks recorded, never treated; acceptance without compensating controls; renewal without re-evaluation | | **Exception Path** | Risk acceptance per RMF-001 §9.7; business owner accepts; renewals require fresh approval cycle | | **Engineering Role** | Treatment implementation; compensating control design | | **Risk Role** | Risk identification; scoring; treatment recommendation | | **Governance Role** | Register curation; acceptance workflow; board reporting | --- ## 17 — Protect Physical Access **Intent:** Cyber starts at the door. [CMX-001 §17](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Badge access for data centers; visitor logging; camera coverage of critical facilities | Multi-factor physical access; zone-based access control; integration with logical access (badge-out = session termination); OT substation physical security | | **Evidence** | Access logs, visitor register, camera coverage map | Physical access review records, zone-access matrix, integration test results | | **Failure Mode** | Physical security treated as "facilities problem" not cyber concern; tailgating accepted; contractor physical access not reviewed | | **Exception Path** | Governance exception for temporary physical access; escort required; time-bound | | **Engineering Role** | Physical security system integration; badge-to-logical-access correlation | | **Risk Role** | Physical access anomaly detection; critical facility risk assessment | | **Governance Role** | Physical access policy; review cadence; evidence collection | --- ## 18 — Monitor Threats Continuously **Intent:** Detect what vulnerability scans miss. [CMX-001 §18](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | SIEM with critical log sources; alerting for known-bad indicators | Full detection engineering pipeline: log source onboarding per [STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), detection rules, purple-team validation, threat intelligence integration | | **Evidence** | SIEM coverage report, alert response metrics | Detection coverage by MITRE ATT&CK technique, purple-team pass rate, threat intel feed integration status | | **Failure Mode** | SIEM as log dump — everything collected, nothing tuned; alert fatigue → alerts ignored; detection rules never validated | | **Exception Path** | Log source gap documented with compensating monitoring; reviewed quarterly | | **Engineering Role** | Log source integration; detection rule development | | **Risk Role** | Threat intelligence; detection validation; alert triage | | **Governance Role** | Logging policy; coverage reporting; retention compliance | --- ## 19 — Plan and Practice Incident Response **Intent:** Know what to do before it happens. [CMX-001 §19](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | IR plan with roles, contact list, and escalation path; annual tabletop exercise | Full IR playbooks by incident type; quarterly tabletop; annual live-fire exercise; SCCT activation path per [TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Evidence** | IR plan, tabletop results, after-action reports | Exercise schedule, improvement tracking, playbook version history, SCCT test records | | **Failure Mode** | IR plan exists as PDF, never exercised; contact list stale; "the IR team will handle it" without defined handoff | | **Exception Path** | No exception path; incident response capability is mandatory and gaps are treated as Critical findings | | **Engineering Role** | IR tooling; forensic capability; containment automation | | **Risk Role** | Detection-to-IR handoff; threat intelligence during incidents | | **Governance Role** | IR plan maintenance; exercise schedule; after-action improvement tracking | --- ## 20 — Manage Recovery and Lessons Learned **Intent:** Restore operations and capture what was learned. [CMX-001 §20](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Backup and restore procedures for critical systems; annual restore test | RTO/RPO defined per system tier; automated backup validation; restoration test schedule per [STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md); lessons-learned pipeline to standards feedback | | **Evidence** | Backup success reports, restore test results, lessons-learned records | RTO/RPO compliance dashboard, automated backup validation, improvement record linkage to standards updates | | **Failure Mode** | Backups exist but restore never tested; lessons learned documented but never acted on; same incident repeats | | **Exception Path** | Restoration gap documented as risk; compensating manual procedure defined; tested quarterly | | **Engineering Role** | Backup architecture; restore automation; resilience engineering | | **Risk Role** | Recovery risk assessment; single-point-of-failure identification | | **Governance Role** | BC/DR policy; test schedule enforcement; lessons-learned feedback loop | --- ## 21 — Manage Accounts Throughout Their Lifecycle **Intent:** Provisioning through termination — no orphaned access. [CMX-001 §21](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Joiner/mover/leaver process; access removed within 24 hours of termination | Automated identity lifecycle; HRIS-integrated provisioning/de-provisioning; access recertification per [STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | | **Evidence** | Termination tickets, access removal confirmation | Identity lifecycle automation log, recertification status dashboard, orphaned account report | | **Failure Mode** | Manual de-provisioning — "we'll get to it"; contractor accounts not tracked; service accounts with no owner | | **Exception Path** | Conditional retention of access for knowledge transfer; time-bound (max 30 days); supervisor approval required | | **Engineering Role** | Identity lifecycle automation; HRIS integration | | **Risk Role** | Orphaned account detection; dormant account monitoring | | **Governance Role** | Access lifecycle policy; recertification schedule; audit evidence | --- ## 22 — Define and Enforce a Compliance Calendar **Intent:** No surprises at audit time. [CMX-001 §22](CERG-GOV-CMX-001_Compliance_Matrix.md) | | Minimum Viable | Good Implementation | |---|---|---| | **Implementation** | Annual calendar of compliance activities; evidence collected throughout the year | Continuous compliance monitoring; evidence auto-collection; regulatory mapping per framework; pre-audit readiness review 60 days before engagement | | **Evidence** | Compliance calendar, activity completion records | Evidence freshness dashboard, framework-to-control mapping, pre-audit readiness report | | **Failure Mode** | Pre-audit scramble; evidence collected once and never refreshed; calendar exists but activities not tracked to completion | | **Exception Path** | Missed activity documented as finding; compensating evidence identified where possible; entered in improvement register | | **Engineering Role** | Evidence-producing automation; control implementation | | **Risk Role** | Continuous control monitoring; independent validation | | **Governance Role** | Calendar ownership; activity tracking; evidence library; audit liaison | --- ## 23 — Document Control ### Revision History | Version | Date | Author | Change Summary | |---------|------|--------|---------------| | 1.1 | 2026-06-18 | Governance Pillar Leader | Reframed cards as security-intent adoption paths and added the maturity lens for agents and adopters. | | 1.0 | 2026-06 | CERG Governance | Initial release. 22 implementation cards mapping security intents to actionable implementation guidance. | ### Review Triggers Annual review or upon material change to the control baseline, compliance matrix, or CERG operating model. ### Related Documents | Document | ID | Relationship | |----------|-----|-------------| | Compliance Matrix | CERG-GOV-CMX-001 | Source of the 22 intents | | Control Baseline | CERG-GOV-CB-001 | Controls referenced by implementation cards | | Architecture Review Procedure | CERG-PRC-AR-001 | Pre-approved patterns referenced | | Exposure Management Procedure | CERG-PRC-VM-001 | Intent 2 operational implementation | | TPRM Procedure | CERG-PRC-TPRM-001 | Intent 8 operational implementation | | Risk Management Framework | CERG-GOV-RMF-001 | Risk acceptance authority | | Edge Register | CERG-GOV-EDG-001 | Edge management for vendor/network intents | --- > > _An intent without implementation guidance is governance poetry. These cards make the intents actionable._ --- _CERG-GOV-IMP-004 · Version 1.1 · PUBLIC_ --- ## ORGANIZATION ADAPTATION PROFILE ### Token Scheme · Values File · Render Tool --- | | | |---|---| | **Document ID** | CERG-GOV-VAR-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) · [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | | **Review Cycle** | Annual / On any change to the token scheme | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How Adaptation Works](#2-how-adaptation-works) 3. [The Token Scheme](#3-the-token-scheme) 4. [Token Catalog](#4-token-catalog) 5. [The Organization Profile File](#5-the-organization-profile-file) 6. [The Render Tool](#6-the-render-tool) 7. [The Phrase Map](#7-the-phrase-map) 8. [Adaptation Workflow](#8-adaptation-workflow) 9. [Rules and Discipline](#9-rules-and-discipline) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope The CERG README says: "Drop it in, adapt the names and org structure to fit yours, and you have a functioning program." That sentence hides a problem. There has never been a map of *what* to adapt. An adopter who wants to change "the organization" to their own name, or scale the headcount figures down, or swap the illustrative sector, has had to read all 28 documents and find every occurrence by hand. That is slow, it is error-prone, and it is the kind of work that gets done once and then drifts. This document removes that problem. It defines a token scheme, ships a single values file an organization fills in once, and ships a render tool that produces an organization-specific copy of the entire corpus in one command. It applies to every adopter of CERG and to every CERG artifact that contains adaptable text. > **Adaptation Is Mechanical** > > Adapting CERG is not a creative act. It is a substitution. Names, headcounts, sectors, regulators, and illustrative examples are variables; the framework around them is fixed. The moment adaptation becomes hand-editing prose, version discipline is lost. Fill in the profile once. Render. Review the output. That is the whole job. --- ## 2. How Adaptation Works CERG separates two kinds of content. **Fixed content** is the framework itself: the three pillars, the canonical role roster, the control baseline, the procedures, the cross-reference rules. This content does not change between adopters. It is the product. **Variable content** is everything that names a specific organization: the organization's name, its sector, its size, the regulators it answers to, the names of its standing teams, and the illustrative examples chosen to make a point. This content is different for every adopter. Adaptation is the act of replacing variable content with an organization's own values. CERG does this in two layers: 1. **Tokens.** Explicit variable tokens of the form `{{TOKEN_NAME}}`. Any new CERG content, and any organization-maintained content, uses tokens directly. The render tool substitutes them. 2. **The phrase map.** The V1 corpus was written before the token scheme existed, so it contains hard-coded variable phrases (for example, a specific headcount used as a scaling upper bound). The phrase map is a configurable list of those known phrases and the token each maps to. The render tool applies it so the existing corpus adapts without the source files being rewritten. The published corpus is left intact and generic. The render tool produces a separate, organization-specific output. The source stays the master; the output is an export, exactly as [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) requires. > **Why Not Just Edit the Source Documents** > > Tokenizing the approved source corpus in place is a corpus-wide normalization pass that touches many artifacts and changes revision history. That is its own scoped piece of work, not a side effect of adoption. Until it is done, the phrase map carries the load: it adapts the existing corpus at render time without mutating approved source files. New documents use tokens natively from day one. --- ## 3. The Token Scheme A token is an uppercase identifier wrapped in double braces. ``` {{TOKEN_NAME}} ``` Rules for tokens: - **Uppercase, underscore-separated.** `{{ORG_NAME}}`, not `{{OrgName}}` or `{{org-name}}`. - **Double braces, no spaces.** `{{ORG_NAME}}`, not `{{ ORG_NAME }}` or `{ORG_NAME}`. The double-brace form is chosen because it does not collide with Markdown syntax and is visually obvious in a draft. - **Every token appears in the catalog.** Section 4 is the authoritative list. A token used in a document but absent from the catalog is an error the render tool reports. - **Tokens never appear in fixed content.** Role names stay canonical (see Section 9). The three pillars are never tokenized. Document IDs are never tokenized. - **A token has exactly one meaning.** `{{REGULATORS}}` is always the full regulator list. It is never reused to mean something else in another document. > **Tokens Are Not for Roles** > > The single most important rule. Canonical role names from [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 are fixed content. They are never tokenized. "Governance Pillar Leader" is written literally, every time, in every document. If an organization renames that seat internally, that mapping lives in the organization's own role-assignment map, not in the CERG corpus. Tokenizing a role would let an adopter silently rename a seat and break every cross-reference that depends on it. --- ## 4. Token Catalog This is the authoritative list of tokens. New tokens are added only by amendment to this document. ### 4.1 Organization Identity | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{ORG_NAME}}` | The organization's common name, as used in running prose. | `Northwind Energy` | | `{{ORG_LEGAL_NAME}}` | The full legal entity name, for cover pages and approvals. | `Northwind Energy Holdings, Inc.` | | `{{ORG_SHORT_NAME}}` | A short form or abbreviation. | `Northwind` | | `{{ORG_SECTOR}}` | The industry sector, used in illustrative examples. | `[your sector]` | | `{{ORG_CONTENT_REPO}}` | Where the authoritative Markdown corpus lives. | `https://git.example.com/security/cerg` | ### 4.2 Program Identity | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{PROGRAM_NAME}}` | The name the organization gives its security program. Defaults to `CERG`. | `CERG` | | `{{PROGRAM_ACRONYM}}` | The program acronym for the pillar set. Defaults to `CERG`. | `CERG` | ### 4.3 Scale and Structure | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{TOTAL_EMPLOYEES}}` | Headcount of the organization. | `[your headcount]` | | `{{PROTECTED_POPULATION}}` | Total population of identities, devices, and access relationships managed. | `[your number]` | | `{{CERG_TEAM_SIZE}}` | Size of the security team running the program. | `[your team size]` | | `{{ENG_STAFF}}` | Headcount in the Engineering pillar. | `14` | | `{{RISK_STAFF}}` | Headcount in the Risk pillar. | `15` | | `{{GOV_STAFF}}` | Headcount in the Governance pillar. | `13` | | `{{SCALE_TIER}}` | The reference scale band this adopter sits in: `small`, `mid`, or `large`. | `[small, mid, or large]` | ### 4.4 Oversight and Standing Teams | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{COG_NAME}}` | The organization's name for the Cyber Oversight Group, the CISO reporting body. | `Cyber Oversight Group` | | `{{IR_TEAM_NAME}}` | The name of the standing Incident Response team that owns `CERG-PLN-IR-001`. | `Security Incident Response Team` | | `{{EXEC_BODY_NAME}}` | The executive or board body that endorses the policy. | `Risk and Audit Committee` | ### 4.5 Regulatory Context | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{REGULATORS}}` | The full list of regulators and frameworks in scope. | `NERC-CIP, CMMC L2, SOX ITGC` | | `{{PRIMARY_REGULATOR}}` | The single most consequential regulator, used where one example is needed. | `NERC-CIP` | ### 4.6 Contact and Control | **Token** | **Meaning** | **Example Value** | |---|---|---| | `{{SECURITY_CONTACT}}` | The published contact address for security matters. | `security@example.com` | | `{{DOC_CONTROL_CONTACT}}` | The contact for document-control questions. | `cerg-docs@example.com` | | `{{ADOPTION_DATE}}` | The date the organization adopted CERG. | `2026-05-21` | > **The Scale Figures Are an Upper Bound** > > The V1 corpus uses a large-enterprise illustration as a deliberate upper bound, so readers can scale down. The scale tokens in §4.3 exist precisely so an adopter can replace that upper bound with their own reality. A five-person team sets `{{CERG_TEAM_SIZE}}` to `5` and `{{SCALE_TIER}}` to `small`, and the rendered corpus stops describing a large-enterprise organization back to them. --- ## 5. The Organization Profile File An adopter fills in exactly one file: `cerg-org-profile.yml`. It lives at the root of the adopter's content repository. It is the single source of truth for every token value. The file ships in the repository pre-populated with the V1 reference values (the upper-bound illustration), so an adopter sees a working example and edits it down to their own organization. The file structure mirrors the catalog in Section 4: one block per category, one key per token (lowercase form of the token name). The render tool reads this file and nothing else for token values. > **One File, One Source of Truth** > > Every token value lives in `cerg-org-profile.yml`. Not in a second file, not in a wiki page, not in someone's head. When a value changes, it changes in one place and the next render propagates it everywhere. An organization that maintains token values in more than one place has recreated the drift problem this scheme exists to remove. --- ## 6. The Render Tool The render tool is `tools/cerg-render.py`. It is a single Python script with no dependencies outside the standard library, so it runs anywhere Python 3 runs. ### 6.1 What It Does 1. Reads `cerg-org-profile.yml`. 2. Walks the corpus for Markdown files. 3. For each file, applies the phrase map (Section 7), then substitutes every `{{TOKEN}}`. 4. Writes the result to an output directory, leaving the source untouched. 5. Reports any token found in a document that is not in the profile, and any profile key that maps to no catalog token. ### 6.2 Usage ``` # Render the whole corpus into ./rendered using ./cerg-org-profile.yml python3 tools/cerg-render.py # Explicit paths python3 tools/cerg-render.py --profile cerg-org-profile.yml --source . --out rendered # Check only: report unresolved tokens and exit non-zero if any are found. # Does not write output. Use this in CI. python3 tools/cerg-render.py --check ``` ### 6.3 Exit Behavior The tool exits non-zero if it finds an unresolved token (a `{{TOKEN}}` with no value in the profile) or an unknown token (a `{{TOKEN}}` not in the catalog). This makes `--check` usable as a continuous-integration gate: a document that introduces a token without registering it fails the build. --- ## 7. The Phrase Map The phrase map handles hard-coded variable text in the V1 corpus, text written before tokens existed. It is a list of exact phrases and the rendered replacement each should receive. It is defined inside the render tool and is editable by the adopter. The V1 phrase map covers the known hard-coded strings, primarily the upper-bound scale figures. As the corpus is progressively tokenized in future work, phrase-map entries are retired and replaced by native tokens. The phrase map is a bridge, not a permanent fixture. > **The Phrase Map Shrinks Over Time** > > Every phrase-map entry is debt. It exists because a document contains a hard-coded value instead of a token. The correct long-term fix is to tokenize the source. Until then the phrase map carries it. A healthy CERG corpus has a phrase map that gets shorter with each release, not longer. --- ## 8. Adaptation Workflow This is the workflow an adopter follows. It is referenced by [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §5.1, step 2. | **Step** | **Action** | **Role** | |---|---|---| | 1 | Copy `cerg-org-profile.yml` and fill in every token value for the organization. | Policy & Standards Manager | | 2 | Run `python3 tools/cerg-render.py --check` and resolve every reported unresolved token. | Policy & Standards Manager | | 3 | Run `python3 tools/cerg-render.py` to produce the rendered corpus. | Policy & Standards Manager | | 4 | Review the rendered output. Confirm names, scale figures, and examples read correctly. | Governance Pillar Leader | | 5 | Publish the rendered corpus as the organization's working library. The CERG source remains the upstream master for future updates. | Governance Pillar Leader | When CERG publishes an update upstream, the adopter pulls the new source, updates the profile if new tokens were added, and re-renders. The organization's values are never lost because they live in one file, separate from the corpus. --- ## 9. Rules and Discipline 1. **Never tokenize a canonical role name.** Roles from [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 are fixed content. See the callout in Section 3. 2. **Never tokenize a Document ID.** IDs are stable identifiers. `CERG-GOV-VAR-001` is written literally, always. 3. **Never tokenize the pillar names.** Cyber Engineering, Cyber Risk, and Cyber Governance are the framework. They are fixed. 4. **Every token is in the catalog.** A token not in Section 4 is invalid. Add it by amendment before using it. 5. **One profile file.** All values live in `cerg-org-profile.yml`. See the callout in Section 5. 6. **Render; do not hand-edit.** Adaptation is the render tool. Hand-editing the rendered output breaks the ability to re-render on the next upstream update. 7. **The source stays generic.** The CERG corpus in this repository is never rendered in place. Rendering produces a separate output for a separate organization. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-VAR-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the token scheme | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.5 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed documentation | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-21 | Cyber Governance | Initial release. Establishes the token scheme, the token catalog, the `cerg-org-profile.yml` values file, the `cerg-render.py` render tool, the phrase map bridge for the un-tokenized V1 corpus, the adaptation workflow, and the adaptation discipline rules. | ### Review Triggers - A new token is required by a new or revised CERG artifact - The canonical role roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 changes - The corpus is tokenized in place, retiring phrase-map entries - Adopter feedback indicating a missing or ambiguous token - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Document Control) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative artifact inventory; source-versus-export rule | | Implementation and Adaptation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Consumer of the adaptation workflow defined here | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster; roles are never tokenized | --- ## PROGRAM IMPROVEMENT REGISTER ### Register Schema · Lifecycle · Integration · Reporting · Operating Procedure --- | | | |---|---| | **Document ID** | CERG-GOV-IMPREG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-PRC-LL-001`](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | | **Review Cycle** | Annual / Reviewed at each quarterly CERG leadership review | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.IM, GOVERN) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (PM) · ISO/IEC 27001 A.10 | | **Regulations** | Cross-cutting : applies to all CERG-supported frameworks | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Why a Separate Improvement Register](#2-why-a-separate-improvement-register) 3. [Register Schema](#3-register-schema) 4. [Improvement Lifecycle](#4-improvement-lifecycle) 5. [Integration with the Risk Register](#5-integration-with-the-risk-register) 6. [Integration with Other CERG Instruments](#6-integration-with-other-cerg-instruments) 7. [Reporting](#7-reporting) 8. [Roles and Responsibilities](#8-roles-and-responsibilities) 9. [Register Maintenance and Hygiene](#9-register-maintenance-and-hygiene) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope The CERG Framework targets NIST CSF Adaptive maturity. A defining characteristic of an Adaptive program is that it does not just respond to findings : it changes itself in response to what it learns. It identifies systemic weaknesses, alters its own controls and procedures, and verifies that the changes worked. This document defines the Program Improvement Register: the authoritative, durable record of every program-level change CERG makes, why it was made, who was accountable, and whether it produced the intended effect. It is the audit trail that answers the assessor's question: "How has your program evolved, and can you prove that evolution made it better?" This document applies to every CERG program improvement, regardless of source: lessons learned (PRC-LL-001), intelligence-driven reprioritization, maturity assessment gaps (MAT-001), metric threshold breaches (MTR-001), CISO direction, or external requirement changes. > **Program Improvement vs. Operational Change** > > Patching a server is an operational change. It does not go in the improvement register. Adding a control to CB-001 that requires automated patch verification is a program improvement. It goes in the improvement register. > > The test: "Would this change still be relevant to an assessor reviewing our program two years from now?" If yes, it belongs here. --- ## 2. Why a Separate Improvement Register CERG already has a risk register (PRC-RM-001). Using it for program improvements creates three problems: 1. **Category error.** A risk is a threat-vulnerability-impact-likelihood construct with a treatment plan. A program improvement : "we consolidated two duplicate procedures," "we raised the architecture review SLA from 85% to 95%," "we added a new leading indicator" : is not a risk. Forcing it into a risk register schema distorts both the risk data and the improvement data. 2. **Noise in risk reporting.** The CISO and board review the risk register to understand exposure. Mixing in program improvements : which are positive, forward-looking changes : dilutes the risk signal. 3. **Wrong lifecycle.** Risks have treatment plans, residual scores, and acceptance decisions. Improvements have implementation, verification, and effectiveness outcomes. The lifecycles are different; the register should be different. > **When to Use Each Register** > > | Situation | Correct Register | > |---|---| > | A vulnerability is found on a production server | Risk register (PRC-RM-001) | > | The same vulnerability class appears across four pen tests and an audit; the root cause is a missing standard | Improvement register (this document) | > | A business unit wants to accept a risk for 6 months | Risk register | > | The exception process itself needs a revision because it takes too long | Improvement register | > | An incident occurred; the IR team contained it | Risk register (post-incident risk entry) | > | The incident revealed that detection rules need updating for an entire attack technique family | Improvement register | --- ## 3. Register Schema The improvement register is a structured record. Every entry contains the following fields. The register may be maintained in any platform that supports structured data (spreadsheet, database, GRC tool), but the schema is fixed. | Field | Description | Example | |---|---|---| | **Improvement ID** | IMP-YYYY-NNN (year assigned, sequential) | IMP-2026-001 | | **Title** | Short description of the change | "Add automated firmware-version discovery to asset management" | | **Source** | What triggered this improvement | Lesson ID LL-2026-Q2-003 / Intelligence review Q2 2026 / MAT-001 domain 14 gap / MTR-001 VM-001 threshold breach / CISO directive / External requirement change | | **Source Detail** | Specific reference to the triggering event or analysis | "Quarterly Lessons Aggregation Q2 2026 : pattern cluster: firmware versions not tracked in CMDB" | | **Type** | Improvement action type per PRC-LL-001 Section 6.1 | Control amendment / Standard revision / Procedure update / New capability / Training gap flag / Staffing or budget / Metric or threshold change / Retirement | | **Current State** | What exists today, including why it is insufficient | "Firmware versions tracked manually in spreadsheets; three of last four critical vulns had un-tracked firmware" | | **Target State** | What will exist after the change | "Firmware versions auto-discovered by CMDB agent; STD-AM-001 requires firmware version as a tracked attribute; PRC-VM-001 adds firmware-age SLA" | | **Affected Artifacts** | CERG document IDs that will be modified | STD-AM-001, PRC-VM-001 | | **Accountable Role** | Single owner per the canonical role roster (OM-001 Section 6.1) | Engineering Pillar Leader | | **Approved By** | CISO | CISO | | **Approval Date** | When approved | 2026-04-15 | | **Target Date** | When this should be operational | 2026-09-30 (Q3) | | **Status** | Current lifecycle state (see Section 4) | In Progress | | **Actual Completion Date** | When the change reached Complete status | (blank until status reaches Complete) | | **Verification Method** | How effectiveness will be proven | "Firmware attribute appears in CMDB for 100% of critical assets; next quarterly VM report shows zero firmware-related vulns past SLA" | | **Verification Date** | When verification occurred | (blank until verification occurs) | | **Verification Outcome** | Effective / Partially Effective / Ineffective | (blank until verification occurs) | | **Re-open Reason** | If Ineffective, what was the gap and what is the revised approach | (blank unless re-opened) | | **Notes** | Free-text for context, blockers, dependencies | "Dependency: CMDB agent deployment scheduled for Q2; Engineering will coordinate with IT ops" | > **One Improvement, One Entry** > > If an improvement requires changes to three documents and a new tool, it is still one improvement : one root cause analysis, one decision, one accountable owner. The "Affected Artifacts" field captures the scope. Do not create multiple entries for one improvement decision. --- ## 4. Improvement Lifecycle Every improvement follows a defined lifecycle. Status changes are recorded with a date and the role making the change. ### 4.1 Lifecycle States ``` Proposed → Approved → In Progress → Complete → Verified → Closed ↘ ↘ Declined Ineffective → Re-Opened → In Progress (revised) ``` | State | Meaning | Entry Criteria | Exit Criteria | |---|---|---|---| | **Proposed** | Improvement has been identified and documented but not yet approved | Improvement identified per PRC-LL-001 pipeline or equivalent source | Approval decision | | **Approved** | Improvement has been approved by the appropriate authority | Approver signs off | Work begins | | **In Progress** | Work is actively underway | Accountable role accepts; resources allocated | All affected artifacts updated, new capabilities deployed, or other Target State achieved | | **Complete** | Target state achieved; improvement implemented | All "Affected Artifacts" updated; operator confirms change is operational | Verification checkpoint | | **Verified** | Verification confirms the improvement was effective | Verification method executed; outcome assessed | Closure | | **Closed** | Improvement is permanently closed | Verified Effective | : | | **Declined** | Improvement was reviewed and rejected | Approver declines with rationale | : (entry retained for audit trail) | | **Ineffective** | Verification showed the improvement did not work or partially worked | Verification outcome is Partially Effective or Ineffective | Re-opened with revised approach | | **Re-Opened** | Previously Complete or Verified improvement is re-activated with a revised approach | Root cause analysis of ineffectiveness complete; revised approach defined | In Progress (with revised Target State) | > **Complete Is Not Closed** > > "Complete" means the change was made : the standard was amended, the tool was deployed, the procedure was updated. "Verified" means the change worked : the amendment actually prevented recurrence, the tool actually caught the thing it was designed to catch, the procedure actually improved the outcome. An improvement that sits at "Complete" without verification is an open item, not a success. ### 4.2 Aging Rules - An improvement in "Proposed" for more than 30 days without an approval decision is escalated to the CISO. - An improvement in "In Progress" past its target date is flagged at the next quarterly review. - An improvement in "Complete" for more than one quarter without verification is escalated : the verification was either not planned or is being avoided. - An improvement in "Re-Opened" for more than two quarters is escalated to the CISO for a decision: revise the approach, accept the gap, or close with a documented rationale. --- ## 5. Integration with the Risk Register The risk register (PRC-RM-001) and the improvement register are distinct instruments with a defined interface. ### 5.1 Risk-to-Improvement Linkage When a risk register entry identifies a systemic weakness that requires a program change (not just a risk treatment), the risk register entry references the improvement ID. Example: - Risk register entry RM-2026-047: "Critical vulnerability in SCADA firmware : CVSS 9.1 : treatment: patch within 90 days." - Improvement register entry IMP-2026-001: "Add automated firmware-version discovery to CMDB; amend STD-AM-001 and PRC-VM-001." - Risk register entry RM-2026-047 is updated with a reference: "Systemic improvement tracked in IMP-2026-001." The risk itself is still managed in the risk register. The systemic fix is managed in the improvement register. They reference each other; neither subsumes the other. ### 5.2 Improvement-to-Risk Linkage When an improvement is approved that will reduce a class of risk, the risk register owner is notified. If the improvement changes the residual risk score for any open risk, the risk entry is re-scored at the next monthly risk register review. ### 5.3 What Does NOT Go in the Improvement Register - Individual risk entries (use PRC-RM-001) - Exception requests (use PRC-RM-001 exception workflow) - Vulnerability remediation tracking (use PRC-VM-001) - Access review findings (use PRC-AC-002) - Incident response actions (use PRC-IR-002) - Audit finding remediation (tracked in PRC-AUD-001; systemic improvements from audit patterns go in the improvement register) --- ## 6. Integration with Other CERG Instruments | Instrument | Integration Point | |---|---| | **PRC-LL-001** (Lessons Learned) | Primary intake pipeline. Approved improvements from the quarterly aggregation are created here. | | **GOV-MTR-001** (Metrics) | Improvement register metrics (Section 7) are reported alongside risk metrics. Open improvements, aging improvements, and recently verified improvements are included in the quarterly CISO brief. | | **GOV-MAT-001** (Maturity) | When the maturity scorecard identifies a domain gap, the gap may be recorded as an improvement entry rather than a risk register entry if it requires a program change. | | **GOV-CAL-001** (Calendar) | The improvement register is reviewed at each quarterly CERG leadership review. Annual catalog amendments triggered by improvements are scheduled in the calendar. | | **GOV-TRC-001** (Traceability) | When an improvement amends a control, the traceability matrix is updated to reflect the new or changed control-to-procedure mapping. | | **GOV-CAT-001** (Catalog) | When an improvement creates, amends, or retires an artifact, the catalog is amended. | | **GOV-RAC-001** (RACI) | When an improvement changes ownership or accountability, the RACI instrument is updated. | | **TMPL-GOV-001** (Stakeholder Perception Survey) | Survey results are an intake source. A mean Likert score below 3.0, a recurring open-ended theme across "START doing" and "STOP doing," or a year-over-year decline of 0.5 points or more triggers a perception-survey-driven improvement entry with source "Stakeholder Perception Survey YYYY." | | **GOV-SLC-001** (Service-Level Commitments) | Each monthly Service Responsiveness metric (SR-001 through SR-005) that breaches its target becomes an improvement candidate. The annual perception survey is the qualitative companion to these continuous quantitative measures. | --- ## 7. Reporting ### 7.1 Quarterly CISO Brief At each quarterly CISO Risk and Posture Review (per GOV-CAL-001), the Governance Pillar Leader presents: - **Improvement register summary:** total open, count by status, count by type - **Aging report:** improvements past target date, improvements in "Complete" without verification - **Recently verified:** improvements verified in the trailing quarter with outcome - **Re-opened count:** improvements re-opened in the trailing quarter - **Pipeline health:** lessons-intake-to-improvement-approval cycle time (median days) ### 7.2 Annual Program Evolution Report At the annual program review, the improvement register provides the narrative backbone for "how the program evolved this year." The report includes: - Total improvements proposed, approved, completed, verified, and declined - Verification pass rate (Effective / total verified) - Improvements grouped by source (lessons learned, intelligence-driven, maturity gaps, CISO direction) - Top 5 most impactful improvements (by assessor-visible program change) - Improvements that changed the control baseline, standards, or metrics > **The Annual Evolution Narrative** > > The improvement register is the raw material for the single most important answer an Adaptive program must give: "How did your program get better this year?" Every improvement that reached "Verified Effective" is a data point in that answer. If the register is empty, the program did not improve : it only operated. --- ## 8. Roles and Responsibilities | Role | Responsibility | |---|---| | **Governance Pillar Leader** | Owns this instrument. Maintains the improvement register. Presents improvement metrics at quarterly reviews. Escalates aging improvements. | | **CISO** | Approval authority for improvements that affect the control baseline, require budget, or change staffing. Reviews the improvement register quarterly. | | **Risk Pillar Leader** | Proposes improvements from Risk pillar sources (vulnerability, adversarial, intelligence). Accountable for Risk-owned improvement actions. | | **Engineering Pillar Leader** | Proposes improvements from Engineering pillar sources (architecture, configuration, SDLC). Accountable for Engineering-owned improvement actions. | | **Risk Register Owner** | Links risk register entries to improvement entries per Section 5.1. Re-scores affected risks when an improvement changes the risk landscape. | | **Policy & Standards Manager** | Executes catalog amendments triggered by improvements. Updates cross-references when artifacts are modified. | | **Evidence Librarian** | Archives improvement register snapshots for audit trail. Maintains the verification evidence for completed improvements. | --- ## 9. Register Maintenance and Hygiene ### 9.1 Platform and Access The improvement register is maintained in a structured platform accessible to all pillar leaders and the CISO. The minimum viable platform is a shared spreadsheet with column-level permissions and an audit log. Larger organizations may use a GRC tool or database. Regardless of platform, the register must support: - Filtering by status, type, accountable role, and source - Date-based aging queries (items past target date, items in Complete without verification) - Export for quarterly and annual reporting - Audit trail of status changes (who changed what, when) ### 9.2 Hygiene Rules - **No orphan entries.** Every entry has an accountable role and a target date. Entries without both are returned to Proposed. - **No stale entries.** The Governance Pillar Leader reviews the register monthly for entries that have not been updated in 60 days. Stale entries are flagged at the next CERG leadership sync. - **Declined entries are retained.** A declined improvement is an audit artifact : it shows the improvement was considered and rejected with rationale. It is not deleted. - **Ineffective entries are re-opened, not deleted.** The failure is itself a data point. The original approach, the verification evidence, and the re-open rationale are preserved. ### 9.3 Archival The improvement register is archived annually. The archived register becomes an audit artifact. The active register continues with a new year prefix (IMP-YYYY-NNN). --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-IMPREG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST CSF 2.0 (ID.IM, GOVERN); NIST 800-53r5 (PM); ISO/IEC 27001 A.10 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-26 | Cyber Governance | Initial draft. Established the Program Improvement Register: schema, lifecycle, risk register integration, reporting, and maintenance procedure. Addresses NIST CSF Adaptive gap: tracking program evolution as a distinct management discipline from risk management. | --- ## ROLE-BASED IMPLEMENTATION CHECKLISTS ### First 48 Hours · First 30 Days · First 90 Days --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-006 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly / Upon adoption path or role model change | | **Frameworks** | NIST CSF 2.0 (GOVERN) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adoption paths | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How to Use These Checklists](#2-how-to-use-these-checklists) 3. [CISO or Security Lead Checklist](#3-ciso-or-security-lead-checklist) 4. [Governance Lead Checklist](#4-governance-lead-checklist) 5. [Risk Lead Checklist](#5-risk-lead-checklist) 6. [Engineering Lead Checklist](#6-engineering-lead-checklist) 7. [Small-Team Consolidated Checklist](#7-small-team-consolidated-checklist) 8. [First 90-Day Completion Criteria](#8-first-90-day-completion-criteria) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope CERG adoption fails when everyone agrees with the framework but no one knows what to do next. This document converts the adoption model into role-based action. It is designed for first adoption, restart, or rescue of a stalled implementation. It does not replace the Implementation Guide. It gives each accountable role a concrete checklist. --- ## 2. How to Use These Checklists 1. Pick an adoption path using [IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md). 2. Complete the Organization Adaptation Profile in [VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md). 3. Assign people to the roles below. One person may hold multiple roles in CERG Lite. 4. Create the first records listed in [CAT-002](CERG-GOV-CAT-002_Record_Catalog.md). 5. Review checklist status weekly for the first 30 days. 6. Move incomplete items into the Program Improvement Register after day 30. Completion means there is an artifact, record, decision, or evidence link. A verbal agreement is not complete. --- ## 3. CISO or Security Lead Checklist ### 3.1 First 48 hours | Done | Action | Output | |---|---|---| | [ ] | Name the Executive Sponsor. | Executive Sponsor recorded in Role Assignment Map. | | [ ] | Confirm the organization is ready to adopt CERG. | Readiness answers documented using IMP-005 §2.1. | | [ ] | Select adoption path: Lite, Standard, or Regulated overlay. | Path decision recorded. | | [ ] | Approve initial in-scope business units, systems, and regulators. | Organization Adaptation Profile started. | | [ ] | Assign interim owners for Engineering, Risk, and Governance. | Role Assignment Map created. | | [ ] | Approve use of a temporary evidence store if no GRC platform exists. | Evidence storage decision recorded. | ### 3.2 First 30 days | Done | Action | Output | |---|---|---| | [ ] | Sign or route the Cybersecurity Policy for approval. | Approved policy or approval workflow record. | | [ ] | Approve the first 10 risks. | Initial risk register reviewed. | | [ ] | Approve risk appetite defaults or schedule calibration. | Risk appetite decision or meeting scheduled. | | [ ] | Establish Cyber Oversight Group or equivalent. | Meeting cadence and membership recorded. | | [ ] | Review first exposure backlog. | Backlog triage decision record. | | [ ] | Confirm exception and risk acceptance authority. | Authority map recorded. | | [ ] | Approve 30-day improvement backlog. | Program Improvement Register seeded. | ### 3.3 First 90 days | Done | Action | Output | |---|---|---| | [ ] | Review first metrics dashboard. | CISO dashboard record. | | [ ] | Review control implementation snapshot. | Control baseline status reviewed. | | [ ] | Approve Standard or Regulated expansion if needed. | Adoption expansion decision. | | [ ] | Review open high risks and expired exceptions. | Oversight decision record. | | [ ] | Sponsor resourcing decisions from observed workload. | Budget, staffing, or deferral decision. | --- ## 4. Governance Lead Checklist ### 4.1 First 48 hours | Done | Action | Output | |---|---|---| | [ ] | Create or update the Document Catalog. | Local catalog entry set. | | [ ] | Create the Evidence Index. | Evidence index record. | | [ ] | Create the Role Assignment Map. | Named accountable roles. | | [ ] | Start the Organization Adaptation Profile. | Draft profile with scope and regulators. | | [ ] | Identify which regulatory packages are applicable. | Regulatory applicability decision. | ### 4.2 First 30 days | Done | Action | Output | |---|---|---| | [ ] | Label adopted artifacts as Required-Core, Conditional, Recommended, Example, Deferred, or Not Applicable. | Local catalog labels. | | [ ] | Establish evidence quality expectations. | Evidence Quality Standard adopted or tailored. | | [ ] | Create the initial control implementation snapshot. | Control implementation records. | | [ ] | Set the annual governance calendar. | Calendar record. | | [ ] | Define where policies, standards, procedures, and evidence live. | Repository or document library decision. | | [ ] | Prepare first CISO metrics view. | Dashboard draft. | | [ ] | Create the Program Improvement Register. | Active improvement register. | ### 4.3 First 90 days | Done | Action | Output | |---|---|---| | [ ] | Run first evidence quality review. | Evidence quality findings or acceptance. | | [ ] | Complete first maturity self-assessment checkpoint. | Maturity record and gaps. | | [ ] | Map core controls to procedures and evidence. | Traceability matrix or control records updated. | | [ ] | Prepare first oversight package. | COG or board-ready brief. | | [ ] | Update documents based on adoption lessons. | Approved document changes or improvement items. | --- ## 5. Risk Lead Checklist ### 5.1 First 48 hours | Done | Action | Output | |---|---|---| | [ ] | Create the risk register. | Risk register with required fields. | | [ ] | Create the exception register. | Empty or active exception register. | | [ ] | Define severity and risk scoring approach. | Scoring basis recorded. | | [ ] | Seed initial top risks. | Initial top 10 risk records. | | [ ] | Identify current vulnerability sources. | Scanner, audit, EDR, cloud, or manual source list. | ### 5.2 First 30 days | Done | Action | Output | |---|---|---| | [ ] | Run or ingest first exposure scan cycle. | Exposure backlog. | | [ ] | Triage vulnerabilities against asset criticality and reachability. | Validated finding records. | | [ ] | Route remediation to Engineering. | Assigned remediation records. | | [ ] | Establish exception workflow. | Exception intake and approval path. | | [ ] | Identify high-risk vendors or SaaS platforms. | Initial vendor tiering list. | | [ ] | Identify crown jewels or critical services. | Draft crown jewel entries. | | [ ] | Define threat intelligence sources. | TI source list and review cadence. | ### 5.3 First 90 days | Done | Action | Output | |---|---|---| | [ ] | Verify closure evidence for remediated findings. | Verified closure records. | | [ ] | Escalate overdue high-risk findings. | Escalation record. | | [ ] | Complete first vendor risk assessment for highest-risk vendor. | Vendor assessment record. | | [ ] | Create first threat-informed detection or validation priority. | TI-to-detection action. | | [ ] | Review accepted risks and expiring exceptions with CISO. | Oversight decision record. | | [ ] | Feed recurring failure patterns into improvement register. | Program improvement items. | --- ## 6. Engineering Lead Checklist ### 6.1 First 48 hours | Done | Action | Output | |---|---|---| | [ ] | Identify authoritative asset inventory source. | Asset source decision. | | [ ] | Identify highest-risk systems and owners. | Critical asset owner list. | | [ ] | Identify identity provider and privileged access owners. | Identity ownership record. | | [ ] | Identify logging, endpoint, backup, and exposure-management tooling. | Coverage source list. | | [ ] | Name intake path for new projects and changes. | Project intake path recorded. | ### 6.2 First 30 days | Done | Action | Output | |---|---|---| | [ ] | Produce asset inventory extract. | Asset inventory record set. | | [ ] | Create asset coverage snapshot for critical systems. | Coverage records for scan, log, backup, endpoint, identity. | | [ ] | Define first secure configuration baseline scope. | Baseline scope record. | | [ ] | Start remediation work for validated high findings. | Remediation records. | | [ ] | Establish architecture review intake for new work. | Intake form or queue. | | [ ] | Identify privileged groups and service accounts for first review. | Access review scope. | | [ ] | Produce backup/restore evidence for one critical system. | Recovery test or restore evidence. | ### 6.3 First 90 days | Done | Action | Output | |---|---|---| | [ ] | Complete first privileged access review. | Access review record. | | [ ] | Complete first baseline drift check or configuration review. | Baseline evidence. | | [ ] | Complete architecture review for at least one active project. | Project security review record. | | [ ] | Validate logging coverage for critical systems. | Detection or logging coverage record. | | [ ] | Close or exception top remediation items. | Closure evidence or exception records. | | [ ] | Document engineering constraints blocking risk reduction. | Oversight or improvement record. | --- ## 7. Small-Team Consolidated Checklist For CERG Lite, one person may act as Security Lead, Governance Lead, Risk Lead, and Engineering Lead. Do not try to do every checklist item at once. Use this order. ### Week 1 1. Confirm executive sponsor. 2. Select CERG Lite. 3. Complete Organization Adaptation Profile. 4. Create Role Assignment Map. 5. Create risk register. 6. Create evidence index. 7. Export asset inventory. 8. Seed initial top 10 risks. 9. Create exposure backlog. 10. Record regulatory applicability decision. ### Weeks 2 to 4 1. Run exposure triage. 2. Assign remediation owners. 3. Start exception register. 4. Identify critical systems. 5. Capture first access review evidence for privileged groups. 6. Capture first backup or restore evidence for a critical system. 7. Adopt the minimum document set in the local catalog. 8. Prepare first simple metrics view. 9. Create 30-day improvement backlog. 10. Review status with executive sponsor. ### Days 31 to 90 1. Add architecture intake. 2. Add vendor tiering for top vendors. 3. Add core standards based on actual scope. 4. Create control implementation snapshot. 5. Run first maturity checkpoint. 6. Hold first Cyber Oversight Group or equivalent meeting. 7. Move unresolved adoption gaps into the Program Improvement Register. --- ## 8. First 90-Day Completion Criteria A first adoption is complete enough to operate when the organization can answer yes to these questions: | Area | Question | |---|---| | Governance | Is there a signed policy or active approval record? | | Governance | Is the adopted document set known and labeled? | | Governance | Does an evidence index exist? | | Governance | Is there an owner for every CERG pillar or consolidated role? | | Risk | Does the risk register contain current risks with owners and treatment? | | Risk | Are exceptions documented with expiration and approval? | | Risk | Are vulnerability findings triaged and assigned? | | Engineering | Is there an asset inventory extract with owners? | | Engineering | Are critical systems covered for at least vulnerability, identity, logging, and backup decisions? | | Engineering | Is there a project or change intake path for security review? | | Oversight | Has the CISO or sponsor reviewed metrics, risks, and blockers? | | Improvement | Are unresolved gaps tracked as improvement work? | If any answer is no after 90 days, create a Program Improvement Record and assign an owner. --- ## 9. Document Control | | | |---|---| | **Document ID** | CERG-GOV-IMP-006 | | **Version** | 1.0 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Governance Pillar Leader | | **Next Review** | Quarterly / Upon adoption path or role model change | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.0 | 2026-06-13 | Governance Pillar Leader | Initial publication. Adds role-based implementation checklists for CISO, Governance, Risk, Engineering, and small-team consolidated adoption. | ### Review Triggers - Change to adoption paths. - Change to canonical roles or role consolidation model. - Feedback from first-time adopters. - New minimum record or evidence requirement. - Material change to the first 90-day rollout model. ### Related Documents - [START-HERE](../START-HERE.md) - First 48 hours guide - [CERG-GOV-IMP-001](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) - Implementation and Adaptation Guide - [CERG-GOV-IMP-003](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) - Small Team Adoption Path - [CERG-GOV-IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) - Adoption Decision Tree and Dependency Matrix - [CERG-GOV-CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) - Record Catalog - [CERG-GOV-RAC-001](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) - RACI Instrument --- | | | |---|---| | **Document ID** | CERG-GOV-JD-001 | | **Version** | 2.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; or upon any change to the canonical role roster | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [About This Document](#1-about-this-document) 2. [Job Family Structure](#2-job-family-structure) 3. [Per-Role Document Index](#3-per-role-document-index) 4. [Document Control](#4-document-control) --- ## 1. About This Document **This document is now a family-level index.** As of v2.0 (2026-06-11), individual role descriptions have been extracted from this monolithic file into standalone per-role documents under `roles/`. Each per-role document includes: - **NICE Workforce Framework mapping** — primary and secondary NICE Work Roles with codes - **Job Family and Level placement** — family designation and grade range per [JF-001](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) - **Key Responsibilities** — extracted from the original JD-001 content, organized by core vs. grade-level differentiation - **Required KSAs** — domain expertise, technical skills, and CERG-specific knowledge - **NICE TKS Statement References** — populated sections for Task, Knowledge, and Skill statement IDs - **KPIs** — mapped sections for MTR-001 canonical metrics with grade-level thresholds - **Competency Expectations** — populated sections with CMP-001 behavioral anchors - **Career Path** — within-family progression, cross-family movement, and management track options > **The original JD-001 content is preserved in the per-role files.** This index file replaces the monolithic structure to enable modular use: a hiring manager can attach a single role description to a requisition; an auditor can pull the specific role evidence they need; a team member can see their career options. --- ## 2. Job Family Structure The 27 canonical CERG roles are organized into five Job Families. See [JF-001](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) for the full family structure, level definitions, career lattice, and progression gates. | Family ID | Family Name | Family Index | Roles | |-----------|-------------|--------------|-------| | **JF-SECENG** | Security Engineering | [`SECENG-000`](../roles/jf-seceng/CERG-GOV-JD-SECENG-000_Security_Engineering_Family.md) | 6 engineering roles | | **JF-RISKOPS** | Risk Operations | [`RISKOPS-000`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-000_Risk_Operations_Family.md) | 7 risk operations roles | | **JF-GOVCOMP** | Governance & Compliance | [`GOVCOMP-000`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-000_Governance_Compliance_Family.md) | 6 compliance roles | | **JF-EXEC** | Executive Leadership | [`EXEC-000`](../roles/jf-exec/CERG-GOV-JD-EXEC-000_Executive_Leadership_Family.md) | 2 executive roles | | **JF-ADJUNCT** | Incident Response | [`ADJUNCT-000`](../roles/jf-adjunct/CERG-GOV-JD-ADJUNCT-000_Incident_Response_Family.md) | 2 adjacent IR roles | **Pillar Leaders** — three management-track roles (Engineering Pillar Leader, Risk Pillar Leader, Governance Pillar Leader) have per-role documents within their respective families. They are M4/Director-level roles with distinct leadership expectations. --- ## 3. Per-Role Document Index ### JF-SECENG — Security Engineering | # | Role | Document | |---|------|----------| | 1 | Engineering Pillar Leader | [`CERG-GOV-JD-SECENG-007`](../roles/jf-seceng/CERG-GOV-JD-SECENG-007_Engineering_Pillar_Leader.md) | | 2 | Cloud Security Engineer | [`CERG-GOV-JD-SECENG-001`](../roles/jf-seceng/CERG-GOV-JD-SECENG-001_Cloud_Security_Engineer.md) | | 3 | Identity Engineer | [`CERG-GOV-JD-SECENG-002`](../roles/jf-seceng/CERG-GOV-JD-SECENG-002_Identity_Engineer.md) | | 4 | OT Security Engineer | [`CERG-GOV-JD-SECENG-003`](../roles/jf-seceng/CERG-GOV-JD-SECENG-003_OT_Security_Engineer.md) | | 5 | Application Security Engineer | [`CERG-GOV-JD-SECENG-004`](../roles/jf-seceng/CERG-GOV-JD-SECENG-004_Application_Security_Engineer.md) | | 6 | Endpoint Engineer | [`CERG-GOV-JD-SECENG-005`](../roles/jf-seceng/CERG-GOV-JD-SECENG-005_Endpoint_Engineer.md) | | 7 | Cryptography Engineer | [`CERG-GOV-JD-SECENG-006`](../roles/jf-seceng/CERG-GOV-JD-SECENG-006_Cryptography_Engineer.md) | | 8 | Pre-production Reviewer | [`CERG-GOV-JD-SECENG-008`](../roles/jf-seceng/CERG-GOV-JD-SECENG-008_Pre-production_Reviewer.md) | ### JF-RISKOPS — Risk Operations | # | Role | Document | |---|------|----------| | 9 | Risk Pillar Leader | [`CERG-GOV-JD-RISKOPS-008`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-008_Risk_Pillar_Leader.md) | | 10 | Exposure Management Lead | [`CERG-GOV-JD-RISKOPS-001`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-001_Exposure_Management_Lead.md) | | 11 | Adversarial Testing Lead | [`CERG-GOV-JD-RISKOPS-002`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-002_Adversarial_Testing_Lead.md) | | 12 | Threat Intelligence Analyst | [`CERG-GOV-JD-RISKOPS-003`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-003_Threat_Intelligence_Analyst.md) | | 13 | Detection Engineer | [`CERG-GOV-JD-RISKOPS-004`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-004_Detection_Engineer.md) | | 14 | OT Risk Analyst | [`CERG-GOV-JD-RISKOPS-005`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-005_OT_Risk_Analyst.md) | | 15 | Identity Risk Analyst | [`CERG-GOV-JD-RISKOPS-006`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-006_Identity_Risk_Analyst.md) | | 16 | Vendor Risk Analyst | [`CERG-GOV-JD-RISKOPS-007`](../roles/jf-riskops/CERG-GOV-JD-RISKOPS-007_Vendor_Risk_Analyst.md) | ### JF-GOVCOMP — Governance & Compliance | # | Role | Document | |---|------|----------| | 17 | Governance Pillar Leader | [`CERG-GOV-JD-GOVCOMP-007`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-007_Governance_Pillar_Leader.md) | | 18 | NERC-CIP Compliance Manager | [`CERG-GOV-JD-GOVCOMP-001`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-001_NERC-CIP_Compliance_Manager.md) | | 19 | CMMC / Federal Compliance Manager | [`CERG-GOV-JD-GOVCOMP-002`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-002_CMMC_Federal_Compliance_Manager.md) | | 20 | SOX ITGC Lead | [`CERG-GOV-JD-GOVCOMP-003`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-003_SOX_ITGC_Lead.md) | | 21 | Policy & Standards Manager | [`CERG-GOV-JD-GOVCOMP-004`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-004_Policy_and_Standards_Manager.md) | | 22 | Risk Register Owner | [`CERG-GOV-JD-GOVCOMP-005`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-005_Risk_Register_Owner.md) | | 23 | Evidence Librarian | [`CERG-GOV-JD-GOVCOMP-006`](../roles/jf-govcomp/CERG-GOV-JD-GOVCOMP-006_Evidence_Librarian.md) | ### JF-EXEC — Executive Leadership | # | Role | Document | |---|------|----------| | 24 | Chief Information Security Officer (CISO) | [`CERG-GOV-JD-EXEC-001`](../roles/jf-exec/CERG-GOV-JD-EXEC-001_Chief_Information_Security_Officer.md) | | 25 | Executive Sponsor | [`CERG-GOV-JD-EXEC-002`](../roles/jf-exec/CERG-GOV-JD-EXEC-002_Executive_Sponsor.md) | ### JF-ADJUNCT — Incident Response | # | Role | Document | |---|------|----------| | 26 | Incident Commander | [`CERG-GOV-JD-ADJUNCT-001`](../roles/jf-adjunct/CERG-GOV-JD-ADJUNCT-001_Incident_Commander.md) | | 27 | Lead Investigator | [`CERG-GOV-JD-ADJUNCT-002`](../roles/jf-adjunct/CERG-GOV-JD-ADJUNCT-002_Lead_Investigator.md) | --- ## 4. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-001 | | **Version** | 2.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; or upon any change to the canonical role roster | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-27 | Cyber Governance | Initial release. Monolithic file with full job descriptions for all 25 canonical CERG roles. | | 2.0 | 2026-06-11 | Governance Pillar Leader | Restructured as family-level index. Extracted per-role content into standalone documents under `roles/`. Added NICE Work Role mapping, KPI sections, and competency anchor sections to each per-role file. Added NICE SP 800-181r1 framework reference. | ### Review Triggers - Addition or retirement of a canonical role in OM-001 §6.1 - Change to the NICE Work Role mappings in JF-002 - Change to the Job Family structure in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | --- ## COMPETENCY MODEL AND BEHAVIORAL ANCHORS ### Leveled Knowledge · Skills · Behaviors Across All Three Pillars --- | | | |---|---| | **Document ID** | CERG-GOV-CMP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) · [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | | **Review Cycle** | Annual / On any change to grade definitions, role roster, or material shift in cybersecurity competency frameworks | | **Frameworks** | [NIST NICE Workforce Framework](https://www.nist.gov/itl/applied-cybersecurity/nice) (SP 800-181r1) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · [ISO/IEC 27001](https://www.iso.org/standard/27001) A.7.2 · [DCWF](https://public.cyber.mil/wid/dcwf/) (DoD 8140.03) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How This Model Works](#2-how-this-model-works) 3. [Competency Domains](#3-competency-domains) 4. [Engineering Pillar: Competency Matrix and Behavioral Anchors](#4-engineering-pillar-competency-matrix-and-behavioral-anchors) 5. [Risk Pillar: Competency Matrix and Behavioral Anchors](#5-risk-pillar-competency-matrix-and-behavioral-anchors) 6. [Governance Pillar: Competency Matrix and Behavioral Anchors](#6-governance-pillar-competency-matrix-and-behavioral-anchors) 7. [Management Track Competency Addendum](#7-management-track-competency-addendum) 8. [Using This Model for Hiring, Development, and Promotion](#8-using-this-model-for-hiring-development-and-promotion) 9. [Mapping to NICE and Industry Frameworks](#9-mapping-to-nice-and-industry-frameworks) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope The Job Architecture and Grade Framework (CERG-GOV-JA-001) defines what each grade expects: scope, autonomy, influence, craft mastery, and organizational impact. It tells you *at what altitude* a Specialist, Sr. Specialist, Advisor, or Sr. Advisor operates. What it does not do is define what "craft mastery" actually means for a Cloud Security Engineer at S2 versus S3, or what "influence" looks like for a Threat Intelligence Analyst versus a Vendor Risk Analyst. This document answers those questions. It defines eight competency domains, distributes them across the SME grades (S1 through S4) for each of the three role families (Engineering, Risk, Governance), and provides behavioral anchors: observable, concrete examples of what competent performance looks like at each level. A person in the role, their manager, and a promotion panel should be able to read the relevant cell and agree on whether the person is meeting, exceeding, or not yet demonstrating that competency at that grade. It applies to every CERG SME-track role. Management-track competencies are addressed in Section 7 as an addendum, referencing the leadership dimensions already defined in JA-001 §5. The two Adjacent Incident Response roles are out of scope. > **A Model, Not a Checklist** > > No one demonstrates every anchor at their grade simultaneously. The anchors describe the target. A Specialist who is strong in Technical Depth but still developing Cross-Pillar Fluency is on a normal trajectory. A promotion case should address each competency domain honestly, not check every box. The model exists to make the conversation specific, not to automate the decision. --- ## 2. How This Model Works ### 2.1 Structure For each role family, a matrix maps eight competency domains (rows) against the four SME grades (columns). Each cell contains a behavioral anchor: a one-to-two-sentence description of what that competency looks like at that grade in that role family. The anchors are cumulative. An Advisor (S3) is expected to demonstrate the S1 and S2 anchors plus the S3 anchor. They do not lose the earlier capabilities; they add new ones. ### 2.2 Role Families The competencies are calibrated to three role families aligned to the CERG pillars: | Role Family | Pillar | Roles | |---|---|---| | **Engineering** | Cyber Engineering | Cloud Security Engineer, Identity Engineer, OT Security Engineer, Application Security Engineer, Endpoint Engineer, Cryptography Engineer | | **Risk** | Cyber Risk | Threat Intelligence Analyst, Vendor Risk Analyst, OT Risk Analyst, Identity Risk Analyst, Detection Engineer, Exposure Management Lead (SME track), Adversarial Testing Lead (SME track) | | **Governance** | Cyber Governance | NERC-CIP Compliance Manager (SME track), CMMC/Federal Compliance Manager (SME track), SOX ITGC Lead (SME track), Policy & Standards Manager (SME track), Risk Register Owner (SME track), Evidence Librarian | Management-track roles (Pillar Leaders, Managers, Senior Managers) use the SME competencies for their home family plus the management addendum in Section 7. ### 2.3 Reading a Cell A cell that says "authors new detection rules from threat reports with minimal false positives; peer-reviews rules written by Specialists" is specific enough that a manager and a Detection Engineer can look at a quarter's work and say "yes, that is happening" or "no, the peer review part is not happening yet." It is not a job description. It is a lens for evaluating demonstrated capability. --- ## 3. Competency Domains The eight domains below apply to every CERG role. Their relative weight varies by role family: Technical Depth is the primary domain for Engineering; Risk Judgment is primary for Risk; Compliance and Regulatory Literacy is primary for Governance. But every domain matters for every role, because the left-right knowledge model in CERG-GOV-FRM-001 §9.2 means a Cloud Security Engineer who cannot read a compliance finding and a SOX ITGC Lead who cannot read a vulnerability report are both half-effective. | Domain | What It Measures | Primary Family | |---|---|---| | **Technical Depth** | Mastery of the tools, platforms, and techniques specific to the role's domain. The ability to execute, troubleshoot, and improve the technical work. | Engineering | | **Cross-Pillar Fluency** | Understanding of how the other two pillars operate, what they produce, and how the person's work connects to theirs. The left-right knowledge model in practice. | All | | **Risk Judgment** | The ability to assess severity, likelihood, and business impact of a finding, vulnerability, or design decision. Knowing what is a fire and what is smoke. | Risk | | **Communication** | The ability to explain technical or regulatory findings to audiences that do not share the person's expertise: business owners, executives, auditors, vendors. Written and verbal. | All | | **Operational Discipline** | Consistency in following procedures, documenting work, collecting evidence, and meeting operational SLAs. The part of cybersecurity that is a profession, not a calling. | All | | **Influence and Mentorship** | The ability to improve the team's output through teaching, code review, procedure improvement, or setting standards, without formal authority. | All | | **Compliance and Regulatory Literacy** | Understanding of the regulatory frameworks in the organization's scope and the ability to translate between regulatory language and technical reality. | Governance | | **Continuous Learning** | Evidence of active skill maintenance and growth. Cybersecurity skills have a half-life; this domain measures whether the person is investing in keeping theirs current. | All | > **The Domains Are Interdependent** > > An engineer with deep Technical Depth and zero Communication is a risk: their findings die in their terminal. An analyst with strong Risk Judgment and weak Operational Discipline is a liability: their assessments are brilliant but their evidence is missing when the auditor arrives. The model values the whole practitioner, not the specialist who is dangerous in every dimension except one. --- ## 4. Engineering Pillar: Competency Matrix and Behavioral Anchors ### 4.1 Technical Depth | Grade | Anchor | |---|---| | **S1 Specialist** | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | | **S2 Sr. Specialist** | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. Debugs non-trivial failures without assistance. | | **S3 Advisor** | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack (new service, new acquisition, new cloud region) will affect security posture before they land. Performs architecture reviews across domains with credibility. Authors standards that govern how their domain is secured. | | **S4 Sr. Advisor** | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems (e.g., "how do we safely federate with this acquisition's identity provider across three clouds and an on-prem OT environment?"). Represents the organization's engineering position to vendors, industry working groups, and regulators. Writes the standards others follow. Can step into any Engineering domain and contribute meaningfully within days. | ### 4.2 Cross-Pillar Fluency | Grade | Anchor | |---|---| | **S1** | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | | **S2** | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. Recognizes when a design decision has regulatory implications (e.g., "this crosses CIP boundaries") and raises it. | | **S3** | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. Identifies when a Risk finding or Governance requirement is based on a misunderstanding of the technology and corrects it constructively. | | **S4** | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | ### 4.3 Risk Judgment | Grade | Anchor | |---|---| | **S1** | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | | **S2** | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. Recognizes when a finding they are working on is part of a larger risk pattern and escalates with the pattern, not just the ticket. | | **S3** | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. Contributes risk assessments to the risk register that the Risk Pillar Leader treats as authoritative. | | **S4** | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | ### 4.4 Communication | Grade | Anchor | |---|---| | **S1** | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | | **S2** | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. Communicates technical trade-offs to non-engineering audiences. | | **S3** | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. Mentors junior engineers on how to structure written analysis. | | **S4** | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | ### 4.5 Operational Discipline | Grade | Anchor | |---|---| | **S1** | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | | **S2** | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | | **S3** | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | | **S4** | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | ### 4.6 Influence and Mentorship | Grade | Anchor | |---|---| | **S1** | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | | **S2** | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | | **S3** | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. Contributes to hiring decisions through candidate evaluations. | | **S4** | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. Represents the engineering culture to leadership. | ### 4.7 Compliance and Regulatory Literacy | Grade | Anchor | |---|---| | **S1** | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | | **S2** | Understands the specific regulatory requirements that affect their domain (e.g., CIP-007 for OT engineers, CMMC access control requirements for Identity engineers). Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | | **S3** | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | | **S4** | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | ### 4.8 Continuous Learning | Grade | Anchor | |---|---| | **S1** | Completes assigned training. Pursues foundational certifications relevant to their domain (e.g., AWS Security Specialty, AZ-500). Learns the organization's technology stack. | | **S2** | Maintains current certifications. Stays current on developments in their domain (new cloud services, new attack techniques, new regulatory requirements). Shares what they learn with the team. | | **S3** | Pursues advanced certifications (e.g., CISSP, SANS GIAC, cloud architecture certifications). Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | | **S4** | Recognized externally for expertise (conference presentations, industry working groups, published research). Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | --- ## 5. Risk Pillar: Competency Matrix and Behavioral Anchors ### 5.1 Technical Depth | Grade | Anchor | |---|---| | **S1 Specialist** | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | | **S2 Sr. Specialist** | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. Authors detection rules, threat advisories, or vendor risk reports that require minimal revision. | | **S3 Advisor** | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. Authors threat intelligence products that shape organizational decisions. Evaluates and recommends new Risk tooling. | | **S4 Sr. Advisor** | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions (e.g., "what is our actual risk from this newly disclosed supply chain compromise given our architecture and controls?"). Represents the organization's risk posture to regulators, auditors, and industry peers. | ### 5.2 Cross-Pillar Fluency | Grade | Anchor | |---|---| | **S1** | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | | **S2** | Delivers risk findings in a format Engineering can act on (specific, actionable, prioritized by business impact). Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | | **S3** | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings and ensures the trail is complete before the auditor arrives. | | **S4** | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | ### 5.3 Risk Judgment | Grade | Anchor | |---|---| | **S1** | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | | **S2** | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context (compensating controls, exposure path, threat actor capability) and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | | **S3** | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. Contributes risk assessments to significant business decisions (vendor selection, architecture change, M&A). | | **S4** | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. Engages with industry peers on emerging risk methodologies. | ### 5.4 Communication | Grade | Anchor | |---|---| | **S1** | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | | **S2** | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | | **S3** | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. Represents Risk in regulatory and customer inquiries. | | **S4** | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. Mentors Risk team members on how to structure risk communication for different audiences. | ### 5.5 Operational Discipline | Grade | Anchor | |---|---| | **S1** | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | | **S2** | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. Their assessment records are audit-ready. | | **S3** | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | | **S4** | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. Ensures the pillar's SLAs, coverage targets, and quality standards are defined, measured, and reported. | ### 5.6 Influence and Mentorship | Grade | Anchor | |---|---| | **S1** | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | | **S2** | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | | **S3** | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. Contributes to hiring through candidate evaluations and interview panel participation. | | **S4** | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. Represents the Risk function's philosophy to leadership and to the broader security community. | ### 5.7 Compliance and Regulatory Literacy | Grade | Anchor | |---|---| | **S1** | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance (e.g., vulnerability scan results as evidence for CIP-007, vendor assessments for CMMC). | | **S2** | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. Can explain to an auditor how a risk assessment supports a compliance finding. | | **S3** | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. Represents Risk in regulatory audits. | | **S4** | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. Ensures the Risk program's output meets the highest standard of regulatory defensibility. | ### 5.8 Continuous Learning | Grade | Anchor | |---|---| | **S1** | Completes assigned training. Pursues foundational certifications (e.g., Security+, CEH, vendor-specific certs for tools in use). Learns the organization's threat landscape. | | **S2** | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. Shares threat intelligence and lessons learned with the team. | | **S3** | Pursues advanced certifications (e.g., CISSP, GCIH, GCFA, OSCP). Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities (ISACs, sector-specific groups). | | **S4** | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. Shapes the organization's approach to emerging threats and risk assessment techniques. | --- ## 6. Governance Pillar: Competency Matrix and Behavioral Anchors ### 6.1 Technical Depth | Grade | Anchor | |---|---| | **S1 Specialist** | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | | **S2 Sr. Specialist** | Owns a compliance domain (e.g., NERC-CIP evidence for a subset of standards, CMMC control family, SOX ITGC control set). Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision from the Governance Pillar Leader. | | **S3 Advisor** | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. Authors standards and policy sections. Evaluates and recommends GRC tooling. | | **S4 Sr. Advisor** | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions (e.g., "does this new operational model require a CIP boundary recertification?"). Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | ### 6.2 Cross-Pillar Fluency | Grade | Anchor | |---|---| | **S1** | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | | **S2** | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. Recognizes when a control requirement is technically impractical and works with Engineering to design a compensating control. | | **S3** | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. Participates in cross-pillar working groups as the Governance voice. Ensures standards are technically validated by Engineering and risk-prioritized by Risk before publication. | | **S4** | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. Ensures the Governance program enables the other pillars rather than constraining them. | ### 6.3 Risk Judgment | Grade | Anchor | |---|---| | **S1** | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | | **S2** | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. Contributes compliance-related risk items to the risk register with accurate severity ratings. | | **S3** | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions (e.g., "we can meet the letter of this requirement with a compensating control, but here is the residual risk"). Correlates compliance findings with vulnerability and threat data to produce integrated risk pictures. | | **S4** | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. Their judgment on compliance risk is treated as equivalent to the Risk Pillar Leader's on technical risk. | ### 6.4 Communication | Grade | Anchor | |---|---| | **S1** | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | | **S2** | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. Communicates with auditors and assessors under supervision. | | **S3** | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. Communicates compliance risk to executive audiences. Mentors junior Governance staff on regulatory communication. | | **S4** | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. Represents the organization in industry regulatory working groups. | ### 6.5 Operational Discipline | Grade | Anchor | |---|---| | **S1** | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | | **S2** | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times, not just during audit season. Improves evidence collection workflows. | | **S3** | Designs compliance operations that are sustainable year-round, not just during audit cycles. Ensures the Governance pillar's operational cadence is documented, measured, and improving. Designs evidence architectures that support multiple frameworks without duplication. | | **S4** | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. Ensures the compliance program can survive the departure of any single person. | ### 6.6 Influence and Mentorship | Grade | Anchor | |---|---| | **S1** | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | | **S2** | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff who need to understand compliance requirements. | | **S3** | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive (respond to auditor findings) to proactive (operate in a way that makes audit findings rare). Contributes to hiring decisions. | | **S4** | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. Influences the organization's compliance culture. Represents the Governance function's philosophy to leadership. | ### 6.7 Compliance and Regulatory Literacy | Grade | Anchor | |---|---| | **S1** | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | | **S2** | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. Stays current on regulatory changes and updates. Can explain to an auditor how the organization's controls satisfy specific regulatory requirements. | | **S3** | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes and prepares the organization before they take effect. Advises leadership on regulatory strategy. Represents the organization in regulatory proceedings. | | **S4** | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. Their regulatory interpretations are treated as authoritative by the organization and respected by external stakeholders. | ### 6.8 Continuous Learning | Grade | Anchor | |---|---| | **S1** | Completes assigned training. Pursues foundational certifications (e.g., Security+, CISA fundamentals, framework-specific training). Learns the organization's regulatory landscape. | | **S2** | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. Pursues intermediate certifications (e.g., CISA, CRISC, CMMC RP/RPA). Shares regulatory knowledge with the team. | | **S3** | Pursues advanced certifications (e.g., CISSP, CISM, CGEIT, lead auditor certifications). Contributes to the Governance body of knowledge through documented regulatory analysis. Represents the organization in regulatory working groups. | | **S4** | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. Shapes the organization's approach to emerging regulatory frameworks. | --- ## 7. Management Track Competency Addendum CERG managers are expected to demonstrate the SME competencies of their home role family at the S2 level or above, plus the five management-specific domains below. A Governance Pillar Leader who rose through the Risk pillar demonstrates Risk-family SME competencies at S3 or S4 plus the management addendum. The management competencies are progressive. A Manager demonstrates the M1 anchors; a Director demonstrates the M1 through M4 anchors cumulatively. The grade definitions in JA-001 §5 establish the performance expectations (span of control, scope, people leadership). This addendum defines the observable behaviors that demonstrate those expectations are being met. ### 7.1 People Leadership | Grade | Anchor | |---|---| | **M1 Manager** | Conducts regular, meaningful 1:1s. Sets clear expectations for each direct report. Delivers honest performance feedback promptly, not just at annual review. Addresses performance issues early, before they become team problems. Hires with a clear understanding of what the role needs. | | **M2 Senior Manager** | Develops the Managers reporting to them. Ensures consistent people-management practices across their function. Identifies and develops high-potential team members. Manages team composition actively: hires for gaps, addresses skill imbalances, manages departures without disruption. | | **M3 Principal Manager** | Builds a leadership bench: ensures every critical role has an identified successor or development plan for one. Shapes the people strategy for their scope: hiring profile, retention approach, career pathways. Creates a management culture that reflects CERG values. | | **M4 Director** | Accountable for the entire pillar's talent health. Develops the next generation of CERG leaders. Owns the pillar's organizational design. Builds a culture of cross-pillar collaboration and continuous development. | ### 7.2 Strategic Thinking | Grade | Anchor | |---|---| | **M1** | Translates pillar goals into actionable team tasks. Prioritizes team work against organizational objectives. Identifies when team priorities need to shift and communicates the rationale. | | **M2** | Defines a function strategy and roadmap aligned to pillar and organizational objectives. Anticipates how changes in the threat landscape, technology, or regulatory environment will affect the function's priorities. Contributes to pillar strategy discussions. | | **M3** | Shapes pillar strategy. Identifies emerging organizational needs and positions the pillar to meet them before the need becomes a crisis. Contributes to organizational strategy beyond the pillar. | | **M4** | Sets the multi-year strategic direction for the pillar. Aligns pillar strategy with organizational strategy, the threat landscape, and the regulatory environment. Represents the pillar's strategic position to the CISO, the board, and external stakeholders. | ### 7.3 Resource and Budget Management | Grade | Anchor | |---|---| | **M1** | Manages team resources effectively. Identifies when the team is over- or under-resourced and communicates the gap to their manager. Advocates for tooling and training investments with clear business justification. | | **M2** | Owns the function's budget input. Defends headcount requests with workload data, not anecdotes. Manages vendor relationships and tooling procurement for the function. Makes resource allocation trade-offs across teams transparently. | | **M3** | Owns significant budget lines. Builds multi-year resource plans. Evaluates build-vs-buy decisions with total-cost-of-ownership analysis. Identifies efficiency opportunities that free resources for higher-value work. | | **M4** | Owns the pillar's budget. Allocates resources across functions in alignment with organizational priorities. Makes investment cases to the CISO and executive leadership. Ensures the pillar's resource allocation reflects its risk priorities. | ### 7.4 Stakeholder Management | Grade | Anchor | |---|---| | **M1** | Represents the team effectively to peer teams, pillar leadership, and business stakeholders. Manages stakeholder expectations: communicates timelines, risks, and trade-offs honestly. Escalates issues that require leadership attention with clear context and recommended actions. | | **M2** | Manages complex stakeholder relationships across functions and business units. Navigates competing priorities among stakeholders without compromising the function's core mission. Represents the function to executive stakeholders. | | **M3** | Manages executive stakeholder relationships. Aligns stakeholders with competing interests toward a shared objective. Represents CERG to external stakeholders (regulators, auditors, industry peers) with credibility. | | **M4** | Manages the organization's most critical stakeholder relationships: the CISO, executive leadership, the board, regulators, and industry peers. Shapes stakeholder expectations rather than just meeting them. Builds organizational consensus for the pillar's strategic direction. | ### 7.5 Organizational Development | Grade | Anchor | |---|---| | **M1** | Contributes to team culture and morale. Recognizes team members' contributions publicly. Addresses behaviors that undermine team cohesion. | | **M2** | Builds a positive, high-performance culture within the function. Establishes norms for collaboration, knowledge sharing, and professional development. Identifies and removes systemic barriers to team effectiveness. | | **M3** | Shapes organizational culture across the pillar. Designs organizational structures that enable the strategy. Leads organizational change initiatives. Builds cross-pillar collaboration norms. | | **M4** | Shapes organizational culture across CERG. Designs the pillar's organizational model to meet current and future needs. Champions diversity of thought, cross-pillar collaboration, and continuous improvement as organizational values. | --- ## 8. Using This Model for Hiring, Development, and Promotion ### 8.1 Hiring For each open requisition, select the target grade and role family. Use the competency matrix to define the interview assessment plan: 1. **Technical Depth** is assessed through a technical interview or practical exercise calibrated to the target grade. 2. **Cross-Pillar Fluency** and **Communication** are assessed through a panel interview with members from a different pillar. 3. **Risk Judgment** is assessed through a case study or scenario discussion. 4. **Operational Discipline** and **Continuous Learning** are assessed through behavioral questions and resume review. The model ensures every candidate is evaluated against the same dimensions, reducing the "I liked them but I cannot explain why" hiring pattern. ### 8.2 Development For each team member, the manager and the team member review the competency matrix for their role family at their current grade and the next grade. Together they identify: - **Strengths** (competencies where the person consistently demonstrates at-grade or above-grade behavior) - **Growth areas** (competencies where the person is not yet demonstrating at-grade behavior, or needs development to reach the next grade) - **Development actions**: specific experiences, training, mentoring, or stretch assignments that will close the gaps This review should happen at least semi-annually, aligned to the performance management cadence in CERG-GOV-PERF-001. ### 8.3 Promotion A promotion case addresses every competency domain. The standard is not "checks every box." It is: 1. The candidate consistently demonstrates at-grade behavior in their current role. 2. The candidate demonstrates next-grade behavior in the majority of competency domains. 3. The candidate has a credible development plan for domains where they are not yet at the next grade. 4. The manager, a peer manager from a different pillar, and the pillar leader concur. > **Calibration Prevents Drift** > > Two managers evaluating the same engineer against the same matrix should reach similar conclusions. If they do not, the model is not specific enough or the managers are not applying it consistently. The promotion calibration process defined in CERG-GOV-PERF-001 exists to catch and correct this drift. A promotion that one manager supports and another would block is not a close call to be resolved by advocacy; it is a signal that the competency evidence needs to be examined together. --- ## 9. Mapping to NICE and Industry Frameworks ### 9.1 NIST NICE Workforce Framework (SP 800-181r1) The NICE Framework defines cybersecurity work through Task, Knowledge, and Skill (TKS) statements organized into Work Roles and Competency Areas. This section maps CERG's eight competency domains to NICE Competency Areas and provides sample TKS references for skills-gap analysis. #### 9.1.1 CERG Competency Domains → NICE Competency Areas | CERG Competency Domain | NICE Competency Area(s) | Description | |------------------------|------------------------|-------------| | Technical Depth | Technology Management; Systems Integration | Deep expertise in security technologies, architectures, and platforms | | Cross-Pillar Fluency | Interpersonal Skills; Systems Integration | Ability to work across Engineering, Risk, and Governance boundaries | | Risk Judgment | Risk Management; Threat Analysis | Sound judgment about security risk, severity, and treatment | | Communication | Interpersonal Skills; Communication | Clear, audience-appropriate communication of security concepts | | Operational Discipline | Process Management; Data Management | Reliable execution of security processes and evidence production | | Influence and Mentorship | Leadership; Training and Education | Developing others; shaping security culture and practice | | Compliance & Regulatory Literacy | Legal and Regulatory; Policy and Governance | Understanding and applying regulatory requirements | | Continuous Learning | Continuous Learning; Training and Education | Staying current; developing new capabilities | #### 9.1.2 Sample TKS References by Competency Domain | CERG Domain | NICE Task ID (Example) | NICE Knowledge ID (Example) | NICE Skill ID (Example) | |-------------|----------------------|----------------------------|------------------------| | Technical Depth | T0452: Develop security architectures | K0004: Knowledge of cybersecurity principles | S0005: Skill in applying security architecture methods | | Risk Judgment | T0043: Conduct risk assessments | K0002: Knowledge of risk management processes | S0034: Skill in conducting vulnerability assessments | | Compliance & Regulatory Literacy | T0034: Conduct security audits | K0060: Knowledge of applicable laws and regulations | S0025: Skill in evaluating security controls | | Operational Discipline | T0012: Maintain security documentation | K0023: Knowledge of configuration management | S0013: Skill in maintaining operational security | | Communication | T0295: Brief senior leadership on security posture | K0059: Knowledge of business continuity | S0012: Skill in preparing and presenting briefings | #### 9.1.3 CERG Role Family → NICE Work Role Mapping The complete mapping of all 27 canonical CERG roles to NICE Work Roles is maintained in [JF-002](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). The summary below maps role families to their primary NICE categories: | CERG Job Family | Primary NICE Category | Representative NICE Work Roles | |-----------------|----------------------|-------------------------------| | **JF-SECENG** (Security Engineering) | SP — Securely Provision | Security Architect (SP-ARC-001), Systems Security Analyst (OM-ANA-001) | | **JF-RISKOPS** (Risk Operations) | PR — Protect and Defend; AN — Analyze | Vulnerability Assessment Analyst (PR-VAM-001), Threat/Warning Analyst (AN-TWA-001) | | **JF-GOVCOMP** (Governance & Compliance) | OV — Oversee and Govern | Security Control Assessor (OV-SCA-001), Cyber Policy and Strategy Planner (OV-PSP-001) | | **JF-EXEC** (Executive) | OV — Oversee and Govern | Executive Cyber Leader (OG-WRL-001) | | **JF-ADJUNCT** (Incident Response) | PR — Protect and Defend | Cyber Defense Incident Responder (PR-CIR-001) | #### 9.1.4 How to Use the NICE TKS Database The full NICE TKS database is available as a downloadable CSV from the NICE Framework Resource Center at https://www.nist.gov/nice/framework/. For each CERG role, filter by the NICE Work Role(s) mapped to that role (see [JF-002](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md)) and extract the TKS statements. The most relevant 5-10 Task statements, 5-10 Knowledge statements, and 5-10 Skill statements should be included in each per-role description's §6 (NICE TKS Statement References). Organizations that need to demonstrate workforce alignment to NICE (e.g., federal agencies, defense contractors under DoD 8140.03) can map each CMP-001 behavioral anchor back to the relevant NICE KSAs using the cross-reference in NIST SP 800-181r1 Appendix C. ### 9.2 Other Frameworks The competency domains in this model are compatible with: - **DoD Cyber Workforce Framework (DCWF / DoD 8140.03)**: Work roles and proficiency levels map to CERG grades. Specialist (S1) aligns to DCWF Basic/Intermediate; Sr. Specialist (S2) to Intermediate/Advanced; Advisor (S3) to Advanced; Sr. Advisor (S4) to Advanced/Expert. - **SANS GIAC Role-Based Certifications**: GIAC certifications provide objective validation of Technical Depth for specific domains and can be referenced in development plans. - **ISC2 CISSP / CCSP / CSSLP**: These certifications validate breadth across multiple competency domains and are appropriate development targets for Advisor-level practitioners. - **ISACA CISA / CRISC / CISM / CGEIT**: These certifications validate Governance-family competencies and are appropriate for Governance practitioners and managers. The Training, Development, and Certification Framework (CERG-GOV-TRN-001) provides the full role-to-certification mapping and training curriculum. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CMP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to grade definitions, canonical role roster, or material shift in cybersecurity competency frameworks | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST NICE SP 800-181r1; NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2; DoD 8140.03 (DCWF) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Defines eight competency domains with leveled behavioral anchors for Engineering, Risk, and Governance role families across SME grades S1-S4. Provides management track competency addendum for M1-M4. Includes hiring, development, and promotion guidance. Maps competency domains to NIST NICE SP 800-181r1 and other industry frameworks. | ### Review Triggers - Change to the grade definitions in CERG-GOV-JA-001 - Change to the canonical role roster in CERG-GOV-OM-001 §6.1 - Material shift in cybersecurity competency frameworks (NICE, DCWF, industry certification bodies) - Feedback from promotion panels indicating anchors are unclear or inconsistent - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Architecture and Grade Framework | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions and progression dimensions | | CERG Job Descriptions | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | KSA requirements per role | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Performance Management Framework | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Promotion calibration and development planning process | | Training and Certification Framework | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Role-to-certification mapping | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Left-right knowledge model | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## CONTRACTOR AND NON-EMPLOYEE STAFF INTEGRATION GUIDE ### Role Eligibility · Knowledge Retention · Supervision · Onboarding and Offboarding --- | | | |---|---| | **Document ID** | CERG-GOV-CON-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) · [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | | **Review Cycle** | Annual / On any significant change to contractor population or engagement model | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.2 · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PS-7 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The Contractor Reality](#2-the-contractor-reality) 3. [Role Eligibility: Who Can Be a Contractor](#3-role-eligibility-who-can-be-a-contractor) 4. [Engagement Models](#4-engagement-models) 5. [Supervision and Accountability](#5-supervision-and-accountability) 6. [Knowledge Retention and Artifact Ownership](#6-knowledge-retention-and-artifact-ownership) 7. [Contractor Onboarding](#7-contractor-onboarding) 8. [Contractor Offboarding](#8-contractor-offboarding) 9. [Contractor Performance and Renewal](#9-contractor-performance-and-renewal) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope The CERG Framework (FRM-001) notes that the illustrative CERG team operates alongside "an equal population of consultants and contractors." The RACI Instrument (RAC-001) and Job Descriptions (JD-001) assume employees. The Onboarding Program (ONB-001) is built for permanent team members who will be with the organization for years, not contractors who may be engaged for a six-month audit cycle or a twelve-month platform migration. This document closes the gap. It defines which CERG roles can be filled by contractors and which must remain employee-only, establishes the knowledge retention requirements that prevent a departing contractor from taking the only copy of critical artifacts, defines the supervision model (every contractor has a named employee supervisor who is accountable for the contractor's work product), and provides condensed onboarding and offboarding programs for non-employee staff. It applies to all non-employee staff performing CERG work: independent contractors, consultants from professional services firms, staff augmentation personnel, and managed service providers whose personnel operate as embedded team members. It does not apply to external auditors, assessors, or penetration testing firms operating under a statement of work with defined deliverables and limited access, though the knowledge retention requirements in §6 apply to any artifacts those external parties produce. > **Contractors Are a Force Multiplier, Not a Replacement for Capability** > > A contractor can accelerate a cloud migration, clear a exposure backlog, or run a CMMC assessment readiness program. A contractor cannot be the organization's institutional memory, its regulatory relationship, or its leadership bench. The Framework envisions a CERG team where contractors supplement, not substitute for, the employee core. This document ensures that distinction does not blur in practice. --- ## 2. The Contractor Reality ### 2.1 Why CERG Organizations Use Contractors CERG-adopting organizations engage contractors for legitimate reasons: - **Surge capacity.** A major platform migration, an audit cycle, or a regulatory deadline creates temporary workload that does not justify permanent headcount. - **Specialized expertise.** A cryptographic migration, an OT security assessment, or a specific regulatory framework may require expertise the organization needs for 6-12 months and not permanently. - **Initial build-out.** An organization adopting CERG for the first time may use contractors to accelerate the build-out while recruiting permanent staff. - **Headcount constraints.** A budget that funds contractors but not employees is a reality in many organizations. The framework accommodates it without pretending it is ideal. ### 2.2 The Risks Every contractor engagement carries three risks that this document is designed to mitigate: 1. **Knowledge flight.** A contractor who builds the threat model, designs the detection pipeline, or structures the evidence library and then departs takes that knowledge with them. If the knowledge is not captured in CERG repositories before they leave, the organization has lost both the person and the capability. 2. **Accountability diffusion.** A contractor who reports to an account manager at their firm, not to a CERG manager, operates without the performance management, feedback, and development that ensure quality. When the contractor's work is inadequate, the CERG manager may not discover it until the engagement ends and the cleanup falls to employees. 3. **Cultural separation.** A contractor who is not included in team meetings, not given a CERG buddy, and not expected to understand the left-right model operates as a hired tool, not a team member. Their work reflects their isolation: it meets the letter of the statement of work but misses the context that makes it integrate with the rest of CERG's output. --- ## 3. Role Eligibility: Who Can Be a Contractor ### 3.1 The Eligibility Matrix | Canonical Role | Contractor Eligible? | Rationale | |---|---|---| | **CISO** | No | Executive role. Must be an employee. | | **Executive Sponsor** | No | Business-side role; by definition an organizational insider. | | **Engineering Pillar Leader** | No | Management role with organizational authority, budget ownership, and strategic accountability. | | **Risk Pillar Leader** | No | Same rationale as Engineering Pillar Leader. | | **Governance Pillar Leader** | No | Same rationale. Additionally, the regulatory relationships this role carries cannot reside with a non-employee. | | **Cloud Security Engineer** | Yes | Surge capacity for cloud migrations, platform build-outs, and specific cloud expertise is a common contractor use case. | | **Identity Engineer** | Yes | Specialized identity platform expertise (PAM deployment, federation architecture) is often contractor-delivered. | | **OT Security Engineer** | Conditional | Yes for specific OT security assessments or architecture engagements. No for ongoing OT security operations in a NERC-CIP environment, where CIP-004 personnel risk assessment requirements make contractor use administratively heavy. | | **Application Security Engineer** | Yes | Application security testing, SDLC integration, and tool deployment are common contractor engagements. | | **Endpoint Engineer** | Yes | EDR deployment and migration are common contractor use cases. | | **Cryptography Engineer** | Conditional | Yes for specific cryptographic migration or PKI deployment projects. No for ongoing key management operations due to the sensitivity of key material access. | | **Exposure Management Lead** | Conditional | Yes for initial VM program build-out or backlog clearance. No for ongoing VM operations in a regulated environment, where the person managing vulnerability data should be an employee. | | **Adversarial Testing Lead** | Yes | Penetration testing and red team operations are commonly contractor-delivered. A contractor Adversarial Testing Lead must be supervised by the Risk Pillar Leader; their findings become organizational risk register entries owned by employees. | | **Threat Intelligence Analyst** | Yes | Threat intelligence production can be contractor-delivered, especially for sector-specific threat expertise. | | **Vendor Risk Analyst** | Yes | Vendor assessment surge capacity (clearing a backlog, supporting a major procurement cycle) is a common contractor use case. | | **OT Risk Analyst** | Conditional | Same rationale as OT Security Engineer: yes for specific assessments, no for ongoing operations in CIP environments. | | **Identity Risk Analyst** | Yes | UEBA deployment and identity threat detection rule authoring can be contractor-delivered. | | **Detection Engineer** | Yes | Detection rule authoring and SIEM migration are common contractor engagements. | | **NERC-CIP Compliance Manager** | No | Regulatory relationship role. The person who represents the organization to its regional entity must be an employee. | | **CMMC / Federal Compliance Manager** | No | Same rationale. The person who signs or represents the organization's CMMC posture must be an employee. | | **SOX ITGC Lead** | Conditional | Yes for SOX readiness or remediation projects. No for ongoing SOX ITGC operations with external auditor relationship. | | **Policy & Standards Manager** | Conditional | Yes for document library build-out or framework migration. No for ongoing policy and standards management, which requires organizational authority to enforce. | | **Risk Register Owner** | No | The person who curates the risk register and runs the Monthly Risk Register Review must be an employee. Risk acceptance decisions and exception management require organizational authority. | | **Evidence Librarian** | Yes | Evidence collection and organization can be contractor-delivered, especially during audit preparation surges. | ### 3.2 The "Must Be Employee" Principle A role must be filled by an employee when it: - Holds risk acceptance or approval authority - Maintains a primary regulatory relationship with an external auditor, assessor, or regulator - Manages employees (contractors cannot supervise employees) - Makes or concurs on budget decisions - Is accountable for organizational strategy or policy enforcement > **"Conditional" Means "Ask Before You Engage"** > > A role marked Conditional is not a blanket authorization. Each Conditional contractor engagement requires the pillar leader and the CISO to confirm that the specific engagement does not cross the "must be employee" boundaries above. Document the confirmation. A Conditional role engaged without this confirmation is a compliance finding waiting to happen. --- ## 4. Engagement Models ### 4.1 Staff Augmentation The contractor operates as an embedded team member under the day-to-day direction of a CERG employee manager. They attend team meetings, use CERG tools and repositories, and follow CERG procedures. Their deliverables are integrated into the team's standing output, not delivered as a separate work product. **Best for:** Surge capacity in roles where the work is ongoing and the contractor needs to collaborate closely with the team (Cloud Security Engineer, Detection Engineer, Vendor Risk Analyst). **Supervision:** Daily direction from a named CERG employee. The contractor's firm provides administrative support (payroll, benefits, compliance) but does not direct the work. ### 4.2 Project-Based Engagement The contractor or consulting firm delivers a defined scope of work against a statement of work with milestones, deliverables, and acceptance criteria. The contractor operates with a degree of independence, providing updates at defined intervals rather than participating in daily team operations. **Best for:** Specialized, time-bounded initiatives (PKI migration, CMMC assessment readiness, SIEM deployment, exposure backlog clearance). **Supervision:** The CERG employee who owns the project outcome is accountable for the contractor's deliverables. The contractor manages their own day-to-day work within the SOW boundaries. ### 4.3 Managed Service An external provider operates a CERG function or sub-function on an ongoing basis. For example, a managed security service provider (MSSP) operating the SIEM and detection pipeline, or a third-party risk management firm conducting vendor assessments. **Best for:** Functions that are important but not core to the organization's differentiated security capability, or functions where the organization cannot recruit and retain the necessary expertise. **Supervision:** A CERG employee (typically a pillar leader or senior manager) owns the service relationship, reviews service levels, and is accountable for the function's output. The managed service provider operates per a service level agreement (SLA) with defined metrics, escalation paths, and regular service reviews. --- ## 5. Supervision and Accountability ### 5.1 The Named Supervisor Rule Every contractor, regardless of engagement model, has a named CERG employee who is accountable for the contractor's work product. The supervisor: - Approves the contractor's access to CERG systems, tools, and repositories - Reviews the contractor's work at defined intervals appropriate to the engagement (daily for staff augmentation, milestone-based for project engagements, monthly for managed services) - Is the escalation point for issues with the contractor's quality, responsiveness, or conduct - Signs off on the contractor's deliverables before they are accepted as complete - Ensures the contractor's artifacts are stored in CERG repositories (§6) - Conducts the contractor's offboarding (§8) The supervisor is not the contractor's "manager" in the employment sense. They do not conduct performance reviews, approve time off, or manage the contractor's career development. They are accountable for what the contractor produces and for ensuring the organization retains it when the contractor leaves. ### 5.2 Supervision by Engagement Model | Engagement Model | Supervision Cadence | Review Method | |---|---|---| | **Staff Augmentation** | Daily or near-daily | Work product review; inclusion in team meetings and rituals; informal feedback as with employees | | **Project-Based** | Weekly or milestone-based | Deliverable review against SOW; progress against timeline; issue escalation | | **Managed Service** | Monthly service review; quarterly business review | SLA performance review; service improvement planning; relationship health check | --- ## 6. Knowledge Retention and Artifact Ownership ### 6.1 The Repository Rule All contractor-produced artifacts must be stored in CERG-controlled repositories, not on contractor devices, contractor firm systems, or contractor-managed cloud platforms. This applies to: - Code: Infrastructure-as-code, policy-as-code, detection rules, automation scripts - Documents: Architecture diagrams, threat models, risk assessments, compliance documentation, finding reports - Configurations: Tool configurations, platform settings, baseline definitions - Data: Scan results, assessment data, evidence items, risk register entries - Credentials: No contractor stores CERG credentials outside the organization's approved secrets management system ### 6.2 The Artifact Handoff Protocol At defined intervals (at least monthly for staff augmentation, at each milestone for project engagements, and at minimum quarterly for managed services), the contractor transfers all work-in-progress artifacts to the CERG repository. The supervisor verifies the transfer by: 1. Confirming that the artifacts exist in the CERG repository 2. Opening a sample of artifacts to confirm they are complete and usable, not stubs 3. Confirming that the contractor has not retained copies on non-CERG systems (for regulated environments, this may require a documented verification) ### 6.3 Prohibited Practices The following are explicitly prohibited: - **Contractor-maintained repositories.** A contractor who sets up a GitHub organization, a shared drive, or a Confluence space for CERG work has created a knowledge silo the organization cannot access when the contractor leaves. All work product must flow into CERG repositories within one week of creation. - **Contractor-owned tooling accounts.** A contractor who registers a cloud security tool, a threat intelligence platform, or a GRC instance under their own or their firm's account has created an access dependency. All CERG tooling must be provisioned under organizational accounts. - **Contractor-exclusive knowledge.** A contractor who is the only person who knows how a specific tool is configured, a specific process works, or a specific system is architected represents a knowledge flight risk. The supervisor must ensure that at least one employee understands the contractor's work well enough to operate it after the contractor departs. > **The Contractor's Laptop Is Not the Organization's Repository** > > A contractor who leaves with the only copy of the threat model on their laptop has not delivered a threat model; they have borrowed one to the organization for the duration of their engagement. The artifact handoff protocol exists to ensure that borrowed becomes owned before the engagement ends. --- ## 7. Contractor Onboarding ### 7.1 Condensed Onboarding Program Contractors follow a condensed version of the employee onboarding program (ONB-001). The condensed program recognizes that a contractor engaged for 3-12 months does not need the full 90-day program but does need enough context to be effective and enough access to be productive. | Timeframe | Activity | |---|---| | **Before day one** | Supervisor provisions access per ONB-001 §3. Supervisor prepares a contractor-specific 30-day plan focused on the engagement's objectives, not long-term development. | | **Day one** | Access verification. CERG overview (90-minute version: what CERG is, the three pillars, the contractor's role in the engagement). Introduction to immediate teammates. | | **Week one** | Read CERG 101 core documents relevant to the engagement (FRM-001 §§1-3, OM-001 §§3-4, the standards and procedures specific to the contractor's domain). Meet key stakeholders. Begin work under supervision. | | **Day 30** | First artifact handoff (§6.2). Supervisor review of work quality and integration with the team. Adjustment of scope, access, or supervision based on first-month performance. | ### 7.2 What Contractors Do Not Receive Contractors do not receive: - **CERG 101 full curriculum.** The condensed reading is sufficient for a time-bounded engagement. - **Cross-pillar rotation.** Contractors may interact with other pillars as their work requires but are not assigned formal rotation days. - **Career development planning.** The contractor's development is their firm's responsibility, not CERG's. - **Performance reviews in the CERG format.** The contractor's performance is evaluated against their SOW, not against CMP-001 competency anchors. - **A CERG buddy.** The supervisor provides the orientation and support a buddy would provide. ### 7.3 Access Limitations Contractor access to CERG systems is role-appropriate and time-bounded: - Access is provisioned for the duration of the engagement plus a defined transition period, not indefinitely - Access to the risk register, evidence library, and policy repository is read/write as needed for the role but audited - Access to sensitive systems (PAM, HSM, key management, board reporting) is limited and logged - All contractor access is reviewed at each artifact handoff and revoked at offboarding --- ## 8. Contractor Offboarding ### 8.1 The Offboarding Checklist Contractor offboarding begins two weeks before the engagement end date (or immediately, if the engagement ends early). The supervisor and the contractor complete the following checklist: | Item | Owner | Timeline | |---|---|---| | **Final artifact handoff.** All contractor-produced artifacts are in CERG repositories. The supervisor has verified completeness (§6.2). | Supervisor + Contractor | No later than 3 business days before end date | | **Knowledge transfer.** The contractor has documented or verbally transferred any undocumented knowledge about their work to the supervisor or a designated employee. This includes: tool configurations, known issues, workarounds, undocumented dependencies, and "the thing I was going to fix next week." | Contractor + Supervisor | No later than 3 business days before end date | | **Access revocation.** All system access, accounts, credentials, VPN, and physical access are revoked. The supervisor confirms with IT/security that revocation is complete. | Supervisor + IT | End date (no later than end of business) | | **Credential rotation.** Any credentials the contractor had access to (service accounts, API keys, shared secrets) are rotated within 5 business days of the end date. | Supervisor + relevant Engineering team | Within 5 business days | | **Equipment return.** All organization-owned equipment is returned, wiped, or remotely deprovisioned. | Supervisor + IT | End date | | **Data retention confirmation.** The contractor confirms in writing that they have not retained CERG data, artifacts, or credentials on personal or firm-owned systems. For regulated environments, this confirmation may be a contractual obligation in the SOW. | Contractor | End date | | **Exit interview (optional).** For long-duration or high-impact engagements, the supervisor conducts a 30-minute exit interview: what worked, what did not, what would the contractor recommend CERG do differently? The feedback is documented and reviewed for engagement model improvements. | Supervisor | Before end date | ### 8.2 Post-Departure Verification Within one week of the contractor's departure: 1. The supervisor opens and verifies that key artifacts can be accessed and understood by an employee who was not involved in the engagement. The test: can a peer pick up where the contractor left off? 2. The supervisor confirms that no standing meetings, automated reports, or scheduled processes depend on the contractor's account or credentials. 3. If the engagement will be renewed or a replacement contractor engaged, the supervisor documents lessons learned for the next engagement. > **Offboarding Is Not Complete Until the Artifacts Are Verified** > > A contractor who hands over a repository link, shakes hands, and departs has been transitioned. A contractor whose artifacts have been opened, read, and confirmed usable by an employee who was not part of the engagement has been offboarded. The difference is the difference between a knowledge transfer that happened and one that was assumed to have happened. Assume nothing. Verify. --- ## 9. Contractor Performance and Renewal ### 9.1 Performance Evaluation Contractor performance is evaluated against the SOW, not against CMP-001 competency anchors. The evaluation addresses: | Dimension | Question | |---|---| | **Quality** | Does the contractor's work meet the standard defined in the SOW? Does it integrate with the team's work without requiring significant rework? | | **Timeliness** | Are deliverables on schedule? Are issues escalated early or discovered late? | | **Collaboration** | Does the contractor communicate effectively with the team? Do they share knowledge or hoard it? Do they follow CERG procedures or work around them? | | **Knowledge transfer** | Is the contractor producing artifacts that are complete and usable? Are they documenting their work without being chased? | ### 9.2 Engagement Renewal Contractor engagement renewal is a deliberate decision, not an automatic extension. The supervisor evaluates: 1. **Is the work still needed?** The surge that justified the engagement may have passed. 2. **Has the organization developed internal capability?** The engagement may have served its purpose of bridging to an employee hire or developing an internal team member. 3. **Is the contractor the right resource?** The evaluation dimensions above inform whether the same contractor or firm should be re-engaged. 4. **Is the engagement model still appropriate?** A project-based engagement that has become ongoing operational work should be converted to staff augmentation or a managed service, or the work should be absorbed by employees. An engagement that is renewed more than twice should trigger a review of whether the role should be converted to an employee position. A function that depends on contractors indefinitely has a structural gap that headcount planning should address. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-CON-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any significant change to contractor population or engagement model | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2; NIST 800-53r5 PS-7 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Defines role eligibility matrix identifying which CERG roles can be contractor-filled and which must remain employee-only. Establishes three engagement models (staff augmentation, project-based, managed service), the named supervisor rule, knowledge retention and artifact handoff protocols, condensed contractor onboarding program, mandatory offboarding checklist with post-departure verification, and contractor performance evaluation and renewal criteria. | ### Review Triggers - Material change to the contractor population (new roles engaged, significant increase in contractor ratio) - Change to regulatory requirements affecting contractor personnel (CIP-004, CMMC, etc.) - Lessons learned from a contractor engagement that ended with knowledge retention issues - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster; engagement models | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade structure (contractors are typically engaged at S2-S4 level) | | RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Accountabilities that determine role eligibility | | Onboarding Program | [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | Full employee onboarding (condensed version for contractors) | | Implementation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Organizational adoption of CERG | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Illustrative staffing model referencing contractors | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## JOB ARCHITECTURE AND GRADE FRAMEWORK ### Grade Definitions · Progression Ladders · Leveling Guide · Career Pathing --- | | | |---|---| | **Document ID** | CERG-GOV-JA-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | | **Review Cycle** | Annual / On any change to the canonical role roster or organizational design | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · [NIST NICE Workforce Framework](https://www.nist.gov/itl/applied-cybersecurity/nice) (SP 800-181r1) · ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Design Principles](#2-design-principles) 3. [The Two-Track Model](#3-the-two-track-model) 4. [SME Progression: Grade Definitions](#4-sme-progression-grade-definitions) 5. [Management Progression: Grade Definitions](#5-management-progression-grade-definitions) 6. [Leveling Guide: Dimensions of Growth](#6-leveling-guide-dimensions-of-growth) 7. [Role-to-Grade Mapping](#7-role-to-grade-mapping) 8. [Career Pathing: Moving Between Tracks and Pillars](#8-career-pathing-moving-between-tracks-and-pillars) 9. [Span of Control and Team Design](#9-span-of-control-and-team-design) 10. [Compensation Philosophy](#10-compensation-philosophy) 11. [Adapting Grade Titles to Your Organization](#11-adapting-grade-titles-to-your-organization) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The CERG Framework, the Operating Model, and the RACI Instrument define what work gets done, who is accountable, and how the pillars hand off to one another. What those documents do not answer is how the people doing the work grow, how a hiring manager knows which grade to open a requisition at, or how a team member understands what the next level looks like. This document answers those questions. It establishes the two-track grade structure (SME and Management), defines the expectations at each grade, maps every canonical CERG role to its grade range, and provides the leveling guide a manager uses to calibrate performance and promotion decisions. It applies to every canonical CERG role defined in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1, excluding the two Adjacent Incident Response roles (Incident Commander, Lead Investigator) which belong to the standing IR team. It does not create new roles. It layers progression structure onto the canonical roster established in the Operating Model. > **Architecture Before Requisitions** > > A CISO who opens a requisition for a "senior security person" without a grade framework will calibrate every offer against the last person hired, not against a defined standard. The result is compression, inequity, and a team where nobody can explain what it takes to reach the next level. This document is the antidote. Read it before you write your first job description. Use it to calibrate every offer, every promotion, and every development conversation. --- ## 2. Design Principles 1. **Two tracks, equal ceiling.** The SME track and the Management track carry equivalent organizational weight. A Sr. Advisor and a Senior Manager sit at comparable levels of influence, compensation, and expectations. No one is forced into management to advance. 2. **Role titles and grade titles are separate.** A "Cloud Security Engineer" is a role. "Specialist" is a grade. The same role may be filled at Specialist, Sr. Specialist, Advisor, or Sr. Advisor, depending on the person's experience and capability. The role title answers "what domain do you work in?" The grade title answers "at what level do you operate?" 3. **Progression is earned, not tenured.** Years of experience is an input to grade placement, not a guarantee of it. Progression requires demonstrated growth across defined dimensions: scope, autonomy, influence, and craft mastery. 4. **Span of control is explicit.** Management grades define the scope a manager is expected to lead. A Manager running a 15-person team without the title or compensation to match is a retention risk. This framework makes that mismatch visible. 5. **Scales down without breaking.** A 5-person CERG team has no Principal Managers and probably no Managers at all. The grade definitions still hold: the CISO knows that the person running all of Risk is performing at a Director-level scope and should be treated accordingly, even if the organization uses a flat title. --- ## 3. The Two-Track Model CERG recognizes two parallel progression tracks. Every role in the Operating Model falls onto one of them, and the majority of roles can be filled on either track depending on the person and the team's needs. | **Track** | **Grades (ascending)** | **Typical Roles** | **Core Question** | |---|---|---|---| | **SME (Individual Contributor)** | Specialist, Sr. Specialist, Advisor, Sr. Advisor | Engineers, Analysts, the Evidence Librarian | How deep and how broad is your influence without direct authority? | | **Management** | Manager, Senior Manager, Principal Manager, Director | Pillar Leaders, functional leads, team supervisors | How many people and how much scope do you lead, and at what level of abstraction? | The two tracks intersect at the Director level. A Director may rise through either track. A Sr. Advisor who has led major cross-pillar initiatives, shaped reference architecture, and influenced executive decisions is operating at the same altitude as a Director who rose through management. The expectations converge. > **Not Up-or-Out** > > The SME track is a career, not a waiting room for management. An Advisor who stays at Advisor for a decade, deepening their craft and mentoring every new engineer who comes through the pillar, is a success story, not a stagnation case. The grade framework defines what each level looks like so that staying at a level is a deliberate choice, not an unexplained ceiling. --- ## 4. SME Progression: Grade Definitions The SME track is for individual contributors who deliver through expertise, not through managing people. An SME may lead projects, mentor, set technical direction, and represent CERG in senior forums, but they do not carry formal people-management accountability. ### 4.1 Specialist (Grade S1) The entry and early-career grade. A Specialist delivers defined work with guidance. | Dimension | Expectation | |---|---| | **Scope** | A single domain within one pillar. Executes assigned tasks. Works from established procedures. | | **Autonomy** | Requires regular direction from a senior team member or manager. Task-level decisions are made independently; approach-level decisions are reviewed. | | **Influence** | Influences their immediate team through the quality of their work. Not expected to represent the pillar externally. | | **Craft Mastery** | Developing competence in one security domain. Knows the relevant CERG standards and procedures. Can execute the procedures with minimal error. | | **Typical Experience** | 0-3 years in cybersecurity or a related technical field. | **What growth to Sr. Specialist looks like:** The Specialist begins to own outcomes, not just tasks. They complete a procedure and recognize when the procedure's output needs interpretation. They start to see patterns across their work and raise them. They need less direction on approach. ### 4.2 Sr. Specialist (Grade S2) The competent, independent practitioner. A Sr. Specialist owns defined work streams end to end. | Dimension | Expectation | |---|---| | **Scope** | A primary domain plus familiarity with adjacent domains in the same pillar. Owns a work stream (e.g., cloud posture management, vendor assessments for a business unit, a set of detection rules). | | **Autonomy** | Works independently day to day. Escalates appropriately. Chooses their own approach within established boundaries. | | **Influence** | A recognized expert within their pillar on their domain. Other team members seek their input. May represent the pillar in cross-functional working groups. | | **Craft Mastery** | Deep competence in their primary domain. Can author new procedures and improve existing ones. Can onboard a new Specialist without assistance. | | **Typical Experience** | 3-7 years in cybersecurity or a related technical field. | **What growth to Advisor looks like:** The Sr. Specialist expands beyond their home pillar. A Risk Sr. Specialist begins to understand how Engineering consumes their output. A Governance Sr. Specialist begins to anticipate what Engineering and Risk will need from a standard before they ask. They start to lead initiatives, not just execute them. ### 4.3 Advisor (Grade S3) The cross-pillar expert and organizational resource. An Advisor shapes how work is done, not just how well it is executed. | Dimension | Expectation | |---|---| | **Scope** | Deep expertise in their primary domain with working knowledge across all three pillars. Shapes the approach for major initiatives. Anticipates cross-pillar impacts of decisions in their domain. | | **Autonomy** | Operates with minimal direction. Defines their own work priorities in alignment with pillar objectives. Their manager sets outcomes; the Advisor determines the path. | | **Influence** | A trusted advisor to pillar leaders and to adjacent functions. Represents CERG in senior technical forums. Mentors Specialists and Sr. Specialists across pillars. Their technical recommendations are rarely overruled. | | **Craft Mastery** | Authority in their domain. Contributes to the CERG standards and procedures as an author, not just a user. Can design new procedures and lead their adoption. Recognized outside the immediate team for their expertise. | | **Typical Experience** | 7-12 years in cybersecurity, with meaningful cross-pillar exposure. | **What growth to Sr. Advisor looks like:** The Advisor begins to operate at the organizational level. They do not just anticipate cross-pillar impacts; they shape the organization's response to them. They are the person a pillar leader calls when a novel problem does not fit any existing procedure. Their written analysis is treated as authoritative. They influence budget, strategy, and organizational design. ### 4.4 Sr. Advisor (Grade S4) The organizational authority. A Sr. Advisor operates at the level of a pillar leader without carrying management accountability. They are the person the CISO calls for an independent technical assessment. | Dimension | Expectation | |---|---| | **Scope** | Organization-wide. Shapes strategy across all three pillars. Called upon for the hardest problems that span domains, pillars, and organizational boundaries. May lead major cross-functional initiatives. | | **Autonomy** | Self-directed against organizational objectives. Defines what problems are worth solving, not just how to solve them. Their manager reviews outcomes; the Sr. Advisor sets the agenda. | | **Influence** | Influences CISO-level decisions. Represents the organization externally (industry working groups, regulatory forums, conference presentations). Shapes the development of the entire CERG team through mentoring, standards authorship, and by setting the technical bar. | | **Craft Mastery** | Broad and deep. Can step into any pillar's domain and contribute meaningfully within days. Writes the standards and procedures others follow. Their judgment on technical risk is treated as equivalent to a pillar leader's. | | **Typical Experience** | 12+ years in cybersecurity, with demonstrated cross-pillar and organizational impact. | > **The Sr. Advisor Is Not a Manager-in-Waiting** > > A Sr. Advisor who transitions to management starts at a management grade commensurate with their demonstrated leadership scope, not at the bottom. The skills are different, but the altitude is not. A Sr. Advisor moving into a Director role is a lateral move in organizational weight, not a promotion. The compensation and title should reflect that. --- ## 5. Management Progression: Grade Definitions The Management track is for leaders who deliver through other people. A CERG manager is accountable for their team's output, their team's development, and the health of their pillar's operations. CERG managers are expected to retain technical fluency: a manager who cannot read a vulnerability report or evaluate an architecture decision cannot effectively lead a CERG team. ### 5.1 Manager (Grade M1) The first-line people leader. A Manager leads a small team of individual contributors within a single domain. | Dimension | Expectation | |---|---| | **Span of Control** | 3-8 direct reports. All reports operate within the same functional domain (e.g., a Exposure Management team, a Cloud Security Engineering team). | | **Scope** | Accountable for the team's delivery against defined objectives. Translates pillar goals into team tasks. Runs team rituals (standups, retrospectives, 1:1s). | | **People Leadership** | Hires, onboards, develops, and performance-manages their team. Conducts regular 1:1s with meaningful development conversations. Manages performance issues promptly. | | **Technical Fluency** | Retains working knowledge of their team's domain. Can review and approve the team's technical output. Does not need to be the deepest expert on the team, but must be capable of evaluating expert work. | | **Operational Accountability** | Escalates risks and blockers to their Senior Manager or Director. Ensures their team's procedures are followed and their evidence is collected. Represents the team in cross-functional forums. | | **Typical Experience** | 5-10 years in cybersecurity, including 1-3 years of demonstrated people leadership or equivalent team-lead experience. | **What growth to Senior Manager looks like:** The Manager develops their team to the point where daily operations run without the manager's direct intervention. They begin to influence how other teams in the pillar operate. They take on cross-team initiatives. Their team's output is consistently strong and their retention is healthy. ### 5.2 Senior Manager (Grade M2) The multi-team leader. A Senior Manager leads a function that may span multiple related domains, with other managers or team leads reporting to them. | Dimension | Expectation | |---|---| | **Span of Control** | 8-20 people, typically through 1-3 Managers or team leads. | | **Scope** | Accountable for a function within a pillar (e.g., all of Exposure Management and Adversarial Testing within Risk, all Cloud and Identity Engineering within Engineering). Defines the function's strategy and roadmap. | | **People Leadership** | Develops the Managers reporting to them. Ensures consistent people-management practices across the function. Owns workforce planning: headcount requests, role design, succession planning. | | **Technical Fluency** | Broad understanding across the function's domains. Can evaluate technical trade-offs between teams. Represents the function's technical position to pillar leadership and to other pillars. | | **Operational Accountability** | Accountable for the function's KPIs. Owns the function's budget input. Represents the function in pillar-leadership forums. Manages cross-functional dependencies. | | **Typical Experience** | 10-15 years in cybersecurity, including 3-5 years of people management. | **What growth to Principal Manager looks like:** The Senior Manager runs a function that operates with minimal escalation. Their Managers are themselves developing into Senior Managers. The function's strategy is aligned with organizational strategy without constant translation. They begin to contribute to pillar-wide decisions that go beyond their function. ### 5.3 Principal Manager (Grade M3) The pillar-wide leader or multi-function executive. A Principal Manager leads a substantial portion of a pillar or a cross-pillar program with organizational-level impact. | Dimension | Expectation | |---|---| | **Span of Control** | 15-40 people, typically through 2-4 Senior Managers or Managers. May also directly lead senior individual contributors. | | **Scope** | Accountable for a major segment of a pillar or a cross-pillar program (e.g., all of Engineering Operations, all of Risk Assessment and Testing, all of Governance Compliance). Contributes to pillar strategy and organizational design. | | **People Leadership** | Shapes the people strategy for their scope: hiring profile, retention approach, development pathways. Builds a leadership bench. Ensures the management culture under them reflects CERG values. | | **Technical Fluency** | Broad understanding across the pillar. Can represent the pillar's technical position to the CISO, to other pillars, and to external stakeholders. Does not need depth in every domain but must know enough to evaluate the people who do. | | **Operational Accountability** | Accountable for pillar-level outcomes within their scope. Owns significant budget lines. Represents CERG to executive stakeholders for their domain. Contributes to organizational risk decisions. | | **Typical Experience** | 12-18 years in cybersecurity, including 5-10 years of people management at increasing scope. | **What growth to Director looks like:** The Principal Manager operates at a scope where the CISO delegates significant authority. They run their portion of the pillar with minimal oversight. They are a peer to pillar leaders in other functions. Their judgment on major decisions is trusted without review. They are ready for Director when their scope expands to include the full pillar or a cross-pillar mandate. ### 5.4 Director (Grade M4) The pillar leader or cross-functional executive. A Director is accountable for an entire pillar or a cross-cutting organizational function. In the CERG model, each pillar leader is a Director reporting to the CISO. | Dimension | Expectation | |---|---| | **Span of Control** | 10-60+ people, depending on organizational scale. The full Engineering, Risk, or Governance pillar. | | **Scope** | Full accountability for a pillar: strategy, delivery, budget, talent, and stakeholder relationships. Sets the pillar's multi-year direction. Represents the pillar to the CISO, the board (as requested), regulators, and industry peers. | | **People Leadership** | Accountable for the entire pillar's talent health. Owns the pillar's organizational design. Develops the next generation of CERG leaders. Builds a culture of cross-pillar collaboration and continuous improvement. | | **Technical Fluency** | Authoritative understanding of the pillar's domains. Can engage credibly with senior individual contributors on technical matters. Represents the organization's security posture to non-technical executives and to technically sophisticated regulators. | | **Operational Accountability** | Accountable for all pillar outcomes. Owns the pillar's budget. Makes or concurs on risk acceptance decisions per the authority table in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. Accountable for the pillar's contribution to CISO and board reporting. | | **Typical Experience** | 15+ years in cybersecurity, including 8+ years of progressive management experience. | > **Director Is Not a Reward for Tenure** > > The Director grade is the narrowest gate in the framework. It requires demonstrated ability to lead at organizational scale, to manage budgets, to represent the organization externally, and to develop other leaders. A Principal Manager who has never managed a budget, never hired and developed another manager, or never represented the organization to a regulator or auditor is not ready for Director regardless of years of service. --- ## 6. Leveling Guide: Dimensions of Growth Progression across grades is evaluated along five dimensions. A person does not need to demonstrate every dimension at the target grade to be promoted, but a promotion case should address each dimension honestly. The dimensions are cumulative: what distinguished a Sr. Specialist from a Specialist remains true at Advisor, but new capabilities are added. ### 6.1 The Five Dimensions | **Dimension** | **What It Measures** | |---|---| | **Scope** | The breadth and complexity of the work you own. From a single task to an organizational function. | | **Autonomy** | How much direction you need and how much you provide to others. From "tell me what to do" to "I set the agenda." | | **Influence** | Who listens to you and on what topics. From your immediate team to the CISO and the industry. | | **Craft Mastery** | The depth and breadth of your technical or domain expertise. From learning the procedures to writing them. | | **Organizational Impact** | The material consequence of your work. From task completion to organizational strategy. | ### 6.2 The Dimension Matrix | Grade | Scope | Autonomy | Influence | Craft Mastery | Organizational Impact | |---|---|---|---|---|---| | **Specialist** | Single domain, assigned tasks | Needs direction on approach | Immediate team | Learning the craft | Task completion | | **Sr. Specialist** | Primary domain plus awareness of adjacencies | Independent day to day; escalates appropriately | Recognized within pillar | Deep in one domain | Work stream ownership | | **Advisor** | Cross-pillar awareness; shapes approach | Self-directed against objectives | Trusted by pillar leaders | Authority in domain; authors standards | Initiative leadership | | **Sr. Advisor** | Organization-wide; sets agenda | Defines what problems matter | Influences CISO decisions | Broad and deep; sets the bar | Organizational strategy | | Grade (Mgmt) | Scope | Autonomy | Influence | Craft Mastery | Organizational Impact | |---|---|---|---|---|---| | **Manager** | Single team, single domain | Translates goals into team tasks | Team and peer managers | Working knowledge of team's domain | Team delivery | | **Senior Manager** | Multi-team function | Defines function strategy | Function and pillar leadership | Broad across function's domains | Function outcomes and KPIs | | **Principal Manager** | Major pillar segment or cross-pillar program | Contributes to pillar strategy | Executive stakeholders | Broad across pillar | Pillar-level outcomes | | **Director** | Full pillar or cross-cutting function | Sets multi-year direction | CISO, board, regulators, industry | Authoritative in pillar domains | Organizational strategy and risk | --- ## 7. Role-to-Grade Mapping Every canonical CERG role maps to a grade range. The range defines the grades at which that role can be filled, from entry to terminal. The terminal grade is the highest level at which a person can remain in that role without transitioning to a different role or to management. Roles are not locked into a single grade. A "Threat Intelligence Analyst" can be a Specialist learning the craft or a Sr. Advisor whose assessments shape organizational strategy. The role title stays the same; the grade changes. ### 7.1 Executive | Canonical Role | Job Family | Track | Grade Range | Terminal Grade | NICE Work Role | Notes | |---|---|---|---|---|---|---| | Chief Information Security Officer (CISO) | JF-EXEC | Executive | Above grade structure | N/A | Executive Cyber Leader (OG-WRL-001) | Reports to CEO/board. Not mapped to the CERG grade framework. | | Executive Sponsor | JF-EXEC | Business | N/A | N/A | Business-side role outside CERG grade model | Business-side role. Not a CERG employee. | ### 7.2 Engineering Pillar | Canonical Role | Job Family | Track | Grade Range | Terminal Grade | NICE Work Role | Notes | |---|---|---|---|---|---|---| | Engineering Pillar Leader | JF-SECENG | Management | M4 (Director) | M4 | Exec Cyber Leader / Security Architect (OG-WRL-001 / SP-ARC-001) | Full pillar accountability. Reports to CISO. | | Cloud Security Engineer | JF-SECENG | SME | S1-S4 | S4 | Security Architect (SP-ARC-001) | May specialize further (AWS, Azure, SaaS). | | Identity Engineer | JF-SECENG | SME | S1-S4 | S4 | Systems Security Analyst (OM-ANA-001) | May specialize in IGA, PAM, or federation. | | OT Security Engineer | JF-SECENG | SME | S2-S4 | S4 | Security Architect (SP-ARC-001) | Requires OT/ICS experience. Rarely filled below S2. | | Application Security Engineer | JF-SECENG | SME | S1-S4 | S4 | Secure Software Assessor (SP-DEV-001) | May specialize in SAST/DAST tooling or secure code review. | | Endpoint Engineer | JF-SECENG | SME | S1-S3 | S3 | Systems Security Analyst (OM-ANA-001) | Broader scope at S4 would typically transition to Cloud Security Engineer or a cross-domain Advisor role. | | Cryptography Engineer | JF-SECENG | SME | S2-S4 | S4 | Security Architect (SP-ARC-001) | Requires cryptography expertise. Rarely filled below S2. | | Pre-production Reviewer | JF-SECENG | SME (rotated) | S2-S4 | N/A | Security Control Assessor (OV-SCA-001) | A function, not a permanent role. Rotated among qualified Engineers. | ### 7.3 Risk Pillar | Canonical Role | Job Family | Track | Grade Range | Terminal Grade | NICE Work Role | Notes | |---|---|---|---|---|---|---| | Risk Pillar Leader | JF-RISKOPS | Management | M4 (Director) | M4 | Exec Cyber Leader / Vuln Assessment Analyst (OG-WRL-001 / PR-VAM-001) | Full pillar accountability. Reports to CISO. | | Exposure Management Lead | JF-RISKOPS | Management | M1-M3 | M3 | Vulnerability Assessment Analyst (PR-VAM-001) | Leads VM operations. In a small team, may be an SME at S3-S4. | | Adversarial Testing Lead | JF-RISKOPS | Management | M1-M3 | M3 | Vulnerability Assessment Analyst (PR-VAM-001) | Leads pen test, red team, purple team. In a small team, may be an SME at S3-S4. | | Threat Intelligence Analyst | JF-RISKOPS | SME | S1-S4 | S4 | Threat/Warning Analyst (AN-TWA-001) | May specialize in geopolitical, criminal, or ICS threat actors. | | Vendor Risk Analyst | JF-RISKOPS | SME | S1-S4 | S4 | Security Control Assessor (OV-SCA-001) | May specialize in SaaS, critical suppliers, or supply chain. | | OT Risk Analyst | JF-RISKOPS | SME | S2-S4 | S4 | Threat/Warning Analyst (AN-TWA-001) | Requires OT/ICS risk assessment experience. | | Identity Risk Analyst | JF-RISKOPS | SME | S1-S4 | S4 | Cyber Defense Analyst (PR-CDA-001) | Requires UEBA, identity threat detection expertise. | | Detection Engineer | JF-RISKOPS | SME | S1-S4 | S4 | Cyber Defense Analyst (PR-CDA-001) | Detection content authoring and tuning. | ### 7.4 Governance Pillar | Canonical Role | Job Family | Track | Grade Range | Terminal Grade | NICE Work Role | Notes | |---|---|---|---|---|---|---| | Governance Pillar Leader | JF-GOVCOMP | Management | M4 (Director) | M4 | Exec Cyber Leader / Security Control Assessor (OG-WRL-001 / OV-SCA-001) | Full pillar accountability. Reports to CISO. | | NERC-CIP Compliance Manager | JF-GOVCOMP | Management or SME | M1-M3 or S3-S4 | M3 / S4 | Security Control Assessor (OV-SCA-001) | In a large org, leads a compliance team (M track). In a small org, an expert IC (SME track). | | CMMC / Federal Compliance Manager | JF-GOVCOMP | Management or SME | M1-M3 or S3-S4 | M3 / S4 | Security Control Assessor (OV-SCA-001) | Same dual-track pattern as NERC-CIP. | | SOX ITGC Lead | JF-GOVCOMP | Management or SME | M1-M2 or S3-S4 | M2 / S4 | Security Control Assessor (OV-SCA-001) | Typically an IC role except in heavily regulated orgs. | | Policy & Standards Manager | JF-GOVCOMP | Management or SME | M1-M2 or S3-S4 | M2 / S4 | Cyber Policy and Strategy Planner (OV-PSP-001) | Owns the document library. May lead a small team in large orgs. | | Risk Register Owner | JF-GOVCOMP | SME or Management | S2-S4 or M1 | S4 / M1 | Information Systems Security Manager (OV-ISSN-001) | Curates the risk register. Management track only if leading a team of risk analysts. | | Evidence Librarian | JF-GOVCOMP | SME | S1-S3 | S3 | Security Control Assessor (OV-SCA-001) | A specialized IC role. At S4, transitions to a broader Governance Advisor role. | ### 7.5 Reading the Mapping **Range means flexibility.** A role showing S1-S4 can be filled at any grade. A CISO hiring for a Cloud Security Engineer may open the requisition at S2 and consider candidates from S1 to S3 depending on the team's composition and budget. **Terminal grade means ceiling.** A Detection Engineer at S4 who wants to grow further has two paths: transition to a broader Advisor role that spans multiple Risk domains, or move to the Management track by leading a detection engineering team. **Dual-track roles flex with the organization.** Several Governance roles show both SME and Management tracks. In a 5-person CERG, the NERC-CIP Compliance Manager is an individual contributor. In a 60-person CERG, that same role may lead a team of three compliance analysts. The role title is the same; the grade and track reflect the scope. --- ## 8. Career Pathing: Moving Between Tracks and Pillars ### 8.1 SME to Management Transition The most common career move in a growing CERG organization. A Sr. Specialist or Advisor who demonstrates aptitude for people leadership may transition to Manager. **Readiness indicators:** - Consistently sought out by junior team members for guidance (informal mentoring before formal management) - Has led cross-functional initiatives without formal authority - Communicates clearly with non-technical stakeholders - Shows interest in organizational design, process improvement, and team health, not just technical problems - Their manager and a peer manager agree they are ready **The transition is not a promotion in grade altitude.** An S3 Advisor moving to M1 Manager is a track change. Their compensation may increase to reflect new accountability, but their organizational influence does not reset. They carry their technical credibility into the management role. **The first management role should be small.** A new Manager should start with 3-5 direct reports in a domain they know well. A new Manager assigned 10 reports across three unfamiliar domains is being set up to fail. ### 8.2 Management to SME Transition Less common but equally legitimate. A Manager who discovers they prefer deep technical work to people management may return to the SME track. **The return is grade-preserving.** An M2 Senior Manager returning to the SME track should slot at S3 Advisor or S4 Sr. Advisor, depending on their technical currency. The management experience is not wasted: it produces an IC who understands budgeting, stakeholder management, and organizational dynamics. ### 8.3 Cross-Pillar Movement Movement between Engineering, Risk, and Governance is encouraged within limits. It builds the cross-pillar fluency that the Framework's left-right knowledge model depends on. **Guidelines:** - A Specialist moving pillars typically remains at S1 or S2 while they build domain expertise in the new pillar - A Sr. Specialist or above moving pillars may retain their grade if their craft mastery transfers. A Sr. Specialist Cloud Security Engineer moving to Vendor Risk Analyst is learning a new domain and should expect a temporary grade adjustment or a timeline to demonstrate competence at their current grade - Cross-pillar movement at Advisor and above is valuable and should be supported. An Advisor who has worked in two pillars is more valuable than one who has worked in one - Pillar leaders should actively identify candidates for cross-pillar exposure and rotational assignments ### 8.4 The Adjacent-Team Boundary Movement between CERG and the adjacent teams (Security Awareness, Incident Response) is a career option, not a CERG framework concern. The CISO owns the full cybersecurity organization. CERG managers should support team members who want to explore the adjacent functions and should not block internal transfers that benefit the broader security organization. --- ## 9. Span of Control and Team Design ### 9.1 Span-of-Control Guidelines | Manager Grade | Minimum Span | Optimal Span | Maximum Span | Notes | |---|---|---|---|---|---|---| | Manager (M1) | 3 | 5-7 | 8 | Below 3, the role may not justify full-time management. Above 8, 1:1 frequency and quality degrade. | | Senior Manager (M2) | 8 (total) | 12-16 (total) | 20 | Counts all reports, direct and indirect. A Senior Manager with 3 Managers each carrying 5 ICs is at 18 and well within range. | | Principal Manager (M3) | 15 (total) | 25-35 (total) | 40 | At this scale, the Principal Manager's direct reports should be primarily M2s and senior ICs. | | Director (M4) | Pillar-dependent | Pillar-dependent | Pillar-dependent | Director span is measured in organizational scope, not headcount. A 60-person Engineering pillar and a 13-person Governance pillar both require a Director. | ### 9.2 When to Create a Management Role A management role should be created when one of the following is true, not before: 1. **Span-of-control pressure.** An existing manager carries more than 8 direct reports and adding more would degrade their effectiveness. 2. **Domain divergence.** A team has grown to cover two distinct domains that no single manager can credibly lead (e.g., Cloud Engineering and OT Engineering under one Manager). 3. **Succession need.** The organization needs to develop a successor for a critical management role and the candidate needs management experience. 4. **Geographic or temporal distribution.** A team is split across time zones or sites in a way that makes a single manager impractical. **Anti-patterns to avoid:** - Creating a "Manager of Cloud Security" title for a single Cloud Security Engineer to improve retention. Use the SME track instead: promote them to Advisor or Sr. Advisor with appropriate compensation. - Creating management roles for every domain in a small team. A 6-person CERG may have zero Managers. The CISO manages everyone directly with pillar leads operating as player-coaches at S3-S4. --- ## 10. Compensation Philosophy CERG does not prescribe salary bands: those are market-dependent, geography-dependent, and organization-dependent. It does prescribe the principles that should govern compensation decisions. ### 10.1 Principles 1. **Grade drives band.** Compensation bands are defined by grade, not by role title. A Sr. Specialist Cloud Security Engineer and a Sr. Specialist Threat Intelligence Analyst share a band. Role-specific market premiums are applied within the band. 2. **Tracks are equivalent at each level.** An S3 Advisor and an M2 Senior Manager occupy comparable compensation bands. The organization does not pay a premium for management simply because it is management. 3. **Market informs the band, not the individual offer.** CERG organizations should benchmark their bands against relevant cybersecurity compensation surveys annually. An individual candidate's market value does not reset the band; it determines where in the band the offer lands. 4. **Internal equity is maintained over time.** Two people at the same grade, in the same role family, with comparable performance and tenure should not have materially different compensation without a documented reason (e.g., a critical retention situation, a geography differential, a unique specialization). 5. **Progression within a grade is recognized.** Not every year of good performance results in a promotion. Between-grade progression should be recognized through within-band increases. A Specialist who has been at S1 for three years and is performing well but not yet ready for S2 should not be earning the same as a newly hired S1. ### 10.2 Grade-to-Band Guidance | Grade | Market Positioning | Benchmark Target | |---|---|---| | S1 / Specialist | Developing | 25th-40th percentile of relevant market | | S2 / Sr. Specialist | Competitive | 40th-60th percentile | | S3 / Advisor / M1 Manager | Strong | 60th-75th percentile | | S4 / Sr. Advisor / M2 Sr. Manager | Premium | 75th-85th percentile | | M3 / Principal Manager | Leadership | 85th-90th percentile | | M4 / Director | Executive Leadership | 90th+ percentile | | CISO | Executive | Per executive compensation framework | > **Percentiles Are a Starting Point, Not a Formula** > > A CERG organization in a high-cost geography, a competitive talent market, or an industry with acute cybersecurity talent shortages (utilities, healthcare, defense) will need to target higher percentiles to attract and retain. The principle is not "pay at the 50th percentile." The principle is "define your positioning deliberately and apply it consistently." --- ## 11. Adapting Grade Titles to Your Organization The CERG grade titles (Specialist, Sr. Specialist, Advisor, Sr. Advisor) are deliberately chosen to be clear, descriptive, and free of the inflation that has made "VP" and "Director" nearly meaningless across organizations. An adopting organization may need to map CERG grades to its existing title framework. The table below provides a translation layer. ### 11.1 Common Title Translations | CERG Grade | Common Industry Equivalent | Government / Military Equivalent | Consulting Equivalent | |---|---|---|---| | Specialist | Associate, Analyst I, Engineer I | GS-7 to GS-9 | Analyst, Consultant | | Sr. Specialist | Analyst II, Engineer II, Senior Analyst | GS-9 to GS-11 | Senior Consultant | | Advisor | Staff Engineer, Principal Analyst, Lead | GS-12 to GS-13 | Manager, Associate Director | | Sr. Advisor | Senior Staff Engineer, Distinguished Engineer, Fellow | GS-14 to GS-15 | Senior Manager, Director | | Manager | Manager, Team Lead | GS-13 to GS-14 (supervisory) | Manager | | Senior Manager | Senior Manager, Associate Director | GS-14 to GS-15 (supervisory) | Senior Manager | | Principal Manager | Director, Senior Director | SES / SL | Director, Managing Director | | Director | Senior Director, VP | SES | Partner, Managing Director | ### 11.2 What Not to Change The CERG role titles from [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 are canonical and should not be altered. "Cloud Security Engineer" is a Cloud Security Engineer whether the organization's title framework calls engineers "analysts," "architects," or "specialists." The grade title is separate. An organization may call an S3 Cloud Security Engineer a "Staff Cloud Security Engineer" internally while the CERG role remains "Cloud Security Engineer" in all framework documents. The adaptation is cosmetic; the grade expectations do not change. --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JA-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the canonical role roster, organizational design, or compensation philosophy | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); NIST NICE SP 800-181r1; ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Establishes the two-track grade structure for CERG: SME progression (Specialist, Sr. Specialist, Advisor, Sr. Advisor) and Management progression (Manager, Senior Manager, Principal Manager, Director). Defines expectations at each grade across five dimensions. Maps every canonical CERG role to its grade range and terminal grade. Provides career pathing guidance for cross-track and cross-pillar movement. Establishes span-of-control guidelines, compensation philosophy, and grade-title adaptation guidance. | ### Review Triggers - Change to the canonical role roster in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Material change to the organizational design or team structure - Change to the compensation philosophy or market conditions warranting band revision - Addition or retirement of a grade or track - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Authoritative canonical role roster | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Organizational design and talent model | | Consolidated Roles and RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Role descriptions and scaling map | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk acceptance authority references | | CERG Job Descriptions | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | Full job descriptions per role | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the JA domain | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## ONBOARDING AND INTEGRATION PROGRAM ### 30/60/90-Day Plans · CERG 101 · Buddy System · First Contribution --- | | | |---|---| | **Document ID** | CERG-GOV-ONB-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) · [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) · [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) · [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) · [`CERG-GOV-CON-001`](CERG-GOV-CON-001_Contractor_and_Non-Employee_Staff_Integration_Guide.md) | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | | **Review Cycle** | Annual / On any change to organizational structure, tooling, or document library | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Onboarding Philosophy](#2-onboarding-philosophy) 3. [Before Day One: Manager Preparation](#3-before-day-one-manager-preparation) 4. [Week One: Orientation and Access](#4-week-one-orientation-and-access) 5. [The 30/60/90-Day Model](#5-the-306090-day-model) 6. [CERG 101: The Core Curriculum](#6-cerg-101-the-core-curriculum) 7. [The Buddy System](#7-the-buddy-system) 8. [The First Contribution Milestone](#8-the-first-contribution-milestone) 9. [Cross-Pillar Rotation](#9-cross-pillar-rotation) 10. [Role-Specific Onboarding by Family](#10-role-specific-onboarding-by-family) 11. [Onboarding for Managers](#11-onboarding-for-managers) 12. [Measuring Onboarding Effectiveness](#12-measuring-onboarding-effectiveness) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope A new Cloud Security Engineer can take six to nine months to understand their environment well enough to contribute independently. During those months, they are learning where the architecture diagrams live, who owns which platform, what a "normal" alert looks like, and how CERG's pillars interact. They are not yet producing at the level of their grade, and they feel it. The gap between their capability and their output is stressful for them and expensive for the organization. This document closes that gap. It defines a structured onboarding program that cuts time-to-productivity from a typical six-to-nine months to a target of three to four. It provides role-specific 30/60/90-day plans for each role family, a CERG 101 curriculum that ensures every new hire understands the framework, a cross-pillar buddy system, a first-contribution milestone that builds confidence and visibility, and a cross-pillar rotation that makes the left-right knowledge model real from day one. It applies to every new CERG hire, regardless of role, grade, or prior experience. A seasoned Sr. Advisor joining from another organization moves through the same structure faster than a new Specialist, but they move through the same structure. The program also applies to internal transfers joining CERG from another function, with adjustments for their existing organizational knowledge. It does not apply to contractors and consultants, who follow the condensed onboarding defined in CERG-GOV-CON-001 (Planned, V1.x). > **Onboarding Is a Program, Not a Checklist** > > The CERG Framework (FRM-001 §9.2) describes the left-right knowledge model: a new 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. That describes the resources available. It does not describe a program. This document is the program. A new hire who spends their first month reading documents alone is not being onboarded; they are being oriented to a library. Onboarding requires structured exposure, guided practice, and human connection. --- ## 2. Onboarding Philosophy 1. **Productivity is a gradient, not a switch.** The goal is not that the person is fully productive on day 30. It is that on day 30 they have made a concrete contribution; on day 60 they are contributing to their pillar's standing work with decreasing supervision; on day 90 they own a defined work stream and their teammates feel the difference. 2. **The pillar owns the person; the program owns the first 90 days.** The hiring manager is accountable for the new hire's success. The onboarding program provides the structure; the manager executes it. 3. **Cross-pillar fluency starts on day one, not year three.** Every new hire spends structured time in the other two pillars during their first 90 days. The left-right knowledge model in FRM-001 §9.2 is not an aspirational goal for senior practitioners; it is built into how every person enters the organization. 4. **The buddy is not the manager.** Every new hire has a peer buddy from a different pillar. The buddy provides the unvarnished perspective a manager cannot: where the documentation is wrong, which team has a feud with which other team, how the espresso machine actually works. 5. **The first contribution is the inflection point.** Within 30 days, every new hire makes a concrete, visible contribution and presents it to their pillar. This is not a test. It is the moment the person transitions from "learning the environment" to "operating in it." It is psychologically important and it should be celebrated. --- ## 3. Before Day One: Manager Preparation The hiring manager completes the following before the new hire's first day. If these items are not complete, the new hire spends their first week waiting for access and losing momentum that is difficult to regain. | Item | Owner | Timeline | |---|---|---| | **Access provisioning** | Manager + IT | Submitted at offer acceptance; confirmed active before day one | | - System accounts: email, SSO, VPN, collaboration tools | IT | Day -5 | | - CERG tool access: CSPM, vulnerability scanner, GRC platform, SIEM, threat intel platform, detection pipeline, code repositories per role | Manager + tool admins | Day -5 | | - Document library access: CERG repository, policies, standards, procedures | Manager | Day -3 | | **Hardware** provisioned and imaged per Engineering security baseline | IT | Day -3 | | **Workspace** prepared (physical desk or virtual collaboration space) | Manager | Day -3 | | **Buddy assigned** (from a different pillar; confirmed and briefed) | Manager | Day -10 | | **First-week schedule** published: who the new hire meets, when, and why | Manager | Day -3 | | **Welcome message** sent to the team and relevant cross-pillar colleagues | Manager | Day -3 | | **30/60/90-day plan** drafted with role-specific objectives (per §10) | Manager | Day -5 | | **CERG 101 curriculum** assigned with schedule for completion | Manager | Day -1 | > **The First-Day Test** > > A new hire should be able to log in, access their email, read their first-week schedule, open the CERG document library, and start reading the Framework by 10:00 AM on day one. If they spend their first morning waiting for account provisioning, the manager has not prepared. The cost of a lost first morning is not the four hours of productivity; it is the message that the organization does not have its act together. That message is hard to undo. --- ## 4. Week One: Orientation and Access The first week is structured but not overloaded. The goal is orientation to the environment, the people, and the framework, not task execution. ### 4.1 Day One | Time | Activity | With Whom | |---|---|---| | 09:00-10:00 | Welcome and logistics: workspace, badging, tools, HR paperwork | Manager | | 10:00-11:00 | CERG overview: what CERG is, why it exists, the three pillars, the yes-and philosophy, how the new hire's role fits | Manager | | 11:00-12:00 | Tool access verification: confirm the new hire can access every system on the provisioning list | Manager + IT rep | | 12:00-13:00 | Lunch with the team (or virtual equivalent) | Manager + immediate team | | 13:00-14:00 | Read the CERG Framework (FRM-001) §§1-3: the problem statement and the three pillars. Take notes on questions. | Self-directed | | 14:00-15:00 | Meet the buddy: informal introduction. The buddy explains their role, their pillar, and what they wish they had known on day one. | Buddy | | 15:00-16:00 | Review the 30/60/90-day plan with the manager. Adjust based on the new hire's questions and observations from day one. | Manager | ### 4.2 Days Two Through Five By the end of week one, the new hire has: - Met every member of their immediate team and their pillar leader - Met at least one person from each of the other two pillars - Read the CERG Framework (FRM-001) and the CERG Operating Model (OM-001) - Read their own job description (JD-001) - Read the competency model for their role family (CMP-001 §§4-6) - Understood the performance management cadence and what their first review will evaluate (PERF-001 §3-4) - Completed any mandatory organizational training (security awareness, code of conduct, compliance) - Had a daily 15-minute check-in with their manager - Had at least one informal conversation with their buddy - Started the CERG 101 curriculum (§6) The manager sends a Friday-afternoon email to the pillar summarizing the new hire's first week (with the new hire's consent) and noting one thing the new hire observed that the team may find useful. This is the first signal that the new hire's perspective is valued. --- ## 5. The 30/60/90-Day Model ### 5.1 Days 1-30: Learn and Contribute **Goal:** Understand the environment, meet the people, make a first contribution. **Key activities:** - Complete the CERG 101 curriculum (§6) - Shadow at least two standing meetings: one within the home pillar, one cross-pillar - Pair with a senior team member on one active work item: observe, ask questions, understand the workflow end to end - Identify a task the person can complete independently and complete it: this becomes the First Contribution (§8) - Spend one day with the buddy's pillar, observing how that pillar operates (this is the first third of the cross-pillar rotation; §9) - Daily 15-minute manager check-in (weeks 1-2); every-other-day (weeks 3-4) - Weekly informal check-in with the buddy **Success indicators at day 30:** - The person can describe CERG's three-pillar model, their role's place in it, and how their pillar interacts with the other two - The person has completed their First Contribution and presented it to the pillar - The person has met everyone in their pillar and key people in the other two - The person can navigate the document library: they know where to find the policy, standards, procedures, and templates relevant to their role - The person has access to all tools and has used at least the primary ones in a supervised context - The manager has observed the person demonstrate at least one competency from CMP-001 in an authentic work context ### 5.2 Days 31-60: Practice and Deepen **Goal:** Contribute independently to pillar work; develop cross-pillar understanding; identify development priorities. **Key activities:** - Own one defined work stream within the pillar with decreasing supervision (e.g., triage a subset of CSPM alerts, manage evidence collection for a control family, perform supervised architecture reviews for low-complexity projects) - Complete the second cross-pillar rotation day (§9) - Participate in at least one cross-pillar working group or project as an observer-contributor - Review the CMP-001 competency matrix for their role family with their manager. Identify 2-3 development priorities for the first year - Begin the technical onboarding for their role family per §10 - Weekly manager check-in (30 minutes) - Bi-weekly buddy check-in **Success indicators at day 60:** - The person completes assigned work with minimal rework; their output is consistent with grade expectations for routine tasks - The person has contributed to a cross-pillar discussion with a relevant observation or question - The person has a documented development plan with 2-3 priorities aligned to CMP-001 - The person's teammates report that the person is "starting to be useful" (this is a higher bar than it sounds: it means the person is reducing the team's load, not adding to it) - The manager has observed the person demonstrate at least three CMP-001 competencies in authentic work contexts ### 5.3 Days 61-90: Own and Integrate **Goal:** Own a defined scope; demonstrate cross-pillar fluency; establish the performance baseline for the first formal review. **Key activities:** - Own a defined work stream independently: the manager sets outcomes; the person determines the path - Complete the third cross-pillar rotation day (§9) - Lead one item in a standing meeting: present a finding, a status update, or a recommendation to the group - Complete the role-specific technical onboarding per §10 - Conduct a 90-day retrospective with the manager: what worked, what did not, what support the person needs going forward - The manager prepares the first quarterly check-in notes per PERF-001 §3.2 **Success indicators at day 90:** - The person owns at least one defined work stream. Their manager reviews outcomes, not tasks - The person has worked directly with at least one person from each pillar on a shared objective - The person can explain how a decision in their domain affects the other two pillars - The person has identified at least one improvement to a procedure, tool configuration, or documentation item and raised it - The person's teammates would notice if the person were absent - The manager can write a credible first quarterly check-in with evidence across at least four of the six SME evaluation dimensions > **90 Days Is a Target, Not a Deadline** > > A new Specialist with no prior cybersecurity experience may need 120 days to reach the day-90 success indicators. A Sr. Advisor joining from another CERG-adopting organization may hit them at day 45. The structure is the same; the pace varies. The manager adjusts the timeline, not the expectations. --- ## 6. CERG 101: The Core Curriculum Every new hire, regardless of role, grade, or prior experience, completes the CERG 101 curriculum within their first 30 days. The curriculum is a guided reading of the CERG document library, not a passive document dump. For each document, the new hire reads it, writes three questions or observations, and discusses them with their manager or buddy. ### 6.1 Required Reading (First 30 Days) | Day | Document | Focus | |---|---|---| | 1 | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Why CERG exists, the three pillars, the left-right knowledge model, maturity tiers | | 2 | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | How CERG operates: engagement models, staffing, cadence, interfaces with other functions | | 3 | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | The policy that governs everything. What is mandatory, who approves what | | 4 | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Who does what. The RACI for the new hire's own role and adjacent roles | | 5 | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | The grade structure, the two tracks, the dimensions of growth | | 6 | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | What good looks like at each grade in the new hire's role family | | 7 | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | The new hire's own job description and those of their immediate teammates | | 8 | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | How performance is evaluated, how promotion decisions are made | | 9 | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | How the document library is organized, how to find what you need | | 10 | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | How CERG manages risk: taxonomy, scoring, acceptance authority, exception process | ### 6.2 Role-Specific Reading (Days 10-30) | Role Family | Additional Required Reading | |---|---| | **Engineering** | CERG-STD-IT-001, CERG-STD-CFG-001, CERG-STD-NET-001, CERG-STD-EP-001, CERG-STD-SDL-001, CERG-STD-CR-001, CERG-PRC-AR-001, CERG-PRC-CHG-001 | | **Risk** | CERG-STD-LM-001, CERG-STD-RES-001, CERG-PRC-VM-001, CERG-PRC-AV-001, CERG-PRC-TPRM-001, CERG-PRC-TI-001, CERG-PRC-TM-001 | | **Governance** | CERG-STD-CUI-001, CERG-STD-AC-001, CERG-STD-DG-001, CERG-PRC-RM-001, CERG-PRC-AUD-001, CERG-PLN-CIP-001, CERG-PLN-CUI-001, CERG-PLN-SOX-001 | ### 6.3 The CERG 101 Discussion Within the first two weeks, the new hire and their manager have a 60-minute CERG 101 discussion. The agenda: 1. **What was familiar?** What parts of CERG resemble how the new hire's previous organization operated? 2. **What was different?** What parts of CERG are novel, surprising, or challenging to the new hire's mental model of how cybersecurity should work? 3. **What was unclear?** The manager answers questions and clarifies. 4. **What should CERG 101 teach that it currently does not?** The new hire's fresh perspective is valuable. The manager records suggestions for curriculum improvement. --- ## 7. The Buddy System ### 7.1 Buddy Selection Every new hire is assigned a buddy before day one. The buddy is: - A peer (similar grade, not the new hire's manager or the manager's manager) - From a different pillar than the new hire - Not on the new hire's immediate team - Has been with CERG for at least six months (so they have completed their own onboarding and have an informed perspective) - Volunteers or is selected by their manager; nobody is conscripted into buddy duty ### 7.2 Buddy Responsibilities The buddy's role is social, practical, and informational. It is not supervisory. The buddy does not evaluate the new hire's performance or report to the manager (except to flag serious concerns, e.g., the new hire seems profoundly unhappy or has disclosed a compliance violation). | Timeframe | Buddy Activity | |---|---| | **Before day one** | Send a welcome message. Introduce yourself, your role, your pillar. Offer to answer any pre-start questions. | | **Week one** | Have at least two informal conversations (coffee, lunch, virtual chat). Show the new hire where things really are: the best documentation, the useful dashboards, the people who actually know things. | | **Weeks 2-4** | Weekly check-in: 15-30 minutes. How is it going? What is confusing? What is different from what you expected? Answer questions the new hire may not want to ask their manager. | | **Days 31-90** | Bi-weekly check-in. By now the new hire should have their own network; the buddy is a continuing resource, not a daily presence. | | **After 90 days** | The buddy relationship becomes a normal peer relationship. The formal buddy assignment ends. | ### 7.3 The Buddy Is Not - **A substitute for the manager.** The manager owns the new hire's success. The buddy supplements, not replaces. - **A performance evaluator.** The buddy does not contribute to the new hire's performance review unless the new hire specifically requests their perspective. - **An IT help desk.** The buddy can point the new hire to the right resource; they are not expected to troubleshoot the new hire's development environment. - **A therapist.** The buddy is a peer. If the new hire is experiencing harassment, discrimination, or serious mental health concerns, the buddy directs them to HR or the employee assistance program, not to another coffee chat. --- ## 8. The First Contribution Milestone ### 8.1 What Counts Within 30 days, every new hire makes a concrete, visible contribution to CERG and presents it to their pillar. The contribution must be: - **Real, not simulated.** It addresses an actual need, not a fabricated exercise. - **Complete, not in-progress.** The contribution is delivered, not described as "I started working on." - **Presented, not just submitted.** The new hire presents the contribution to their pillar in a standing meeting or a dedicated session. They explain what they did, why, and what they learned. Acceptable first contributions include, but are not limited to: | Role Family | Examples | |---|---| | **Engineering** | First architecture review completed and presented; first IaC module security improvement merged; first CSPM policy tuned with documented rationale; first configuration baseline update reviewed and committed | | **Risk** | First vulnerability triaged through the full lifecycle and closed; first vendor risk assessment completed; first detection rule authored, tested, and deployed; first threat intelligence brief delivered to the team | | **Governance** | First evidence item collected, validated, and stored; first control test completed and documented; first policy section reviewed with documented feedback; first risk register entry reviewed and updated | ### 8.2 The First Contribution Presentation The presentation is 5-10 minutes and follows a simple structure: 1. **What I did.** The contribution, in plain language. 2. **How I did it.** The tools, procedures, and people involved. 3. **What I learned.** One thing about CERG, the technology, or the team that the new hire now understands that they did not understand before. 4. **What I would do differently.** Self-reflection, not self-criticism. Demonstrates that the person is thinking about improvement, not just execution. The pillar responds with recognition, not evaluation. The point is to make the new hire visible as a contributor, not to grade their first work product. The manager ensures that the presentation is scheduled in a standing meeting that the pillar leader attends. > **The First Contribution Is Psychologically Loaded** > > A new hire who contributes nothing visible for 90 days believes, correctly, that they have not yet proven their value. A new hire who presents a completed contribution to their pillar at day 25 knows they belong. The difference in confidence, engagement, and retention is material. This is not a ceremonial milestone; it is the single most important moment in the first 90 days. --- ## 9. Cross-Pillar Rotation ### 9.1 Structure Every new hire spends three dedicated days, one per month during the first 90 days, embedded in a different pillar from their own. The rotation implements the left-right knowledge model (FRM-001 §9.2) from day one, not year three. | Month | Rotation | Host | |---|---|---| | **Month 1 (Days 15-30)** | Buddy's pillar | Buddy | | **Month 2 (Days 31-60)** | Remaining pillar | Designated host from that pillar (Sr. Specialist or above) | | **Month 3 (Days 61-90)** | Return to buddy's pillar or deeper dive into a specific cross-pillar function | Buddy or host | ### 9.2 Rotation Day Agenda Each rotation day is structured: 1. **Morning: Observe.** The new hire shadows the host through their morning. They attend the host's standing meetings (read-only), watch the host triage alerts or review evidence or design architecture, and ask questions. 2. **Midday: Discuss.** The host walks the new hire through one end-to-end workflow in their pillar. For example, how a vulnerability goes from scanner alert to closed finding, or how a regulatory change becomes a policy update. The new hire asks: where does your pillar get its inputs? Where do its outputs go? What frustrates you about how my pillar hands off to yours? 3. **Afternoon: Participate.** The new hire contributes to one low-stakes activity in the host's pillar under supervision. The activity should be authentic: review a finding, test a control, walk through an architecture diagram. The output does not need to be perfect; the experience is the point. ### 9.3 Rotation Debrief After each rotation day, the new hire writes a one-paragraph debrief and sends it to their manager and the host. The debrief answers: - What did I learn about this pillar that I did not know before? - What does my home pillar do that makes this pillar's work harder? - What does this pillar do that my home pillar should know about? The manager reviews the debriefs at the 90-day retrospective. Patterns across debriefs (e.g., "every new hire discovers that Engineering and Risk use different severity language") are signals that should reach pillar leadership. --- ## 10. Role-Specific Onboarding by Family ### 10.1 Engineering Family Engineering new hires add the following to the standard 30/60/90-day plan: | Phase | Technical Milestone | |---|---| | **Days 1-30** | Complete architecture review training: shadow two architecture reviews, perform one supervised review. Gain read access to all cloud/platform environments in the person's domain. Clone and understand the reference architecture repository. | | **Days 31-60** | Perform three independent architecture reviews with senior review. Contribute one improvement to an IaC security module, configuration baseline, or security automation. Present one architecture finding at Pre-production Review Board. | | **Days 61-90** | Own architecture reviews for low-complexity projects independently. Author one new security control or policy-as-code rule. Present a technical deep-dive on a platform or domain to the Engineering team. | ### 10.2 Risk Family | Phase | Technical Milestone | |---|---| | **Days 1-30** | Complete tool training on the primary Risk platforms (vulnerability scanner, CSPM, SIEM, threat intel, detection pipeline). Shadow the vulnerability triage process, vendor assessment workflow, or detection rule lifecycle end to end. | | **Days 31-60** | Independently triage findings in one domain (e.g., cloud vulnerabilities, vendor alerts, detection events). Author one detection rule, threat advisory, or risk assessment with senior review. Present one finding at Vulnerability Triage or Threat Intelligence Brief. | | **Days 61-90** | Own triage for a defined asset group or finding type. Correlate findings across tools: identify one instance where two tools see the same issue differently and document the discrepancy. Present a risk trend or threat landscape update to the Risk team. | ### 10.3 Governance Family | Phase | Technical Milestone | |---|---| | **Days 1-30** | Complete GRC platform and evidence library training. Shadow one audit evidence request from intake to delivery. Shadow one control test from procedure to documentation. Read the organization's last audit report or assessment findings. | | **Days 31-60** | Independently collect and validate evidence for one control family. Map one regulatory requirement to CERG controls with documented rationale. Participate in one auditor or assessor walkthrough as an observer. | | **Days 61-90** | Own evidence management for a defined control set. Author one policy or standard section update with senior review. Present a compliance status update at Compliance Pulse. | --- ## 11. Onboarding for Managers A new CERG Manager or Pillar Leader adds the following to the standard onboarding program. Their first 90 days focus on understanding the team, the operations, and the stakeholder landscape before making changes. | Phase | Leadership Milestone | |---|---| | **Days 1-30** | Meet every direct report individually. Read every team member's most recent performance summary. Attend all standing meetings for the team and the pillar. Identify: what is working well (do not change it), what is fragile (stabilize it), what is broken (plan to fix it). | | **Days 31-60** | Present an initial assessment to the pillar leader or CISO: observations, not recommendations. Identify one operational improvement and implement it (small, visible, demonstrates the manager's operating style without disrupting the team). Begin building relationships with peer managers in other pillars. | | **Days 61-90** | Present a 90-day plan for the team: priorities, structural changes (if any), development focus. Have had a meaningful 1:1 with every direct report. Have identified at least one succession risk or single-point-of-failure in the team's operations. | > **New Managers: Observe Before You Change** > > A new Manager who reorganizes the team in their first month is signaling that they value their own preferences over understanding what exists. The team that survived without this Manager for months will survive another 90 days of observation. The Manager who takes the time to understand why things are the way they are before changing them earns trust. The Manager who changes things before understanding them burns trust they will spend years trying to rebuild. --- ## 12. Measuring Onboarding Effectiveness ### 12.1 Metrics The onboarding program's effectiveness is measured through: | Metric | Target | Measurement | |---|---|---| | **Time to first contribution** | ≤30 days | Days from start date to first contribution presentation | | **Time to independent work-stream ownership** | ≤90 days | Days from start date to manager-confirmed independent ownership of a defined work stream | | **90-day retention** | ≥95% | Percentage of new hires still with CERG at day 90 | | **First-year retention** | ≥85% | Percentage of new hires still with CERG at 12 months | | **New hire satisfaction** | ≥4.0/5.0 | Survey at day 90: "I feel prepared to do my job," "I understand how my role connects to CERG's mission," "I would recommend CERG's onboarding to a friend joining the organization" | | **Manager satisfaction** | ≥4.0/5.0 | Survey at day 90: "The onboarding program gave me the structure I needed to bring my new hire up to speed," "My new hire is contributing at the level I expected by day 90" | ### 12.2 Continuous Improvement The 90-day retrospective (§5.3) includes a structured feedback collection on the onboarding program itself. The manager asks: 1. What part of the onboarding program was most useful? 2. What part was least useful or felt like a waste of time? 3. What was missing that you wish had been included? 4. If you were designing the onboarding program for the next person in your role, what would you change? Aggregated feedback is reviewed annually by the Governance Pillar Leader as part of this document's review cycle. A pattern of "the CERG 101 curriculum assumed knowledge I did not have" or "the cross-pillar rotation days were too short to be useful" should result in document updates. --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-ONB-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to organizational structure, tooling, or document library | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Defines structured 30/60/90-day onboarding program for all CERG roles. Includes pre-day-one manager preparation checklist, week-one orientation, CERG 101 core curriculum, cross-pillar buddy system, first contribution milestone, cross-pillar rotation program, role-specific technical onboarding for Engineering/Risk/Governance families, manager onboarding addendum, and onboarding effectiveness metrics. | ### Review Triggers - Material change to the CERG document library (new or retired documents that affect CERG 101) - Material change to CERG tooling (new platforms that affect role-specific technical onboarding) - Organizational restructure affecting pillar composition or reporting lines - Feedback from 90-day retrospectives indicating systemic onboarding gaps - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Left-right knowledge model; onboarding philosophy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Pillar structure, engagement models, cadence | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade expectations that onboarding accelerates toward | | Competency Model | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Development priorities identified during onboarding | | Performance Management | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | First performance review at 6 months | | Job Descriptions | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | Success profiles inform 90-day objectives | | Contractor Integration | [`CERG-GOV-CON-001`](CERG-GOV-CON-001_Contractor_and_Non-Employee_Staff_Integration_Guide.md) | Condensed onboarding for non-employee staff | | Implementation Guide | [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | Organizational adoption of CERG | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## PERFORMANCE MANAGEMENT AND PROMOTION FRAMEWORK ### Evaluation Cadence · Calibration · Promotion Process · Documentation Standards --- | | | |---|---| | **Document ID** | CERG-GOV-PERF-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-SUCC-001`](CERG-GOV-SUCC-001_Succession_Planning_and_Talent_Review_Framework.md) · [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | | **Review Cycle** | Annual / On any change to grade definitions or organizational structure | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Design Principles](#2-design-principles) 3. [Performance Management Cadence](#3-performance-management-cadence) 4. [Evaluation Dimensions](#4-evaluation-dimensions) 5. [The Performance Conversation](#5-the-performance-conversation) 6. [Calibration Process](#6-calibration-process) 7. [Promotion Process](#7-promotion-process) 8. [Performance Improvement Process](#8-performance-improvement-process) 9. [Documentation Standards](#9-documentation-standards) 10. [Integration with Other CERG Instruments](#10-integration-with-other-cerg-instruments) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope The Job Architecture and Grade Framework (CERG-GOV-JA-001) defines the grade structure. The Competency Model (CERG-GOV-CMP-001) defines what good looks like at each grade. What neither defines is the mechanism: how a manager evaluates performance, how often, with what documentation, and how that evaluation leads to a promotion decision that is consistent across pillars. This document defines that mechanism. It establishes the performance management cadence, the evaluation dimensions, the calibration process that prevents pillar-to-pillar inconsistency, the promotion process from initiation through approval, and the documentation standard that makes every decision defensible. It is designed to be lightweight enough for a 5-person CERG team and rigorous enough for a 60-person organization facing a regulatory audit of its personnel practices. It applies to every CERG team member, manager, and pillar leader. It does not apply to the CISO, whose performance management is governed by the executive evaluation framework of the organization, or to Adjacent Incident Response roles, which belong to the standing IR team. > **A Grade Framework Without a Performance Framework Is a Parking Lot** > > JA-001 says "progression is earned, not tenured." That sentence is aspirational until there is a defined mechanism for evaluating whether it has been earned, a consistent process for making the judgment, and documentation that survives the departure of the manager who made it. This document is that mechanism. --- ## 2. Design Principles 1. **Evaluate against defined expectations, not against peers.** A person's performance is measured against the grade-level expectations in JA-001 §4-5 and the competency anchors in CMP-001. It is not measured against the highest-performing person at the same grade. 2. **Calibration prevents drift.** Two managers evaluating the same person against the same criteria should reach similar conclusions. The calibration process exists to make that true. 3. **Promotion is a decision, not an event.** A promotion is the conclusion of a sustained demonstration of capability at the next level. It is not a reward for tenure, a retention counter-offer, or a response to an external offer. 4. **Documentation is evidence, not bureaucracy.** The performance record exists so that a decision can be explained to the person, to a calibration panel, to HR, and to a regulator or auditor if challenged. It should be thorough enough to survive those audiences and no longer. 5. **Scales without breaking.** A 5-person CERG with no Managers and a 60-person CERG with a full management hierarchy both use the same framework. The forms are the same; the number of people in the calibration room changes. --- ## 3. Performance Management Cadence ### 3.1 The Annual Cycle CERG performance management runs on a semi-annual cycle aligned to the CERG operating rhythm. This is twice as frequent as typical corporate annual review cycles because cybersecurity team members operate in a field where six months is a material span: a Detection Engineer can demonstrate a full cycle of rule authorship, tuning, and measurement in that time; a Cloud Security Engineer can take several projects from intake to go-live. | Event | Timing | Participants | Output | |---|---|---|---| | **Mid-Year Review** | June (aligns with Q2 CISO Risk & Posture Review) | Manager + team member | Mid-year performance summary; development plan update | | **Year-End Review** | December (aligns with Q4 CISO Risk & Posture Review) | Manager + team member | Annual performance summary; promotion nomination if applicable | | **Calibration Session** | Within 2 weeks of year-end reviews | Pillar leaders + CISO | Calibrated performance ratings; approved promotion slate | | **Promotion Decisions** | Within 4 weeks of calibration | CISO (final approval) | Promotion announcements effective Q1 | > **Align to the Existing Cadence, Do Not Add Meetings** > > The mid-year and year-end reviews use the existing CISO Risk & Posture Review as an anchor point. The CERG Leadership Sync (weekly) is the forum for raising performance concerns between cycles. Do not create a new standing meeting for performance management; integrate it into the meetings that already exist. ### 3.2 Quarterly Check-Ins Between formal reviews, managers conduct quarterly check-ins with each direct report. These are 30-minute conversations, not formal evaluations. The agenda: 1. What has gone well since the last check-in? 2. What is blocked or unclear? 3. What development activity has been completed? 4. Is there anything the person wants to flag that has not come up in regular 1:1s? The manager records one to three sentences per check-in in the performance record. The purpose is continuity: the year-end review should summarize a year of documented observations, not reconstruct a year from memory. ### 3.3 Ongoing Feedback Performance feedback should never be a surprise at review time. A manager who waits six months to tell someone their work is not meeting expectations has failed at the most basic responsibility of people leadership. Significant feedback, positive or corrective, should be delivered within days of the observation and documented in the performance record. > **The "No Surprises" Rule** > > If a person reads something in their year-end review that they have not heard before, the performance management system has failed regardless of whether the review is accurate. The review is a summary of a year of documented conversations, not the first conversation. --- ## 4. Evaluation Dimensions > **Per-Role Evaluation Criteria**: Each role's evaluation criteria are now embedded in its per-role JD document under `roles/`. The dimensions below define the evaluation framework; the per-role documents define the role-specific expectations at each grade. See [JD-001](CERG-GOV-JD-001_CERG_Job_Descriptions.md) for the complete per-role index. ### 4.1 SME Track Dimensions SME performance is evaluated along six dimensions. The first five align to the grade-level definitions in JA-001 §4 and §6. The sixth (Outcomes) grounds the evaluation in what the person actually delivered. | Dimension | What It Measures | Source | |---|---|---| | **Craft Mastery** | Depth and breadth of technical or domain expertise relative to grade expectations | CMP-001 §4-6, Technical Depth domains | | **Scope and Autonomy** | Breadth of owned work and degree of self-direction | JA-001 §4 grade definitions | | **Influence and Mentorship** | Impact on others without formal authority | CMP-001 §4-6, Influence and Mentorship domains | | **Cross-Pillar Fluency** | Understanding of and collaboration with other pillars | CMP-001 §4-6, Cross-Pillar Fluency domains | | **Operational Discipline** | Consistency, documentation, SLA adherence, evidence quality | CMP-001 §4-6, Operational Discipline domains | | **Outcomes** | What the person delivered against their objectives in the review period | JD-001 success profiles; role-specific objectives | ### 4.2 Management Track Dimensions Management performance adds three dimensions to the SME evaluation. A Manager is evaluated on their SME-family competencies at S2 or above plus the management dimensions below. | Dimension | What It Measures | Source | |---|---|---| | **People Leadership** | Quality of hiring, development, feedback, and retention | CMP-001 §7.1; JA-001 §5 grade definitions | | **Team Delivery** | The team's output against objectives, not the manager's personal output | JA-001 §5 operational accountability definitions | | **Strategic Contribution** | Quality of strategy, resource planning, and stakeholder management | CMP-001 §7.2-7.5 | ### 4.3 Rating Scale CERG uses a four-point rating scale. The scale is deliberately simple: more gradations create more arguments about the difference between a 3 and a 4 than insight about the person. | Rating | Definition | Promotion Implication | |---|---|---| | **Exceeds Expectations** | Consistently demonstrates capabilities at the next grade in multiple dimensions. Delivers outcomes that materially exceed the role's stated objectives. | Strong promotion candidate. Next-grade behavior is observable and documented. | | **Meets Expectations** | Consistently demonstrates at-grade capabilities. Delivers against role objectives. Most team members in good standing receive this rating. | Not a promotion candidate this cycle. May be developing toward promotion with targeted growth in specific dimensions. | | **Developing** | Demonstrates most at-grade capabilities but has material gaps in one or more dimensions. New-to-role team members typically receive this rating for their first cycle. | Not a promotion candidate. Development plan should target the gap dimensions. | | **Below Expectations** | Does not meet at-grade expectations in multiple dimensions despite feedback and support. | Performance improvement process initiated (see §8). Not eligible for promotion. | > **Most People Are "Meets Expectations"** > > "Meets Expectations" is not a consolation prize. A Cloud Security Engineer who consistently delivers secure architectures, meets their SLAs, mentors junior engineers, and contributes to cross-pillar working groups is meeting expectations at a high bar. "Exceeds" is reserved for people who are observably operating at the next grade. If everyone is "Exceeds," the rating scale has collapsed and the calibration session needs to reset it. --- ## 5. The Performance Conversation ### 5.1 Preparation Before the review conversation, the manager prepares a written performance summary using the documentation standard in §9. The summary addresses each evaluation dimension with specific, dated examples. It does not rely on adjectives ("great communicator") without evidence ("presented the cloud security posture review to the CIO in October; the CIO followed up with a specific question answered in the deck, indicating understanding"). The team member prepares a self-assessment using the same dimensions. The manager reads the self-assessment before the conversation. Disagreements between the self-assessment and the manager's assessment are not problems to be resolved in the room; they are signals that evidence needs to be examined together. ### 5.2 The Conversation The performance conversation follows a structured agenda: 1. **Review the period.** What were the person's stated objectives? What changed? 2. **Walk through each dimension.** For each: the manager's assessment with evidence, the team member's perspective, discussion of any gap between the two. 3. **Discuss the overall rating.** Explain the rationale. If it is not what the person expected, spend the time to ensure they understand why before moving on. 4. **Look forward.** Development priorities for the next period. If promotion is a goal, what specific demonstrations are needed? By when? 5. **The person speaks last.** After the manager has presented the assessment and the forward plan, the person has uninterrupted time to respond, ask questions, or raise concerns. ### 5.3 After the Conversation The manager finalizes the written summary, incorporating any adjustments from the conversation (a fact the person raised that the manager had not considered, a disagreement the manager committed to investigate). The final summary is shared with the team member and stored in the performance record. Both the manager and the team member acknowledge receipt; acknowledgment is not necessarily agreement. --- ## 6. Calibration Process Calibration is the mechanism that prevents the single biggest failure mode of any performance system: two managers applying different standards, producing ratings that reflect the manager's leniency rather than the person's performance. ### 6.1 Calibration Session Within two weeks of year-end reviews, pillar leaders convene a calibration session with the CISO. In a small CERG (fewer than 10 people), the session is all-hands with the CISO facilitating. In a larger CERG, it is pillar leaders plus the CISO, with Managers presenting their teams' ratings. The session proceeds role by role, not person by person. For each role (e.g., Cloud Security Engineer, Vendor Risk Analyst): 1. Every person in that role is listed by pillar, grade, and proposed rating. 2. The managers present the evidence for any "Exceeds" or "Below Expectations" rating. 3. The group discusses: does the evidence support the rating relative to the other people in the same role at the same grade? 4. Ratings may be adjusted by consensus. A rating adjusted downward is not a failure of the manager; it is the calibration process working as designed. > **Calibrate Against the Standard, Not the Curve** > > The goal is not to produce a bell curve. If every Cloud Security Engineer is demonstrably exceeding expectations, the standard may be too low for the grade, or the team may be genuinely exceptional. Either conclusion is more honest than forcing a distribution. The test is: can the manager point to specific behaviors at the next-grade level for every "Exceeds" rating? ### 6.2 Calibration Principles 1. **Evidence rules.** A rating without dated, specific evidence is not a rating; it is an opinion. Opinions are not calibrated. 2. **Cross-pillar perspective matters.** An Engineering manager who has never seen a Governance person's work cannot calibrate an Engineering rating. The calibration session brings cross-pillar visibility: a Risk pillar leader may recognize that an Engineer's "Exceeds" rating in Cross-Pillar Fluency is actually standard behavior for the grade. 3. **The CISO is the tiebreaker.** If the calibration group cannot reach consensus on a rating, the CISO decides. The CISO's decision is final and documented with rationale. 4. **Calibration is about ratings, not compensation.** Compensation decisions follow after ratings are calibrated, not during calibration. Mixing the two conversations produces ratings that are negotiated to fit within budget rather than honest assessments of performance. --- ## 7. Promotion Process > **Level Progression Gates**: The job-family-specific level progression gates (L1→L2, L2→L3, L3→L4) are defined in [JF-001 §8](../roles/CERG-GOV-JF-001_Job_Families_Overview.md). Promotion cases should demonstrate satisfaction of the relevant gate conditions in addition to the grade criteria defined in JA-001. ### 7.1 Initiation A promotion case may be initiated by: 1. **The manager**, who has observed sustained next-grade performance and documented it over at least one review cycle. 2. **The team member**, who may request that their manager initiate a promotion review. The manager is not obligated to agree but must provide a written rationale if they decline, identifying the specific dimensions where next-grade performance is not yet demonstrated. 3. **A pillar leader or the CISO**, who may direct a manager to evaluate a team member for promotion based on their own observation. ### 7.2 The Promotion Case The manager prepares a promotion case document addressing: 1. **Current grade and target grade.** 2. **Evidence by dimension.** For each of the six SME dimensions (or nine management dimensions): specific examples of next-grade behavior with dates and context. The evidence should span at least six months and include both routine excellence (consistent at-grade performance) and stretch demonstrations (next-grade behavior). 3. **Cross-pillar input.** At least one person from a different pillar who has worked with the candidate provides a written perspective. This is not a reference check; it is a specific observation of the candidate's cross-pillar engagement. 4. **Development plan for remaining gaps.** Honest acknowledgment of dimensions where the candidate is not yet demonstrating next-grade behavior and how they will develop those capabilities in the new grade. ### 7.3 Approval The promotion case is presented at the calibration session following the year-end review. The approval sequence: 1. **Manager presents** the promotion case to the calibration group. 2. **Calibration group discusses** whether the evidence supports the case. The discussion follows the same calibration principles as ratings: evidence, cross-pillar perspective, and the standard for the target grade. 3. **Pillar leader concurs or defers.** If the pillar leader concurs, the case proceeds to the CISO. If the pillar leader defers, the case is returned with specific feedback on what additional evidence is needed. 4. **CISO approves or defers.** The CISO makes the final decision. A deferral includes written rationale that the manager and the candidate can act on for the next cycle. > **The Promotion Standard** > > The question is not "is this person ready to try the next grade?" It is "has this person already demonstrated sustained performance at the next grade?" The first question promotes people into roles they grow into, sometimes successfully, sometimes at the team's expense. The second question promotes people who have already proven they can do the work. CERG uses the second question. ### 7.4 Time-in-Grade Expectations JA-001 defines "typical experience" ranges for each grade. These are inputs to placement, not guarantees of progression. That said, the following minimum time-in-grade guidelines ensure that a promotion case has sufficient evidence: | Current Grade | Minimum Time Before Promotion Eligibility | Rationale | |---|---|---| | S1 / Specialist | 18 months | A full performance cycle plus a development cycle to demonstrate growth | | S2 / Sr. Specialist | 24 months | Next-grade behavior at S3 requires cross-pillar demonstration, which takes time to develop | | S3 / Advisor | 30 months | S4 is the narrowest gate in the SME track; requires organizational-level impact | | M1 / Manager | 24 months | Requires demonstrated team development and function-level outcomes | | M2 / Senior Manager | 30 months | Requires multi-team leadership and strategic contribution | | M3 / Principal Manager | 30 months | Director is the narrowest gate in the management track | Exceptional candidates with extraordinary demonstrated capability may be considered before the minimum. "My last company promoted me faster" is not extraordinary capability. "This person rebuilt our cloud security architecture, mentored three engineers to promotion, and is recognized by our regulators as an authority" may be. --- ### 7.5 Promotion Panel Composition Every promotion case is reviewed by a cross-pillar promotion panel that ensures fairness, consistency, and breadth of perspective. | **Panel Role** | **Who** | **Purpose** | |---|---|---| | **Panel Chair** | Pillar leader of the candidate's pillar | Chairs the session; ensures process fairness; presents the promotion case | | **Cross-Pillar Reviewer** | A pillar leader from a different pillar than the candidate's | Provides independent perspective on cross-pillar competency and organizational impact | | **Subject Matter Expert** | A senior practitioner (S3+) in the candidate's discipline, from any pillar | Assesses craft-mastery evidence against the target grade's CMP-001 behavioral anchors | | **HR Business Partner** | HR representative | Ensures process compliance, equity, and documentation standards | | **CISO** | Chief Information Security Officer | Final approval authority; attends or receives written recommendation for decisions at S3+ | The panel must include at least three voting members. The cross-pillar reviewer and the SME must not be the same person. No panel member may evaluate a candidate they directly manage (to prevent conflict of interest), except the panel chair whose role is to present, not to evaluate in isolation. ### 7.6 Promotion Timeline and Communication The promotion cycle follows a defined calendar aligned to the performance management cadence: | **Date** | **Activity** | **Owner** | |---|---|---| | 6 weeks before calibration | Manager initiates promotion case; begins evidence collection | Manager | | 4 weeks before calibration | Cross-pillar input solicited and received | Manager | | 2 weeks before calibration | Promotion case document finalized; submitted to panel chair | Manager | | Calibration session (per §6) | Promotion case presented and evaluated at calibration | Panel Chair | | Within 1 week of calibration | CISO approves or defers; written rationale provided for deferrals | CISO | | Within 2 weeks of approval | Promotion announced to candidate; new grade effective date set | Manager + HR | | Within 1 week of announcement | Team/squad notified by manager; broader team notified by pillar leader | Manager / Pillar Leader | **Communication principles:** 1. **The candidate hears first, before any other team member.** No one learns of a promotion from a colleague before the candidate hears it from their manager. 2. **Deferred promotions include a development plan.** A deferral is not a denial. It identifies specific competency gaps and the timeline and resources to close them. The candidate and manager agree on a development plan within 2 weeks of the deferral. 3. **Communicated promotions are celebrated.** The promotion is announced at the next CERG All-Hands or pillar meeting. The announcement includes what the candidate accomplished to earn the promotion, reinforcing the standard for others. 4. **External communication is coordinated.** If the promotion is part of a broader organizational announcement (e.g., pillar leader hire), coordinate with HR and Communications per organizational policy. ## 8. Performance Improvement Process A "Below Expectations" rating triggers the performance improvement process. This is not punitive; it is a structured attempt to close the gap. It is also a documentation trail that supports a separation decision if the gap does not close. ### 8.1 Performance Improvement Plan (PIP) Within two weeks of a "Below Expectations" rating, the manager and the team member agree on a Performance Improvement Plan: 1. **Specific dimensions** where performance does not meet expectations, with examples. 2. **Specific, measurable improvement targets** for each dimension, with a timeline (typically 60-90 days). 3. **Support the organization will provide**: training, mentoring, reduced scope, or other resources. 4. **Check-in cadence**: typically weekly, with written progress notes. 5. **Outcomes**: success (rating moves to "Meets Expectations" or "Developing"), extension (progress but targets not met; PIP extended by 30-60 days), or separation (targets not met and no credible path to meeting them). ### 8.2 PIP Principles 1. **The PIP is not a surprise.** A person who receives a "Below Expectations" rating should have received feedback on the performance gap throughout the review period. The PIP is a formalization of an ongoing conversation, not the start of one. 2. **The PIP is written, not verbal.** Both parties sign it. It is stored in the performance record. 3. **HR is informed at initiation, not at separation.** HR should know a PIP exists from day one, not day ninety. 4. **Success is celebrated, not held against the person.** A person who completes a PIP successfully and sustains the improvement is not "the person who was on a PIP." The PIP closes and the record reflects the improved performance. --- ## 9. Documentation Standards ### 9.1 The Performance Record Every CERG team member has a performance record maintained by their manager. The record contains: | Document | Frequency | Content | |---|---|---| | **Performance Summary** | Semi-annual | Evaluation per §5 dimensions, overall rating, forward development priorities | | **Quarterly Check-In Notes** | Quarterly | 1-3 sentences capturing the check-in discussion | | **Significant Feedback Notes** | As needed | Dated notes on significant positive or corrective feedback | | **Self-Assessments** | Semi-annual | Team member's self-evaluation against the same dimensions | | **Development Plan** | Annual (updated semi-annually) | Development priorities, actions, and timeline | | **Promotion Case** | As applicable | Full promotion case document per §7.2 | | **PIP Documents** | As applicable | PIP, weekly check-in notes, outcome determination | ### 9.2 The Performance Summary Format The semi-annual performance summary follows a consistent structure designed to be thorough and concise: **Team Member:** [Name] **Role:** [Canonical role from OM-001 §6.1] **Grade:** [Current grade] **Review Period:** [Mid-Year YYYY / Year-End YYYY] **Manager:** [Name] **Outcomes Delivered:** [Bulleted list of 3-7 significant outcomes delivered in the period. Each outcome is specific: what was delivered, on what timeline, with what impact. "Improved cloud security posture" is not an outcome. "Reduced CSPM critical alerts from 47 to 3 across 120 AWS accounts through policy-as-code and engineering-team enablement (March-October)" is an outcome.] **Dimension Assessment:** - **Craft Mastery:** [Evidence-based assessment with examples] - **Scope and Autonomy:** [Evidence-based assessment with examples] - **Influence and Mentorship:** [Evidence-based assessment with examples] - **Cross-Pillar Fluency:** [Evidence-based assessment with examples] - **Operational Discipline:** [Evidence-based assessment with examples] *For management-track roles, add:* - **People Leadership:** [Evidence-based assessment with examples] - **Team Delivery:** [Evidence-based assessment with examples] - **Strategic Contribution:** [Evidence-based assessment with examples] **Overall Rating:** [Exceeds / Meets / Developing / Below Expectations] **Forward Development Priorities:** [2-4 specific development actions for the next period. Each action has a target dimension, a concrete activity, and a timeline.] ### 9.3 Storage and Access Performance records are stored in the organization's HR system of record. If the organization does not have an HR system that supports structured performance documentation, records are maintained as documents in a controlled access location (e.g., a restricted SharePoint folder, a secure HR drive). Access is limited to: - The team member (their own record) - Their manager - Their manager's manager (pillar leader or above) - The CISO - HR business partner - Legal, when relevant to employment actions Performance records are retained per the organization's record retention policy, typically for the duration of employment plus a defined post-employment period. --- ## 10. Integration with Other CERG Instruments ### 10.1 Competency Model (CMP-001) The performance review dimensions map directly to CMP-001 competency domains. The CMP-001 behavioral anchors provide the "what good looks like" reference for each dimension at each grade. A manager evaluating a Detection Engineer at S2 should have CMP-001 §5 open and reference specific anchors. ### 10.2 Job Architecture (JA-001) The JA-001 grade definitions (§4-5) and leveling dimensions (§6) are the authoritative source for what each grade expects. This document operationalizes those expectations into a recurring process. Where this document and JA-001 conflict, JA-001 governs. ### 10.3 Succession Planning (SUCC-001) The talent review process in CERG-GOV-SUCC-001 consumes calibrated performance ratings and promotion decisions as its primary input. Succession planning cannot begin until at least one performance cycle has produced calibrated ratings. ### 10.4 Training and Certification (TRN-001) Development plans produced through this process inform individual training needs. The CERG-GOV-TRN-001 training curriculum is the primary resource for closing competency gaps identified in performance reviews. --- ## 11. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-PERF-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to grade definitions or organizational structure | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Establishes semi-annual performance management cadence aligned to CERG operating rhythm. Defines six SME and three management evaluation dimensions mapped to JA-001 and CMP-001. Establishes calibration process with evidence-based ratings. Defines promotion process from initiation through CISO approval. Provides documentation standards and performance improvement process. | ### Review Triggers - Change to the grade definitions in CERG-GOV-JA-001 - Feedback from calibration sessions indicating dimensions or ratings need refinement - Material change to organizational structure or management hierarchy - Regulatory requirement for personnel evaluation documentation - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Architecture and Grade Framework | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions and progression dimensions | | Competency Model | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors for evaluation dimensions | | CERG Job Descriptions | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | Success profiles and role-specific outcomes | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Succession Planning Framework | [`CERG-GOV-SUCC-001`](CERG-GOV-SUCC-001_Succession_Planning_and_Talent_Review_Framework.md) | Consumes calibrated ratings | | Training Framework | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Development resource for gap closure | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## SUCCESSION PLANNING AND TALENT REVIEW FRAMEWORK ### Heat Maps · Readiness Ratings · Emergency Succession · Development Plans --- | | | |---|---| | **Document ID** | CERG-GOV-SUCC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Confidential - CISO and Pillar Leaders | | **Owner** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) · [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) · [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) · [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | | **Review Cycle** | Annual talent review; emergency succession list reviewed semi-annually | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The Single-Point-of-Failure Problem](#2-the-single-point-of-failure-problem) 3. [Annual Talent Review](#3-annual-talent-review) 4. [The Succession Heat Map](#4-the-succession-heat-map) 5. [Emergency Succession](#5-emergency-succession) 6. [Successor Development Plans](#6-successor-development-plans) 7. [Cross-Pillar Succession](#7-cross-pillar-succession) 8. [Confidentiality and Access](#8-confidentiality-and-access) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope The CERG Framework (FRM-001 §9.2) states that the left-right knowledge model provides "talent resilience." A team where every member understands the other two pillars is more resilient than one where knowledge is siloed. But cross-pillar understanding is not a succession plan. Knowing how the Risk pillar operates does not make a Cloud Security Engineer ready to lead it. Knowing where the evidence library lives does not make a Detection Engineer ready to represent the organization to a NERC-CIP auditor. This document closes that gap. It establishes a formal succession planning framework: an annual talent review cadence, a succession heat map for every critical CERG role, readiness ratings for identified successors (Ready Now, Ready in 1-2 Years, Ready in 3-5 Years, No Identified Successor), development plans for closing successor readiness gaps, an emergency succession protocol defining who steps in on 24 hours' notice, and cross-pillar succession requirements that ensure no pillar leader's only potential successor comes from the same pillar. It applies to every critical CERG role: the CISO, pillar leaders, domain leads, and any role whose sudden vacancy would create a material operational risk. It does not apply to contractor or consultant roles, which are addressed by the knowledge retention requirements in CERG-GOV-CON-001. > **This Document Is Confidential** > > Succession planning is among the most sensitive activities a leadership team undertakes. A person identified as "Ready in 3-5 Years" who learns they are not "Ready Now" may feel passed over. A person not identified as a successor at all may feel their career has plateaued. This document and the heat maps it produces are restricted to the CISO and pillar leaders. Individual development conversations draw from the succession analysis without revealing the analysis itself, the same way a manager uses calibration session output to inform a promotion conversation without naming the people who were rated higher. --- ## 2. The Single-Point-of-Failure Problem ### 2.1 Why Cybersecurity Is Especially Vulnerable Cybersecurity teams have a single-point-of-failure problem that is worse than most knowledge-work functions for three reasons: 1. **Deep specialization resists documentation.** A Cryptography Engineer who has managed the PKI hierarchy for seven years carries knowledge that lives in their head: which certificates have quirks, which CAs have trust-chain issues with which vendors, which renewal processes have undocumented manual steps. That knowledge is partially documented and partially not. The person who leaves takes both halves. 2. **Regulatory relationships are personal.** A NERC-CIP Compliance Manager who has been the organization's face to its regional entity for a decade has a relationship with the auditors that a replacement cannot replicate on day one. The auditor who trusts the Compliance Manager's evidence because of a decade of demonstrated rigor will not extend that trust automatically to a replacement. 3. **Small teams have no bench.** A 5-person CERG team cannot afford a dedicated understudy for every role. When the person who runs Exposure Management leaves, someone else absorbs that work on top of their own. If that person also leaves, the function stops. ### 2.2 What the Left-Right Model Does and Does Not Solve The left-right knowledge model reduces the SPOF risk by ensuring that: - Every person knows enough about the other two pillars to collaborate effectively - Documentation is consumed cross-pillar, not just within the pillar that authored it - The evidence library, risk register, and document library are structured to survive any single person's departure It does not solve: - **Leadership succession.** Cross-pillar understanding is not cross-pillar leadership readiness. The Governance Pillar Leader has a specific set of management, regulatory, and stakeholder skills that are not developed by reading Engineering standards. - **Deep domain succession.** Understanding what a Cryptography Engineer does is not the same as being able to do it. The left-right model provides awareness; succession requires capability. - **Emergency succession.** If the Risk Pillar Leader resigns effective immediately, the left-right model provides nobody who can step into the role on 24 hours' notice unless that person has been deliberately developed for it. --- ## 3. Annual Talent Review ### 3.1 Cadence The talent review occurs annually, within four weeks of the year-end calibration session (PERF-001 §6). It consumes calibrated performance ratings and promotion decisions as input and produces the succession heat map as output. The sequence ensures that succession decisions are based on current, calibrated assessments, not on reputation from two years ago. ### 3.2 Participants | Organization Size | Participants | |---|---| | **5-person CERG** | CISO (sole reviewer; the CISO is also a subject of the review for their own succession, which is addressed with the board or Executive Sponsor) | | **15-person CERG** | CISO + Pillar Leaders | | **35+ person CERG** | CISO + Pillar Leaders + Senior Managers (for their functions) | ### 3.3 Agenda The talent review addresses each critical role in sequence: 1. **Role:** [Canonical role name] 2. **Incumbent:** [Name and current grade] 3. **Retention risk:** Low / Medium / High. Is the incumbent a flight risk? Why? 4. **Succession status:** Review the current heat map ratings for identified successors. 5. **Successor development progress:** What development actions were planned at the last review? What progress was made? 6. **New successors?** Has anyone emerged as a potential successor since the last review? 7. **Emergency successor:** Is the emergency successor still current? Any changes? 8. **Actions:** What will be done in the next 12 months to improve succession readiness for this role? ### 3.4 Output The talent review produces: 1. **Updated succession heat map** for every critical role (§4) 2. **Updated successor development plans** (§6) 3. **Updated emergency succession list** (§5) 4. **Retention risk register:** roles where the incumbent is a flight risk, with mitigation actions 5. **Succession gaps report:** roles with No Identified Successor, with a timeline and plan for developing one --- ## 4. The Succession Heat Map ### 4.1 Critical Roles Not every canonical CERG role is critical for succession planning. A role is critical if its sudden vacancy would cause a material operational disruption that cannot be absorbed by the existing team within 30 days. The minimum set of critical roles includes: | Tier | Roles | |---|---| | **Tier 1: Immediate organizational risk** | CISO; Engineering Pillar Leader; Risk Pillar Leader; Governance Pillar Leader | | **Tier 2: Material function risk** | Cloud Security Engineer (senior/lead); OT Security Engineer (if OT environment); Exposure Management Lead; Detection Engineer (senior/lead); NERC-CIP Compliance Manager (if CIP-regulated); CMMC Compliance Manager (if CMMC-scoped); SOX ITGC Lead (if SOX-scoped); Risk Register Owner; Policy & Standards Manager | | **Tier 3: Important domain risk** | Identity Engineer (senior/lead); Application Security Engineer (senior/lead); Adversarial Testing Lead; Threat Intelligence Analyst (senior/lead); Vendor Risk Analyst (senior/lead); Evidence Librarian; Cryptography Engineer | The CISO and pillar leaders may add or remove roles from the critical list at each annual talent review based on current organizational context. ### 4.2 Readiness Ratings Each identified successor for a critical role receives a readiness rating: | Rating | Definition | Action Implication | |---|---|---| | **Ready Now** | The person could assume the role effectively within 30 days with minimal transition support. They have demonstrated the required competencies at the target level. | No development action required for readiness. Retain the person and ensure they are aware of their readiness (without guaranteeing the role). | | **Ready in 1-2 Years** | The person has the foundational capabilities but needs specific experiences, training, or exposure to be fully ready. The gap is known and a development plan exists. | Execute the development plan. Review progress at each quarterly check-in. Re-rate at the next talent review. | | **Ready in 3-5 Years** | The person is a long-term development candidate. They have demonstrated potential but need substantial growth in multiple dimensions. | Long-term development plan with intermediate milestones. May not be ready for emergency succession. | | **No Identified Successor** | No person in the organization has been identified as a credible successor for this role. | This is a gap that must be addressed. Options: develop an internal candidate, recruit with succession in mind, or document the interim operating model if the role goes vacant. | ### 4.3 The Heat Map Format For each critical role, the heat map records: ``` Role: [Canonical Role] Incumbent: [Name] Retention Risk: [Low/Medium/High] Successors: | Name | Current Role | Readiness | Development Priorities | |---|---|---|---| | [Name] | [Current role] | Ready Now | N/A | | [Name] | [Current role] | Ready in 1-2 Yrs | [2-3 specific gaps] | | No Identified Successor | - | - | [Plan to address] | Emergency Successor: [Name] or [None] Cross-Pillar Successor: [Name] or [None] ``` > **"Ready Now" Does Not Mean "Will Get the Role"** > > Identifying someone as Ready Now is a statement about their capability, not a promise of succession. The incumbent may stay for another decade. The organization's needs may change. Another candidate may emerge. The Ready Now rating means that if the role became vacant tomorrow, this person is the credible internal candidate. It does not mean the role is theirs. --- ## 5. Emergency Succession ### 5.1 The 24-Hour List For every Tier 1 critical role (CISO, pillar leaders), an emergency successor is designated. The emergency successor is the person who steps into the role on 24 hours' notice if the incumbent is suddenly unavailable (resignation, illness, termination, or any other sudden departure). The emergency successor is not necessarily the long-term successor. They are the person who keeps the function operating while a permanent replacement is found. ### 5.2 Emergency Successor Requirements The emergency successor must: - Be a current CERG team member (not a contractor, not an external party) - Have sufficient organizational knowledge to perform the role's most critical functions: approve urgent decisions, represent the function to executive leadership, and ensure standing operations continue - Know they are the emergency successor and have accepted the responsibility - Have documented access to the systems, contacts, and decision authorities they will need - Be reviewed semi-annually (not just at the annual talent review) to confirm they are still with the organization and still willing ### 5.3 Emergency Succession by Tier | Tier | Emergency Successor Model | |---|---| | **CISO** | Designated by the board or CEO in consultation with the CISO. Typically a pillar leader or a Deputy CISO if the organization has one. The Executive Sponsor may serve as interim CISO for a limited period per organizational succession policy. | | **Engineering Pillar Leader** | The senior-most Cloud Security Engineer or OT Security Engineer at S4 or S3, with documented delegation from the CISO. | | **Risk Pillar Leader** | The Exposure Management Lead or senior-most Detection Engineer at S3-S4, with documented delegation from the CISO. | | **Governance Pillar Leader** | The NERC-CIP Compliance Manager or Policy & Standards Manager at S3-S4, with documented delegation from the CISO. | ### 5.4 Emergency Succession Documentation For each emergency successor, the following documentation is maintained and reviewed semi-annually: 1. **Delegation of authority:** A signed document from the CISO (or board, for CISO succession) delegating specific decision authorities to the emergency successor during the interim period. 2. **Access verification:** Confirmation that the emergency successor has (or can rapidly obtain) access to all systems, accounts, and physical spaces needed to perform the role. 3. **Key contacts list:** The 10-15 people the emergency successor needs to contact in the first 24 hours: executive leadership, pillar leaders, key business stakeholders, regulators, critical vendors, the IR team lead. 4. **Standing decisions and deadlines:** A current list of pending decisions, upcoming deadlines, and active escalations that the emergency successor will inherit. 5. **Transition checklist:** Step-by-step actions for the first 24 hours, first week, and first month. > **Emergency Succession Is Not Optional** > > An organization that cannot name who runs Engineering if the Engineering Pillar Leader is hit by a bus tomorrow has not planned; it has hoped. The emergency succession list must exist at all times. A blank emergency successor field for any Tier 1 role is a risk that should be reported to the CISO and recorded in the risk register. --- ## 6. Successor Development Plans ### 6.1 The Development Plan Format For each successor rated "Ready in 1-2 Years" or "Ready in 3-5 Years," a development plan addresses the specific gaps preventing a "Ready Now" rating. The plan is owned by the successor's manager (or the incumbent, if the successor reports to a different manager) and reviewed at each quarterly check-in. The development plan contains: 1. **Target role** and target readiness timeline 2. **Gap assessment:** Which CMP-001 competency domains are not yet at the target level? Which JA-001 management dimensions, if the target is a management role? 3. **Development actions** for each gap: - **Experiential:** Specific stretch assignments, interim role coverage, cross-pillar initiatives, or acting-manager rotations - **Educational:** Specific training, certification, or conference attendance per TRN-001 - **Relational:** Specific exposure to the stakeholders, regulators, or executive forums the person would need to navigate in the target role 4. **Milestones:** Observable demonstrations that would indicate readiness progress (e.g., "led a CISO Risk & Posture Review presentation," "represented Engineering to a regulator walkthrough," "managed the team for two weeks during the incumbent's leave") 5. **Timeline:** When each action is planned and when readiness will be reassessed ### 6.2 Development by Readiness Gap | Gap Domain | Typical Development Actions | |---|---| | **Strategic thinking** | Assign to lead a pillar strategy initiative. Invite to pillar leadership meetings as an observer-contributor. Pair with the incumbent for budget cycle process. | | **Executive communication** | Assign to present at CISO Risk & Posture Review. Coach on written executive communications. Shadow the incumbent in board-preparation sessions. | | **People leadership** | Assign a mentee or intern. Provide acting-manager rotation during the incumbent's leave. Enroll in management training. | | **Stakeholder management** | Assign as the CERG representative in a cross-functional initiative. Accompany the incumbent to regulator/auditor meetings. Build relationships with key business stakeholders directly. | | **Budget and resource management** | Involve in the budget planning cycle. Assign vendor relationship management for a tool or service. Review total cost of ownership for a function. | | **Cross-pillar depth** | Extended cross-pillar rotation (2-4 weeks instead of 1 day). Lead a cross-pillar initiative. Author a standard or procedure in a different pillar's domain with that pillar's review. | ### 6.3 Tracking and Accountability Successor development plan progress is reviewed at: - **Quarterly check-ins** (PERF-001 §3.2): Progress against planned actions - **Annual talent review**: Readiness re-rating based on demonstrated progress - **CISO quarterly review**: The CISO reviews succession readiness for Tier 1 roles at each CISO Risk & Posture Review A successor whose development plan shows no progress for two consecutive quarters is either not motivated, not capable, or not receiving the promised development support. The talent review addresses which it is and adjusts the plan or the readiness rating accordingly. --- ## 7. Cross-Pillar Succession ### 7.1 The Principle Every Tier 1 critical role (CISO and pillar leaders) should have at least one potential successor who comes from a different pillar. The principle is an extension of the left-right knowledge model: a person who has led only Engineering their entire career will struggle to lead Risk or Governance without a deliberate development investment. But a person who knows two pillars deeply and the third well enough to collaborate is a stronger candidate for any pillar leadership role than someone who knows only one. ### 7.2 Cross-Pillar Successor Development | Target Pillar Leader Role | Cross-Pillar Successor Might Come From | Key Development Need | |---|---|---| | **Engineering Pillar Leader** | Senior Risk practitioner (S3-S4) with strong technical background | Deepen engineering craft mastery; lead architecture initiatives; own reference architecture authority | | **Risk Pillar Leader** | Senior Engineering practitioner (S3-S4) with strong analytical skills | Deepen risk methodology; lead threat assessments; own exposure reporting | | **Governance Pillar Leader** | Senior Engineering or Risk practitioner (S3-S4) with regulatory exposure | Deepen compliance methodology; lead audit engagements; own regulatory relationships | | **CISO** | Any pillar leader with cross-pillar experience and executive presence | Board communication; budget ownership at organizational scale; external stakeholder management | ### 7.3 Not a Requirement, a Direction A Tier 1 role with no cross-pillar successor is not a crisis. It is a development priority for the next 2-3 years. The talent review identifies which pillar leaders have cross-pillar successor potential and adds cross-pillar development actions to their plans. Over multiple cycles, the succession bench becomes cross-pillar by development, not by coincidence. --- ## 8. Confidentiality and Access ### 8.1 Access Controls The succession heat map, emergency succession list, and successor development plans are confidential. Access is restricted to: - **CISO:** Full access to all succession materials - **Pillar Leaders:** Access to succession materials for their pillar and cross-pillar successors from their pillar to other Tier 1 roles. A pillar leader does not see the succession plan for their own role (that is held by the CISO). - **Board or designated board committee:** Access to CISO succession plan and summary of Tier 1 succession readiness (not individual names unless requested) - **HR Business Partner:** Access to development plans (not heat maps) for coordination of training, budget, and personnel actions ### 8.2 Communication Guidelines Succession information is communicated on a need-to-know basis: | What | Who Is Told | What They Are Told | What They Are Not Told | |---|---|---|---| | **"Ready Now" successor** | The successor | "If this role became vacant, you would be a strong internal candidate. Let us discuss what you would need to be ready." | That they are the only Ready Now candidate, or that they have been formally designated | | **"Ready in 1-2 Years" successor** | The successor | "We see a leadership path for you toward [role]. Here is the development plan to get you there." | Their specific readiness rating or how they compare to other successors | | **Emergency successor** | The successor | "You are the designated emergency successor for [role]. Here is what that means and what you need." | Nothing about long-term succession | | **No identified successor (Tier 1 role)** | CISO and board (summary) | "We have a succession gap for [role]. Here is our plan to address it." | Not shared with the broader team unless the role becomes vacant | > **Do Not Promise Roles You May Not Be Able to Deliver** > > A manager who tells a team member "you are my successor" has made a promise that organizational changes, hiring decisions, or the person's own career choices may break. The succession framework identifies readiness and develops capability. It does not make commitments. A Ready Now rating is a professional assessment, not a job offer. --- ## 9. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-SUCC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Confidential - CISO and Pillar Leaders | | **Owner** | CISO | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual talent review; emergency succession list reviewed semi-annually | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Establishes annual talent review cadence and succession planning framework for critical CERG roles. Defines four-tier readiness rating scale (Ready Now, Ready in 1-2 Years, Ready in 3-5 Years, No Identified Successor), succession heat map format, emergency succession protocol with 24-hour documentation requirements, successor development plan structure, cross-pillar succession requirements, and confidentiality and access controls. | ### Review Triggers - Annual talent review (mandatory annual refresh) - Any Tier 1 role incumbent departure, resignation notice, or extended leave - Material change to organizational structure affecting role definitions - CISO direction ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade expectations for successor readiness evaluation | | Competency Model | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Competency domains for gap assessment | | Performance Management | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Input ratings for talent review | | Training Framework | [`CERG-GOV-TRN-001`](CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Development resources for successor plans | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster and role definitions | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Left-right knowledge model and talent resilience | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns the framework. The CISO owns the succession plans and heat maps produced under it. The CISO is responsible for initiating the annual talent review, maintaining the emergency succession list, and ensuring successor development plans are resourced and tracked. --- ## TRAINING, DEVELOPMENT, AND CERTIFICATION FRAMEWORK ### Certification Matrix · Development Curriculum · Budget Guidance · Cross-Training --- | | | |---|---| | **Document ID** | CERG-GOV-TRN-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) · [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) · [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) · [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | | **Review Cycle** | Annual / On any change to certification requirements or competency model | | **Frameworks** | [NIST NICE Workforce Framework](https://www.nist.gov/itl/applied-cybersecurity/nice) (SP 800-181r1) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.2 · [DoD 8140.03](https://public.cyber.mil/wid/dcwf/) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Training Philosophy](#2-training-philosophy) 3. [Certification Matrix: Required, Recommended, and Aspirational](#3-certification-matrix-required-recommended-and-aspirational) 4. [Training Curriculum by Competency Domain](#4-training-curriculum-by-competency-domain) 5. [Cross-Training: The 5% Rule](#5-cross-training-the-5-rule) 6. [Professional Development Budget](#6-professional-development-budget) 7. [Conference and External Engagement](#7-conference-and-external-engagement) 8. [Training Administration](#8-training-administration) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope Cybersecurity skills have a half-life measured in months, not years. A Detection Engineer whose knowledge stops advancing writes rules for last year's threats. A Cloud Security Engineer who does not track platform evolution reviews architectures against a mental model that is already obsolete. A NERC-CIP Compliance Manager who does not monitor regulatory developments discovers a new requirement when the auditor cites it. The Job Descriptions (JD-001) list relevant certifications per role. They do not define which are required, which are recommended, who pays, or how certification connects to progression. The Competency Model (CMP-001) defines what good looks like at each grade. It does not define the path to get there. This document closes both gaps. It provides a role-to-certification matrix with three tiers (required, recommended, aspirational) per role and grade, a training curriculum mapped to CMP-001 competency domains, a cross-training standard that operationalizes the left-right knowledge model into a measurable time commitment, a professional development budget guideline, and conference and external engagement expectations. It applies to every CERG team member. Certifications are role-dependent; the training philosophy, cross-training expectation, and budget guidelines are universal. > **Training Is an Investment, Not a Perk** > > An organization that treats training as a reward for good performance is sending a signal that capability development is optional. An organization that treats training as a recurring operational expense, budgeted, tracked, and expected, is building a team that gets better every quarter. The first organization loses its best people to the second. --- ## 2. Training Philosophy 1. **Development is a shared responsibility.** The organization provides the budget, the time, and the curriculum. The individual provides the effort, the curiosity, and the follow-through. Neither party can succeed without the other. 2. **Certifications validate, they do not replace.** A certification confirms that a person has demonstrated a body of knowledge at a point in time. It does not confirm that they apply it effectively in their role. Certifications are useful for hiring credibility, regulatory compliance, and structured learning. They are not a substitute for demonstrated competency. 3. **Training closes the gap between current and target.** Every development activity should connect to a gap identified in the person's performance review (PERF-001) or their self-assessment against the competency model (CMP-001). "I want to learn Kubernetes security" is a valid interest. "I need to learn Kubernetes security because my next-grade competency anchor requires architecture reviews of containerized workloads" is a development plan. 4. **Cross-training is not optional.** The left-right knowledge model (FRM-001 §9.2) depends on every CERG team member understanding the other two pillars well enough to collaborate effectively. Cross-training is a standing expectation, not a discretionary activity. 5. **Knowledge shared is knowledge multiplied.** If the organization sends a person to a conference, a training course, or a certification boot camp, that person presents what they learned to the team. The organization's return on the training investment includes not just one person's capability gain but the team's. --- ## 3. Certification Matrix: Required, Recommended, and Aspirational ### 3.1 Certification Tiers | Tier | Definition | Who Pays | Timeline | |---|---|---|---| | **Required** | The person must hold this certification to perform the role. Required certifications are listed in the job description and verified at hire or within a defined post-hire window. | Organization | Maintained continuously; new hires have 6-12 months to obtain if not held at hire | | **Recommended** | The certification materially improves the person's capability in their role and is expected within the first 18-24 months. | Organization | Expected within 18-24 months of role entry or grade advancement | | **Aspirational** | The certification represents advanced capability in the role or a related domain. It is a development target for progression to the next grade. | Organization (if aligned to development plan) or individual with organizational support | No fixed timeline; pursued when aligned to development priorities | > **NICE Mapping**: The NICE Work Role(s) associated with each certification are documented in [JF-002](../roles/CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). Each certification row below supports the NICE Work Role mapping for the corresponding CERG role. See the individual per-role JD documents for role-specific NICE TKS statement references. ### 3.2 Engineering Pillar: Certification Matrix #### Cloud Security Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ or equivalent | AWS Certified Security - Specialty, Microsoft AZ-500, or Google Professional Cloud Security Engineer (one, platform-dependent) | CCSP | | **S2** | Platform security certification relevant to the organization's primary cloud (as above) | Second platform certification; Terraform Associate or equivalent IaC certification | CISSP, CCSP | | **S3** | CISSP or CCSP | SANS GIAC (GCLD, GPCS, or relevant cloud security GIAC); Kubernetes security certification (CKS) | ISSAP, platform architecture certifications | | **S4** | CISSP | One additional advanced certification (ISSAP, ISSMP, or SANS GIAC expert-level) | Industry contributions in lieu of further certifications | #### Identity Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | Microsoft SC-300 or equivalent IdP certification | - | | **S2** | One IdP-specific certification (SC-300, Okta Certified Professional, etc.) | Second IdP certification; basic PAM certification | CISSP | | **S3** | CISSP | Advanced identity certification (e.g., SC-100, Okta Certified Architect); PAM certification | ISSAP, CIAM-related certification | | **S4** | CISSP | ISSAP or ISSMP | - | #### OT Security Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | GICSP or ISA/IEC 62443 Cybersecurity Specialist | - | | **S2** | GICSP | ISA/IEC 62443 Expert; CISSP | SANS GIAC (GRID, GCIP) | | **S3** | CISSP | SANS GIAC relevant to OT; NERC-CIP-specific training if applicable | ISSAP | | **S4** | CISSP | Advanced ICS/SCADA security certification | - | #### Application Security Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | CSSLP or Certified Ethical Hacker (CEH) | - | | **S2** | CSSLP or CEH | GWEB or relevant SANS GIAC; OWASP certification | CISSP | | **S3** | CISSP | GWEB, GMOB, or GPEN; cloud-native security (CKS or equivalent) | ISSAP | | **S4** | CISSP | ISSAP | - | #### Endpoint Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | Vendor-specific EDR certification | - | | **S2** | One EDR/endpoint security certification | Second platform certification; OS-specific security certification | CISSP | | **S3** | CISSP | GCFE, GNFA, or relevant SANS GIAC | ISSAP | | **S4** | CISSP | ISSAP or additional GIAC expert-level | - | #### Cryptography Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | Vendor PKI/HSM certification | - | | **S2** | One cryptography or PKI certification | CISSP | SANS GIAC (GSE or relevant crypto) | | **S3** | CISSP | SANS GIAC advanced crypto; FIPS/Common Criteria training | ISSAP | | **S4** | CISSP | ISSAP | - | ### 3.3 Risk Pillar: Certification Matrix #### Exposure Management Lead | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | Qualys/ Tenable/ Rapid7 certified specialist (platform-dependent) | CEH | | **S2** | One exposure management platform certification | CEH or GPEN; CISSP | GCIH | | **S3** | CISSP | GPEN, GCIH, or GWAPT | OSCP, OSWE | | **S4** | CISSP | Two or more advanced GIAC certifications | - | #### Adversarial Testing Lead | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | CEH | GPEN | | **S2** | GPEN or CEH (Practical) | OSCP; GWAPT | CISSP | | **S3** | OSCP | OSCE/OSEP; CISSP; cloud penetration testing certification | GXPN, OSEE | | **S4** | CISSP | OSEE or equivalent expert-level offensive certification | - | #### Threat Intelligence Analyst | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | CTIA or equivalent | GCTI | | **S2** | GCTI or CTIA | CISSP; OSINT certification | GREM | | **S3** | CISSP | GCTI (if not already held); GREM | Advanced threat intelligence (GCTI expert, FOR578) | | **S4** | CISSP | GREM or equivalent | - | #### Vendor Risk Analyst | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | CTPRP or equivalent | - | | **S2** | CTPRP or equivalent | CISSP; CISA | CRISC | | **S3** | CISSP | CISA or CRISC; Shared Assessments CTPRP | CGEIT | | **S4** | CISSP | CISA, CRISC, or CGEIT | - | #### Detection Engineer | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | SIEM platform certification (Splunk, Sentinel, Chronicle) | GCIA | | **S2** | SIEM platform certification | GCIA or GCDA; CISSP | GNFA | | **S3** | CISSP | GCIA, GCDA, or GNFA | GSE, advanced forensics | | **S4** | CISSP | Two or more advanced GIAC detection/forensics certifications | - | #### OT Risk Analyst | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | GICSP | - | | **S2** | GICSP | ISA/IEC 62443; CISSP | GRID | | **S3** | CISSP | GRID, GCIP | Advanced ICS security | | **S4** | CISSP | Two or more relevant GIAC certifications | - | #### Identity Risk Analyst | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | UEBA platform certification | - | | **S2** | One identity security or UEBA certification | CISSP; GCIA | GNFA | | **S3** | CISSP | GNFA or equivalent | Advanced identity threat detection | | **S4** | CISSP | Two or more relevant certifications | - | ### 3.4 Governance Pillar: Certification Matrix #### NERC-CIP Compliance Manager | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | NERC CIP-specific training (NERC-approved) | CISA | | **S2** | NERC CIP training completion; Security+ | CISA; CISSP | CRISC | | **S3** | CISSP or CISA | CRISC; advanced NERC compliance training | CGEIT | | **S4** | CISSP | CISA and CRISC; or CGEIT | - | #### CMMC / Federal Compliance Manager | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | CMMC RP or equivalent | CISA | | **S2** | CMMC RP | CMMC RPA; CISA; CISSP | CRISC | | **S3** | CISSP or CISA | CMMC RPA (if not held); CCA (once available); CRISC | CGEIT | | **S4** | CISSP | CISA and CRISC; CCA | - | #### SOX ITGC Lead | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | SOX/ITGC-specific training | CISA | | **S2** | CISA (or in progress) | CISSP; CRISC | CIA | | **S3** | CISA | CISSP; CRISC | CGEIT | | **S4** | CISA and CISSP | CRISC or CGEIT | - | #### Policy & Standards Manager | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | ISO 27001 Lead Implementer or Auditor | CISA | | **S2** | ISO 27001 Lead Implementer or Auditor | CISSP; CISA | CRISC | | **S3** | CISSP or CISA | CRISC; CGEIT | Advanced GRC certification | | **S4** | CISSP | CISA and CRISC; or CGEIT | - | #### Risk Register Owner | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | FAIR or equivalent risk analysis training | CRISC | | **S2** | FAIR certification or equivalent | CISSP; CRISC | CISA | | **S3** | CISSP or CRISC | CISA | CGEIT | | **S4** | CISSP | CRISC and CISA; or CGEIT | - | #### Evidence Librarian | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **S1** | CompTIA Security+ | GRC platform certification | CISA | | **S2** | One GRC or audit-related certification | CISA (or in progress) | CISSP | | **S3** | CISA | CISSP; evidence management or e-discovery certification | CRISC | | **S4** | CISA | CISSP or CRISC | - | ### 3.5 Management Track Certification Addendum CERG managers add the following to their home role family's certification matrix: | Grade | Required | Recommended | Aspirational | |---|---|---|---| | **M1 Manager** | CISSP or CISM (if not already held) | Leadership or management training (instructor-led, not self-paced) | PMP or equivalent program management certification | | **M2 Senior Manager** | CISM or CISSP | PMP or equivalent; advanced management training | CGEIT, CRISC | | **M3 Principal Manager** | CISM | CGEIT or CRISC | Executive education program | | **M4 Director** | CISM or equivalent executive cybersecurity certification | Executive education; board governance training | Industry recognition in lieu of further certifications | > **Certification Is a Floor, Not a Ceiling** > > A person who holds every Aspirational certification for their role and grade is not required to stop pursuing credentials. The tiers represent what the organization commits to supporting. Beyond the Aspirational tier, the individual and their manager make the case for organizational support based on relevance to the person's development plan and the organization's needs. --- ## 4. Training Curriculum by Competency Domain ### 4.1 How the Curriculum Works The training curriculum is organized by CMP-001 competency domain. For each domain, specific training resources, courses, and experiences are recommended at three levels aligned to CERG grades: - **Foundational** (S1-S2): Builds the base of competence - **Intermediate** (S2-S3): Deepens capability and adds breadth - **Advanced** (S3-S4): Develops organizational-level expertise A person's development plan (PERF-001) identifies which domains and which level are the priority for the current review period. The curriculum provides the resources. The manager and the individual select the specific courses and experiences. ### 4.2 Technical Depth | Level | Resources | |---|---| | **Foundational** | Vendor-specific certification tracks (AWS, Azure, GCP security; Splunk, Sentinel, Chronicle; ServiceNow GRC; Tenable, Qualys, CrowdStrike, etc.); platform-specific security courses; internal pairing with senior practitioners | | **Intermediate** | SANS GIAC technical courses (GCIA, GCDA, GCLD, GPCS, GWEB, GMOB, GPEN, GCIH, GREM, GNFA, GCFE, GCIP, GRID, GCTI, GICSP); OSCP/OSEP; CSSLP; advanced vendor certifications | | **Advanced** | SANS GIAC expert-level (GSE, GXPN); advanced cloud architecture (AWS Solutions Architect Professional, Azure Solutions Architect Expert); OSEE; research and publication; teaching internal courses | ### 4.3 Cross-Pillar Fluency | Level | Resources | |---|---| | **Foundational** | CERG 101 curriculum (ONB-001); cross-pillar rotation program; reading the standards and procedures of the other two pillars | | **Intermediate** | Cross-pillar working group participation; paired work on cross-pillar initiatives; CISSP (broad coverage across domains); reading NIST CSF and NIST 800-53 for the frameworks outside the person's primary pillar | | **Advanced** | Cross-pillar initiative leadership; representing CERG in multi-function forums; contributing to standards outside the person's primary pillar; mentoring across pillars | ### 4.4 Risk Judgment | Level | Resources | |---|---| | **Foundational** | FAIR training; CERG Risk Taxonomy (TAX-001); CERG Risk Management Framework (RMF-001); internal pairing on risk assessment | | **Intermediate** | CRISC; quantitative risk analysis training; sector-specific threat assessment training; internal risk assessment authorship with senior review | | **Advanced** | Advanced quantitative risk methods; scenario-based risk exercises (tabletop facilitation); contributing to organizational risk appetite calibration; external risk methodology contributions | ### 4.5 Communication | Level | Resources | |---|---| | **Foundational** | Technical writing courses; presentation skills training; internal presentation practice (pillar meetings) | | **Intermediate** | Executive communication training; audit and regulator communication simulation; written analysis with senior review; representing the pillar in cross-functional meetings | | **Advanced** | Media and public speaking training; conference presentation; board-level communication preparation; mentoring junior team members on communication | ### 4.6 Operational Discipline | Level | Resources | |---|---| | **Foundational** | CERG procedure training (role-specific); internal tool training; evidence management training (AUD-001); pairing with senior team members on operational workflows | | **Intermediate** | ITIL Foundation; process improvement methodology; procedure authorship; operational metric design | | **Advanced** | Process design and optimization; Lean/Six Sigma (if applicable); operational framework design; pillar-level operational improvement initiatives | ### 4.7 Compliance and Regulatory Literacy | Level | Resources | |---|---| | **Foundational** | Framework-specific training (NERC-CIP, CMMC, SOX, ISO 27001); CERG compliance documentation; shadowing audit walkthroughs | | **Intermediate** | CISA; lead auditor training (ISO 27001, or framework-specific); regulatory change monitoring; control mapping methodology | | **Advanced** | CGEIT; regulatory engagement (direct interaction with regulators/assessors); contributing to regulatory development; organizational regulatory strategy | ### 4.8 Continuous Learning | Level | Resources | |---|---| | **Foundational** | Organizational learning platform access; cybersecurity news and threat feeds; internal brown-bag sessions; foundational certifications | | **Intermediate** | Conference attendance (as participant); ISAC/industry group membership; advanced certifications; internal training delivery | | **Advanced** | Conference presentations; industry working group participation; research and publication; mentoring the team's learning culture | --- ## 5. Cross-Training: The 5% Rule ### 5.1 The Standard Every CERG team member is expected to spend at least 5% of their working time on cross-pillar learning and engagement. For a full-time team member, this is approximately: - **2 hours per week**, or - **One day per month**, or - **Two weeks per year** This is a performance expectation, not a suggestion. A person who has not engaged with the other two pillars in a quarter should be asked why during their quarterly check-in. ### 5.2 What Counts Acceptable cross-training activities include: - Cross-pillar rotation days beyond the onboarding program (ONB-001 §9) - Participating in cross-pillar working groups or projects - Attending standing meetings of another pillar (as an observer-contributor) - Shadowing a senior practitioner in another pillar for a specific activity - Reading and providing feedback on a draft standard or procedure from another pillar - Jointly investigating a cross-pillar incident or finding - Teaching a brown-bag session on a topic relevant to another pillar - Self-directed study of another pillar's tools, frameworks, or methods ### 5.3 Tracking The OM-001 §10.4 cross-training log captures cross-training activities. Managers review the log during quarterly check-ins. The log does not need to be granular (it is not a timesheet). It needs to answer: in the last quarter, what did this person do to understand the other two pillars better? > **The 5% Rule Is a Minimum, Not a Cap** > > An Advisor who spends 10% of their time on cross-pillar work because they are leading a cross-pillar initiative is not violating the rule; they are demonstrating advanced Cross-Pillar Fluency. The 5% floor is for team members who are not naturally pulled into cross-pillar work through their role. It ensures that cross-pillar understanding does not become a privilege of seniority. --- ## 6. Professional Development Budget ### 6.1 Per-Person Allocation CERG organizations should budget an annual per-person professional development allocation. The recommended baseline, adjusted for organizational size and budget, is: | Allocation Level | Amount (USD, Annual) | Appropriate For | |---|---|---| | **Minimum** | $3,000 | Early-stage organization, constrained budget. Covers certification exam fees, one online course or local conference, and basic training platform access. | | **Target** | $5,000-$8,000 | Established program. Covers certification training and exam, one major conference or SANS course, and ongoing training platform access. | | **Competitive** | $10,000+ | Mature program competing for top-tier talent. Covers SANS training + GIAC certification, major industry conference attendance, executive education, and external coaching for managers. | ### 6.2 What the Budget Covers The professional development budget covers: | Expense | Covered? | Notes | |---|---|---| | Certification exam fees | Yes | First attempt only; retakes require manager approval and a study plan | | Certification preparation courses or materials | Yes | Up to reasonable cost; self-study materials are preferred over boot camps unless the certification requires hands-on lab access | | Conference registration | Yes | With conference attendance criteria (§7) | | Conference travel and accommodation | Yes | Per organizational travel policy | | Training platform subscriptions | Yes | Organization-wide licenses where cost-effective | | Academic tuition (degree programs) | Partial or case-by-case | Tuition reimbursement per organizational policy; must be relevant to the person's role or progression | | Professional association memberships | Yes | ISACA, ISC2, ISSA, SANS, ISAC memberships | | Books and self-study materials | Yes | Reasonable cost; manager approval for items over a defined threshold | ### 6.3 Budget Administration - The budget is per person, not per team. A manager cannot reallocate a departing team member's unspent budget to a conference trip for themselves. - Unspent budget does not roll over. The annual cycle encourages regular development activity, not end-of-year spending sprees. - Budget requests beyond the annual allocation require a business case: what will the person learn, how does it connect to their development plan, and what is the expected organizational benefit? --- ## 7. Conference and External Engagement ### 7.1 Conference Attendance Criteria The organization supports conference attendance when: 1. The conference content is directly relevant to the person's role or development priorities. 2. The person commits to presenting what they learned to the team within two weeks of returning (a 30-minute brown-bag session, a written summary, or an internal training module). 3. Conference attendance is distributed fairly across the team. The same person attending three conferences while a peer attends none is a signal that the team's development investment is not equitable. ### 7.2 Priority Conferences by Role Family | Role Family | Priority Conferences | |---|---| | **Engineering** | AWS re:Inforce, Microsoft Ignite (security track), Google Cloud Next (security track), KubeCon (security track), fwd:cloudsec, SANS Security East/West | | **Risk** | RSA Conference, Black Hat, DEF CON, SANS Threat Hunting & IR Summit, FIRST Conference, sector-specific ISAC summits | | **Governance** | RSA Conference (GRC track), ISACA conferences, IIA conferences, NIST workshops, sector-specific regulatory conferences | | **Cross-Cutting** | Local BSides events, OWASP Global AppSec, regional cybersecurity summits | ### 7.3 External Engagement Expectations At the Advisor (S3) level and above, external engagement is an expectation, not a perk: | Grade | External Engagement Expectation | |---|---| | **S1-S2** | Encouraged to attend local events and webinars. Conference attendance supported when aligned to development priorities. | | **S3** | Expected to attend at least one major conference per year. Encouraged to submit a presentation proposal. Participating in an industry working group or ISAC. | | **S4** | Expected to present at conferences, participate in industry working groups or standards bodies, and contribute to the broader cybersecurity community. External engagement is part of the Sr. Advisor's influence dimension (CMP-001 §4.6). | > **External Engagement Is Recruitment** > > A Sr. Advisor who presents at RSA, contributes to a NIST working group, and is known in their sector's threat-sharing community is not just developing themselves. They are making the organization visible as a place where serious cybersecurity practitioners work. A candidate who researches the organization and finds its engineers presenting at conferences is more likely to apply than one who finds no public presence at all. External engagement is part of the employer brand strategy. --- ## 8. Training Administration ### 8.1 Individual Development Plan Each team member maintains an Individual Development Plan (IDP) as part of their performance record (PERF-001 §9). The IDP is updated semi-annually and contains: - 2-3 development priorities for the current review period, each mapped to a CMP-001 competency domain - Specific training activities, certifications, or experiences planned to address each priority - Timeline and estimated cost - Status tracking (planned, in progress, completed) ### 8.2 Team Training Calendar Each pillar leader maintains a team training calendar that: - Tracks certification expirations and renewal deadlines - Schedules internal knowledge-sharing sessions (brown-bag presentations, tool training, cross-pillar briefings) - Coordinates conference attendance to avoid staffing gaps - Identifies team-wide training needs (e.g., a new regulatory framework everyone needs to understand) ### 8.3 Training Record The organization maintains a training record for each team member as part of their HR file. The record documents: - Certifications held, with issue and expiration dates - Formal training courses completed - Conference attendance - Internal training delivered (the person teaching counts as development activity) The record supports regulatory compliance (NERC-CIP CIP-004 requires documented training for personnel with access to BES Cyber Systems; CMMC requires documented role-based training) and provides the evidence base for promotion cases that reference certification achievements. --- ## 9. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-TRN-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to certification requirements or competency model | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST NICE SP 800-181r1; NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.2; DoD 8140.03 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Defines three-tier certification matrix (Required, Recommended, Aspirational) for canonical CERG roles across all grades plus management track addendum. Provides training curriculum organized by CMP-001 competency domain at Foundational/Intermediate/Advanced levels. Establishes 5% cross-training standard, per-person professional development budget guidelines ($3K-$10K+), conference attendance criteria, and training administration framework. | ### Review Triggers - Material change to certification requirements by certifying bodies (ISC2, ISACA, SANS, CompTIA) - Material change to the competency model (CMP-001) - New roles added to the canonical roster (OM-001 §6.1) - Regulatory changes affecting personnel training requirements (NERC-CIP CIP-004, CMMC, etc.) - Feedback from performance reviews indicating training curriculum gaps - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Competency Model | [`CERG-GOV-CMP-001`](CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Competency domains the curriculum targets | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions and progression | | Job Descriptions | [`CERG-GOV-JD-001`](CERG-GOV-JD-001_CERG_Job_Descriptions.md) | Certification references and KSA requirements | | Performance Management | [`CERG-GOV-PERF-001`](CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Development plans and budget connection | | Onboarding Program | [`CERG-GOV-ONB-001`](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | Initial training during onboarding | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Left-right knowledge model | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## WORKFORCE PLANNING AND CAPACITY MODEL ### Staffing Methodology · Workload Drivers · Scaling Guidance --- | | | |---|---| | **Document ID** | CERG-GOV-WFP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) · [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) · [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | | **Review Cycle** | Annual / Before each budget cycle | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.7.1 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The Capacity Problem](#2-the-capacity-problem) 3. [Workload Drivers by Pillar](#3-workload-drivers-by-pillar) 4. [The Staffing Methodology](#4-the-staffing-methodology) 5. [Engineering Pillar: Capacity Model](#5-engineering-pillar-capacity-model) 6. [Risk Pillar: Capacity Model](#6-risk-pillar-capacity-model) 7. [Governance Pillar: Capacity Model](#7-governance-pillar-capacity-model) 8. [The Scaling Map: From 5 to 60+](#8-the-scaling-map-from-5-to-60) 9. [Validating the Model](#9-validating-the-model) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope A CISO walks into a budget meeting and says "I need three more Cloud Security Engineers." The CFO asks "why three, and why Cloud Security Engineers specifically?" The CISO who cannot answer that question with a methodology will get zero, or one, or a contractor for six months with no renewal path. The CISO who produces a capacity model built on workload drivers, not headcount comparisons, will get a conversation about which assumptions the CFO disagrees with. A conversation about assumptions is a negotiation. A conversation without assumptions is a request. This document provides the methodology. It defines the workload drivers for each pillar, translates them into staffing formulas, and provides the scaling guidance that supports a headcount request from a 5-person startup CERG to a 60-person enterprise function. It is designed to be a live tool: organizations plug in their numbers and get a recommended staffing range with documented rationale. It applies to every CERG role. It does not prescribe exact headcount; it prescribes the method for arriving at a defensible headcount. The output is a range, not a single number, because judgment about organizational context, team composition, and automation maturity always matters. > **Headcount Without Methodology Is a Wish** > > Every CISO has a wishlist. The capacity model turns wishes into requests and requests into negotiations. It will not eliminate the budget conversation. It will make the conversation about the model's assumptions, not about whether the CISO is credible. That is a better conversation to have. --- ## 2. The Capacity Problem ### 2.1 Why Cybersecurity Staffing Is Hard to Model Most corporate functions have stable workload-to-headcount ratios. Accounts payable: X invoices per clerk per month. IT support: Y tickets per technician per day. Cybersecurity does not work this way for three reasons: 1. **Workload is adversary-driven, not business-driven.** A new ransomware variant can multiply the detection engineering workload overnight. A zero-day in a widely deployed platform can turn every Cloud Security Engineer's week into emergency response. 2. **Work is invisible when done well.** A Cloud Security Engineer who prevents a misconfigured S3 bucket from reaching production has done some of the highest-value work in the organization. The work produced no ticket, no finding, and no metric other than the absence of a breach. Capacity models that measure only tickets undercount security engineering by design. 3. **Regulatory scope changes the workload non-linearly.** Adding NERC-CIP to an organization's compliance scope does not add one FTE of Governance work. It adds a compliance manager, an evidence librarian, OT engineering support, and a new audit cycle. Frameworks multiply; they do not add. ### 2.2 The Capacity Model's Answer This model addresses the capacity problem by defining workload drivers that are: - **Observable.** An organization can count its projects, assets, vendors, and frameworks. - **Predictive.** The relationship between the driver and the staffing need is grounded in how CERG roles actually spend their time. - **Ranged.** Every formula produces a range (minimum, target, maximum), not a point estimate. The range accounts for organizational context, automation maturity, and team experience. - **Calibratable.** Organizations that track actual time allocation can refine the model's coefficients. An organization that discovers its Cloud Security Engineers spend 40% of their time on architecture review rather than the model's assumed 30% can adjust the formula for its next cycle. --- ## 3. Workload Drivers by Pillar ### 3.1 Engineering Pillar Drivers | Driver | Definition | Why It Matters | |---|---|---| | **Active projects** | Number of concurrently active projects receiving Engineering engagement (architecture review through go-live) | Each project consumes recurring Engineering time for architecture review, pre-production check, and go-live support | | **Project complexity mix** | Distribution of projects across Low, Medium, and High complexity tiers | A High-complexity project (new cloud region, major platform migration, M&A integration) consumes 3-5x the Engineering hours of a Low-complexity project (SaaS onboarding, minor feature deployment) | | **Platform count** | Number of distinct platforms requiring reference architecture and security engineering (e.g., AWS, Azure, GCP, on-prem virtualization, OT environments) | Each platform requires a reference architecture, configuration baselines, and ongoing security engineering. Platforms multiply workload, not just add to it | | **Pre-production review volume** | Number of pre-production reviews per week | A hard gate that requires Engineering attendance; cannot be automated away entirely | | **Vertical coverage** | Number of business verticals or operating companies requiring dedicated engineering alignment | A Cloud Security Engineer assigned to a specific business unit develops context that a pooled engineer cannot. Vertical alignment improves quality but reduces fungibility | ### 3.2 Risk Pillar Drivers | Driver | Definition | Why It Matters | |---|---|---| | **Assets under management** | Number of IP-addressable assets (servers, endpoints, network devices, cloud resources, OT devices) in the exposure management and CSPM scope | Scanning, triage, and remediation tracking effort scales with asset count, though not linearly (automation absorbs some growth) | | **Vendor portfolio size** | Number of vendors in the third-party risk assessment program, weighted by tier (Critical, High, Medium, Low) | Critical-tier vendors require annual reassessment with deeper due diligence; Low-tier vendors may be assessed once and monitored | | **Scan frequency** | Vulnerability scan cadence (continuous, daily, weekly) and scope (internal, external, cloud, OT) | Continuous scanning produces more findings to triage; weekly scanning produces manageable volumes with acceptable risk windows | | **Testing cycle requirements** | Number of penetration tests, red team exercises, and purple team engagements per year, plus any regulatory-mandated testing | A NERC-CIP entity has mandated testing cycles. A commercial entity may have an annual pen test. The difference is 4-6x in Adversarial Testing Lead workload | | **Threat intelligence production** | Number of threat advisories, briefings, and intelligence products produced per week or month | A team producing daily threat briefs for leadership needs more analyst capacity than one producing weekly summaries | | **Detection surface** | Number of log sources, detection rules, and use cases under active management | Each new log source requires parsing, baseline profiling, and detection rule authoring. Detection engineering workload grows with the detection surface, not with headcount | ### 3.3 Governance Pillar Drivers | Driver | Definition | Why It Matters | |---|---|---| | **Regulatory frameworks** | Number of distinct regulatory or compliance frameworks in scope (e.g., NERC-CIP, CMMC, SOX, ISO 27001, PCI) | Each framework adds its own evidence requirements, audit cycle, and regulatory change monitoring. Frameworks with overlapping controls reduce the multiplier but do not eliminate it | | **Control count** | Number of controls in the unified control baseline that require evidence collection and testing | Each control has an evidence refresh cycle. More controls = more evidence librarian and compliance manager hours | | **Audit frequency** | Number of external audits, assessments, and regulatory exams per year | Each audit consumes 4-8 weeks of Governance pillar time for preparation, walkthroughs, evidence delivery, and finding response | | **Evidence volume** | Number of evidence items maintained in the evidence library, refreshed on defined cycles | Evidence that is stale at audit time must be recollected under pressure, consuming 2-3x the effort of evidence maintained on schedule | | **Policy and standard count** | Number of policies, standards, and procedures requiring annual review, update, and stakeholder coordination | Each document has a review cycle, a stakeholder list, and an approval workflow. Document count drives Policy & Standards Manager workload directly | --- ## 4. The Staffing Methodology ### 4.1 The Base Formula For each role, the recommended staffing range is calculated as: ``` Headcount = ⌈(Driver1 / Throughput1) + (Driver2 / Throughput2) + ...⌉ × Complexity Factor × Automation Discount ``` Where: - **Driver** is the workload driver value for the organization (e.g., 45 active projects) - **Throughput** is the number of driver units one FTE can handle at target quality (e.g., 8-12 active projects per Cloud Security Engineer) - **Complexity Factor** adjusts for organizational complexity beyond the baseline (1.0 = baseline; 1.3 = highly complex; 0.8 = low complexity) - **Automation Discount** reduces headcount for mature automation (1.0 = no automation; 0.85 = moderate automation; 0.70 = high automation) The ceiling brackets ⌈...⌉ indicate rounding up to the nearest whole person. A calculation that produces 2.3 FTEs means 3 people; the 0.7 surplus is absorbed by management overhead, surge capacity, and the reality that cybersecurity work does not divide evenly. ### 4.2 The Role Consolidation Rule The scaling map in CERG-GOV-RAC-001 §8 shows how 27 canonical roles consolidate onto as few as 5 people. This model respects that consolidation. When the formula produces less than 1.0 FTE for a role, the role is consolidated onto an adjacent role rather than fractionalized: - If the model says 0.4 Detection Engineers and 0.6 Threat Intelligence Analysts, both roles consolidate onto one person who splits their time, or the Detection Engineering work is absorbed by the Exposure Management Lead - Pillar Leader roles consolidate downward: in a 5-person CERG, the CISO directly manages all pillars, and the senior-most practitioner in each pillar operates as a player-coach at S3-S4 The model reports both the unconsolidated headcount (what the formula says) and the consolidated headcount (how roles combine for organizations below a certain scale). ### 4.3 The Management Overhead Factor Every IC headcount carries a management overhead. The overhead is not linear (a 3-person team does not need 0.3 Managers; it needs zero) but emerges at certain thresholds: | IC Headcount in Function | Management Overhead | |---|---| | 1-5 | 0 (consolidated onto pillar leader or CISO) | | 6-10 | 1 Manager (M1) | | 11-20 | 1 Senior Manager (M2) + 1 Manager (M1), or 2 Managers | | 21-40 | 1 Principal Manager (M3) + 1-2 Senior Managers (M2) + 1-2 Managers (M1) | | 40+ | 1 Director (M4) + management hierarchy as above | --- ## 5. Engineering Pillar: Capacity Model ### 5.1 Cloud Security Engineer **Primary driver:** Active projects requiring cloud security engagement. | Complexity Tier | Projects per Engineer (Baseline) | Description | |---|---|---| | **Low** | 12-15 | SaaS tool security review, minor IAM policy change, CSPM alert tuning | | **Medium** | 6-8 | New AWS account onboarding with landing zone, cloud network segmentation change, significant IaC module development | | **High** | 2-3 | New cloud region deployment, multi-cloud architecture design, major platform migration, M&A cloud integration | **Formula:** ``` CE = ⌈(Low_Projects / 14) + (Med_Projects / 7) + (High_Projects / 2.5)⌉ × CF × AD ``` **Additional drivers:** - +0.5 CE for every distinct major cloud platform beyond the first (AWS + Azure = 0.5 additional) - +0.5 CE if the organization operates SaaS security posture management separately from IaaS security - +1.0 CE if the organization has a dedicated cloud security engineering function for OT/ICS environments ### 5.2 Identity Engineer **Primary driver:** Identity platform complexity and integration surface. | Scope | Engineers Required | Trigger | |---|---|---| | **Single IdP, cloud-native, no federation** | 0.5-1.0 | Organization uses one identity provider (e.g., Azure AD/Entra ID), minimal external federation, no PAM program | | **Multi-IdP, federation, basic PAM** | 1.0-2.0 | Multiple identity providers, B2B federation, a PAM solution for privileged access | | **Complex identity: multi-cloud, legacy, PAM, customer IAM** | 2.0-4.0 | Identity spans on-prem AD, cloud IdP, customer-facing CIAM, legacy application authentication, PAM with session management | **Formula:** ``` IE = Base(Org_Size_Tier) + Federation_Count × 0.3 + PAM_Program × 0.5 + CIAM_Program × 0.5 ``` Where Base(Org_Size_Tier) is: Small = 0.5, Medium = 1.0, Large = 1.5, Enterprise = 2.0. ### 5.3 OT Security Engineer **Primary driver:** OT environment count and complexity. | Scope | Engineers Required | |---|---| | **No OT environment** | 0 | | **Single OT site, limited CIP scope** | 1.0 | | **Multiple OT sites, NERC-CIP Medium impact** | 1.5-2.5 | | **Multiple OT sites, NERC-CIP High impact, IT/OT convergence** | 2.5-4.0 | OT Security Engineers are rarely filled below S2. The minimum staffing for any organization with an OT environment is 1.0 FTE; below that, the role consolidates onto a Cloud Security Engineer with OT training (and the risk of that consolidation should be explicitly acknowledged). ### 5.4 Application Security Engineer **Primary driver:** Development team count and deployment frequency. | Scope | Engineers Required | |---|---| | **1-3 development teams, quarterly releases** | 0.5-1.0 | | **4-10 development teams, monthly releases** | 1.0-2.0 | | **11-25 development teams, bi-weekly or continuous deployment** | 2.0-4.0 | | **Enterprise software organization with multiple product lines** | 4.0-8.0 | **Formula:** ``` AppSec = ⌈Dev_Teams / 8⌉ + (CI_CD_Maturity × 0.5) ``` Where CI_CD_Maturity = 0 (quarterly/manual), 1 (monthly), 2 (continuous). ### 5.5 Endpoint Engineer **Primary driver:** Endpoint count and platform diversity. | Scope | Engineers Required | |---|---| | **<2,000 endpoints, single OS** | 0.5 | | **2,000-10,000 endpoints, 2 OS platforms** | 1.0 | | **10,000-50,000 endpoints, 3+ OS platforms, mobile** | 1.5-2.5 | | **50,000+ endpoints, multi-OS, VDI, mobile, OT endpoint overlap** | 2.5-4.0 | ### 5.6 Cryptography Engineer **Primary driver:** PKI scale and regulatory crypto requirements. | Scope | Engineers Required | |---|---| | **Basic TLS, no on-prem PKI, no regulatory crypto mandate** | 0.5 (consolidate with Cloud Security or Identity Engineer) | | **On-prem PKI, internal CA, TLS certificate lifecycle management** | 1.0 | | **Enterprise PKI, HSM management, FIPS compliance, code signing** | 1.5-2.5 | | **Multi-tier CA, cross-certification, regulatory crypto (CIP, CMMC)** | 2.5-4.0 | --- ## 6. Risk Pillar: Capacity Model ### 6.1 Exposure Management Lead / Analyst **Primary driver:** Assets under management and scan frequency. | Scope | Staff Required | |---|---| | **<5,000 assets, weekly scanning** | 1.0 | | **5,000-25,000 assets, continuous scanning** | 1.5-3.0 | | **25,000-100,000 assets, continuous scanning, multi-platform** | 3.0-6.0 | | **100,000+ assets, continuous scanning, OT segmentation** | 6.0-12.0 | **Formula:** ``` VM = ⌈(Assets / 8000) × Scan_Freq_Factor⌉ + OT_Assets × 0.3 ``` Where Scan_Freq_Factor = 0.8 (weekly), 1.0 (daily), 1.3 (continuous). OT_Assets is in thousands. ### 6.2 Adversarial Testing Lead **Primary driver:** Testing cycles and scope breadth. | Scope | Staff Required | |---|---| | **Annual external pen test (outsourced)** | 0.0 (the outsourced test is managed by the Risk Pillar Leader or Exposure Management Lead) | | **Annual pen test (internal or co-sourced) + one purple team exercise** | 1.0 | | **Semi-annual pen test + quarterly purple team + annual red team** | 2.0-3.0 | | **Continuous testing program + red team operations + purple team + regulatory-mandated cycles** | 3.0-6.0 | ### 6.3 Threat Intelligence Analyst **Primary driver:** Intelligence production volume and source diversity. | Scope | Staff Required | |---|---| | **Consuming third-party threat feeds, no production** | 0.5 (consolidate with Detection Engineer or Exposure Management Lead) | | **Weekly threat briefings, 2-3 intelligence sources, basic actor tracking** | 1.0 | | **Daily threat briefings, 5+ intelligence sources, sector-specific ISAC participation** | 1.5-2.5 | | **Full threat intelligence program: strategic/operational/tactical, dedicated platforms, external collaboration** | 2.5-5.0 | ### 6.4 Vendor Risk Analyst **Primary driver:** Vendor portfolio size weighted by tier. | Scope | Staff Required | |---|---| | **<50 vendors, mostly Low/Medium tier** | 0.5 (consolidate with Governance or Risk role) | | **50-200 vendors, mixed tiers, annual reassessment cycle** | 1.0-2.0 | | **200-500 vendors, significant Critical-tier population, continuous monitoring** | 2.0-4.0 | | **500+ vendors, regulatory supply chain requirements (CMMC, CIP-013), dedicated TPRM platform** | 4.0-8.0 | **Formula:** ``` VRA = ⌈(Critical_Vendors / 30) + (High_Vendors / 60) + (Medium_Vendors / 100) + (Low_Vendors / 200)⌉ ``` ### 6.5 Detection Engineer **Primary driver:** Detection surface (log sources and use cases). | Scope | Staff Required | |---|---| | **<10 log sources, SIEM managed by external SOC or MSSP** | 0.5 (consolidate with Exposure Management Lead or Threat Intel Analyst) | | **10-50 log sources, in-house SIEM, basic use case library** | 1.0-2.0 | | **50-200 log sources, detection-as-code, ATT&CK coverage mapping** | 2.0-5.0 | | **200+ log sources, multi-SIEM, detection engineering pipeline, 90%+ ATT&CK technique coverage target** | 5.0-10.0 | ### 6.6 OT Risk Analyst and Identity Risk Analyst These roles are additive to the Risk pillar based on specific organizational scope: - **OT Risk Analyst:** +1.0 for any organization with an OT environment; +0.5 per additional OT site beyond the first; +1.0 if NERC-CIP regulated - **Identity Risk Analyst:** +1.0 if the organization operates UEBA or identity threat detection; +0.5 if the organization has a dedicated identity security program; consolidates onto Detection Engineer or Threat Intelligence Analyst if below 1.0 --- ## 7. Governance Pillar: Capacity Model ### 7.1 NERC-CIP / CMMC / SOX Compliance Managers Each major regulatory framework that requires a dedicated compliance program generates its own staffing demand. The base staffing per framework is: | Framework | Base Staff | Notes | |---|---|---| | **NERC-CIP (Medium impact)** | 1.0-1.5 | CIP-002 through CIP-014; annual self-certification; triennial audit | | **NERC-CIP (High impact)** | 1.5-3.0 | Broader scope; more evidence; more frequent regulatory engagement | | **CMMC L2 (CUI)** | 1.0-2.0 | SSP and POA&M maintenance; pre-assessment and assessment cycles; supplier flow-down | | **SOX ITGC** | 0.5-1.5 | Quarterly evidence cycles; external audit coordination; control rationalization | | **ISO 27001** | 0.5-1.0 | Annual certification cycle; continuous improvement; internal audit program | | **PCI DSS** | 0.5-1.0 | Annual ROC/SAQ; quarterly ASV scans; evidence maintenance | Frameworks with overlapping controls reduce the combined staffing need. Use the higher of two overlapping frameworks plus 30% of the lower, not the sum: ``` Combined_Staff = max(Framework_A, Framework_B) + 0.3 × min(Framework_A, Framework_B) ``` ### 7.2 Evidence Librarian **Primary driver:** Evidence volume and refresh frequency. | Scope | Staff Required | |---|---| | **<100 evidence items, annual refresh, single framework** | 0.5 (consolidate onto a compliance manager) | | **100-500 evidence items, quarterly refresh, 2-3 frameworks** | 1.0 | | **500-1,500 evidence items, continuous refresh, 3-5 frameworks** | 1.0-2.0 | | **1,500+ evidence items, continuous refresh, 5+ frameworks, automated evidence collection** | 2.0-3.0 | ### 7.3 Policy & Standards Manager **Primary driver:** Document count and review cycle complexity. | Scope | Staff Required | |---|---| | **<20 documents, annual review, single author/approver chain** | 0.5 (consolidate onto Governance Pillar Leader) | | **20-50 documents, semi-annual review, cross-pillar stakeholder coordination** | 1.0 | | **50-100 documents, continuous review cycle, multi-stakeholder, public-facing documentation** | 1.0-2.0 | | **100+ documents, multiple frameworks, version-controlled library with rendering/export tooling** | 2.0-3.0 | ### 7.4 Risk Register Owner **Primary driver:** Risk register size and exception volume. | Scope | Staff Required | |---|---| | **<50 active risks, <5 exceptions, monthly review** | 0.5 (consolidate onto Governance Pillar Leader or compliance manager) | | **50-200 active risks, monthly review, quarterly exception renewal cycle** | 1.0 | | **200-500 active risks, continuous review, exception lifecycle management, board reporting** | 1.0-1.5 | | **500+ active risks, risk committee support, multiple risk registers (IT, OT, vendor, project)** | 1.5-2.0 | --- ## 8. The Scaling Map: From 5 to 60+ ### 8.1 Illustrative Staffing at Different Scales The table below applies the capacity model to four illustrative organization profiles. These are examples, not prescriptions. Every organization's numbers will differ. | Role | 5-Person CERG (Small Utility) | 15-Person CERG (Mid-Size) | 35-Person CERG (Large Enterprise) | 60-Person CERG (Major Utility) | |---|---|---|---|---| | **CISO** | 1 | 1 | 1 | 1 | | **Engineering Pillar Leader** | 0* | 1 (M4) | 1 (M4) | 1 (M4) | | Cloud Security Engineer | 0.5* | 1.5 | 3 | 5 | | Identity Engineer | 0* | 1 | 2 | 3 | | OT Security Engineer | 1* | 1.5 | 2 | 4 | | Application Security Engineer | 0* | 0.5 | 1.5 | 3 | | Endpoint Engineer | 0* | 0.5 | 1 | 2 | | Cryptography Engineer | 0* | 0 | 1 | 1.5 | | **Risk Pillar Leader** | 0* | 1 (M4) | 1 (M4) | 1 (M4) | | Exposure Management Lead | 0.5* | 1 | 2 | 3 | | Adversarial Testing Lead | 0* | 0.5 | 1 | 2 | | Threat Intelligence Analyst | 0* | 0.5 | 1 | 2 | | Vendor Risk Analyst | 0* | 0.5 | 1.5 | 3 | | OT Risk Analyst | 0* | 0.5 | 1 | 2 | | Identity Risk Analyst | 0* | 0 | 0.5 | 1 | | Detection Engineer | 0.5* | 1 | 2 | 3 | | **Governance Pillar Leader** | 0* | 1 (M4) | 1 (M4) | 1 (M4) | | NERC-CIP Compliance Manager | 0.5* | 1 | 1.5 | 2 | | CMMC/Federal Compliance Mgr | 0.5* | 0.5 | 1 | 1.5 | | SOX ITGC Lead | 0* | 0.5 | 1 | 1 | | Policy & Standards Manager | 0* | 0.5 | 1 | 1.5 | | Risk Register Owner | 0* | 0.5 | 1 | 1 | | Evidence Librarian | 0* | 0.5 | 1 | 1.5 | | **Total (Unconsolidated)** | ~5 | ~15 | ~27 | ~44 | | **Management Overhead** | 0 | 0.5 | 3 | 5 | | **Consolidated Total** | **5** | **15** | **30** | **49** | *In a 5-person organization, these roles are consolidated per the RACI scaling map (RAC-001 §8). The CISO manages all pillars directly. The senior-most practitioner in each pillar operates at S3-S4 level with expanded scope covering adjacent roles. ### 8.2 When to Split a Role A role that reaches 2.5+ FTE in the model should be evaluated for a split: | Trigger | Action | |---|---| | **2.5 FTE** | Consider whether the role has developed sub-specializations. A Cloud Security Engineer at 2.5 may indicate the need for distinct AWS and Azure engineers, or a Cloud Security Engineer plus a SaaS Security Engineer | | **3.5 FTE** | Split the role. Create a management layer (Manager or Senior Manager) to lead the sub-team | | **5.0+ FTE** | The role is a function. It needs a dedicated manager, defined career paths for the sub-specializations, and its own workforce planning cycle | --- ## 9. Validating the Model ### 9.1 The First-Year Reality Check The capacity model produces a theoretical headcount. The first year of tracking actual time allocation validates or refutes the model's assumptions. Organizations should: 1. **Track time allocation** for at least one quarter. Use broad categories: project work, operational work, unplanned/incident work, administrative overhead. Do not ask for timesheets in 15-minute increments; ask for a weekly estimate by category. 2. **Compare actual to modeled.** If Cloud Security Engineers are spending 50% of their time on unplanned work, the model's project-throughput assumptions are wrong for this organization. Adjust the model or fix the source of unplanned work. 3. **Refine the coefficients.** The throughput numbers in this model are baseline estimates. An organization that discovers its Engineers can handle 10 medium-complexity projects (not the model's 7) should update its formula. The model improves with use. 4. **Recalibrate before each budget cycle.** An organization that is growing, adding platforms, adding regulatory frameworks, or maturing its automation should run the model fresh each year. ### 9.2 Automation Maturity Adjustment Organizations with mature security automation should apply the Automation Discount (AD) factor from §4.1. Signs of automation maturity include: | Indicator | Discount Signal | |---|---| | Policy-as-code for cloud security (OPA, Terraform Sentinel, AWS SCPs) | Cloud Security Engineer throughput improves 15-25% | | Detection-as-code pipeline with automated testing and deployment | Detection Engineer throughput improves 20-30% | | Automated evidence collection from security tools to evidence library | Evidence Librarian throughput improves 30-50% | | Exposure-management tooling to ticketing system bi-directional integration with auto-triage rules | Exposure Management Lead throughput improves 15-25% | | Automated vendor risk scoring from security rating services | Vendor Risk Analyst throughput improves 20-30% | ### 9.3 The Experience Adjustment A team of predominantly S3-S4 practitioners handles more throughput per person than a team of S1-S2 practitioners. An organization with a senior-heavy team may increase throughput coefficients by 15-25%. An organization with a junior-heavy team (common during rapid growth) should decrease throughput coefficients by 15-25% and budget for the mentoring overhead that junior practitioners require. > **The Model Is Honest About Its Limits** > > This model will not tell you that you need exactly 2.3 Cloud Security Engineers. It will tell you that based on your project count, complexity mix, and automation maturity, your range is 2-3. The decision between 2 and 3 depends on factors no model captures: your risk appetite, your team's current burnout level, your ability to hire, and whether you have a major platform migration coming in Q3 that is not yet on the project register. The model provides the range and the rationale. The CISO provides the judgment. --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-WFP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-27 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and before each budget cycle | | **Next Scheduled Review** | 2027-05-27 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.7.1 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-27 | Cyber Governance | Initial release. Defines workload-driver-based staffing methodology for all CERG roles. Provides capacity models for Engineering (6 roles), Risk (6 roles), and Governance (6 roles) pillars with formulas, throughput coefficients, and scope-based staffing ranges. Includes scaling map from 5 to 60+ personnel with role consolidation rules and management overhead factors. Provides model validation guidance and automation maturity adjustments. | ### Review Triggers - Before each annual budget cycle (re-run the model with current data) - Material change to organizational scope: new platforms, new regulatory frameworks, major initiative launches - Material change to automation maturity - Feedback from time allocation tracking indicating model coefficients need adjustment - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) | Pillar structure and canonical role roster | | RACI Instrument | [`CERG-GOV-RAC-001`](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Role consolidation scaling map | | Job Architecture | [`CERG-GOV-JA-001`](CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade-level experience adjustments | | CERG Framework | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | Illustrative 60-person staffing model | | Maturity Assessment | [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Automation maturity context | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- | | | |---|---| | **Document ID** | CERG-GOV-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed evidence | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Evidence Quality Rules](#2-evidence-quality-rules) 3. [Bad Evidence — What Not to Accept](#3-bad-evidence--what-not-to-accept) 4. [Design vs. Operating Effectiveness](#4-design-vs-operating-effectiveness) 5. [Sampling Methodology](#5-sampling-methodology) 6. [Evidence Freshness Rules](#6-evidence-freshness-rules) 7. [Business-Owner Accountability](#7-business-owner-accountability) 8. [Evidence by Control Type](#8-evidence-by-control-type) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope This document defines what qualifies as acceptable evidence in the CERG operating model. It extends the evidence quality tiers (E1/E2/E3) defined in [FLOW-001 §17](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) with specific quality rules, sampling methodology, and freshness requirements. This standard applies to every CERG artifact that produces or references evidence: the Unified Control Baseline (CB-001), the Audit and Evidence Management Procedure (PRC-AUD-001), the Risk Register and Exception Process (PRC-RM-001), and all standards and procedures that define evidence requirements. `CERG-GOV-AUD-001` is authoritative for evidence quality, freshness, and sampling expectations. `CERG-PRC-AUD-001` governs how evidence is collected, stored, tested, and produced during audit response. Where the procedure needs to determine whether evidence is acceptable, this standard governs. > **Evidence proves the control works.** A document that says a control exists is not evidence that it operates. An email that says "done" is not evidence. A screenshot with no date is not evidence. This standard defines what is. --- ## 2. Evidence Quality Rules Every piece of evidence accepted into the CERG evidence library must answer these questions. If the answer to any required question is "no" or "unknown," the evidence is insufficient for its claimed tier. ### Required for All Evidence (E1 minimum) | Question | Required | Meaning | |----------|----------|---------| | **Who produced it?** | Yes | A named person, system, or automated process. "The security team" is insufficient. | | **When was it produced?** | Yes | A specific date or timestamp. "Last quarter" is insufficient. | | **What system/control does it apply to?** | Yes | A specific control ID (from CB-001), asset, or requirement. "Access management" is insufficient. | | **What period does it cover?** | Yes | A specific time window. "Current" is insufficient — current as of when? | | **Where is it stored?** | Yes | A file path, URL, or repository location. Must be retrievable by someone other than the person who produced it. | ### Required for E2 (Control Operates) | Question | Required | Meaning | |----------|----------|---------| | **Is it complete?** | Yes | The evidence covers the full scope claimed. A sample must be identifiable as a sample — see §5. | | **Is it tamper-resistant?** | Preferred | Can the evidence be altered after collection? If yes, compensating controls (hash, read-only storage, audit log) must be documented. | | **Does it show a sample or full population?** | Yes | Must be explicit. "We reviewed all 250 accounts" or "We sampled 25 of 250 accounts (see sampling methodology §5)." | ### Required for E3 (Control Is Effective) | Question | Required | Meaning | |----------|----------|---------| | **Is it repeatable?** | Yes | Could someone else produce equivalent evidence using the same method? If the method is "I looked at it," the evidence is not repeatable. | | **Does it prove design, operation, or both?** | Yes | Must be explicit. A configuration export proves design. A test result proves operation. Both may be needed. | | **Is the evidence independent of the person asserting the control?** | Required for E3 | The person producing the evidence should not be the person whose work is being evidenced. Self-attestation is E2 at best. Independence means: a different person, an automated system, or an external assessor. | | **Does it include failure conditions?** | Yes | What would the evidence look like if the control had failed? A test that always passes is not a test. | ### Evidence Tier Decision Table | If... | Then the evidence is at most... | |-------|-------------------------------| | Produced by the same person who operates the control | E2 | | No timestamp or date | E1 — insufficient for E2+ | | Cannot be retrieved independently | E1 — insufficient for E2+ | | Scope is undefined ("some accounts were reviewed") | E1 — insufficient for E2+ | | Method is not documented ("I checked it") | E2 — insufficient for E3 | | No failure condition defined | E2 — insufficient for E3 | | Automated, timestamped, independently retrievable, scope-defined, with failure conditions | E3 | --- ## 3. Bad Evidence — What Not to Accept The following are common evidence submissions that should be rejected. Each represents a pattern, not an exhaustive list. ### Screenshot with No Date **What it looks like:** A screenshot of a configuration page. No visible timestamp. No URL. No indication of when it was captured or by whom. **Why it fails:** Screenshots are tamperable, non-repeatable, and usually undated. A screenshot proves someone looked at a screen at some point. It does not prove the configuration was in that state during the audit period. **What to request instead:** A configuration export with timestamp and origin metadata. A scripted configuration audit with output. An automated CSPM/CNAPP posture report. ### Email Saying "Done" **What it looks like:** An email thread where someone asks "is the access review done?" and someone replies "yes, done." **Why it fails:** An email is an assertion, not evidence. It does not show what was reviewed, what was found, what was remediated, or who performed the work. It does not prove the control operated — it proves someone sent an email. **What to request instead:** The access review output: population list, sample methodology (if sampled), findings, remediations, reviewer sign-off with date. ### Vendor Says Yes **What it looks like:** A vendor responds to a security questionnaire with "yes" to every question. No supporting evidence. **Why it fails:** Self-attestation without evidence is not evidence. A vendor that checks "MFA enforced" without providing the IdP policy configuration has not evidenced the control. **What to request instead:** Vendor-provided evidence: SOC 2 report, ISO 27001 certificate, penetration test summary, configuration exports, or architecture documentation. If the vendor cannot provide evidence, the control status is "Inherited — Unverified" with documented residual risk. ### Meeting Notes with No Action Owner **What it looks like:** Meeting minutes stating "the team discussed the risk and agreed to monitor it." **Why it fails:** Discussion is not treatment. "Monitor" without a method, frequency, owner, and trigger is not a treatment strategy. Meeting notes do not create accountability. **What to request instead:** A risk register entry with named owner, treatment strategy, due date, and next review date. The decision log entry documenting what was decided and by whom. ### Policy Text with No Proof of Operation **What it looks like:** A policy document excerpt that says "access reviews shall be performed quarterly." No evidence that one was performed. **Why it fails:** A policy describes intent. Evidence proves execution. The gap between "we have a policy that says we do this" and "we did this" is where controls fail. **What to request instead:** The output of the access review. Evidence that it was performed, not evidence that it was required. ### Tool Export with No Scope Definition **What it looks like:** A vulnerability scan report with 10,000 findings. No indication of which assets were scanned, which were excluded, or why. **Why it fails:** Without scope definition, you cannot determine whether the scan covered the assets it needed to cover. A scan of 80% of assets with 10,000 findings may be worse than a scan of 100% of assets with 12,000 findings — but you cannot tell from the report alone. **What to request instead:** Scan configuration showing target scope, exclusions with rationale, and scan date. The report should include "X of Y assets scanned; Z excluded with documented rationale." ### Sample with No Population **What it looks like:** "We reviewed 25 accounts. They were all correct." **Why it fails:** Without knowing the population size (25 out of how many?) and the sampling method (random? judgmental? convenience?), you cannot assess whether the sample is representative. 25 out of 25 is complete. 25 out of 2,500 with no methodology is not auditable. **What to request instead:** Population definition (total accounts), sample size, sampling method, and rationale. See §5 Sampling Methodology. --- ## 4. Design vs. Operating Effectiveness Every control has two dimensions. Evidence must address the right one. ### Design Effectiveness **Question:** If the control were performed as designed, would it achieve its objective? **Evidence needed:** - Control description (what is supposed to happen) - Configuration or design documentation (how it is implemented) - Comparison to the control objective (does the design match the intent?) **Example:** An access review control requires quarterly review of all privileged accounts. The design evidence is the access review procedure document and the IdP configuration showing privileged role definitions. This proves the control is *designed* to identify and review privileged access. **Design is NOT sufficient to prove the control operates.** ### Operating Effectiveness **Question:** Was the control actually performed consistently during the period under review? **Evidence needed:** - Output of the control's operation (the actual review results) - Evidence of cadence (was it done when it was supposed to be done?) - Evidence of completeness (was the full scope covered?) - Evidence of follow-through (were findings remediated?) **Example:** The quarterly access review output: population list of 47 privileged accounts, sample of 15 reviewed, 2 accounts flagged for excessive access, both remediated and re-validated. Review performed 2026-06-15, next review due 2026-09-15. This proves the control *operated*. ### Testing Both For Tier 1 controls (Critical systems, regulated environments), test both: 1. **Design test:** Review the control documentation. Walk through the control with the control owner. Confirm the design addresses the control objective. 2. **Operating test:** Select a sample from the audit period. Examine evidence for each item in the sample. Confirm the control was performed as designed, at the required cadence, with appropriate follow-through. ### Status Implications | Design | Operating | Control Status | |--------|-----------|----------------| | Designed | Operating with evidence | **Implemented** | | Designed | Operating, evidence incomplete | **Partially Implemented** — evidence gap documented | | Designed | Not operating consistently | **Partially Implemented** — operating gap documented | | Designed | Not yet operating | **Planned** — implementation in progress | | Not designed | N/A | **Planned** or **Not Implemented** | --- ## 5. Sampling Methodology This section is the canonical CERG sampling standard for evidence review and control testing. When testing a control across a population, sampling is acceptable if the methodology is documented and defensible. Regulatory, assessor, or auditor-specific sampling requirements override these CERG defaults for that engagement and must be documented in the test plan. ### When Sampling Is Acceptable - The population is large enough that full-population testing is impractical - The control produces consistent results (not highly variable) - The sampling method is documented before testing begins - The sample is representative of the population ### When Full-Population Testing Is Required - The population is small (<30 items) — test all of them - The control is Tier 0/Tier 1 (Crown Jewel / Critical systems) - The control has previously failed - A regulatory requirement mandates full-population testing - The evidence is for an E3 claim and the control is high-variability ### Sample Size Guidelines | Population Size | CERG Baseline Minimum Sample | For High-Risk Controls | |----------------|------------------------------|----------------------| | <30 | Full population | Full population | | 30-100 | 25 | 30 | | 101-500 | 50 | 80 | | 501-1,000 | 80 | 120 | | 1,001-5,000 | 100 | 200 | | >5,000 | 150 | 300 | These are baseline defaults, not statistical guarantees. Adjust based on control risk, prior test results, regulatory requirements, assessor direction, and whether the evidence supports an E2 or E3 claim. Document the rationale for any deviation. ### Sampling Method | Method | When to Use | Documentation Required | |--------|------------|----------------------| | **Random** | Preferred. Every item has equal selection probability. | Random seed or selection method. List of selected items. | | **Judgmental** | When specific high-risk items must be included. Supplement with random sampling of remaining population. | Rationale for judgmental selection. List of items and why each was selected. | | **Stratified** | When the population has distinct subgroups with different risk profiles. | Stratification criteria. Sample size per stratum. | | **Convenience** | Not acceptable for audit evidence. | Not applicable; convenience sampling is prohibited. | ### Documentation Required for Every Sample 1. Population definition (what is the full set of items?) 2. Population size (how many items total?) 3. Sampling method (random, judgmental, stratified) 4. Sample size (how many were tested?) 5. Selection rationale (why this method and size?) 6. List of selected items 7. Test results per item 8. Exception handling (what if a selected item cannot be tested?) 9. Extrapolation (do sample results apply to the full population?) 10. Tester name and date --- ## 6. Evidence Freshness Rules Evidence ages. An access review from 2024 does not prove the control operated in 2026. Every piece of evidence has a shelf life. ### Freshness by Evidence Type | Evidence Type | Freshness Window | Refresh Trigger | Stale After | |--------------|-----------------|-----------------|-------------| | Access review output | Current review cycle + 30 days | Next scheduled review | Review date + 90 days | | Joiners/movers/leavers (JML) log | Current month | Monthly | 60 days | | Exposure scan report | Current scan cycle | Next scheduled scan | Scan date + 30 days (IT) / 90 days (OT with approval) | | MFA/enforcement configuration | Current quarter | Configuration change | 90 days or on change | | Firewall rule review | Current quarter | Next scheduled review | 120 days | | Backup restore test | Current test cycle | Next scheduled test | Test date + 180 days | | Vendor SOC 2 report | Report period + 90 days | New report issued | Report expiration | | Vendor ISO 27001 certificate | Certificate validity period | Renewal | Certificate expiration | | Penetration test report | Current test cycle | Next scheduled test | Test date + 365 days | | Policy/procedure approval | Current approved version | Document change | Version superseded | | Incident lessons learned | Incident closure + 30 days | Corrective action completion | Action due date + 90 days | | Risk acceptance | Acceptance date to expiration | Expiration or review date | Expiration date | | Exception approval | Approval date to expiration | Expiration or review date | Expiration date | | Training completion record | Current training cycle | Next training cycle | Training date + 365 days | ### Stale Evidence Evidence that exceeds its freshness window is **stale**. Stale evidence: - Cannot be used to support E3 claims - Can be used for E2 claims only if a documented rationale explains why the evidence is still representative - Creates a Finding Record if the control relies on it and no fresh evidence is available - Must be flagged in the evidence index with "Stale" quality status ### Freshness Monitoring The Evidence Librarian checks evidence freshness at the monthly review. The evidence index spreadsheet (§7 of the Small Team Adoption Path) or the GRC platform tracks freshness dates. Stale evidence is flagged in the monthly metrics report. ### 6.1 Evidence Retrieval SLA (Adoption-Gate Tiered) Evidence must be retrievable within the following SLA, tiered by adoption gate. The applicable gate is defined in the organization's Adoption Gates document ([`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) where published; otherwise default to Gate 1). | Gate | Timeframe | Retrievable Within | Method | Evidence Index Required | |------|-----------|-------------------|--------|------------------------| | Gate 1 (Spine) | 0–90 days | 15 business days | Manual collection from control owners; shared drive or email attachment acceptable | No — file naming convention suffices | | Gate 2 (Operating) | 90–180 days | 10 business days | Structured evidence index (spreadsheet or lightweight GRC tool) | Yes — spreadsheet with control-id, path, date, owner | | Gate 3 (Governed) | 180+ days | 5 business days | Tool-supported retrieval (GRC platform, evidence repository with search) | Yes — tool-native index | | Gate 4 (Adaptive) | Mature program | 2 business days | Automated evidence pipeline (API-driven collection, on-demand retrieval) | Yes — automated index updated continuously | > **SLA Clock Start.** The retrieval SLA clock starts when the evidence request is formally received by the Evidence Librarian or the owning pillar leader, not when the request is initiated. The requesting party is notified within 1 business day that the SLA clock has started. A process finding is opened if evidence is not retrievable within the applicable gate SLA, regardless of whether the underlying control is operating. The finding owner is the Evidence Librarian or the pillar leader responsible for the control evidence. --- ## 7. Business-Owner Accountability Evidence proves a control operated. The business owner proves the risk is owned. These are different things and both must be present for risk acceptance. ### Every Risk Acceptance Must Include | Field | Required | Meaning | |-------|----------|---------| | **Business Owner Name** | Yes | A specific person outside the security team. Not a role. Not a department. A named individual. | | **Business Owner Acknowledgement** | Yes | Evidence that the business owner understands and accepts the risk. An email is acceptable. An unsigned form is not. | | **Business Impact Statement** | Yes | What happens to the business if the risk materializes? Revenue impact, operational impact, customer impact, regulatory impact. Written by the business owner, not by security. | | **Risk Scenario in Business Terms** | Yes | The risk statement translated from security terminology into business terminology. "Unpatched systems" → "Potential for service outage affecting customer ordering for up to 48 hours." | | **Acceptance Rationale** | Yes | Why is accepting this risk better than treating it? Cost, operational impact, timing, vendor limitation? Must be specific. | | **Review Commitment** | Yes | The business owner commits to reviewing this risk on the specified cadence. | ### Red Flags — Return the Acceptance Reject a risk acceptance if: - The business owner field says "Security," "CISO," or is blank - The business impact statement was written by the security team - The acceptance rationale is "we have always done it this way" - The review commitment is missing or vague ("we'll review it sometime") - The business owner cannot be reached to confirm their acknowledgement ### Template Enforcement Every risk acceptance template, exception request form, and risk register entry must include business-owner fields that cannot be bypassed. The Risk Register Owner is responsible for rejecting incomplete submissions. --- ## 8. Evidence by Control Type Different controls produce different evidence. This section maps control types to their expected evidence forms. | Control Type | Expected Evidence (E2 minimum) | E3 Evidence | |-------------|-------------------------------|-------------| | **Access Review** | Review output showing population, sample/full scope, findings, remediations, reviewer, date | Independent re-performance of a sample by a different reviewer | | **JML (Joiners/Movers/Leavers)** | JML log export from HRIS/IdP showing all changes in period | Sample validation: verify 5 leavers' accounts were actually disabled | | **MFA Enforcement** | IdP policy export showing MFA requirement, exclusions list, date | Authenticated login attempt without MFA — must be rejected | | **Vulnerability Scanning** | Scan report with scope, exclusions, findings, date | Authenticated re-scan confirming critical/high findings resolved | | **Patch Management** | Patch compliance report, deployment records | Verify a sample of critical patches were applied within SLA | | **Firewall Rule Review** | Rule set export, review date, reviewer, findings | Automated rule analysis comparing current rules to approved baseline | | **Backup Restore Test** | Test plan, test results, RTO/RPO achieved, system owner sign-off, date | Independent observation of a restore test | | **Change Management** | Change record, security impact analysis, approval, implementation evidence, post-change validation | Verify a sample of changes: did control continuity check pass? | | **Vendor Risk Assessment** | Completed assessment questionnaire, evidence reviewed, risk rating, review date | Independent review of a sample of vendor-provided evidence | | **Incident Response** | Incident record, timeline, containment actions, lessons learned, corrective actions | Post-incident tabletop or simulation validating corrective actions | | **Security Awareness Training** | Training completion report, population coverage, date | Phishing simulation results showing behavior change | | **Logging/Monitoring** | Log source inventory, coverage report, detection rule inventory | Simulated attack: did the detection rule fire? | --- ## 9. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST CSF 2.0 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed evidence | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Evidence quality rules, bad evidence examples, design vs. operating effectiveness, sampling methodology, freshness rules, business-owner accountability, and evidence-by-control-type mapping. | ### Review Triggers - Change to evidence requirements in CB-001 - Feedback from audit or assessment findings - Change to regulatory evidence retention requirements - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Cross-Pillar Operational Flows | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Evidence quality tiers (E1/E2/E3) | | Unified Control Baseline | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control definitions and evidence requirements | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Operational evidence collection and audit response | | Control Effectiveness Framework | [`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) | Control testing methodology | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk acceptance evidence requirements | --- ## CALIBRATION CHECKLIST ### Consolidated Preliminary Default Register --- | | | |---|---| | **Document ID** | CERG-GOV-CAL-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the risk appetite calibration | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.6.1 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Using This Checklist](#2-using-this-checklist) 3. [Risk Appetite and Impact Calibration (RMF-001)](#3-risk-appetite-and-impact-calibration-rmf-001) 4. [Service Level Commitment Calibration (SLC-001)](#4-service-level-commitment-calibration-slc-001) 5. [Metric Threshold Calibration (MTR-001)](#5-metric-threshold-calibration-mtr-001) 6. [Crown Jewel Scenario Calibration (CJ-001)](#6-crown-jewel-scenario-calibration-cj-001) 7. [Risk Acceptance Duration Calibration (RMF-001)](#7-risk-acceptance-duration-calibration-rmf-001) 8. [Calibration Governance](#8-calibration-governance) 9. [Document Control](#9-document-control) --- ## 1. Purpose and Scope The CERG framework embeds **preliminary defaults requiring organizational calibration** across multiple documents. These defaults are educated starting points for a mid-market organization; they are not approved values until calibrated against the organization's specific risk profile, staffing, and financial context. A program that operates on uncalibrated defaults makes decisions against thresholds that do not reflect its actual exposure. This document consolidates **every preliminary default** in the CERG corpus into a single register. It identifies each parameter, its default value, the calibration inputs required, the calibration method, the owning role, and the review cadence. It is the authoritative reference for the organization's calibration status. Adopting teams use this checklist during adoption (IMP-001 §5) and maintain it as the calibration maturity tracker. > **Calibration Is Not Optional** > > Risk acceptance decisions made against uncalibrated values are opinions, not risk management. SLA commitments made against uncalibrated values are promises the organization may not be able to keep. Every preliminary default in this register must have either a calibrated value or a documented plan for calibration, with a target date, before the CISO signs the adoption gate. --- ## 2. Using This Checklist ### 2.1 Register Structure Each calibration item records: | Field | Description | |-------|-------------| | **Parameter** | The value that requires calibration | | **Document** | Source document containing the default | | **Section** | Section reference in the source document | | **Default Value** | The uncalibrated starting value | | **Calibration Inputs** | Organizational data required to determine the calibrated value | | **Calibration Method** | How inputs are combined to produce the calibrated value | | **Owning Role** | Canonical role responsible for calibration | | **Review Cadence** | How often the calibrated value is reviewed | | **Organization Value** | (To be filled) The organization's calibrated value | | **Last Calibrated** | (To be filled) Date of last calibration | | **Next Review** | (To be filled) Date of next scheduled review | ### 2.2 Calibration Priority - **Gate 2 (Operating)** — Risk appetite bands and impact thresholds must be calibrated before operating risk acceptance. - **Gate 3 (Governed)** — SLA commitments and metric thresholds must be calibrated before publishing SLAs. - **Gate 4 (Adaptive)** — All remaining defaults should be calibrated, including scenario-specific figures. ### 2.3 Verification At each adoption gate review, the Governance Pillar Leader (Policy & Standards) presents the calibration register with current status for each item. Items that remain uncalibrated must be accompanied by a documented plan and target date. --- ## 3. Risk Appetite and Impact Calibration (RMF-001) ### 3.1 Loss Magnitude (Impact) Bands | Field | Value | |-------|-------| | **Parameter** | Loss Magnitude bands (Catastrophic / Major / Medium / Minor / Negligible) | | **Document** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.5 | | **Section** | §9.5 — Impact (LM) bands | | **Default Value** | Catastrophic >$10M · Major $1M–$10M · Medium $100K–$1M · Minor $10K–$100K · Negligible <$10K | | **Calibration Inputs** | Annual revenue; critical service downtime cost (per hour); regulatory fine exposure (per incident); cyber insurance retention; cyber insurance coverage limit; board reporting materiality threshold | | **Calibration Method** | Ratio of revenue × risk factor. Small org ($100M rev) at ~5% revenue; mid-market ($500M–$2B) at midpoint; large ($5B+) at ~2%. Calibration workbook in RMF-001 §9.8.1 provides structured prompts. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) coordinates with Finance (CFO office) | | **Review Cadence** | Annual; on material change to revenue, insurance, or regulatory exposure | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 3.2 Annualized Loss Exposure (ALE) Tolerance Bands | Field | Value | |-------|-------| | **Parameter** | Total open ALE (Critical + High) — OK / Caution / Escalate | | **Document** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.8 | | **Section** | §9.8 — Quantitative tolerance (preliminary calibration) | | **Default Value** | OK <$5M · Caution $5M–$15M · Escalate >$15M | | **Calibration Inputs** | Same as §3.1 above | | **Calibration Method** | Revenue-gated scaling per workbook in §9.8.1. Small (<$100M rev): OK <$500K, Caution $500K–$2M, Escalate >$2M. Mid: <$5M / $5M–$15M / >$15M. Large: <$25M / $25M–$100M / >$100M. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) coordinates with Finance | | **Review Cadence** | Annual; on revenue change or material risk change | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 3.3 Single-Risk ALE Mandatory CISO Review Threshold | Field | Value | |-------|-------| | **Parameter** | Single-risk ALE requiring mandatory CISO review | | **Document** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.8 | | **Section** | §9.8 table — Single-risk ALE | | **Default Value** | >$2M | | **Calibration Inputs** | Revenue; insurance retention; maximum single-incident loss tolerance | | **Calibration Method** | Revenue-proportional: Small >$250K · Mid >$2M · Large >$10M | | **Owning Role** | Governance Pillar Leader (Policy & Standards) | | **Review Cadence** | Annual | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | --- ## 4. Service Level Commitment Calibration (SLC-001) ### 4.1 Architecture Review Turnaround | Field | Value | |-------|-------| | **Parameter** | Architecture review turnaround time | | **Document** | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) §3.1 | | **Section** | §3.1 — Project Engagement — Architecture review disposition | | **Default Value** | Tier 1 (high-impact/regulated/OT/AI): 10 business days · Tier 2 (standard): 7 business days · Tier 3 (minimal): 5 business days | | **Calibration Inputs** | Staffing levels; intake volume; average review complexity; regulatory deadlines | | **Calibration Method** | Measure actual turnaround over 2 complete quarters; set targets at P80 of actual performance; tighten as staffing grows. Adoption-phase SLA targets in SLC-001 §3.5 provide graduated defaults (15/10/5 business days for Gates 1/2/3). | | **Owning Role** | Engineering Pillar Leader (coordinates with Risk and Governance) | | **Review Cadence** | Annual; on material staffing change | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 4.2 Continuous Service Coverage SLA | Field | Value | |-------|-------| | **Parameter** | New asset vulnerability/CSPM coverage establishment | | **Document** | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) §3.2 | | **Section** | §3.2 — Continuous Service | | **Default Value** | Coverage established within 5 business days of go-live notification | | **Calibration Inputs** | Tooling maturity; onboarding automation; staffing; asset churn rate | | **Calibration Method** | Measure actual coverage establishment time over 2 quarters; set internal target based on tooling capability. | | **Owning Role** | Risk Pillar Leader | | **Review Cadence** | Annual; on tooling change | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 4.3 Advisory Response Time | Field | Value | |-------|-------| | **Parameter** | Advisory or office-hours question response time | | **Document** | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) §3.3 | | **Section** | §3.3 — Advisory | | **Default Value** | Substantive written response within 3 business days | | **Calibration Inputs** | Staffing; advisory volume; question complexity distribution | | **Calibration Method** | Measure P80 response time over 2 quarters; set target accordingly. | | **Owning Role** | Owning Pillar Leader per question | | **Review Cadence** | Annual | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 4.4 New SaaS/Cloud Service Review | Field | Value | |-------|-------| | **Parameter** | New SaaS/cloud service review decision time | | **Document** | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) §3.3 | | **Section** | §3.3 — Advisory — New SaaS/cloud service review | | **Default Value** | Restricted-data placement: 10 business days · Non-Restricted: 5 business days | | **Calibration Inputs** | Staffing; review volume; vendor response time | | **Calibration Method** | Measure P80 over 2 quarters; calibrate by data classification. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) | | **Review Cadence** | Annual | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 4.5 Exception/Risk-Acceptance Request Intake | Field | Value | |-------|-------| | **Parameter** | Exception/risk-acceptance request acknowledgement and routing | | **Document** | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) §3.4 | | **Section** | §3.4 — Program Oversight | | **Default Value** | Acknowledge and route within 3 business days | | **Calibration Inputs** | Request volume; staffing; automation of routing | | **Calibration Method** | Measure P80 acknowledgement time over 2 quarters. | | **Owning Role** | Risk Register Owner | | **Review Cadence** | Annual | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | --- ## 5. Metric Threshold Calibration (MTR-001) ### 5.1 Service Responsiveness Metric Thresholds | Field | Value | |-------|-------| | **Parameter** | Green/Amber/Red thresholds for SR-001 through SR-005 | | **Document** | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §3.9 | | **Section** | §3.9 — Service Responsiveness Metrics | | **Default Value** | Preliminary defaults per SLC-001 commitment values until organizationally calibrated | | **Calibration Inputs** | Actual performance data over 2+ quarters; staffing levels; demand patterns | | **Calibration Method** | Measure actual performance distribution; set green threshold at or above P80 of actual performance; amber as buffer zone. Review adoption-phase targets from SLC-001 §3.5 as starting point. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) | | **Review Cadence** | Annual; or when metric is red-stalled for 3+ consecutive months | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | ### 5.2 Other Metric Thresholds All discipline metrics (EM-001 through EM-010, RM-001 through RM-008, GV-001 through GV-006) carry preliminary green/amber/red thresholds defined in MTR-001 §3. These thresholds follow the same calibration rules (MTR-001 §10): tighten on green drift, escalate on red stall, adjust on risk appetite change. The initial preliminary values remain in effect until either triggered by the calibration rules or reviewed at the annual metrics program review. | Field | Value | |-------|-------| | **Parameter** | All discipline metric thresholds | | **Document** | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §3.1–§3.9 | | **Section** | §3 — Discipline Metrics | | **Default Value** | Per-metric thresholds defined in MTR-001 §3 tables | | **Calibration Inputs** | Actual performance data; risk appetite changes; maturity improvements; peer benchmarks | | **Calibration Method** | MTR-001 §10 triggers: Green drift (tighten), Red stall (escalate/recalibrate), Risk appetite change (proportional adjustment), Maturity improvement (review for tightening), External benchmark (peer comparison). One change per domain per quarter. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) | | **Review Cadence** | Continuous (trigger-based); annual comprehensive review | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | --- ## 6. Crown Jewel Scenario Calibration (CJ-001) ### 6.1 Scenario Financial Impact Figures | Field | Value | |-------|-------| | **Parameter** | Scenario-specific financial or impact figures in crown jewel loss scenarios | | **Document** | [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md) §4.1 | | **Section** | §4.1 — Scenario Record Components | | **Default Value** | Preliminary defaults per scenario; not approved loss values until Finance and CISO sign | | **Calibration Inputs** | Business impact analysis data; revenue exposure per scenario; regulatory fines; operational downtime cost | | **Calibration Method** | For each scenario (SCN-01 through SCN-10+), the owning role works with the business unit owner to estimate: direct financial loss, regulatory exposure, operational downtime cost, and reputational impact. Record calibrated values in the scenario record. | | **Owning Role** | Risk Pillar Leader (scenario library owner) coordinates with impacted business unit owners | | **Review Cadence** | Semi-annual; on material change to crown jewel population or business operations | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | --- ## 7. Risk Acceptance Duration Calibration (RMF-001) ### 7.1 Default Risk Acceptance Durations | Field | Value | |-------|-------| | **Parameter** | Maximum duration for each risk acceptance tier | | **Document** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 | | **Section** | §9.7 — Risk Acceptance Authority — Default Max Duration column | | **Default Value** | Critical: 30 days · High: 90 days · Medium: 180 days · Low: 365 days | | **Calibration Inputs** | Regulatory deadlines; audit cycle; typical remediation timelines; business constraints | | **Calibration Method** | Compare against environment-specific rules, regulatory packages, POA&M, CIP deviations, contracts, and procedures. The shortest applicable duration wins per §9.7 Duration Rule. | | **Owning Role** | Governance Pillar Leader (Policy & Standards) | | **Review Cadence** | Annual; when a regulatory package or procedure sets a conflicting duration | | **Organization Value** | | | **Last Calibrated** | | | **Next Review** | | --- ## 8. Calibration Governance ### 8.1 Calibration Status Register The Governance Pillar Leader (Policy & Standards) maintains the calibration status of each item in this document. The register records, for each item: - **Status:** Uncalibrated / In Progress / Calibrated / Reviewed — No Change Needed - **Calibrated Value:** The organization-approved value - **Date:** When calibration was completed or last reviewed - **Next Review:** Scheduled review date based on cadence - **Approver:** CISO or designee (per RMF-001 §9.7 delegation rules) ### 8.2 Calibration Cadence | Activity | Frequency | Owner | |----------|-----------|-------| | Risk appetite and impact band calibration | Annual (aligned to budget cycle) | Governance Pillar Leader + Finance | | SLA commitment calibration | Annual | Governance Pillar Leader | | Metric threshold review | Continuous (trigger-based); annual comprehensive | Governance Pillar Leader | | Crown jewel scenario calibration | Semi-annual | Risk Pillar Leader | | Risk acceptance duration review | Annual | Governance Pillar Leader | | Full calibration register status report to CISO | Quarterly (concurrent with CISO Risk & Posture Review) | Governance Pillar Leader | ### 8.3 Calibration Documentation Every calibration decision is documented in the organization's Decision Log (IMP-002 §4) with: - Parameter being calibrated - Previous value (default or last calibrated) - New calibrated value - Rationale and data sources - Approver name and date - Next review date ### 8.4 Integration with Other CERG Instruments - **Adoption gates (IMP-005):** Calibration status is a Gate 2→3 transition criterion. At least risk appetite and impact bands must be calibrated before exiting Gate 2. - **Risk acceptance (RMF-001):** Risk acceptance decisions made against uncalibrated values use qualitative judgment until calibration occurs. Document this in the risk acceptance record. - **Metrics (MTR-001):** Metric thresholds that reference SLC-001 commitment values remain as preliminary defaults until SLC-001 is calibrated. - **Improvement register (IMPREG-001):** Calibration actions are recorded as improvement register entries of type "Metric or threshold change" when they improve program precision. --- ## 9. Document Control | Field | Value | |-------|-------| | **Document ID** | CERG-GOV-CAL-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-18 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on any change to the risk appetite calibration | | **Next Scheduled Review** | 2027-06-18 | | **Frameworks** | NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.6.1 | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-06-18 | Cyber Governance | Initial release. Consolidates all preliminary defaults from RMF-001, SLC-001, MTR-001, and CJ-001 into a single calibration register. Provides calibration inputs, methods, owning roles, and review cadence for each parameter. | ### Review Triggers - Material change to organizational revenue or risk appetite - Change to cyber insurance coverage or retention - Regulatory change affecting impact thresholds - Metric that is red-stalled for 3+ consecutive months (indicates unrealistic threshold) - Feedback from adoption gate reviews indicating calibration gaps - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Risk Management Framework | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | Source of risk appetite and impact band defaults | | Service Level Commitments | [`CERG-GOV-SLC-001`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) | Source of SLA commitment defaults | | Metrics Dashboard and Reporting | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Source of metric threshold defaults and calibration rules | | Crown Jewel Register | [`CERG-GOV-CJ-001`](CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md) | Source of scenario financial impact defaults | | Adoption Safety Guide | [`CERG-GOV-IMP-002`](CERG-GOV-IMP-002_Adoption_Safety_Guide.md) | Decision Log for calibration records | | Program Improvement Register | [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | Tracks calibration actions | | Document Catalog | [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. --- ## CERG GLOSSARY ### Canonical Terms, Record Types, and Conversion Rules --- | | | |---|---| | **Document ID** | CERG-GOV-GEN-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / On any new record type or major terminology change | | **Frameworks** | NIST CSF 2.0 (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [How to Use This Glossary](#2-how-to-use-this-glossary) 3. [Canonical Terms](#3-canonical-terms) 4. [Record Types and Their Terms](#4-record-types-and-their-terms) 5. [Conversion Rules](#5-conversion-rules) 6. [Role Names](#6-role-names) 7. [Document Control](#7-document-control) --- ## 1. Purpose and Scope CERG uses specific terms with specific meanings. "Finding" is not a vulnerability. "Risk" is not a finding. "Exception" is not an exception to risk acceptance. Confusing these terms produces records that do not match what auditors and adopters expect. This document is the canonical glossary for CERG. It collects the terms that appear across the corpus and gives each one a definition, an authoritative record type, and a statement of what it converts to. Where the same word appears with different meanings in different documents (for example, "control" in POL-001 vs CB-001), this document disambiguates. The glossary is the first place to look when a term is ambiguous. The Flow F-04 walkthrough (in [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md)) and the day-in-the-life stories use the terms defined here. The glossary does not redefine terms that already have a published definition in another CERG artifact. Where a term's authoritative definition lives elsewhere (for example, "Risk Appetite" lives in [CERG-GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md)), this document points to that source rather than restating the definition. ## 2. How to Use This Glossary - **A leader adopting CERG for the first time** should read §3 and §4 once before reading any other CERG document. The 30 minutes invested pays back across every subsequent read. - **A contributor** writing a new CERG artifact should check this glossary before coining a new term. If a term does not appear here and is not defined in the parent artifact, add it to §3 of this glossary before using it elsewhere. - **An auditor or assessor** reviewing CERG adoption can use this glossary as the authoritative vocabulary against which to test that records, evidence, and reports use the same term consistently. ## 3. Canonical Terms These terms appear throughout the CERG corpus with specific meanings. | Term | Definition | Source | |---|---|---| | **Adoption path** | One of three preset operating modes (CERG Lite, CERG Standard, CERG Regulated) selected by an adopter based on team size and regulatory scope. Determines which artifacts are adopted first and which are deferred. | [CERG-GOV-IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | | **Adopter** | An organization that has decided to operate its cybersecurity program using CERG, regardless of adoption path or scope. | This document | | **Adversarial Validation** | The CERG capability for authorized testing of controls under adversary-like conditions. It includes external, internal, application, cloud, OT-safe, red-team, purple-team, social-engineering, and related validation activities where those activities are in scope. Penetration testing is one engagement type within this broader capability. | [CERG-PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | | **Asset** | A system, service, application, dataset, or other component that is in scope for the security program and is inventoried in the asset register. | [CERG-STD-AM-001](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | | **Asset Owner** | The named individual accountable for an asset's risk posture, classification, and adherence to applicable controls. | [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | | **Audit** | A formal review of program adherence against an external standard (NERC-CIP, CMMC, SOX, ISO 27001) or internal control baseline. Distinct from a Finding. | [CERG-PRC-AUD-001](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | | **Business Owner** | The named individual accountable for a business process that depends on one or more assets. Signs risk acceptance memos and exception requests on the business side. | [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | | **CERG** | The cybersecurity operating model defined in this repository. Pronounced "surge." The name "CERG" is the program name; the pronunciation appears only in the README. | [README.md](../README.md) | | **Control** | A requirement that, when implemented, reduces a specific risk. In CERG, controls live in [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) (Unified Control Baseline) and are implemented via Standards and Procedures. | [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) | | **Control Change Record** | The authoritative record of work to convert a governance-originated control intent into implemented technical change. | [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-01 | | **Evidence** | A timestamped, attributable artifact that demonstrates a control was operating as required. Quality tiers defined in [CERG-GOV-AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md). | [CERG-GOV-AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | | **Exception** | An approved deviation from a control or requirement, with compensating controls, expiration, and named approver. Distinct from a Risk Acceptance. | [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **MVC (Minimum Viable CERG)** | The eight-document spine required for any CERG adoption: Policy, Framework, Operating Model, Document Catalog, Risk Management Framework, Risk Register Process, Risk Register Templates, Exposure Management Procedure. | [CERG-GOV-IMP-001](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §4 | | **Pillar** | One of three accountability lines in CERG: Cyber Engineering (builds securely), Cyber Risk (knows exposure), Cyber Governance (makes rules clear). | [CERG-GOV-FRM-002](CERG-GOV-FRM-002_Framework_System_Map.md) §3.3 | | **Risk** | A loss-event scenario with a named owner, treatment strategy, and acceptance decision. Distinct from a Finding (which is an observed condition) and from Vulnerability (which is a technical weakness). | [CERG-GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) | | **Risk Acceptance** | A documented decision by a Business Owner to operate with a known residual risk, with named approver, rationale, and review date. Distinct from an Exception (which is a deviation from a control). | [CERG-TMPL-RM-003](../templates/CERG-TMPL-RM-003_Risk_Acceptance_Memo_Template.md) | | **SLA** | Service-Level Agreement. In CERG, used in two directions: business-side SLAs (remediation clocks) and CERG-side SLAs (the commitments in [CERG-GOV-SLC-001](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md)). | [CERG-GOV-SLC-001](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md) | ## 4. Record Types and Their Terms Every material workflow in CERG resolves to one of the following primary record types. Each record type is owned by one source-of-truth system. Where multiple systems hold similar data, the source-of-truth wins. | Record Type | Definition | Owning Pillar | Source of Truth | |---|---|---|---| | **Project Intake Record** | The initial record of a project, application, or major change entering the security review pipeline. The first artifact in F-02. | Engineering | Project intake system (e.g., Jira, ServiceNow, spreadsheet) | | **Architecture Review Record** | The record produced by an architecture review: scope, design decisions, conditions, disposition. | Engineering | GRC system or document management | | **Threat Model Record** | The record of a threat modeling exercise: assets, threats, mitigations, residual risk. | Engineering (in flow) / Risk (when promoted) | GRC system | | **Asset Record** | The authoritative inventory record for a system, service, application, or dataset. Includes owner, classification, criticality, coverage status. | Engineering | CMDB or asset management system | | **Finding Record** | An observed condition requiring disposition. Discovered through scanning, testing, audit, or review. Distinct from a Vulnerability (raw input) or a Risk (loss scenario). | Risk | GRC system or exposure backlog | | **Risk Record** | A loss-event scenario with a named owner, treatment strategy, and acceptance decision. May be promoted from a Finding or created directly. | Risk | GRC system or risk register | | **Exception Record** | An approved deviation from a control or requirement, with compensating controls, expiration, and named approver. | Governance | GRC system or exception register | | **Change Record** | The authoritative record of a security-relevant change: implementation window, SIA, rollback plan, control continuity result. | Engineering | Change management system | | **Incident Record** | A declared security event requiring active response. Owned by the standing IR team; CERG is adjacent, not authoritative. | Adjunct (IR team) | IR incident tracking system | | **Evidence Record** | A timestamped, attributable artifact demonstrating control operation. Indexed in the evidence library. | Governance | Evidence repository | | **Improvement Record** | A program-level improvement item tracked in the Program Improvement Register with source attribution. | Governance | Program Improvement Register | | **Control Change Record** | The record of converting a governance-originated control intent into implemented technical change and validated outcome. | Governance | GRC system | | **Reporting Metric Record** | A single metric value for a defined period, with source, threshold, and action assignment. | Governance | BI dashboard or reporting tool | ### Conversion Rules These are the rules that govern when one record type becomes another. They appear in [CERG-GOV-FLOW-001 §2](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#2-operating-principles) and are repeated here for discoverability. - A **Vulnerability** becomes a **Finding** when triaged. It may be directly remediated without becoming a Risk. - A **Finding** promotes to a **Risk Record** when: the SLA is exceeded, the affected asset is Tier 0 or Tier 1, exploitation is active, remediation requires a business decision, or compensating controls are needed. - A **Risk** that involves a control deviation creates an **Exception Record**. - An **Exception** that expires without renewal auto-creates a **Finding** (severity: High). - A recurring **Finding** in the same control family triggers a **Control Change Record** (F-01). - A **Control Gap** (a missing or ineffective control, a systemic condition) is usually recorded as a **Risk** because of its systemic impact. - An **Incident** declaration does not replace a Finding. Lessons learned from an Incident may create Findings, Risks, or Control Change Records, but the Incident Record itself is the authoritative artifact for the event. ## 5. Conversion Rules (extended) These extended rules cover record-to-record transitions that appear less frequently but still matter. - A **Risk Acceptance** that expires without renewal auto-creates a **Finding** (severity: High). The original acceptance approver is notified. - An **Exception** that is renewed without a change in scope does not create a new Finding; the existing Exception Record is updated with a new expiration date. - A **Finding** that is closed as a False Positive does not create a Risk or an Exception. The determination method and evidence are recorded in the Finding Record's closure rationale. - A **Risk** that is closed by treatment does not automatically close the underlying Finding. Each is closed independently based on its own closure criteria. - A **Control Change Record** that is closed does not close related Findings. The Findings close when their remediation evidence is validated. ## 6. Role Names These are the canonical role names used across CERG artifacts. Roles collapse onto fewer heads in CERG Lite per [CERG-GOV-IMP-003 §4](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md#4-role-consolidation-map). The questions the role owns do not collapse. ### Executive and Pillar Leadership - **CISO (Chief Information Security Officer)** - accountable for the security program overall - **Executive Sponsor** - accountable executive outside the security team - **Engineering Pillar Leader** - accountable for the Engineering pillar - **Risk Pillar Leader** - accountable for the Risk pillar - **Governance Pillar Leader** - accountable for the Governance pillar ### Engineering Pillar Roles - **Cloud Security Engineer** - **Identity Engineer** - **OT Security Engineer** - **Application Security Engineer** - **Endpoint Engineer** - **Cryptography Engineer** - **Pre-production Reviewer** ### Risk Operations Pillar Roles - **Exposure Management Lead** - **Adversarial Testing Lead** - **Threat Intelligence Analyst** - **Detection Engineer** - **OT Risk Analyst** - **Identity Risk Analyst** - **Vendor Risk Analyst** ### Governance and Compliance Pillar Roles - **NERC-CIP Compliance Manager** - **CMMC / Federal Compliance Manager** - **SOX ITGC Lead** - **Policy & Standards Manager** - **Risk Register Owner** - **Evidence Librarian** ### Adjunct Function Roles (Incident Response) - **Incident Commander** - accountable during a declared incident - **Lead Investigator** - accountable for incident investigation ## 7. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-GEN-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-18 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Document Control) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / On any new record type or major terminology change | | **Next Scheduled Review** | 2027-06-18 | | **Frameworks** | NIST CSF 2.0 (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.0 | 2026-06-18 | Governance Pillar Leader (Document Control) | Initial publication. Extracted canonical terms from FLOW-001 §2 (Operating Principles, Record Type Definitions) and CB-001 / RMF-001 / OM-001 cross-references. Added extended conversion rules and canonical role names per roles/ directory. | ### Review Triggers - A new record type is added to [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) §4. - A new term is introduced in any CERG artifact that does not appear in this glossary. - A canonical role is added to or removed from the roles directory. - A new pillar or sub-pillar is added to [CERG-GOV-FRM-001](CERG-GOV-FRM-001_CERG_Framework.md). - A maintainer review identifies a term whose meaning has drifted from the original definition. ### Related Documents - [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) - Source of the record type definitions and conversion rules in §4 and §5. - [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) - Authoritative source for "Risk Appetite" and risk treatment vocabulary. - [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) - Authoritative source for control vocabulary. - [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) - Authoritative source for role definitions and pillar descriptions. - [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) - Three-pillar model and CERG philosophy. - [`CERG-GOV-STY-001`](CERG-GOV-STY-001_Document_Authoring_and_Style_Guide.md) - Style conventions for CERG documents. - [`roles/CERG-GOV-JF-001_Job_Families_Overview.md`](../roles/CERG-GOV-JF-001_Job_Families_Overview.md) - Job family structure and per-role descriptions. --- ## CERG SERVICE-LEVEL COMMITMENTS ### What the Business Can Expect Back From CERG · Reciprocal, Published, Measured --- | | | |---|---| | **Document ID** | CERG-GOV-SLC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Chief Information Security Officer | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) · [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md) · [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | | **Review Cycle** | Annual / On engagement-model change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Service Commitment Catalog](#3-service-commitment-catalog) - 3.6 [What a missed commitment looks like in practice](#36-what-a-missed-commitment-looks-like-in-practice) 4. [Escalation Path for Missed Commitments](#4-escalation-path-for-missed-commitments) 5. [What This Is Not](#5-what-this-is-not) 6. [Metrics and Reporting](#6-metrics-and-reporting) 7. [Roles and Responsibilities](#7-roles-and-responsibilities) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope CERG's operating premise is the yes-and default in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §2.2: the hard work is making "yes" safe, and guardrails should make the business move faster, not slower. The entire framework is built on engaging Engineering early, understanding exposure, and making the rules clear enough that work moves. There is an asymmetry in how that premise is currently operationalized. Every service-level clock in the framework runs against the business: findings have remediation SLAs, exceptions have aging limits, patch currency is tracked. CERG's own responsiveness back to the business, how fast it answers an architecture review request, dispositions an intake, or responds to an advisory question, is measured only by an annual stakeholder perception survey ([`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md)). By the time that annual survey reports friction, the business has already built its workarounds. Shadow IT and shadow AI are what a slow security function produces. This document corrects the asymmetry. It publishes CERG's reciprocal commitments: for every clock CERG runs against the business, CERG runs a clock against itself. It applies to every CERG engagement model in OM-001 §5 (Project, Continuous Service, Advisory, Program Oversight). > **A Slow Yes Is a No** > > "Make yes safe" only enables the business if yes is also fast. A security function that takes three weeks to answer a question has, in practice, said no, because the business has already moved without it. Publishing a clock on ourselves is how we prove the yes-and philosophy is a commitment and not a slogan. --- ## 2. Principles Five principles govern CERG's service commitments: 1. **Reciprocity.** For every service-level clock CERG runs against the business, CERG runs a clock against itself. Accountability is symmetric. 2. **Tiered.** Commitments scale by request criticality and project tier, not one-size-fits-all. A high-impact regulated project and a minor internal tool do not get the same clock. 3. **Published.** Commitments are visible to the business, not internal targets. The business is entitled to know what to expect and to escalate when it does not get it. 4. **Measured.** Every commitment maps to a metric in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) and is reported alongside, and with equal weight to, the discipline metrics that measure the business. 5. **Escalation, not silence.** A missed commitment triggers a defined escalation, never a silent delay. A request that will miss its commitment is surfaced before the clock expires, not after. --- ## 3. Service Commitment Catalog The turnaround values below are **preliminary defaults requiring organizational calibration**, following the calibration pattern in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §12. They are starting points for a mid-size organization; each organization calibrates them to its own staffing and demand, and the CISO approves the calibrated set. Business days are used throughout. ### 3.1 Project Engagement (Engineering-Led, OM-001 §5.1) | Request type | Tier / trigger | CERG commitment (preliminary default) | Escalation if missed | Metric | |---|---|---|---|---| | Architecture review intake acknowledgement | All projects | Acknowledge and assign a reviewer within 2 business days | Auto-notify Engineering Pillar Leader | SR-003 | | Architecture review disposition | Tier 1 (high-impact / regulated / OT / AI) | Disposition within 10 business days of complete intake | Engineering Pillar Leader, then CISO | SR-001 | | Architecture review disposition | Tier 2 (standard) | Disposition within 7 business days | Engineering Pillar Leader | SR-001 | | Architecture review disposition | Tier 3 (minimal) | Disposition within 5 business days | Engineering Pillar Leader | SR-001 | ### 3.2 Continuous Service (Risk-Led, OM-001 §5.2) | Request type | Tier / trigger | CERG commitment (preliminary default) | Escalation if missed | Metric | |---|---|---|---|---| | Bring a new asset under vulnerability / CSPM coverage | Post go-live | Coverage established within 5 business days of go-live notification | Risk Pillar Leader | SR-005 | ### 3.3 Advisory (Cross-Pillar, OM-001 §5.3) | Request type | Tier / trigger | CERG commitment (preliminary default) | Escalation if missed | Metric | |---|---|---|---|---| | Advisory or office-hours question | All | Substantive written response within 3 business days | Owning Pillar Leader | SR-002 | | New SaaS / cloud service review | Restricted-data placement | Decision within 10 business days | Governance + Engineering, then CISO | SR-003 | | New SaaS / cloud service review | Non-Restricted | Decision within 5 business days | Owning Pillar Leader | SR-003 | ### 3.4 Program Oversight and Risk Decisions (Governance-Led, OM-001 §5.4) | Request type | Tier / trigger | CERG commitment (preliminary default) | Escalation if missed | Metric | |---|---|---|---|---| | Exception / risk-acceptance request intake | All | Acknowledge and route to the correct approver within 3 business days | Risk Register Owner | SR-004 | > **Intake clock, not decision clock.** The commitment in §3.4 is to acknowledge and route the request promptly. The decision authority and the substantive risk judgment remain with the approver named in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. SLC commitments govern CERG's responsiveness; they never compress or override a risk decision. ### 3.5 Adoption-Phase SLA Targets The commitment values in §3.1–§3.4 are mature-program targets. New adopters progress through adoption gates; SR metrics use the phase-adjusted targets below until the program reaches Gate 3. Phase context is reported on the CISO Dashboard. | Phase | Architecture Review (SR-001) | Advisory Response (SR-002) | Intake Disposition (SR-003) | Time-to-Coverage (SR-005) | |-------|----------------------------|---------------------------|----------------------------|--------------------------| | **Gate 1 (Spine, 0–90 days)** | 15 business days | 10 business days | 15 business days | 15 business days | | **Gate 2 (Operating, 90–180 days)** | 10 business days | 5 business days | 10 business days | 10 business days | | **Gate 3+ (Governed / Adaptive)** | Per §3.1 (10 / 7 / 5 business days by tier) | Per §3.3 (3 business days) | Per §3.1 / §3.3 | Per §3.2 (5 business days) | > **Phase Advancement.** Advancement from one gate to the next is recorded in the adoption gates document ([`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md)) and communicated to the Cyber Oversight Group. SR metric reporting switches to the next phase target upon confirmation of gate transition. ### 3.6 What a missed commitment looks like in practice The SLA commitments above are not abstractions. They show up in real meetings. The worked example below is a fictional but realistic Tuesday morning scenario at a 60-person SaaS company in the second quarter of CERG Standard adoption. It illustrates what the §4 escalation path actually produces. A product team submits a T1 architecture review intake for a new customer-facing analytics feature on a Tuesday at 9 a.m. The intake is logged in the Project Intake Record, tiered T1 because the workload is internet-facing and handles customer data, and routed to Engineering. Per §3.5 Gate 2, the SR-001 commitment is a 10-business-day architecture review turnaround. By day 6, Engineering has not started the review. The intake sits in the queue behind two higher-priority reviews. Nobody on Engineering has acknowledged the delay to the product team. By day 9, the product manager pings Engineering directly. Engineering says "we'll get to it." By day 11, the 10-business-day commitment has been missed. No notification was sent per §4 step 1. Here is what the §4 escalation path produces: 1. **Day 11 (commitment missed, no notification sent).** The Engineering Pillar Leader is auto-notified by the SR-001 metric breach. The single miss is logged. The Engineering Pillar Leader contacts the product manager the same morning with a revised date (day 14) and a reason ("behind on two other T1s; yours is next"). The revised date goes into the intake record. 2. **Day 14 (revised date met).** The architecture review is delivered. The SR-001 metric records the miss: the commitment clock was 10 business days, the actual was 14. Quality was acceptable; the product team got a useful review. 3. **End of month (single miss).** The Engineering Pillar Leader reviews the SR-001 trend. One miss in the month is within noise. No further action. The miss is in the dashboard. 4. **Quarter review (pattern).** If the same pillar has three or more misses in a quarter, the pattern surfaces to the CISO and the Cyber Oversight Group per §4 step 3. The CISO opens a discussion: is the published value mis-calibrated to capacity, or is the pillar overcommitted? The answer drives a workforce-planning or scoping decision, not a "try harder" instruction. 5. **Annual (systemic).** If the same pillar has chronic misses across two quarters, the CISO records a Program Improvement Register entry per §4 step 4 with source "SLC systemic miss, pillar X, YYYY." The improvement is owned at the CISO level, not the pillar level, because chronic misses signal a capacity gap CERG must fix. The same pattern applies to every commitment in §3. The numbers are smaller or larger, the pillar is different, but the chain is the same: miss, log, communicate, escalate by pattern, address systemically. The point of publishing these commitments is not to create a metric treadmill. The point is to make CERG's responsiveness visible so that friction is caught early, not when the business has built workarounds. A single miss is acceptable. A pattern is a finding. Chronic is a program-level problem. For a 90-day narrative that includes the first SR-001 miss in a real adoption arc, see [Story 10 (The new CISO's first 90 days)](../examples/day-in-the-life/story-10-new-ciso-90-days.md). For the worked example of how a business-side SLA breach is handled by Risk, see [Story 2 (Critical vulnerability)](../examples/day-in-the-life/README.md#story-2-critical-vulnerability). --- ## 4. Escalation Path for Missed Commitments When CERG misses, or forecasts that it will miss, a published commitment: 1. **Before the clock expires:** the owning role notifies the requester that the commitment will be missed, with a revised date and reason. Silence is not permitted. 2. **On a miss:** the owning Pillar Leader is auto-notified. A single miss is logged. 3. **On repeated misses:** a pattern of misses in a service category surfaces to the CISO and to the Cyber Oversight Group, mirroring the escalation symmetry that applies to business-side SLA breaches. 4. **Systemic misses** are a CERG program finding and are recorded in the Program Improvement Register ([`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md)). A missed commitment is CERG's problem to fix, not the requester's problem to absorb. Chronic misses signal a capacity or process gap in CERG, addressed through workforce planning, not by quietly deprioritizing the business. --- ## 5. What This Is Not - **Not a guarantee of "yes."** The commitment is to respond within the clock, not to approve. A fast, documented "no" with a path forward satisfies the commitment fully. - **Not a bypass of rigor.** SLC commitments never justify a shallow architecture review or a rubber-stamp risk decision. Speed is measured alongside quality, and the anti-shallow-metrics guardrails in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §8 apply. A fast review that misses a material risk is a failure, not a success. - **Not a substitute for prioritization.** When demand exceeds capacity, CERG triages by risk and business criticality and communicates the revised dates per Section 4. It does not silently let the lowest-priority requests rot. --- ## 6. Metrics and Reporting Every commitment in Section 3 maps to a CERG Service Responsiveness metric (SR-001 through SR-005) defined in [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). These metrics are reported on the CISO dashboard with equal standing to the business-discipline metrics, and SR-004 (SLC Commitment Adherence) is reported to the Cyber Oversight Group and the board. The annual stakeholder perception survey ([`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md)) provides the qualitative companion to these continuous quantitative measures, so friction is caught monthly rather than once a year. --- ## 7. Roles and Responsibilities | Role | Responsibility | |---|---| | **CISO** | Owns this document; approves the calibrated commitment values; owns board-level SLC adherence reporting. | | **Engineering Pillar Leader** | Accountable for project-engagement and architecture-review commitments (§3.1) and their misses. | | **Risk Pillar Leader** | Accountable for continuous-service coverage commitments (§3.2). | | **Governance Pillar Leader** | Accountable for advisory and program-oversight commitments (§3.3, §3.4) and for SLC reporting. | | **Risk Register Owner** | Accountable for exception / risk-acceptance intake routing (§3.4). | --- ## 8. Document Control | | | |---|---| | **Document ID** | CERG-GOV-SLC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Chief Information Security Officer | | **Next Review** | Annual / On engagement-model change | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.0 | 2026-06-12 | CISO | Initial publication. Establishes CERG's reciprocal, published, measured service-level commitments back to the business, with an escalation path for misses and a mapping to MTR-001 SR-series metrics. | ### Review Triggers - Annual scheduled review. - Change to any OM-001 §5 engagement model. - Calibration of the preliminary default turnaround values. - A pattern of missed commitments indicating the published values are mis-calibrated to capacity. ### Related Documents - [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) - Operating Model (engagement models) - [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) - Metrics and Reporting (SR-series metrics) - [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) - Cross-Pillar Operational Flows (F-02 intake) - [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - Architecture Review and Project Intake - [`CERG-TMPL-GOV-001`](../templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md) - Stakeholder Perception Survey - [`CERG-GOV-IMPREG-001`](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) - Program Improvement Register --- ## CROWN JEWEL REGISTER AND LOSS SCENARIO LIBRARY ### What Would End Us, and Who Defends Each Chain End-to-End --- | | | |---|---| | **Document ID** | CERG-GOV-CJ-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader / Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) · [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) · [`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) · [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) · [`CERG-GOV-EDG-001`](CERG-GOV-EDG-001_Edge_Register.md) · `machine-readable/cerg-crown-jewel-schema.yaml` | | **Review Cycle** | Annual / On material change to crown-jewel population or threat landscape | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (IDENTIFY, GOVERN) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (RA, CP, CA) · NIST 800-37 RMF | | **Regulations** | NERC-CIP CIP-002 · [CMMC L2](https://dodcio.defense.gov/CMMC/) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT, CUI | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Relationship to Bottom-Up Risk](#2-relationship-to-bottom-up-risk) 3. [The Crown Jewel Register](#3-the-crown-jewel-register) 4. [The Loss Scenario Library](#4-the-loss-scenario-library) 5. [Scenario Pressure-Test Process](#5-scenario-pressure-test-process) 6. [Integration Points](#6-integration-points) 7. [Roles and Responsibilities](#7-roles-and-responsibilities) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope CERG's operational pipeline is bottom-up. A scanner, a penetration test, an audit, or a review produces an observation; Risk validates its reachability, scores it, and tracks it to closure through [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) and the risk register in [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) Section 9. This pipeline is disciplined and measurable, and it is necessary. It is not sufficient. A program can be green on every finding metric and still have an undefended path to a catastrophic loss, because nothing in the bottom-up pipeline asks the top-down question: **what is the small set of events that would actually end this organization, and is anyone defending each of those chains end-to-end?** A bottom-up pipeline sees individual findings. It does not see a chain that crosses four assets and three control families, where each link looks acceptable in isolation but the chain as a whole is fatal. This document adds the top-down layer. It does two things: 1. Establishes the **Crown Jewel Register** as the authoritative inventory of the assets whose loss would be catastrophic or severe, and defines the minimum control profile those assets must carry, verified rather than assumed. 2. Establishes the **Loss Scenario Library**, a curated set of named loss scenarios that are pressure-tested against the program's actual control coverage, so that catastrophic gaps are discovered by deliberate exercise rather than by an incident or an auditor. This document is scoped to CERG-managed assets and controls. It does not replace the System Categorization Register maintained under RMF-001 Section 3; it is a view over that register plus the scenario reasoning the register does not contain. > **The Adaptive Test** > > An assessor asks: "Show me your crown jewels and the scenarios you test against them." A Repeatable program answers with a control list. An Adaptive program answers with a named-scenario library, the control families that should break each chain, the detections that should fire, the recovery path, and the dated record of the last time each scenario was walked end-to-end. The difference is whether the program waits to be surprised. --- ## 2. Relationship to Bottom-Up Risk The two layers are complementary and must reconcile. Neither replaces the other. | Dimension | Bottom-Up (existing) | Top-Down (this document) | |---|---|---| | **Starting point** | An observation: scan, test, audit, intel, review | A crown jewel and a named loss scenario | | **Question asked** | "Is this finding reachable, and how bad is it?" | "What would end us, and is the chain broken?" | | **Primary owner** | Exposure Management Lead / Risk Register Owner | Risk Pillar Leader (scenarios) / Governance (register) | | **Authoritative home** | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md), RMF-001 Section 9 | This document | | **Failure it catches** | Individual exploitable exposures | Cross-asset, cross-control kill chains | | **Cadence** | Continuous | Scheduled pressure-test (Section 5) | **Reconciliation rules:** 1. Every crown jewel in the register (Section 3) must exist as a categorized system in the RMF-001 Section 3 System Categorization Register. The register here does not invent assets; it flags and enriches the most consequential ones. 2. Every chain-breaking control named in a scenario (Section 4) must trace to a control in [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md). Scenarios do not invent controls; they assert which existing controls must hold. 3. Every gap surfaced by a pressure-test becomes a bottom-up artifact: a Finding Record per [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-04. This is the bridge that returns top-down discoveries to the disciplined bottom-up pipeline for tracked closure. --- ## 3. The Crown Jewel Register ### 3.1 Criticality Tiers The register classifies assets by the consequence of their loss. Tier 0 and Tier 1 assets are crown jewels and carry the minimum control profile in Section 3.3. Tiers 2 through 4 are governed by the standard baseline and overlays in CB-001. The tier definitions are the authoritative markdown form of the criticality tiers in `machine-readable/cerg-crown-jewel-schema.yaml`; where the two differ, this document wins and the schema is regenerated. | Tier | Meaning | Control expectation | |---|---|---| | **Tier 0** | Crown Jewel. Loss would be catastrophic - existential or grid/safety-level. | All applicable controls at enhanced verification frequency, plus the Section 3.3 minimum profile. | | **Tier 1** | Critical. Loss would be severe. | All applicable controls at standard verification frequency, plus the Section 3.3 minimum profile. | | **Tier 2** | High. Loss would be significant. | All applicable controls per CB-001. | | **Tier 3** | Moderate. Loss would be manageable. | Priority controls per CB-001. | | **Tier 4** | Low. Loss would be minor. | Baseline controls per CB-001. | ### 3.2 Register Field Set Each crown-jewel entry records the following fields. These are the authoritative form of the `crown_jewel_fields` in the machine-readable schema: | Field | Description | |---|---| | `asset_id` / `system_id` | Identifier tying back to the System Categorization Register and asset inventory. | | `business_service` | The business service the asset delivers. | | `owner` | Accountable asset owner. | | `executive_sponsor` | Named business executive sponsor (per OM-001 canonical roster). | | `criticality_tier` | Tier 0 or Tier 1 for crown jewels. | | `crown_jewel` | Boolean flag surfaced on the categorization register. | | `regulated_scope` | BES Cyber System, CUI enclave, SOX ITGC, or none. | | `data_classification` | Highest data sensitivity handled. | | `operational_impact` / `safety_impact` / `financial_reporting_impact` / `customer_impact` | Consequence dimensions of loss. | | `internet_exposed` | Whether any reachable path originates from the Internet. | | `third_party_dependencies` | Vendors, SaaS tenants, or sub-processors in the asset's trust or recovery path (cross-reference [`CERG-GOV-EDG-001`](CERG-GOV-EDG-001_Edge_Register.md)). | | `recovery_time_objective` / `recovery_point_objective` | RTO / RPO from BC-001. | | `minimum_logging_profile` / `minimum_backup_profile` / `minimum_identity_profile` / `minimum_segmentation_profile` / `minimum_adversarial_validation_profile` | The verified minimum control profile (Section 3.3). | | `review_date` | Next scheduled review of this entry. | ### 3.3 Minimum Control Profile for Crown Jewels A crown jewel does not merely inherit a NIST baseline overlay. It carries a minimum control profile that must be **verified, not assumed**. Each line is additive on top of the asset's standard baseline and regulatory overlays per CB-001 (consistent with the CB-001 design principle that overlays add and never relax). A crown jewel that cannot evidence each line below generates a Finding Record per FLOW-001 F-04. | Profile element | Tier 0 (Crown Jewel) | Tier 1 (Critical) | Verifying evidence | CB-001 / standard reference | |---|---|---|---|---| | **Tested recovery** | Recovery tested at enhanced frequency; backup demonstrably outside the asset's blast radius (separate trust domain / immutable / offline). | Recovery tested at standard frequency; backup isolation documented. | Restoration test record; backup isolation attestation. | CP family; [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | | **Phishing-resistant identity** | Phishing-resistant MFA enforced for all human and machine access paths; no legacy-auth bypass. | Phishing-resistant MFA for privileged access. | IdP enforcement report; legacy-auth disablement evidence. | AC, IA; [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | | **Segmentation** | Asset is segmented to limit lateral movement; reachable paths enumerated and minimized. | Segmentation documented; reachable paths reviewed. | Segmentation diagram; reachability validation. | SC; [`CERG-STD-NET-001`](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) | | **Day-one detection** | ATT&CK-mapped detections for the asset's likely kill chains are authored, tested, and operating. | Day-one detection set present and tested. | Detection coverage report (LM-001 DT-001). | AU, SI; [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Adversarial validation** | Validated by penetration test or purple-team exercise at enhanced frequency. | Validated at standard frequency. | Adversarial validation report. | CA-8; [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | > **Verified, Not Assumed** > > "We back it up" is not tested recovery. "MFA is on" is not phishing-resistant identity enforced with legacy auth disabled. "It's in its own VLAN" is not enumerated, minimized reachability. The crown-jewel profile is satisfied only by the named evidence, current within its freshness window. An assumed control on a crown jewel is the most expensive kind of optimism. ### 3.4 Relationship to the System Categorization Register The crown-jewel register is a **view over** the RMF-001 Section 3 System Categorization Register, not a parallel inventory. The Tier 0 / Tier 1 flag lives on the categorization register; Governance maintains both records together. This document surfaces and operates the crown-jewel subset and attaches the minimum control profile and scenario linkage that the categorization register does not carry. There is exactly one authoritative list of systems, and it is the categorization register. --- ## 4. The Loss Scenario Library ### 4.1 Scenario Structure A loss scenario is a named, narrated kill chain against one or more crown jewels. Each scenario is recorded with the following structure: - **Scenario ID and Name** - **Narrative**: one paragraph describing the loss event in business terms. - **Crown jewels in blast radius**: the register entries the scenario threatens. - **Kill chain**: the high-level adversary steps. - **Chain-breaking controls**: the CB-001 control families that should stop the chain, with the specific control intent at each link. - **Detections that should fire**: the ATT&CK techniques and LM-001 detections that should surface the activity. - **Recovery path**: the BC-001 / RES-001 path that restores the service if prevention and detection both fail. - **Owner**: the role accountable for keeping this scenario current and walking it. Scenario-specific financial or impact figures are recorded as **preliminary defaults requiring organizational calibration**, following the RMF-001 Section 12 calibration pattern. They are not approved loss values until Finance and the CISO sign. ### 4.2 Starter Scenario Set The following scenarios are the starting library. Each organization tailors the set to its own crown jewels and sector; the utility/OT and CUI flavor below reflects CERG's reference environment. The library should hold roughly ten to fifteen live scenarios at any time. | ID | Name | Crown jewels in blast radius | Chain-breaking control families | Detections that should fire | Recovery path | |---|---|---|---|---|---| | **SCN-01** | Ransomware encrypts production while backups share a trust domain | Primary business systems; backup infrastructure | CP (backup isolation), AC/IA (privilege containment), SC (segmentation), SI (anti-malware) | T1486 Data Encrypted for Impact; T1490 Inhibit System Recovery; mass file-change and backup-deletion alerts | Restore from blast-radius-isolated backup per RES-001; BC-001 activation | | **SCN-02** | OT/SCADA historian compromise causing loss of grid visibility or control | Historian; control servers; BES Cyber Systems | SC (IT/OT boundary), AC (least privilege), AU (OT monitoring), MA (controlled maintenance) | ATT&CK for ICS: T0859 Valid Accounts; T0816 Device Restart/Shutdown; OT protocol anomalies | OT recovery runbook; manual operations fallback; CIP-008 path | | **SCN-03** | CUI exfiltration via MSP or vendor admin path | CUI enclave; vendor admin tooling | SA/SR (vendor controls), AC (vendor privilege), AU (vendor-path logging), edge controls (EDG-001) | T1199 Trusted Relationship; T1078 Valid Accounts; anomalous vendor-path access | CUI containment; POA&M; SCCT activation per TPRM-001 | | **SCN-04** | Code-signing, CA, or secrets key compromise propagating to customers | Signing infrastructure; key management; CA hierarchy | CR (key management), AC (key access), AU (key-use logging), SI (integrity) | T1552 Unsecured Credentials; T1588.004 stolen certificates; anomalous signing events | Key revocation and re-issuance; IR-002 cryptographic playbook | | **SCN-05** | Identity provider or federation compromise yielding org-wide privilege | IdP; federation; PAM | IA (phishing-resistant MFA), AC (privileged access), AU (identity detection) | T1556 Modify Authentication Process; T1606 Forge Web Credentials; impossible-travel, MFA-fatigue | Emergency credential reset; break-glass procedures; federation rebuild | | **SCN-06** | Cloud control-plane / root account takeover | Cloud management plane; landing zones | AC (root protection), IA (MFA on root), CM (guardrails), AU (control-plane logging) | T1078.004 Cloud Accounts; T1098 Account Manipulation; root-use and policy-change alerts | Control-plane lockdown; account recovery; landing-zone redeploy | | **SCN-07** | Privileged insider exfiltrates or sabotages | Crown-jewel systems within insider's access | PS (personnel security), AC (least privilege, separation of duties), AU (privileged-session monitoring) | T1078 Valid Accounts; anomalous bulk access; privileged-session anomaly (AC-EFF-002) | Access revocation; HR/Legal coordination; investigation per IR-002 | | **SCN-08** | Critical SaaS tenant compromise where data lives off-premises | SaaS tenant holding regulated/crown-jewel data | SA (SaaS governance), AC (SaaS identity), AU (SaaS audit logs), edge controls (EDG-001) | T1078 Valid Accounts; SaaS audit-log anomalies; OAuth grant abuse (T1528) | SaaS tenant lockdown; provider escalation; data recovery per agreement | | **SCN-09** | Business email compromise leading to financial fraud or wire diversion | Email platform; finance approval workflow | AC/IA (email identity), AU (email-anomaly detection), AT (awareness) | T1566 Phishing; T1534 Internal Spearphishing; mailbox-rule and wire-anomaly alerts | Transaction reversal coordination; finance control review; LL-001 | | **SCN-10** | Sub-processor concentration failure cascading across multiple vendors | Services depending on a shared sub-processor | SR (supply chain), SA (vendor controls), edge controls (EDG-001 concentration rule) | Vendor-incident intelligence; concentration alert (>= 3 T1/T2 vendors on one sub-processor) | Vendor failover; TPRM-001 concentration response; SCCT | Each scenario above is maintained as a fuller record (narrative, kill-chain steps, owner, preliminary impact) in the scenario library operated by the Risk Pillar Leader. The table is the index; the records carry the detail. --- ## 5. Scenario Pressure-Test Process ### 5.1 What a Pressure-Test Is A scenario pressure-test is a deliberate desk exercise in which the Risk pillar walks a named scenario's kill chain link by link and asks, at each link: 1. **Does the chain-breaking control exist** for the crown jewels in the blast radius? 2. **Is it Implemented** per CB-001 (not Planned, not assumed)? 3. **Is it Effective** per [`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) (the effectiveness metric is green, not merely the implementation metric)? 4. **Would the detection fire**, and would someone investigate it within SLA? 5. **Does the recovery path work**, and is it tested? Any answer of "no" or "unknown" is a gap. ### 5.2 What a Pressure-Test Is Not This is a control-coverage validation, not an incident drill. Full incident-response tabletops are owned by the standing IR team and documented in the IR plan. A scenario pressure-test may be combined with an IR tabletop, but its purpose is distinct: the tabletop rehearses the response; the pressure-test verifies that the controls which should prevent, detect, and recover from the scenario actually exist and work. The pressure-test does not require an active incident or a live exercise; it is a structured walk of the chain against documented control state. ### 5.3 From Gap to Tracked Closure Every gap a pressure-test surfaces is logged as a **Finding Record per FLOW-001 F-04**, entering the disciplined bottom-up pipeline for owned, dated closure. Where a gap materially changes the residual risk of an asset, it also triggers the RMF-001 Section 9 re-score (Section 6 below). This is how a top-down discovery becomes bottom-up tracked work rather than a slide that is forgotten after the meeting. ### 5.4 Cadence Scenario pressure-tests are scheduled in [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md). The recommended cadence is semi-annual for the full library, with any individual scenario re-walked when the threat landscape, the crown-jewel population, or a material control change warrants it. Each pressure-test produces a Scenario Pressure-Test Report and the associated Finding Records. --- ## 6. Integration Points This document is connective tissue. Its value is in the cross-references below; each is wired in the named document. | Integration | Where | What it does | |---|---|---| | **Re-score trigger** | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) Section 9 | A pressure-test that reveals an unbroken chain on an asset in the blast radius re-scores every register risk touching that crown jewel. | | **Project intake / design target** | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-02 | Projects touching or creating a crown jewel must meet the Section 3.3 minimum control profile pre-go-live; relevant scenarios become threat-model design targets. | | **Coverage validation** | FLOW-001 F-03 | Asset registration validates that crown-jewel assets carry the verified minimum control profile, not just scan coverage. | | **Control overlay** | [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) | The Crown-Jewel Overlay applies the Section 3.3 profile additively on top of baseline and regulatory overlays. | | **Metrics** | [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | EM-006 (exposures on crown jewels) cites this register as its source; RM-007 (Scenario Defense Coverage) measures the fraction of scenarios fully defended. | | **Board reporting** | [`CERG-TMPL-MTR-001`](../templates/CERG-TMPL-MTR-001_Board_and_CISO_Reporting_Deck_Template.md) | A Scenario Defense Posture view gives the board the top-down framing alongside the bottom-up top risks. | | **Cadence and maturity** | [`CERG-GOV-CAL-001`](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md), [`CERG-GOV-MAT-001`](CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | The pressure-test is scheduled and the program's scenario coverage is scored as a maturity domain. | | **Machine-readable** | `machine-readable/cerg-crown-jewel-schema.yaml` | The schema is the derived form of this register; this document is authoritative and the schema is regenerated from it. | --- ## 7. Roles and Responsibilities | Role | Responsibility | |---|---| | **Risk Pillar Leader** | Owns the scenario library; runs the pressure-tests; produces the Scenario Pressure-Test Report; opens Finding Records for gaps. | | **Governance Pillar Leader** | Maintains the crown-jewel flags on the System Categorization Register; owns this document's place in the catalog and review cycle; reports scenario coverage to the COG and board. | | **Engineering Pillar Leader** | Implements the Section 3.3 minimum control profile on crown-jewel assets; treats scenarios as design targets at project intake. | | **Executive Sponsor** | Named per crown jewel; concurs on residual risk where a scenario gap is accepted rather than remediated, per RMF-001 Section 9.7. | | **CISO** | Approves the crown-jewel population and the scenario library; owns the board-level scenario defense posture. | --- ## 8. Document Control | | | |---|---| | **Document ID** | CERG-GOV-CJ-001 | | **Version** | 1.0 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Risk Pillar Leader / Governance Pillar Leader | | **Next Review** | Annual / On material change to crown-jewel population or threat landscape | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.0 | 2026-06-12 | Risk Pillar Leader / Governance Pillar Leader | Initial publication. Establishes the crown-jewel register as authoritative, defines the Tier 0/1 minimum control profile, and creates the named loss scenario library with the pressure-test process. | ### Review Triggers - Annual scheduled review. - Material change to the crown-jewel population (new Tier 0/1 asset, decommission, ownership change). - Material threat-landscape shift that introduces or retires a scenario. - A scenario pressure-test or incident that proves a scenario or control assumption wrong. ### Related Documents - [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) - Risk Management Framework (categorization, re-score triggers) - [`CERG-GOV-CB-001`](CERG-GOV-CB-001_Unified_Control_Baseline.md) - Unified Control Baseline (chain-breaking controls, Crown-Jewel Overlay) - [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) - Cross-Pillar Operational Flows (F-02, F-03, F-04) - [`CERG-GOV-CEF-001`](CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) - Control Effectiveness Framework (effectiveness test in pressure-test) - [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) - Metrics and Reporting (EM-006, RM-007) - [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) - Business Continuity and DR (recovery paths) - [`CERG-GOV-EDG-001`](CERG-GOV-EDG-001_Edge_Register.md) - Edge Register (vendor and SaaS edges in scenarios) --- ## EDGE REGISTER ### The Organizational Edge Is No Longer Only IP Space · Six Edge Types · Defend What's Actually Reachable --- | | | |---|---| | **Document ID** | CERG-GOV-EDG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Vendor Risk Analyst / Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-NET-001](../standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) · [CERG-STD-SDL-001](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) · [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | | **Review Cycle** | Annual / On material change to vendor population, SaaS portfolio, or network architecture | | **Frameworks** | NIST CSF 2.0 (IDENTIFY, GOVERN) · NIST 800-53r5 (CA, SA, SR) · NIST 800-161r1 | | **Regulations** | NERC-CIP CIP-013 · CMMC L2 · SOX ITGC | | **Environments** | All organizational edges — network, identity, SaaS, vendor, software supply, data | --- ## Table of Contents 1. [The Edge — What Changed](#1-the-edge--what-changed) 2. [The Six Edge Types](#2-the-six-edge-types) 3. [Edge Management Model](#3-edge-management-model) 4. [Low-Control / High-Dependency Operating Model](#4-low-control--high-dependency-operating-model) 5. [Edge Register Operations](#5-edge-register-operations) 6. [Document Control](#6-document-control) --- ## 1. The Edge — What Changed For twenty years, "the organizational edge" meant the firewall. You knew what was inside and what was outside, and security's job was to harden the perimeter. That edge no longer exists in any useful form. Organizations operate across SaaS tenants, identity providers, vendor admin paths, MSP tooling, CI/CD dependencies, managed detection providers, cloud control planes, APIs, domains, certificates, subprocessors, and data egress paths. Each of these is a boundary across which trust, data, privilege, or control flows. Each of these is an edge. > **The organizational edge is not a network diagram. It is the set of boundaries across which the organization's security posture can be changed by someone outside the organization.** CERG maintains this Edge Register as the authoritative inventory of organizational edges. It is not a replacement for the TPRM procedure — it is the conceptual model that elevates third-party and supply-chain risk from "a procedure" to a first-class architectural concern. The TPRM procedure ([CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md)) is the operational document that implements this model. A program that truly knows its edge is less impressed by AI-powered attack branding. The edge doesn't care whether the attacker used AI. It cares whether the path existed. --- ## 2. The Six Edge Types ### 2.1 Network Edge The traditional perimeter — and still relevant. What is Internet-reachable? What VPNs, APIs, and remote-access paths exist? | Attribute | Description | |-----------|-------------| | **Examples** | Internet-facing hosts, VPN concentrators, public APIs, cloud load balancers, exposed management interfaces | | **Primary owner** | Network Engineering / Cloud Engineering | | **CERG role** | Risk validates external attack surface continuously; Engineering reviews architecture for new Internet-facing services | | **Evidence** | EASM export, DNS/cloud reconciliation, firewall rule review | | **Key question** | "If we didn't know this was here, could an attacker find it?" | ### 2.2 Identity Edge The most consequential edge in modern environments. Who can authenticate? What can they reach after authentication? What federated trust relationships exist? | Attribute | Description | |-----------|-------------| | **Examples** | IdP (Entra ID, Okta), federation trusts, OAuth applications, privileged groups, service principals, API keys | | **Primary owner** | Identity Engineering | | **CERG role** | Risk monitors privileged access; Governance tracks recertification; Engineering reviews federation and OAuth grants | | **Evidence** | IdP logs, privileged group membership diff, OAuth application inventory, service principal audit | | **Key question** | "If an attacker has a valid credential, what can they reach before we detect them?" | ### 2.3 SaaS Edge Every SaaS tenant is an organizational edge. The organization's data, identities, and configurations live inside a provider's infrastructure. | Attribute | Description | |-----------|-------------| | **Examples** | M365 tenant, Salesforce org, Workday instance, ServiceNow, GitHub org, Slack workspace | | **Primary owner** | Business application owners + IT | | **CERG role** | Governance maintains Approved Provider Catalog; Risk runs SSPM; Engineering reviews tenant configurations | | **Evidence** | SSPM report, admin setting export, OAuth grant review, shared responsibility matrix per provider | | **Key question** | "What data lives in this tenant, who can access it, and what happens if the provider is compromised?" | ### 2.4 Vendor Edge Vendors and service providers with privileged access, remote connectivity, or administrative paths into organizational systems. | Attribute | Description | |-----------|-------------| | **Examples** | MSP tooling, remote support accounts, OT vendor maintenance access, managed detection providers, contractor admin paths | | **Primary owner** | Vendor Risk Analyst | | **CERG role** | Risk assesses and tiers vendors; Governance tracks contract clauses and evidence; Engineering validates access controls | | **Evidence** | PAM session logs, vendor access review, contract clause register, kill-switch test records | | **Key question** | "If this vendor is compromised, what can the attacker reach, and how fast can we cut them off?" | ### 2.5 Software Supply Edge Every dependency — open-source library, commercial SDK, CI/CD pipeline, build system — is a path through which malicious code can enter the organization. | Attribute | Description | |-----------|-------------| | **Examples** | npm/PyPI/Maven packages, Docker base images, CI/CD pipeline integrations, build system access, signed releases | | **Primary owner** | Engineering / Application Security | | **CERG role** | Risk runs SCA; Engineering maintains SBOM; Governance tracks integrity requirements | | **Evidence** | SBOM (NTIA minimum elements), CVE advisory subscription, signed release verification, pipeline access review | | **Key question** | "If a popular open-source package we depend on is compromised tonight, do we know within hours?" | ### 2.6 Data Edge Every path through which organizational data leaves the organization's control — subprocessors, external data shares, outbound integrations, backup targets. | Attribute | Description | |-----------|-------------| | **Examples** | External data shares (SharePoint, Box), subprocessor data flows, outbound API integrations, backup replication targets, analytics pipelines | | **Primary owner** | Data Governance / Business application owners | | **CERG role** | Governance tracks subprocessor inventory; Risk assesses data egress paths; Engineering reviews integration architecture | | **Evidence** | Subprocessor register, data flow diagrams, DLP policy coverage, external share audit | | **Key question** | "Where does our data live outside our control, and who can see it?" | --- ## 3. Edge Management Model Every edge is managed through a common lifecycle: | Phase | Activity | Owner | |-------|----------|-------| | **Discover** | Identify and inventory the edge. What exists? | Risk / Engineering | | **Assess** | Evaluate the risk. What's the blast radius if compromised? | Risk | | **Control** | Implement controls. What reduces the exposure to acceptable levels? | Engineering | | **Monitor** | Continuously validate. Has anything changed? | Risk | | **Respond** | React to compromise. How fast can we cut access? | Engineering / Risk / SCCT | Each edge type has its own discovery cadence, assessment criteria, control catalog, and monitoring signals. The table below summarizes the primary tooling and evidence for each type: | Edge Type | Discovery | Assessment | Control | Monitoring | |-----------|-----------|------------|---------|------------| | Network | EASM, external scan, cloud inventory | CVSS + exposure + asset criticality | Firewall, WAF, ACL, segmentation | Continuous external scan, drift detection | | Identity | IdP export, privileged group review | Access review, privilege analysis | PAM, JIT, phishing-resistant MFA | IdP logs, anomalous access detection | | SaaS | SSPM, tenant inventory, OAuth review | Configuration assessment, data classification | Tenant configuration baseline, OAuth app approval | SSPM continuous monitoring, drift alerting | | Vendor | Vendor register, contract review | Tier-based assessment, evidence collection | PAM, session recording, kill-switch | Access review, SOC 2 / attestation monitoring | | Software supply | SBOM, pipeline inventory, dependency scan | CVE matching, exploitability analysis | Signed releases, pipeline access control, dependency pinning | SCA continuous monitoring, advisory feeds | | Data | DLP discovery, share audit, integration map | Data classification, egress path analysis | DLP policies, encryption, access controls | DLP alerts, external share review, subprocessor change alerts | --- ## 4. Low-Control / High-Dependency Operating Model Not all edges can be controlled. Some can only be influenced, contracted, or monitored. CERG recognizes four control levels: | Control Level | What the Org Can Do | Examples | |---------------|---------------------|----------| | **Direct Control** | Configure, monitor, patch, test | Owned servers, self-managed cloud workloads, on-premise network | | **Shared Control** | Configure tenant, require evidence, validate logs | SaaS tenants (M365, Salesforce), IaaS/PaaS (AWS, Azure) | | **Contractual Control** | Negotiate clauses, notification, audit rights | MSPs, managed security providers, subprocessors | | **Opaque Dependency** | Track residual risk, exit plan, kill switch, compensating monitoring | SaaS vendor's underlying infrastructure, open-source library maintainers, upstream cloud provider outages | **Operating at each level:** - **Direct and Shared control** environments follow standard CERG controls — baselines, scanning, change management, evidence collection. - **Contractual control** environments require: security clauses in contracts, annual evidence collection (SOC 2, ISO 27001, or equivalent), incident notification commitments, and a tested kill-switch procedure. - **Opaque dependency** environments require: documented residual risk acceptance, an exit/migration plan, compensating monitoring (e.g., CSPM/SSPM for what IS visible), and a documented assumption of what the dependency provides. CERG does not pretend to control what it cannot control. --- ## 5. Edge Register Operations ### 5.1 Register Maintenance The Edge Register is maintained as a living document. The Vendor Risk Analyst (or delegate) reviews each edge type quarterly: - New edges added within 30 days of discovery - Edges retired when the relationship, service, or path no longer exists - Control level re-assessed annually ### 5.2 Integration with CERG Procedures | Procedure | Edge Type | Integration | |-----------|-----------|-------------| | [TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor, SaaS, Software supply | Primary operational procedure for third-party edges | | [VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Network, Software supply | Exposure management feeds edge assessment | | [AC-002](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Identity, Vendor | Access reviews and privileged access management | | [AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | All | New services trigger edge registration during architecture review | | [IR Plan](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | All | SCCT activation when a vendor edge is compromised | ### 5.3 The Principle > **A program that knows its edge is less impressed by attack branding.** > > AI-powered attacks, supply-chain campaigns, and nation-state actors all exploit the same thing: an edge the organization didn't know it had, or didn't manage. The edge doesn't care about the attacker's tooling. It cares whether the path existed. --- ## 6. Document Control ### Revision History | Version | Date | Author | Change Summary | |---------|------|--------|---------------| | 1.0 | 2026-06 | CERG Governance | Initial release. Six edge types, edge management model, low-control operating model. | ### Review Triggers Annual review or upon: material change to vendor population, SaaS portfolio, network architecture, or regulatory scope. ### Related Documents | Document | ID | Relationship | |----------|-----|-------------| | TPRM Procedure | CERG-PRC-TPRM-001 | Operational implementation of vendor, SaaS, and software supply edges | | Access Management Standard | CERG-STD-AC-001 | Identity edge controls | | IT/Cloud/SaaS Security Standard | CERG-STD-IT-001 | SaaS and cloud edge controls | | Network Security Standard | CERG-STD-NET-001 | Network edge controls | | Secure Development Standard | CERG-STD-SDL-001 | Software supply edge controls | | Cross-Pillar Operational Flows | CERG-GOV-FLOW-001 | SCCT activation and edge compromise response | | Exposure Management Procedure | CERG-PRC-VM-001 | Exposure discovery feeds network and software supply edge assessment | --- > > _Know your edge. Manage it deliberately. Never be surprised._ --- _CERG-GOV-EDG-001 · Version 1.0 · PUBLIC_ --- ## FRAMEWORK SYSTEM MAP ### Front Door · Document Relationships · Adoption Navigation --- | | | |---|---| | **Document ID** | CERG-GOV-FRM-002 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Quarterly / Upon significant library structure change | | **Frameworks** | NIST CSF 2.0 (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adoption paths | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The CERG Spine](#2-the-cerg-spine) 3. [How the Library Fits Together](#3-how-the-library-fits-together) 4. [How Work Moves Through CERG](#4-how-work-moves-through-cerg) - 4.1 [How the three pillars interact during a single event](#41-how-the-three-pillars-interact-during-a-single-event) - 4.2 [When the three pillars collapse onto fewer people](#42-when-the-three-pillars-collapse-onto-fewer-people) 5. [Navigation by User Need](#5-navigation-by-user-need) 6. [Navigation by Adoption Path](#6-navigation-by-adoption-path) 7. [Navigation by Pillar](#7-navigation-by-pillar) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope CERG is intentionally complete. That completeness can make the first hour difficult for a new reader. This document is the map. It explains how the policy, framework, operating model, risk model, controls, standards, procedures, templates, records, evidence, metrics, and improvement loops relate to one another. It does not replace those documents. It tells the reader which document to open next and why. Use this document when: - A leader asks, "What is CERG?" - A new adopter asks, "Where do I start?" - A practitioner asks, "Which artifact owns this activity?" - A contributor asks, "Where does a proposed document belong?" - An auditor asks, "How do policy statements become evidence?" --- ## 2. The CERG Spine The CERG spine is the minimum chain that turns security intent into operating work. ```text Cybersecurity Policy -> CERG Framework -> CERG Operating Model -> Risk Management Framework -> Unified Control Baseline -> Standards -> Procedures and Plans -> Templates and Records -> Evidence -> Metrics and Oversight -> Program Improvement ``` | Layer | Primary artifact | What it answers | |---|---|---| | Policy | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) | What is always true? | | Framework | [CERG-GOV-FRM-001](CERG-GOV-FRM-001_CERG_Framework.md) | How is the program conceptually organized? | | Operating model | [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | Who owns the work and how do the pillars interact? | | Risk model | [CERG-GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) | How is risk categorized, scored, treated, accepted, and monitored? | | Control model | [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Which control expectations exist and what evidence supports them? | | Operating flows | [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | How does work move across Engineering, Risk, and Governance? | | Requirements | Standards in [`../standards/`](../standards/) | What requirements apply by domain? | | Execution | Procedures in [`../procedures/`](../procedures/) | How is the work performed? | | Records | [CERG-GOV-CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) | What records prove work happened? | | Evidence quality | [CERG-GOV-AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | What makes evidence reliable? | | Metrics | [CERG-GOV-MTR-001](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | How is posture reported and governed? | | Improvement | [CERG-GOV-IMPREG-001](CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | How does the program learn and change? | --- ## 3. How the Library Fits Together ### 3.1 Authority hierarchy | Level | Artifact type | Authority | Example | |---|---|---|---| | 1 | Policy | Executive / CISO | Cybersecurity Policy | | 2 | Governance instruments | CISO / Pillar Leaders | Framework, Operating Model, RMF, Control Baseline | | 3 | Standards | Governance Pillar Leader | Access, Cloud, OT, CUI, Logging, Endpoint | | 4 | Procedures | Pillar Owner | Exposure Management, TPRM, Architecture Review | | 5 | Plans and packages | Pillar Owner | IR Plan, CUI package, NERC-CIP package, SOX package | | 6 | Templates and records | Process Owner | Risk register, exception form, evidence worksheet | ### 3.2 Execution chain ```text Policy principle -> control objective -> standard requirement -> procedure step -> assigned role -> record created -> evidence stored -> metric updated -> oversight decision ``` If any link is missing, the program can still have activity, but it will not have an auditable operating loop. ### 3.3 Three-pillar accountability | Pillar | Primary question | Typical output | |---|---|---| | Cyber Engineering | How do we build and operate this securely? | Architecture decisions, baselines, secure patterns, remediations | | Cyber Risk | What exposure remains and what treatment is required? | Findings, risk records, vendor assessments, threat validation | | Cyber Governance | What rule, evidence, decision, or report governs this? | Standards, evidence records, metrics, audit packages, improvement actions | --- ## 4. How Work Moves Through CERG CERG work should not move by informal chat alone. It should move through one of the canonical flows in [FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md). | Flow | Use when | Primary output | |---|---|---| | F-01 Control Intent to Implementation | A policy, regulation, audit result, or risk decision needs implementation | Control implementation record | | F-02 Project Intake, Architecture Review, and Threat Modeling | A project, platform, application, SaaS, cloud workload, or OT change needs review | Project security review record | | F-03 Asset Registration and Coverage Validation | A new or changed asset enters scope | Asset coverage record | | F-04 Finding to Remediation, Exception, or Residual Risk | A vulnerability, audit finding, test result, or gap is found | Finding record, remediation record, exception, or risk acceptance | | F-05 Change and Release Security Routing | A change could alter security posture | Security change review record | | F-06 Incident to Recovery to Standards Feedback | An incident or exercise produces learning | Lessons learned record and improvement action | | F-07 Metrics, Oversight, and Improvement Routing | Metrics, maturity results, or oversight decisions require action | Program improvement record | ### 4.1 How the three pillars interact during a single event The three pillars are not three teams that vote on everything. They are three accountability lines that each own a distinct question. During a single event, each pillar does one thing and only one thing. | Pillar | Owns this question | Does this during an event | |---|---|---| | **Cyber Engineering** | How do we build and operate this securely? | Builds the remediation, runs the change, captures implementation evidence | | **Cyber Risk** | What exposure remains and what treatment is required? | Triages the finding, sets severity, runs the SLA clock, files the risk record or exception | | **Cyber Governance** | What rule, evidence, decision, or report governs this? | Confirms the SLA, indexes the evidence, updates the dashboard, routes to the right authority | A worked example: a critical vulnerability hits an internet-facing application server on a Tuesday morning. 1. **Risk** validates reachability, sets severity, opens the Finding Record, and starts the SLA clock. 2. **Engineering** owns the remediation: patch, configuration change, WAF rule, or service isolation. Engineering captures implementation evidence. 3. **Governance** confirms the SLA clock is correct, the evidence quality is acceptable, the dashboard reflects status, and any required escalation reaches the right authority. Governance does not run the patch. The handoffs are explicit. The records are explicit. The clock is explicit. No pillar holds the work hostage waiting for consensus. **For canonical worked examples, read the [Day in the Life stories](../examples/day-in-the-life/README.md).** They are the canonical reference for what each pillar does during a real event. Stories 2, 4, 5, 6, and 8 walk a single event from detection through closure and show the three-pillar handoff in motion. Stories 9 and 10 show how the pillars work together across time. ### 4.2 When the three pillars collapse onto fewer people In small teams (CERG Lite, 2-8 people), the three pillars collapse onto fewer heads. The collapse is intentional, documented in the Decision Log per [IMP-002 §4](../governance/CERG-GOV-IMP-002_Adoption_Safety_Guide.md#4-the-decision-log), and follows the [role consolidation map in IMP-003 §4](../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md#4-role-consolidation-map). The questions do not collapse, only the heads. Risk still triages. Engineering still builds. Governance still routes. One person may answer all three questions in a single hour, but the questions remain distinct. Story 8 ([CERG Lite - Maria and the Tuesday scanner report](../examples/day-in-the-life/story-8-cerg-lite-maria.md)) is the canonical worked example of the collapse pattern. --- ## 5. Navigation by User Need | If you need to... | Start with | Then use | |---|---|---| | Explain CERG to executives | This document and [FRM-001](CERG-GOV-FRM-001_CERG_Framework.md) | [MTR-001](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) board reporting sections | | Act as a Business Owner / System Sponsor | [IMP-007 §6](CERG-GOV-IMP-007_Role_Reader_Paths.md#6-business-owner--system-sponsor-reader-path) | [PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md), [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [TMPL-RM-004](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | | Adopt CERG for the first time | [START-HERE](../START-HERE.md) | [IMP-001](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md), [IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | | Run a small-team version | [IMP-003](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) | [IMP-006](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) | | Decide which documents apply | [IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | [VAR-001](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | | Know what records to create | [CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) | Procedure-specific templates | | Prepare for audit | [AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | [PRC-AUD-001](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md), operational package for the regulator | | Stand up risk management | [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) | [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), [TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | | Start exposure management | [PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) | | Defer an OT/BES patch or exposure treatment | [PRC-VM-001 §7.4](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md#74-otbes-patch-deferral-routing) | [STD-OT-001 §11](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md#11-exceptions-and-escalation), [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | Review a new system or SaaS | [PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | [TMPL-AR-001](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md), [PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | Show how CERG runs in practice | [Day in the Life examples](../examples/day-in-the-life/README.md) | [FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md), [OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | | Onboard a new team member | [Day in the Life examples](../examples/day-in-the-life/README.md), [ONB-001](CERG-GOV-ONB-001_Onboarding_and_Integration_Program.md) | [RAC-001](CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | | Take on a CERG role for the first time | [Role Reader Paths](CERG-GOV-IMP-007_Role_Reader_Paths.md) | [IMP-006](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) (action list, after reading) | | Look up a CERG term or record type | [CERG Glossary](CERG-GOV-GEN-001_CERG_Glossary.md) | [FLOW-001 §2](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#2-operating-principles) (origin of record type definitions) | --- ## 6. Navigation by Adoption Path ### 6.1 CERG Lite Use when the organization has a small security team or first security hire. The goal is to create a real operating spine without adopting every document. Start with: 1. Policy 2. Framework 3. Operating Model 4. Document Catalog 5. RMF 6. Risk Register and Exception Process 7. Risk Register Templates 8. Exposure Management Procedure 9. Record Catalog 10. Role-Based Implementation Checklists To see what this looks like in practice on a 2-8 person team, read the [CERG Lite day-in-the-life story](../examples/day-in-the-life/story-8-cerg-lite-maria.md). ### 6.2 CERG Standard Use when the organization has an existing security function and needs consistent operation. Add: - Core standards for access, assets, configuration, IT/cloud/SaaS, logging, endpoint, network, and resilience. - Architecture review and project intake. - Third-party and supply-chain risk. - Metrics and reporting. - Evidence quality and audit procedure. For worked examples of how the three pillars produce outcomes together, see the [Day in the Life examples](../examples/day-in-the-life/README.md) — Stories 1, 2, 3, 5, and 7 cover the most common Standard-team situations. ### 6.3 CERG Regulated Use when the organization has explicit regulatory obligations. Add the applicable package: | Obligation | Add | |---|---| | CUI / CMMC | CUI standard, CUI operational package, SSP, POA&M, evidence matrix | | NERC-CIP / OT | OT standard, NERC-CIP operational package, segmentation, logging, access, recovery | | SOX | SOX ITGC operational package, access/change/evidence controls | | ISO 27001 | ISO operational package, control baseline, SoA support | | Privacy | Privacy and data protection operational package, data governance standard | For regulator-facing walkthroughs, see the [Day in the Life examples](../examples/day-in-the-life/README.md) — Story 3 (audit request) and Story 6 (third-party incident notification) are written so a regulated audience can map them straight to their own audit and notification obligations. --- ## 7. Navigation by Pillar | Pillar | First documents to read | Operating artifacts to run | |---|---|---| | Engineering | [OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md), [FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md), relevant standards | Architecture intake, asset coverage, configuration baseline, remediation records | | Risk | [RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [TAX-001](CERG-GOV-TAX-001_Risk_Taxonomy.md), [FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) | Risk register, finding records, vendor assessments, threat validation records | | Governance | [POL-001](CERG-POL-001_Cybersecurity_Policy.md), [CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md), [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md), [AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | Evidence index, control implementation records, metrics dashboard, improvement register | | All three pillars working together | [Day in the Life examples](../examples/day-in-the-life/README.md) | [FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md), [OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | --- ## 8. Document Control | | | |---|---| | **Document ID** | CERG-GOV-FRM-002 | | **Version** | 1.2 | | **Status** | Approved | | **Approved By** | CISO | | **Owner** | Governance Pillar Leader | | **Next Review** | Quarterly / Upon significant library structure change | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.2 | 2026-06-18 | Governance Pillar Leader | Added navigation for Business Owner / System Sponsor reader path and decision artifacts. | | 1.1 | 2026-06-18 | Governance Pillar Leader | Added direct practitioner navigation for OT/BES patch and exposure-treatment deferral routing. | | 1.0 | 2026-06-13 | Governance Pillar Leader | Initial publication. Adds a front-door system map for CERG navigation, adoption, and document relationships. | ### Review Triggers - New top-level governance artifact. - Change to adoption paths. - Change to canonical cross-pillar flows. - New regulated operational package. - User feedback indicating navigation confusion. ### Related Documents - [CERG-GOV-FRM-001](CERG-GOV-FRM-001_CERG_Framework.md) - CERG Framework - [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) - Operating Model - [CERG-GOV-FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) - Cross-Pillar Operational Flows - [CERG-GOV-IMP-001](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) - Implementation and Adaptation Guide - [CERG-GOV-IMP-005](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) - Adoption Decision Tree and Dependency Matrix - [CERG-GOV-CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) - Record Catalog --- ## ROLE READER PATHS ### Sequenced Reading Orders for New CERG Roles · CISO, Risk Lead, Engineering Lead, Business Owner --- | | | |---|---| | **Document ID** | CERG-GOV-IMP-007 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / On adoption-architecture change | | **Frameworks** | NIST CSF 2.0 (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The Reader Path Format](#2-the-reader-path-format) 3. [CISO Reader Path](#3-ciso-reader-path) 4. [Risk Lead Reader Path](#4-risk-lead-reader-path) 5. [Engineering Lead Reader Path](#5-engineering-lead-reader-path) 6. [Business Owner / System Sponsor Reader Path](#6-business-owner--system-sponsor-reader-path) 7. [When to Skip the Path](#7-when-to-skip-the-path) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope CERG is intentionally complete. That completeness can make the first hour difficult for a new reader. This document is the antidote. Each section below is a sequenced reading order for a specific role. The order is chosen because each document in the sequence builds on the previous one. Total time for the CISO path is approximately 35 minutes. Total time for the Risk and Engineering paths is approximately 30 minutes each. Use this document when: - A new CISO, Risk Lead, Engineering Lead, Business Owner, or System Sponsor joins a team that has adopted CERG. - An existing leader takes on a new CERG role or accountable business-owner role for the first time. - An executive sponsor wants to understand what the leader they hired will be reading. This document does not replace the documents it points at. It tells the reader which document to open next and why. ## 2. The Reader Path Format Each reader path follows the same format: | Field | Meaning | |---|---| | **Read time** | Approximate minutes for the focused reader | | **Goal** | What the reader should be able to do or say after finishing | | **Sequence** | Documents in the order to read them, with a one-line reason before each | | **Skip if** | Conditions under which a step can be omitted | | **After the path** | What to do once the sequence is complete | The reader path is a reading list, not an action list. For action items, see the role-based implementation checklists ([`CERG-GOV-IMP-006`](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md)). For the adoption-mode selection that determines which reader path is relevant, see [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md). ## 3. CISO Reader Path **Read time:** 35 minutes. **Goal:** You can explain the CERG program to a board member in five minutes, name the three pillars and what each one owns, identify your adoption mode (Lite, Standard, Regulated), and produce your first quarterly oversight checklist. **Sequence:** | # | Document | Time | Why this comes next | |---|----------|------|---------------------| | 1 | [`README.md`](../README.md) | 5 min | Establishes what CERG is and what it is not. The mission statement, the three pillars, and the link to [START-HERE.md](../START-HERE.md). | | 2 | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) | 5 min | The narrative Framework. Explains the conceptual organization: principles, three pillars, operating layers, value driver maturity. | | 3 | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §6 only | 5 min | Role consolidation for small teams. If you are CERG Lite, §6 tells you which canonical roles collapse onto which people. If you are Standard or Regulated, skim §6 to understand the consolidation logic and then move on. | | 4 | [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) | 5 min | The system map. Front door for the rest of the library. Use it as a navigation reference, not a cover-to-cover read. | | 5 | [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | 5 min | The decision tree and dependency matrix. Pick your adoption mode (Lite, Standard, Regulated) and learn what must be adopted together. | | 6 | [`CERG-GOV-IMP-006`](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) §3 | 5 min | The CISO checklist at 48 hours, 30 days, and 90 days. This is your action list once the reading is done. | | 7 | [Day in the Life Story 10](../examples/day-in-the-life/story-10-new-ciso-90-days.md) | 5 min | A worked example: another new CISO's first 90 days. Read this last, when the framework is in your head, to see it all in motion. | **Skip if:** - You have held a CISO role at a CERG-adopting organization before. Skip step 7 and read steps 1-6 only. - You are CERG Lite with fewer than 5 people. Spend the OM-001 time on the consolidation map (step 3) and the Small Team Adoption Path ([`CERG-GOV-IMP-003`](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md)) instead of the Operating Model detail. **After the path:** 1. Run [`CERG-GOV-IMP-006`](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) §3.1 (First 48 hours) immediately. The reader path is preparation, not a substitute. 2. Schedule the first 30-day review (step §3.2) before the 30th day. 3. Bookmark [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) for the duration of your tenure. It is the navigation reference. 4. Add the [Day in the Life stories](../examples/day-in-the-life/README.md) to your onboarding checklist for future new hires on your team. ## 4. Risk Lead Reader Path **Read time:** 30 minutes. **Goal:** You can name the risk pillar's scope (exposure management, threat intelligence, threat modeling, adversarial validation, vendor risk), describe the canonical cross-pillar flows, and triage a critical finding from intake to closure. **Sequence:** | # | Document | Time | Why this comes next | |---|----------|------|---------------------| | 1 | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §3-4 | 5 min | Risk pillar scope within the framework narrative. | | 2 | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) | 8 min | Risk taxonomy, scoring, treatment, acceptance, monitoring. The Risk pillar's parent governance instrument. | | 3 | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-04 | 5 min | The Finding to Remediation flow. The Risk pillar's most-used flow. Read the SLA and decision logic carefully. | | 4 | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | 5 min | The Exposure Management Procedure. Your operating procedure for vulnerability and finding work. | | 5 | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | 5 min | The TPRM Procedure. Your operating procedure for vendor risk. | | 6 | [Day in the Life Story 2](../examples/day-in-the-life/README.md#story-2-critical-vulnerability) | 2 min | A critical vulnerability walked end to end through F-04. Read this last, when the framework is in your head, to see it all in motion. | **Skip if:** - You have held a Risk Lead role at a CERG-adopting organization before. Skip step 6. **After the path:** 1. Open the risk register and the exposure backlog. Read both before the next weekly cadence. 2. Run the biweekly vulnerability SLA review per [`CERG-GOV-IMP-003`](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) §3. 3. Bookmark [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) §2 (Operating Principles) for reference. ## 5. Engineering Lead Reader Path **Read time:** 30 minutes. **Goal:** You can name the engineering pillar's scope (architecture review, asset coverage, configuration baseline, secure development, remediation), describe how a project goes through intake to disposition, and route a high-risk architecture review correctly. **Sequence:** | # | Document | Time | Why this comes next | |---|----------|------|---------------------| | 1 | [`CERG-GOV-FRM-001`](CERG-GOV-FRM-001_CERG_Framework.md) §3-4 | 5 min | Engineering pillar scope within the framework narrative. | | 2 | [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md) §4-5 | 5 min | Engineering pillar ownership of the consulting model and architecture review. | | 3 | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-02 | 5 min | The Project Intake, Architecture Review, and Threat Modeling flow. The Engineering pillar's most-used flow. Read the tier routing carefully. | | 4 | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | 5 min | The Architecture Review and Project Intake Procedure. Your operating procedure for project intake work. | | 5 | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | 5 min | The Secure Configuration Baseline (DISH). Your default hardening reference for new systems. | | 6 | [Day in the Life Story 1](../examples/day-in-the-life/README.md#story-1-new-saas-application) | 5 min | A new SaaS application walked through F-02 end to end. Read this last, when the framework is in your head, to see it all in motion. | **Skip if:** - You have held an Engineering Lead role at a CERG-adopting organization before. Skip step 6. **After the path:** 1. Open the architecture review queue and the asset coverage report. Read both before the next weekly cadence. 2. Run the weekly intake review per [`CERG-GOV-IMP-003`](CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) §3. 3. Bookmark the standards catalog ([`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) §5.3) for the standards you are most likely to apply this quarter. ## 6. Business Owner / System Sponsor Reader Path **Read time:** 25 minutes. **Goal:** You can explain what CERG expects from a business owner or system sponsor: own the business objective, provide scope and priority, fund or accept treatment decisions, approve go-live for your system, and understand that Security/Risk recommends while the business owns residual consequence. **Sequence:** | # | Document | Time | Why this comes next | |---|----------|------|---------------------| | 1 | [`README.md`](../README.md) | 4 min | Establishes what CERG is and what it is not. Business owners need the operating-model view, not the whole corpus. | | 2 | [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) §5 | 5 min | Shows where to go by user need: new system, risk decision, audit evidence, or exposure treatment. | | 3 | [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-02 and F-04 | 6 min | Shows how project intake and finding remediation move across Engineering, Risk, Governance, and the business owner. | | 4 | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) §§2, 5, and 9 | 5 min | Names the sponsor responsibilities for intake, go-live, handoff, and production ownership. | | 5 | [`CERG-GOV-RMF-001`](CERG-GOV-RMF-001_Risk_Management_Framework.md) §§9.5 and 9.7 | 3 min | Explains treatment recommendation versus business consequence acceptance. | | 6 | [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | 2 min | Shows what a residual-risk decision looks like when a business owner is asked to accept consequence. | **Skip if:** - You are only funding a one-time security project and do not own a system, business process, or residual risk decision. Read [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §3 instead. - You have already sponsored a CERG-governed system through intake, pre-production, and go-live. Use [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) §5 as your quick reference. **After the path:** 1. Confirm the named Business Owner / System Sponsor for each system or project you own. 2. For active projects, confirm whether [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) has been submitted and whether Phase 4/5 records are required. 3. For accepted risks, confirm the treatment owner, funding decision, expiration date, and next review date. ## 7. When to Skip the Path Reader paths are for new readers. Skip them if: - You are the **executive sponsor** and do not own a system, project, or residual-risk decision. Read [README.md](../README.md), [START-HERE.md](../START-HERE.md) Path selection, and [`CERG-GOV-MTR-001`](CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §3 (Board Reporting). Total time: 15 minutes. - You are a **program-level contributor** (auditor, consultant, advisor). Read [README.md](../README.md), [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md), and one Day in the Life story relevant to your engagement. Total time: 20 minutes. - You have **already adopted CERG and run it for six months or more**. Use [`CERG-GOV-CAT-001`](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) §5 as your reference, not the reader path. The reader paths are designed for the first hour of engagement. They are not a substitute for the operating rhythm that follows. ## 8. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-IMP-007 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-18 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / On adoption-architecture change | | **Next Scheduled Review** | 2027-06-18 | | **Frameworks** | NIST CSF 2.0 (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | All CERG adopters | ### Revision History | **Version** | **Date** | **Author** | **Change** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader (Policy & Standards) | Added Business Owner / System Sponsor reader path focused on project sponsorship, go-live ownership, and residual-risk consequence decisions. | | 1.0 | 2026-06-18 | Governance Pillar Leader (Policy & Standards) | Initial publication. Establishes sequenced reading orders for the CISO, Risk Lead, and Engineering Lead roles. Each path totals 30-35 minutes and points at the documents the new reader needs in the order each builds on the previous. | ### Review Triggers - A change to the role consolidation map in [`CERG-GOV-OM-001`](CERG-GOV-OM-001_CERG_Operating_Model.md). - A change to the canonical cross-pillar flows in [`CERG-GOV-FLOW-001`](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md). - A new role added to the workforce architecture in [`roles/`](../roles/) that warrants its own reader path. - A material change to adoption sequencing in [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) or [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md). - User feedback indicating the path is too long, too short, missing a business-owner decision point, or in the wrong order. ### Related Documents - [`CERG-GOV-IMP-001`](CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) - Implementation and Adaptation Guide - [`CERG-GOV-IMP-005`](CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) - Adoption Decision Tree and Dependency Matrix - [`CERG-GOV-IMP-006`](CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) - Role-Based Implementation Checklists (action lists) - [`CERG-GOV-FRM-002`](CERG-GOV-FRM-002_Framework_System_Map.md) - Framework System Map (navigation reference) - [`README.md`](../README.md) - Top-level project README - [`START-HERE.md`](../START-HERE.md) - First-48-hours adoption guide - [`examples/day-in-the-life/`](../examples/day-in-the-life/README.md) - Worked examples referenced from each reader path --- ## STAKEHOLDER PERCEPTION SURVEY ### Survey Instrument · Administration Cadence · Analysis · Program Integration --- | | | |---|---| | **Document ID** | CERG-TMPL-GOV-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-PRC-LL-001`](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) · [`CERG-GOV-IMPREG-001`](../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | | **Review Cycle** | Annual / After administration cycle | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Why Measure Perception](#2-why-measure-perception) 3. [Survey Instrument](#3-survey-instrument) 4. [Administration](#4-administration) 5. [Analysis and Reporting](#5-analysis-and-reporting) 6. [Program Integration](#6-program-integration) 7. [Document Control](#7-document-control) --- ## 1. Purpose and Scope The CERG Framework (FRM-001 Section 6.1) states that at Adaptive maturity, "The business views security as a value driver, not a cost center." Section 6.2 lists "Cybersecurity is viewed as a value driver" as an Adaptive criterion, backed by "Engineering's consulting model and yes-and Governance orientation." This is a cultural claim that requires evidence. An assessor cannot verify stakeholder perception without a measurement instrument. This survey template provides the instrument, the administration cadence, and the analysis framework. This survey is administered to business stakeholders who interact with CERG: project managers, business unit leaders, IT and OT operations managers, procurement leads, and any role that has been through a CERG engagement in the assessment period. > **The Value-Driver Test** > > An assessor asks a business unit leader: "Does security help you move faster or slower?" If the answer is "slower," the program has an Adaptive gap regardless of its control maturity. An Adaptive program proves it is a value driver by measuring whether the business agrees. --- ## 2. Why Measure Perception A program that does not measure stakeholder perception is guessing about its most important relationship. Five reasons this survey matters: 1. **Governance mandate.** The Framework claims Adaptive organizations view security as a value driver. Without measurement, the claim is untestable. 2. **Engagement model feedback.** Engineering's consulting model and Governance's yes-and orientation are operational choices. The survey measures whether they are working. 3. **Early warning.** Declining perception scores precede declining engagement, which precedes shadow IT, workarounds, and missed security reviews. 4. **Assessor evidence.** "The business views security as a value driver" requires evidence. A declining or neutral survey trend is evidence of the opposite. 5. **Improvement driver.** Open-ended feedback reveals what the program should start, stop, or continue doing, in the stakeholder's own words. --- ## 3. Survey Instrument ### 3.1 Target Respondents The survey is administered to business stakeholders who have interacted with CERG in the assessment period (trailing 12 months for annual survey; trailing project period for post-project survey). Minimum respondent set: - Project managers for projects that went through architecture review - Business unit leaders or product owners whose teams were engaged by Engineering - IT and OT operations managers who interact with Risk (VM, adversarial, TPRM) - Procurement or vendor-management leads who worked with TPRM - Any role that submitted an exception request or risk acceptance ### 3.2 Survey Questions Each question uses a 5-point Likert scale: Strongly Agree (5), Agree (4), Neutral (3), Disagree (2), Strongly Disagree (1). | # | Question | What It Measures | |---|---|---| | 1 | Security engaged early enough to influence the project outcome. | Engineering intake timeliness | | 2 | The security review added value beyond checking a compliance box. | Perceived value of engagement | | 3 | Security requirements were clear and actionable : I knew what to do. | Quality of guidance | | 4 | The yes-and approach was evident : we got to yes with guardrails rather than a flat no. | Governance orientation | | 5 | I would proactively engage security on my next project. | Willingness to re-engage (the ultimate value test) | | 6 | Security understood our business constraints and worked within them. | Business empathy and pragmatism | | 7 | The security engagement did not meaningfully delay our timeline. | Operational efficiency | ### 3.3 Open-Ended Questions | # | Question | What It Measures | |---|---|---| | 8 | What should security START doing that it does not do today? | Unmet needs | | 9 | What should security STOP doing that creates friction or adds no value? | Friction and waste | > The friction signal from this annual survey is paired with the continuous CERG service-responsiveness metrics (SR-001 through SR-005) defined in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) and the published commitments in [`CERG-GOV-SLC-001`](../governance/CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md), so friction is caught monthly (quantitative), not only once a year (qualitative). | 10 | What should security CONTINUE doing that works well? | Strengths to preserve | | 11 | Any other feedback you want the CISO to hear. | Unprompted signal | ### 3.4 Administration Options The survey may be administered in any format that preserves anonymity (respondents must feel safe giving honest feedback): - Survey platform (preferred): online form, anonymous by default - Paper form: for OT or field environments where online access is limited - Structured interview: Governance Pillar Leader or a neutral third party conducts the interview; responses are recorded without attribution The minimum viable instrument is a shared anonymous form. The template above is the content; the platform is the adopter's choice. --- ## 4. Administration ### 4.1 Cadence | Trigger | Respondents | Purpose | |---|---|---| | **Annual** | All stakeholders who interacted with CERG in the trailing 12 months | Trend measurement; program-health indicator | | **Post-major-project** | Project team for projects exceeding a defined threshold (budget, risk, or regulatory scope) | Engagement-quality feedback while the experience is fresh | The annual survey is administered in Q4 so results are available for the annual program review and the next year's planning cycle. ### 4.2 Administration Rules 1. **Anonymity is mandatory.** Responses must not be attributable to individuals. If the organization is too small for anonymity (fewer than 10 respondents), use a neutral third party to administer. 2. **The CISO is copied on results, not raw responses.** The Governance Pillar Leader administers, analyzes, and reports. Individual responses are not shared, even with the CISO. 3. **Minimum response threshold.** If fewer than 10 responses are received for the annual survey, the results are reported as directional only and the low response rate is itself a finding (why are stakeholders not engaging?). 4. **Do not survey during an active incident or audit.** Survey fatigue and contextual noise distort results. --- ## 5. Analysis and Reporting ### 5.1 Scoring - Each Likert question is scored 1-5. The overall perception score is the mean across all Likert questions. - Scores are trended year-over-year. A single-year score is nearly useless; the trend tells the story. - Any question with a mean score below 3.0 (Neutral) triggers a program review. ### 5.2 Open-Ended Analysis Open-ended responses are analyzed for themes. The Governance Pillar Leader groups responses into themes and counts them. A theme that appears in three or more responses is flagged for program review. A theme that appears across both "START doing" and "STOP doing" suggests a known pain point. ### 5.3 Reporting The annual survey produces a Stakeholder Perception Report, included in the CISO's annual program review package. It contains: - Overall perception score (mean), with year-over-year trend - Question-level scores with trend - Any question scoring below 3.0 with recommended action - Top 3 "START," "STOP," and "CONTINUE" themes from open-ended responses - Response rate and respondent demographics (role categories, not individuals) - Comparison to the CISO dashboard: does the perception trend align with or contradict the metric trends? --- ## 6. Program Integration ### 6.1 Metrics Dashboard The overall perception score is reported as a program-health indicator alongside the risk and compliance metrics in MTR-001: | ID | Name | Formula | Source | Refresh | G / A / R | Reported In | |---|---|---|---|---|---|---| | PH-001 | Stakeholder Perception Score | Mean of Q1-Q7 Likert scores | Annual survey | Annual | >= 4.0 / 3.0-4.0 / < 3.0 | CISO Dashboard (annual report) | | PH-002 | Re-Engagement Willingness | Mean of Q5 ("I would proactively engage security") | Annual survey | Annual | >= 4.0 / 3.0-4.0 / < 3.0 | CISO Dashboard | ### 6.2 Lessons Learned Open-ended feedback themes are an intake source for the Lessons Learned procedure (PRC-LL-001). A recurring theme of "security takes too long" or "requirements were unclear" is a lesson that must be addressed through the program improvement pipeline. ### 6.3 Improvement Register When a perception score decline or an open-ended theme triggers a program change, the change is recorded in the improvement register (IMPREG-001) with the source "Stakeholder Perception Survey YYYY." --- ## 7. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-GOV-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / After each survey administration cycle | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST CSF 2.0 (GOVERN: Organizational Context) | | **Regulations** | Cross-cutting | | **Environments** | Program-wide | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-26 | Cyber Governance | Initial draft. Established the stakeholder perception survey instrument: 7 Likert-scale questions, 4 open-ended questions, annual and post-project administration cadence, analysis and reporting framework, and integration with MTR-001 metrics, lessons learned, and the improvement register. Addresses NIST CSF Adaptive gap: measuring whether the business views security as a value driver. | --- ## The CERG Framework ### A Scalable, Adaptive Cybersecurity Operating Model > Designed for Adaptive [NIST CSF 2.0](https://www.nist.gov/cyberframework) maturity. Applicable to IT and OT environments. Calibrated for [CMMC](https://dodcio.defense.gov/CMMC/), NERC-CIP, and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204). > > _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/`](../examples/). See also [`CERG-GOV-VAR-001`](CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) for mechanical adaptation._ --- | | | |---|---| | **Document ID** | CERG-GOV-FRM-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CISO | | **Parent Policy** | [`CERG-POL-001`](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to framework | | **Frameworks** | NIST CSF 2.0; NIST 800-53r5; NIST 800-171r3; NIST RMF | | **Regulations** | NERC-CIP; CMMC L2; SOX ITGC | | **Environments** | All in-scope environments | --- ## Table of Contents 1. [Executive Summary](#1-executive-summary) 2. [The CERG Operating Model](#2-the-cerg-operating-model) 3. [Capability Taxonomy: What CERG Builds](#3-capability-taxonomy-what-cerg-builds) 4. [Cyber Engineering](#4-cyber-engineering) 5. [Cyber Risk](#5-cyber-risk) 6. [Cyber Governance](#6-cyber-governance) 7. [Targeting NIST CSF Adaptive Maturity](#7-targeting-nist-csf-20-adaptive-maturity) 8. [Regulatory Alignment](#8-regulatory-alignment) 9. [IT/OT Considerations](#9-itot-considerations) 10. [Team Structure and Talent Model](#10-team-structure-and-talent-model) 11. [Getting Started, The Path to Adaptive](#11-getting-started-the-path-to-adaptive) 12. [Compliance as Exhaust — Evidence Factories](#12-compliance-as-exhaust-evidence-factories) 13. [Document Control](#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](https://dodcio.defense.gov/CMMC/), NERC-CIP, [NIST CSF 2.0](https://www.nist.gov/cyberframework), 800-53, 800-171, and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) - **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](https://www.nist.gov/cyberframework) 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: |Function|Teams / Scope| |---|---| |**CERG**|Engineering · Risk · Governance| |**Security Awareness**|Training programs · Phishing simulations · Culture campaigns| |**Incident Response**|SOC / detection · Threat hunting · IR planning & execution| |**CISO**|Strategy & vision · Executive & board reporting · Budget & resource authority| > **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. |Lifecycle Stage|Primary Pillar|Supporting Pillars| |---|---|---| |Business requirement / new project|Engineering|Governance sets standards; Risk flags vendor/solution concerns| |Design and architecture review|Engineering|Risk performs threat modeling and vendor assessment| |Pre-production vulnerability scan|Risk|Engineering remediates findings pre-launch| |Risk acceptance (if vuln unresolvable)|Engineering + Risk|Governance provides risk treatment plan template; CISO/leadership signs off on High/Critical| |Production deployment|Engineering|Governance and Risk assume post-production monitoring| |Ongoing compliance monitoring|Governance|Risk tracks patch status and emerging CVEs; Engineering supports remediation| |Audit and evidence collection|Governance|Engineering and Risk produce artifacts from their daily work| |Adversarial validation: pen test / red team / purple team|Risk|Engineering reviews findings for architectural impact; Governance logs findings| |Regulatory exam or audit|Governance|All pillars provide evidence; Engineering and Risk support responses| --- ## 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. | ID | Capability | Primary Owner | Anchors | Evidence | Validation Method | |---|---|---|---|---|---| | CAP-ENG-SECIN-001 | Secure systems are reviewed before production go-live. | Cyber Engineering | [PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md), [PRC-TM-001](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md), [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) SA controls | Architecture review record, threat model record, pre-production checklist, risk acceptance package when needed | Quarterly sample of project records and go-live decisions | | CAP-ENG-CONFIG-001 | Approved configuration baselines are implemented and drift is detected. | Cyber Engineering | [STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md), [STD-AM-001](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md), [PRC-CHG-001](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) | Baseline record, asset coverage report, drift finding, change record | Automated configuration scan and quarterly drift review | | CAP-ENG-RES-001 | Critical systems can be restored within defined recovery expectations. | Cyber Engineering + IR / BCDR | [STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md), [PLN-BC-001](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md), [PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Backup evidence, restore test record, DR exercise package, recovery gap report | Restore test and DR exercise cadence by recovery tier | | CAP-RSK-EXP-001 | Critical and High exposure is triaged, treated, or accepted within defined SLAs. | Cyber Risk | [PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md), [GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Finding record, SLA report, treatment plan, risk acceptance or exception record | Monthly SLA review and quarterly risk-register sample | | CAP-RSK-ADV-001 | Controls are validated under adversary-like conditions. | Cyber Risk | [PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md), [STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), [GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) CA-8 | Rules of engagement, engagement report, detection validation results, retest evidence | Annual adversarial validation plan with pen test, red-team, purple-team, cloud, application, or OT-safe activities as in scope | | CAP-RSK-DET-001 | Required telemetry and detections cover priority attack paths. | Cyber Risk + Incident Response | [STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), [PRC-TI-001](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md), [PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Detection coverage record, source inventory, tuning record, ATT&CK coverage gap | Purple-team validation or automated adversary emulation | | CAP-RSK-TPRM-001 | Third-party and supply-chain risk is tiered, evidenced, and tracked. | Cyber Risk | [PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md), [GOV-EDG-001](CERG-GOV-EDG-001_Edge_Register.md), [CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) SR controls | Vendor assessment record, tiering record, contract clauses, shared-responsibility matrix | Vendor sample review and critical-vendor refresh cadence | | CAP-GOV-RISK-001 | Risk decisions are recorded with owners, treatment, authority, and review dates. | Cyber Governance | [GOV-RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md), [PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), [TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Risk record, acceptance memo, exception record, review history | Monthly register review and overdue-risk escalation | | CAP-GOV-EVID-001 | Control evidence is complete, organized, attributable, and retrievable. | Cyber Governance | [PRC-AUD-001](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md), [GOV-AUD-001](CERG-GOV-AUD-001_Evidence_Quality_Standard.md), [GOV-CAT-002](CERG-GOV-CAT-002_Record_Catalog.md) | Evidence index, evidence quality score, retrieval log, audit request package | Unannounced evidence spot-check by control family | | CAP-GOV-REG-001 | Regulated scopes are mapped once and operated through normal CERG workflows. | Cyber Governance | [PLN-CIP-001](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md), [PLN-CUI-001](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md), [PLN-SOX-001](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md), [GOV-CMX-001](CERG-GOV-CMX-001_Compliance_Matrix.md) | Scope record, control mapping, evidence calendar, POA&M or deviation record | Regulatory calendar review and evidence-package sample | | CAP-XPN-IR-READY-001 | CERG can support incident response with asset, exposure, evidence, and recovery context. | Cross-pillar + standing IR team | [PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md), [PRC-IR-002](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md), [PRC-LL-001](../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) | Incident action log, asset context package, exposure summary, lessons-learned record | Tabletop or functional exercise with CERG liaison participation | ### 3.3 Capability Maturity Grading Capability maturity is scored by evidence and validation, not by whether a document exists. | Level | Label | Operational Meaning | |---|---|---| | 1 | **Absent** | No documented capability, named owner, evidence chain, or test. Work is ad hoc or absent. | | 2 | **Ad Hoc** | Practice exists but varies by person or team. Evidence is partial, inconsistent, or not independently verifiable. | | 3 | **Defined** | Capability is documented, owned, and produces named evidence. It has been tested or sampled at least once in the past 12 months. | | 4 | **Repeatable** | Capability operates consistently across its intended scope. Evidence is complete, retrievable, and reviewed on a defined cadence. Findings drive tracked improvement. | | 5 | **Adaptive** | Capability improves from threat intelligence, incidents, exercises, adversarial validation, and operational metrics. Automation or continuous validation reduces manual effort. | 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](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) 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. |Element|Description| |---|---| |Intake|Engineers are engaged via a lightweight request - a brief summary of the project, timeline, and primary contact. No complex ticketing or lengthy intake forms.| |Assignment|Each engagement is assigned a lead engineer. On large projects, multiple engineers may be assigned. Engineers manage their own capacity with CISO visibility.| |Engagement scope|Engineers work alongside project teams, not above them. They advise, review, and recommend - the project team retains implementation accountability.| |Pre-production gate|Before any system or tool goes live, Engineering confirms that open vulnerabilities have been remediated or formally risk-accepted. This is a lightweight confirmation, not a gate that stops work.| |Handoff documentation|At production cutover, Engineering produces or confirms existence of: asset registration, configuration baseline, control mapping, and any open risk items.| |Post-production|Once a system is in production, Engineering moves to the next project. Risk and Governance assume ongoing oversight. Engineering may be re-engaged for significant changes.| ### 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 |NIST Framework|Relevant Controls / Functions|Engineering Role| |---|---|---| |[NIST CSF 2.0](https://www.nist.gov/cyberframework)|GOVERN, IDENTIFY (Asset Mgmt, Risk Assessment), PROTECT (Identity Mgmt, Data Security, Platform Security)|Primary driver of PROTECT function; co-owner of IDENTIFY| |[NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)|SA (System & Services Acquisition), CM (Configuration Mgmt), SI (System & Info Integrity)|Implements SA and CM controls during project delivery| |[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)|3.13 System & Communications Protection, 3.14 System & Info Integrity|Ensures CUI protection controls are designed into systems handling federal data| |NIST RMF|Steps 2 (Select), 3 (Implement), 4 (Assess - pre-production)|Leads control selection and implementation; supports pre-production assessment| |NERC-CIP|CIP-005 (Electronic Security Perimeters), CIP-007 (Systems Security Mgmt), CIP-010 (Config Mgmt)|Designs systems to conform to CIP requirements from the start| |[CMMC](https://dodcio.defense.gov/CMMC/)|Level 2: Access Control, Configuration Mgmt, Identification & Auth|Ensures [CMMC](https://dodcio.defense.gov/CMMC/) practices are implemented in applicable systems| --- ## 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. |Finding Type|Handling| |---|---| |Pre-production, Low/Medium severity|Engineering remediates with project team before go-live. Tracked to closure by Risk.| |Pre-production, High/Critical severity|Engineering and Risk jointly assess. If unremediated, a risk treatment plan is required with VP+ sign-off before go-live.| |Post-production, Low/Medium severity|Tracked in vulnerability register. Assigned to appropriate owner (IT/OT ops) with SLA. Governance monitors SLA compliance.| |Post-production, High/Critical severity|Escalated immediately. CISO notified. Risk treatment plan required. Engineering may be re-engaged for architectural remediation. NERC-CIP and [CMMC](https://dodcio.defense.gov/CMMC/) deviation processes invoked as applicable.| |Vendor/Third-party finding|Risk documents and includes in vendor risk register. Governance tracks contractual remediation commitments. Engineering consulted if architectural change is needed.| ### 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 |NIST Framework|Relevant Controls / Functions|Risk Team Role| |---|---|---| |[NIST CSF 2.0](https://www.nist.gov/cyberframework)|GOVERN (Risk Strategy), IDENTIFY (Risk Assessment, Improvement), DETECT (Adverse Event Analysis)|Primary driver of IDENTIFY and DETECT; co-owner of GOVERN risk functions| |[NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)|RA (Risk Assessment), CA (Assessment & Authorization), PM (Program Mgmt), SI-2 (Flaw Remediation)|Executes RA and CA controls; owns SI-2 for patch and vuln tracking| |[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)|3.11 Risk Assessment|Performs periodic assessments of CUI-handling environments| |NIST RMF|Step 4 (Assess), Step 6 (Monitor)|Primary executor of continuous monitoring; supports periodic assessments| |NERC-CIP|CIP-007 (Patch Mgmt), CIP-010 (Vuln Assessments), CIP-011 (Info Protection)|Manages CIP-007 patch tracking; conducts CIP-010 annual vuln assessments| |[CMMC](https://dodcio.defense.gov/CMMC/)|Level 2: Risk Assessment (RA), Audit & Accountability (AU)|Performs [CMMC](https://dodcio.defense.gov/CMMC/) risk assessments; supports audit log review program| --- ## 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](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), 800-171, [CSF](https://www.nist.gov/cyberframework), 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](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), 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](https://dodcio.defense.gov/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`](CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md)), so that a fast, safe yes is a measured obligation: a slow yes is a no the business routes around. |Situation|"Yes, And..." Response| |---|---| |Project team cannot patch within standard SLA|Yes, you can extend the patching window - and we need a risk treatment plan, documentation of affected systems, compensating controls, and VP sign-off within 5 business days.| |New SaaS tool handles CUI but lacks FedRAMP authorization|Yes, you can evaluate this vendor - and Risk needs to complete a vendor security assessment before procurement, and we'll need contractual security requirements in the agreement.| |OT team needs remote access to SCADA during maintenance window|Yes, remote access is possible - and it must route through the approved jump server, use MFA, be logged, and the session record retained per CIP-007.| |Business unit wants to skip architecture review to meet deadline|Yes, we can compress the review timeline - and Engineering must complete at minimum a 2-hour express review, and any open items become tracked exceptions with a remediation commitment.| |NERC-CIP deviation required for emergency maintenance|Yes, the deviation can proceed - and we'll invoke the CIP deviation process: document the circumstances, notify as required, implement compensating measures, and close the deviation within the regulatory window.| ### 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](https://dodcio.defense.gov/CMMC/) requires evidence available for assessment. ### 6.5 Illustrative Example: Electrical Utility > **Scenario: [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 Assessment Preparation** > > The utility has a contract with the Department of Energy that requires [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 compliance. Governance leads the preparation effort. They map all 110 [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 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 |NIST Framework|Relevant Controls / Functions|Governance Role| |---|---|---| |[NIST CSF 2.0](https://www.nist.gov/cyberframework)|GOVERN (all functions), IDENTIFY (Improvement), RESPOND (Improvements)|Primary owner of the GOVERN function across all six sub-functions| |[NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)|PL (Planning), PM (Program Mgmt), CA (Assessment), PS (Personnel Security)|Owns PL and PM control families; coordinates CA; sets PS standards| |[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)|3.12 Security Assessment, all documentation requirements|Manages 800-171 assessment readiness and documentation compliance| |NIST RMF|Step 1 (Categorize), Step 2 (Select - policy), Step 5 (Authorize), Step 6 (Monitor - compliance)|Leads categorization; co-leads authorization; owns compliance monitoring| |NERC-CIP|CIP-003 (Security Mgmt Controls), CIP-004 (Personnel Training), CIP-014 (Physical Security Policy)|Primary owner of CIP-003; coordinates CIP-004 with Awareness team; maintains all deviation records| |[CMMC](https://dodcio.defense.gov/CMMC/)|All documentation and evidence requirements across all domains|Manages assessment readiness, evidence collection, and C3PAO coordination| |[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC|IT General Controls documentation, change management evidence|Maintains ITGC control library; coordinates with external auditors| --- ## 7. Targeting [NIST CSF 2.0](https://www.nist.gov/cyberframework) 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. |[CSF](https://www.nist.gov/cyberframework) Tier|What It Looks Like in Practice| |---|---| |**Partial (Tier 1)**|Ad hoc processes. Risk decisions made reactively. Limited awareness of threats. No consistent policy or evidence collection.| |**Informed (Tier 2)**|Policies exist but are not consistently applied. Risk management happens in silos. Some awareness of threat environment. Inconsistent evidence.| |**Repeatable (Tier 3)**|Defined, documented, and practiced processes. Risk management is consistent. Compliance calendar exists. Evidence is collected systematically. Teams understand their roles.| |**Adaptive (Tier 4)**|Cybersecurity is integrated into organizational decision-making. Threat intelligence actively shapes priorities. Lessons learned drive continuous improvement. Risk appetite is clearly defined and applied. The business views security as a value driver, not a cost center.| ### 7.2 How CERG Produces Adaptive Behavior The CERG model is designed to produce Adaptive-tier behavior through its structure, not just its aspirations. |Adaptive Criterion|CERG Mechanism|Pillar(s)| |---|---|---| |Risk management is integrated into business decisions|Engineering engages at the business requirements stage - before designs are set or budgets committed. Security cost is a design input, not an afterthought.|Engineering| |Threat intelligence informs priorities|Risk maintains a live threat intelligence function including ICS/OT-specific sources. Intelligence is distributed to Engineering (design decisions), IR (detection), and Governance (policy updates).|Risk| |Lessons learned drive improvement|Post-incident reviews, penetration test retrospectives, and audit findings are tracked in the Governance risk register with assigned owners and improvement actions.|Governance, Risk| |Risk appetite is defined and applied consistently|Governance maintains a documented risk appetite and tolerance framework. The "yes, and..." model applies this consistently across all risk treatment decisions.|Governance| |Continuous improvement of the security program|Governance conducts periodic QA reviews of Engineering and Risk outputs. The CISO reviews CERG performance metrics quarterly.|Governance, All| |Cybersecurity is viewed as a value driver|Engineering's consulting model and "yes, and..." Governance orientation build organizational trust. The business experiences security as an enabler, not an obstacle.|All| |Cross-pillar knowledge transfer prevents single points of failure|CERG roles are designed with deliberate left-right knowledge sharing. Engineers learn Risk thinking; Risk analysts understand Governance requirements; Governance understands operational constraints.|All| ### 7.3 [CSF](https://www.nist.gov/cyberframework) Core Function Coverage The [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) Core consists of six functions. CERG provides primary or strong supporting ownership for all six. |[CSF](https://www.nist.gov/cyberframework) Function|Primary Owner|CERG Coverage| |---|---|---| |**GOVERN**|Governance|Governance owns the risk strategy, policy, roles, and accountability structures. Risk contributes risk appetite data. Engineering ensures operational compliance.| |**IDENTIFY**|Risk + Engineering|Risk owns asset, risk, and improvement identification. Engineering contributes asset documentation through project handoffs.| |**PROTECT**|Engineering|Engineering designs and implements protective controls. Governance sets the standard. Risk validates effectiveness through vuln management.| |**DETECT**|Risk + IR (adjacent)|Risk owns vuln and threat detection. Incident Response owns event detection and SOC. Risk feeds intelligence to IR.| |**RESPOND**|IR (adjacent) + Governance|IR leads response execution. Governance owns the playbook library and post-incident documentation. Risk provides threat context during incidents.| |**RECOVER**|IR (adjacent) + Governance|IR leads recovery. Governance manages lessons-learned documentation and improvement tracking. Engineering supports system restoration where architectural changes are needed.| --- ## 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. |CIP Standard|CERG Ownership and Application| |---|---| |**CIP-002:** BES Cyber System Categorization|Governance leads the annual categorization process. Engineering provides technical input on system connectivity and function. Risk validates the asset inventory.| |**CIP-003:** Security Management Controls|Governance owns all CIP-003 policies and senior manager approval processes. Risk provides threat context for policy updates.| |**CIP-004:** Personnel & Training|Governance sets training requirements and coordinates with the Security Awareness team for delivery. Engineering and Risk fulfill their own training obligations.| |**CIP-005:** Electronic Security Perimeters|Engineering designs and implements ESPs and EAPs. Governance maintains ESP documentation. Risk validates perimeter integrity through scanning.| |**CIP-006:** Physical Security|Governance maintains physical security policy. Engineering reviews physical security requirements for new OT deployments.| |**CIP-007:** Systems Security Management|Risk owns patch management tracking and vulnerability assessment. Engineering implements port/service controls during deployment. Governance tracks compliance.| |**CIP-010:** Configuration Management & Vuln Assessments|Engineering produces and maintains configuration baselines. Risk performs CIP-010 annual vulnerability assessments. Governance retains assessment records.| |**CIP-011:** Information Protection|Governance defines BES Cyber System Information (BCSI) handling requirements. Engineering implements technical protections. Risk validates through scanning.| |**CIP-013:** Supply Chain Risk Management|Risk leads vendor risk assessment. Governance maintains the supply chain risk management plan. Engineering applies controls to vendor-supplied systems.| |**CIP-014:** Physical Security (Transmission)|Governance maintains risk assessment documentation. Engineering consults on physical-cyber interdependencies.| ### 8.2 [CMMC](https://dodcio.defense.gov/CMMC/): Cybersecurity Maturity Model Certification [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 requires implementation and assessment of all 110 practices in [NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final). For organizations handling Controlled Unclassified Information (CUI) on behalf of the federal government, [CMMC](https://dodcio.defense.gov/CMMC/) certification is a contract requirement. CERG provides the operational backbone for [CMMC](https://dodcio.defense.gov/CMMC/) compliance. - **Engineering** implements the technical controls across the 14 [CMMC](https://dodcio.defense.gov/CMMC/) domains, access control, configuration management, system and communications protection, and others, during project delivery - **Risk** performs the periodic assessments required by [CMMC](https://dodcio.defense.gov/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](https://www.govinfo.gov/app/details/PLAW-107publ204) For organizations subject to [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC requirements, CERG provides the structural foundation for compliance without requiring a separate compliance team. - **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) 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](https://dodcio.defense.gov/CMMC/), and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) 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: |Role|Pillar|Key Responsibilities| |---|---|---| |CISO|Executive|Strategy, CERG leadership, board and executive reporting, regulatory escalation, budget authority| |Engineering Pillar Leader|Engineering|Engagement portfolio oversight; vertical alignment model; OT/IT convergence program lead; senior architecture decisions; team development| |Senior Cyber Engineer - OT/ICS (×3)|Engineering|Generation, transmission, and distribution vertical leads; SCADA and substation security architecture; CIP-005/CIP-010 design consultation; OT modernization advisory| |Senior Cyber Engineer - IT/Cloud (×3)|Engineering|Enterprise IT and cloud vertical leads; application and infrastructure security architecture; identity and access design; pre-production assessment leadership| |Cyber Engineer (×8)|Engineering|Project-level security consultation across assigned verticals; pre-production coordination with Risk; vendor solution review; risk treatment plan drafting; handoff documentation| |Risk Pillar Leader|Risk|Program ownership across vuln management, adversarial validation, threat intel, and vendor risk; OT risk strategy; executive risk reporting| |Senior Risk Analyst - Exposure Management (×3)|Risk|Enterprise vuln scan operations; OT-safe scanning program; finding prioritization and triage; SLA tracking and escalation; remediation verification| |Threat Intelligence Analyst (×2)|Risk|Threat actor tracking; ICS/OT-specific intelligence production; E-ISAC and ICS-CERT liaison; intelligence distribution to Engineering and IR| |Senior Risk Analyst - Vendor & Third-Party Risk (×2)|Risk|Vendor security assessment program; contractor access risk; contract redline support; supply chain risk reporting| |Risk Analyst - Adversarial Testing (×3)|Risk|Internal pen test execution; external red team coordination; purple-team support; OT adversarial testing; findings documentation and tracking| |Risk Analyst (×5)|Risk|Day-to-day vuln tracking and owner follow-up; vendor assessment support; threat feed monitoring; finding remediation documentation| |Governance Pillar Leader|Governance|Policy and standard ownership; NERC-CIP compliance program leadership; regulatory and audit liaison; risk register governance; Governance team development| |NERC-CIP Compliance Manager (×3)|Governance|BES Cyber System compliance; CIP deviation and mitigation management; NERC-CIP evidence library; regulatory exam coordination; reliability-security interface| |Senior Governance Analyst - Technical Domains (×4)|Governance|Domain SME coverage across network security, IAM, cloud, and cryptography; implementation guidance production; standard development; Engineering QA reviews| |CMMC / Federal Compliance Manager (×3)|Governance|[CMMC](https://dodcio.defense.gov/CMMC/) SSP and POA&M management; 800-171 control tracking; C3PAO coordination; federal contract compliance calendar| |Governance / Compliance Analyst - Commercial Frameworks (×3)|Governance|and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC compliance; external audit coordination; evidence collection and library management; compliance calendar| |Policy & Standards Manager (×3)|Governance|Policy and procedure documentation; version control and review cycles; cross-pillar QA reviews; training content support for Security Awareness| 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 |Interaction|Description| |---|---| |CERG → Security Awareness|Governance provides policy and procedure content for awareness training. Risk provides threat intelligence for targeted awareness campaigns (e.g., spear-phishing scenarios relevant to ICS/OT). Engineering feeds real-world examples from project work into training scenarios.| |CERG → Incident Response|Risk provides threat intelligence and vulnerability context during incidents. Engineering provides architecture and configuration documentation to support containment and recovery. Governance provides playbooks and manages post-incident documentation.| |Security Awareness → CERG|Awareness provides metrics on training completion and phishing simulation results - inputs for Governance's compliance tracking and risk register.| |Incident Response → CERG|IR provides post-incident findings and lessons learned - inputs for Risk (threat landscape updates), Engineering (architectural improvements), and Governance (policy and playbook updates).| --- ## 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](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) 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](https://dodcio.defense.gov/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](https://dodcio.defense.gov/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: | Operational Work | Evidence Produced | Compliance Consumers | |-----------------|-------------------|---------------------| | Architecture review ([AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md)) | Design decision, data flow, control scope, pre-approved pattern match | NIST 800-53 (SA/PL), CMMC (SC), SOX ITGC, NERC-CIP CIP-005/010 | | Exposure management ([VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)) | Finding state, exposure classification, treatment, verification | NIST 800-53 (RA/SI), CMMC (RA), NERC-CIP CIP-007, SOX ITGC | | SaaS onboarding ([TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md)) | Shared responsibility matrix, vendor evidence, contract clauses, SSPM posture | CMMC (SR), SOX ITGC, privacy regulations, NERC-CIP CIP-013 | | Access review ([AC-002](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md)) | Population reviewed, reviewer, exceptions, recertification status | SOX ITGC, CMMC (AC), NERC-CIP CIP-004 | | Change security routing ([FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-05) | Impact analysis, approval, test result, CAB record | SOX ITGC, NERC-CIP CIP-010, NIST 800-53 (CM) | | Risk acceptance ([RMF-001](CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7) | Risk assessment, compensating controls, business owner acceptance | NIST 800-53 (RA), CMMC (RM), NERC-CIP deviation process | | Incident response ([IR Plan](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md)) | Timeline, investigation, lessons learned, corrective actions | NIST 800-53 (IR), CMMC (IR), NERC-CIP CIP-008 | | Asset registration ([FLOW-001](CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) F-03) | Owner confirmed, classification, coverage validated | NIST 800-53 (CM-8), CMMC (AM), NERC-CIP CIP-002 | 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](CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) maps each evidence factory to its production cadence. ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-FRM-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CISO | | **Parent Policy** | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to framework | | **Next Scheduled Review** | 2027-05-01 | | **Frameworks** | NIST CSF 2.0; NIST 800-53r5; NIST 800-171r3; NIST RMF | | **Regulations** | NERC-CIP; CMMC L2; SOX ITGC | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-01 | CISO + Cyber Governance | Initial release. Narrative description of the CERG framework, pillars, and operating model. | | 1.21 | 2026-05-22 | Cyber Governance | Updated framework references and pillar descriptions. | | 1.22 | 2026-06-24 | CISO + Cyber Governance | Added capability taxonomy, capability reference set, maturity grading, and evidence-factory linkage. | ### Review Triggers - Material change to CERG structure or operating model - Framework version change - Direction from the CISO or executive leadership ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [CERG-GOV-OM-001](CERG-GOV-OM-001_CERG_Operating_Model.md) | Operating model detail | | Document Catalog | [CERG-GOV-CAT-001](CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Master document inventory | | Unified Control Baseline | [CERG-GOV-CB-001](CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control spine | | Implementation Cards | [CERG-GOV-IMP-004](CERG-GOV-IMP-004_Implementation_Cards.md) | Intent-to-implementation guidance | | Edge Register | [CERG-GOV-EDG-001](CERG-GOV-EDG-001_Edge_Register.md) | Organizational edge management | --- --- ## ACCESS MANAGEMENT STANDARD ### Identity · Authentication · Authorization · Lifecycle --- | | | |---|---| | **Document ID** | CERG-STD-AC-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Significant Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-63](https://pages.nist.gov/800-63-3/)-3 (B/C) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final) · NIST RMF | | **Regulations** | NERC-CIP · [CMMC L2](https://dodcio.defense.gov/CMMC/) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · HIPAA (where applicable) | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [CERG Roles in Access Management](#2-cerg-roles-in-access-management) 3. [Identity Foundation](#3-identity-foundation) 4. [Authentication](#4-authentication) 5. [Authorization](#5-authorization) 6. [Privileged Access Management](#6-privileged-access-management) 7. [Remote, Vendor, and Third-Party Access](#7-remote-vendor-and-third-party-access) 8. [Identity Lifecycle (Joiner / Mover / Leaver)](#8-identity-lifecycle-joiner--mover--leaver) 9. [Access Review and Recertification](#9-access-review-and-recertification) 10. [Monitoring, Logging, and Detection](#10-monitoring-logging-and-detection) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Exceptions and Escalation](#12-exceptions-and-escalation) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope This standard implements the foundational principles established in **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)** for identity, authentication, authorization, and the full access lifecycle. It defines specific, measurable requirements that apply to every in-scope asset, regardless of system class, environment, or trust level. Access management is the connective tissue between every other security control. A perfectly hardened system is no more secure than the worst credential authorized to log into it. A perfectly classified data store is no more protected than the weakest authorization rule that permits read access. This standard treats identity as the primary enforcement layer it has become. ### 1.1 Scope This standard applies to: - All workforce identities (employees, contractors, consultants) accessing organizational systems - All system, service, and application identities (machine identities, workload identities, API credentials) - All third-party identities (vendors, integrators, customers, partners) with access to organizational systems - All authentication and authorization decisions across owned, hybrid, cloud, SaaS, and OT environments - All credentials, secrets, keys, tokens, and certificates used to authenticate or authorize access ### 1.2 Standard Versus Subordinate Detail This standard establishes the requirements. Specific implementation details, IdP configuration baselines, MFA enrollment procedures, PAM workflows, access review run-books, are maintained as procedures and platform guides linked from this document. Where a subordinate procedure conflicts with this standard, this standard governs. ### 1.3 Relationship to Parent Policy and Peer Standards This standard is subordinate to **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)** and operates alongside the IT ([CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md)), OT ([CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md)), and CUI ([CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md)) standards. Where any peer standard imposes more stringent access requirements for a specific environment or data class (e.g., NERC-CIP CIP-004 for BES Cyber Systems, 800-171 3.5 for CUI), the more stringent requirement controls. --- ## 2. CERG Roles in Access Management | **CERG Pillar** | **Access Management Responsibilities** | |---|---| | **Engineering** | Designs, implements, and maintains identity platforms - IdP, directory, MFA, SSO, federation, PAM, secrets management, and certificate authorities. Builds joiner / mover / leaver automations. Maintains identity-related infrastructure-as-code, conditional access policies, and platform-level access controls. | | **Risk** | Operates continuous identity threat detection (UEBA, identity provider risk signals, privileged session monitoring). Conducts identity-focused adversarial testing. Maintains the identity-risk view in the risk register: stale accounts, excessive privileges, MFA bypass paths, dormant service accounts. | | **Governance** | Owns this standard and all access management procedures. Operates the access review and recertification program. Maintains role definitions, segregation-of-duties (SoD) policies, and approval matrices. Produces access-control evidence for [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), NERC-CIP, [CMMC](https://dodcio.defense.gov/CMMC/), and other regulatory regimes. Coordinates access-related findings during audits. | > **The "Every Door, Every Time" Standard** > > Strong access control is not selective. An MFA prompt that can be bypassed once, through legacy protocols, an unmanaged endpoint, or an exception with no expiration, is not a strong control; it is a control with a documented bypass. CERG measures access maturity by the absence of exceptions, not by the strength of the primary path. --- ## 3. Identity Foundation ### 3.1 Authoritative Identity Sources | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Maintain an authoritative source for each identity class: HRIS for employees, a contractor management system for contractors, an asset / configuration system for machine identities, and a vendor management record for third-party identities. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-4, AC-2 | | Provision and deprovision workforce accounts only from authoritative sources via automated workflows. Manual account creation is an exception case requiring documented justification. | Engineering | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(1) | | Reconcile downstream systems (IdP, directory, applications) with authoritative sources on at least a daily cadence. Discrepancies are flagged and resolved within defined SLAs. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(4), CA-7 | ### 3.2 Identity Federation and SSO | **Requirement** | **CERG Owner** | **Regulatory Reference** | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------ | -------------------------------------- | | All in-scope applications shall integrate with the central identity provider via SSO (SAML, OIDC, or equivalent) where technically supported. Local-account-only applications require a documented exception and compensating controls. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2, IA-8 · [NIST 800-63](https://pages.nist.gov/800-63-3/)-3 | | Identity federation to third parties (partners, customers, vendors) shall be approved by Engineering and Governance, scoped to the minimum necessary, and reviewed annually. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-8, CA-3 | | Where SSO is not technically feasible, local accounts shall be uniquely identified, MFA-enforced, and included in the access review program. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7), IA-2 | ### 3.3 Identity Classes The organization recognizes the following identity classes. Controls in this standard apply to all classes; specific provisions are noted where they differ. | **Class** | **Definition** | **Primary Controls** | |---|---|---| | **Workforce - Employee** | Permanent or fixed-term employees of the organization. | HR-driven lifecycle, full MFA, conditional access, role-based authorization. | | **Workforce - Contractor / Consultant** | Non-employee individuals performing work on the organization's behalf. | Contractor-system lifecycle, sponsor accountability, fixed end-dates, MFA, narrower authorization scope. | | **Privileged Administrator** | Workforce identities with elevated rights to platforms, systems, or data classes. | All workforce controls, plus PAM-managed credentials, JIT elevation, session recording, dedicated privileged workstation where required. | | **Service / Machine Identity** | Non-human identities (service accounts, managed identities, workload identities) authenticating to systems and APIs. | Secrets manager custody, no interactive login, scoped permissions, rotation policy, ownership, expiration. | | **Vendor / Third-Party** | Identities belonging to external organizations with access to organizational systems. | Federation or sponsored accounts, scope-limited, time-bound, monitored, contractually obligated. | | **Break-Glass / Emergency** | Highly privileged identities reserved for emergency access when normal mechanisms are unavailable. | Vaulted credentials, dual control, alarmed use, post-use review, documented procedure. | --- ## 4. Authentication ### 4.1 Multi-Factor Authentication > **Phishing-Resistant by Default for Anything That Matters** > > SMS and voice MFA are no longer sufficient for privileged access or for anything that holds Restricted-tier data. [NIST 800-63](https://pages.nist.gov/800-63-3/)-3 retired SMS as a restricted authenticator. The standard for administrative paths is phishing-resistant authentication, FIDO2/WebAuthn, platform authenticators, or smart cards. TOTP and push remain acceptable for general workforce access where conditional access policies provide compensating signals. | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Enforce MFA for all remote access, all access to privileged functions, and all access to systems classified Confidential or Restricted, regardless of network location. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2(1), IA-2(2), IA-2(11) | | Use phishing-resistant authenticators (FIDO2, platform authenticators, PIV / CAC, or equivalent) for: privileged roles in any environment, root / global-admin accounts, all CUI-system access ([CMMC L2](https://dodcio.defense.gov/CMMC/) expectation), and all break-glass paths. | Engineering | [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B AAL3 · [CMMC](https://dodcio.defense.gov/CMMC/) IA.L2-3.5.3 | | For non-privileged workforce access, MFA shall be enforced via methods that meet [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B AAL2 or higher. SMS / voice methods are not acceptable as the sole second factor for new enrollments. | Engineering | [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B AAL2 | | Service-to-service and workload-to-service authentication shall use platform-issued credentials (managed identities, workload identities, mTLS) where technically available; long-lived static API keys are an exception case. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-9 · [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B | | Authentication failures, lockouts, and MFA bypass events shall be logged and alerted on. Account-lockout thresholds and durations are defined in the IdP baseline. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-7, AU-2 | ### 4.2 Credential Management | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | All credentials (passwords, keys, tokens, certificates) shall meet the cryptographic strength requirements defined in the IdP / cryptographic standard. Legacy algorithms (e.g., MD5, SHA-1, weak cipher suites) shall be disabled wherever technically possible. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5 · [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B | | Default and vendor-supplied credentials shall be changed before deployment or first connection of any system to organizational networks. Detection of unchanged defaults is a Critical finding. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5(1) · NERC-CIP CIP-007 R5.5 | | Workforce passwords shall meet the organization's password policy aligned with [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B. Periodic forced rotation is not required unless a compromise is suspected; passwords shall be screened against known-compromised lists at set / reset. | Engineering | [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B §5.1.1 | | Shared accounts are prohibited. Where a vendor or vendor product requires a shared credential, document the exception, vault the credential under PAM, and apply session-attribution monitoring. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2, AC-2 · NERC-CIP CIP-007 R5.1 | | Secrets, API keys, and certificates shall be stored in an approved secrets management platform with rotation, access logging, and least-privilege retrieval. Plaintext secrets in source repositories, configuration files, IaC, container images, or chat tools are prohibited. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5(7) · OWASP ASVS | ### 4.3 Session Management | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Enforce session inactivity timeouts and absolute session lifetimes appropriate to the sensitivity of the system. Privileged sessions and Restricted-data systems use shorter limits than general workforce systems. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-11, AC-12 | | Bind sessions to device posture where supported. Sessions established on noncompliant devices for sensitive paths shall be terminated automatically. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-12(1), IA-2(12) | | Provide session revocation capability for the IdP and for Tier 1 SaaS / cloud control planes. Compromise response shall be able to invalidate sessions globally within minutes. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-12, IR-4 | --- ## 5. Authorization ### 5.1 Least Privilege | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Grant access strictly on the basis of least privilege - the minimum required to perform an authorized function. New roles and entitlements shall be reviewed for least-privilege adherence before approval. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.5 | | Default to deny. Network, application, and platform authorization defaults shall be deny-by-default with explicitly authorized exceptions. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-3 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.3 | | Authorization shall reference role, attribute, or policy - not user identity alone. Identity-only authorization (entitlements assigned directly to a user without role/group/policy abstraction) is restricted to documented exceptions. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-3 · [NIST CSF 2.0](https://www.nist.gov/cyberframework) PR.AA | ### 5.2 Role and Group Design | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Maintain documented role definitions for in-scope applications and platforms. Each role specifies entitlements, intended use, and owner. Roles are reviewed annually and upon material application change. | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Segregation of duties (SoD) policies shall be defined for systems supporting financial reporting, payment processing, regulated operational activities, and security-control configuration. SoD violations are detected and remediated as part of the access review program. | Governance / Engineering | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-5 | | Role and group assignments shall be made through a documented request and approval workflow with line-manager and resource-owner approvals as appropriate. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(1) | ### 5.3 Authorization for Sensitive Data and Functions | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Access to Restricted-tier data (CUI, PCI, PHI, financially material data) requires explicit authorization by the data owner. Inherited group access is permitted only where the inheriting group has an authorized purpose. | Governance / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.3 · HIPAA 164.308 | | Highly destructive functions (mass delete, configuration baseline modification, identity-platform changes) shall require additional authorization controls: dual approval, JIT elevation, or compensating session monitoring. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6 · [NIST CSF 2.0](https://www.nist.gov/cyberframework) PR.AA | | Cross-organizational data sharing (federation, OAuth grants to third-party apps, API integrations) shall be authorized by Engineering and Governance and documented in the third-party integration register. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-21 · CSA CCM IAM-13 | --- ## 6. Privileged Access Management ### 6.1 Privileged Access Definition The following access types shall be treated as privileged and subject to the controls in this section: - Administrative access to operating systems, hypervisors, and container platforms - Administrative access to identity platforms (IdP, directory, MFA, PAM, KMS, CA) - Administrative access to cloud control planes (account / subscription / project admin, IAM-policy authoring) - Administrative access to Tier 1 SaaS applications (M365 GA, Salesforce SysAdmin, etc.) - Administrative access to security infrastructure (SIEM, EDR, firewall, DLP, CSPM, network appliances) - Administrative access to BES Cyber Systems and OT control systems - Access to break-glass / emergency accounts - Administrative access to backup, snapshot, and restoration systems ### 6.2 Privileged Access Controls | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | All privileged access shall be brokered through an approved Privileged Access Management (PAM) platform. Direct administrative access bypassing PAM is an exception case with documented compensating controls. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6, IA-2 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.5 | | Implement just-in-time (JIT) privileged access - standing administrative entitlements are eliminated in favor of time-bound, request-approved elevation. Where JIT is not technically feasible, document the technical limit and apply enhanced session monitoring. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6(2), AC-6(5) | | Privileged sessions shall be logged and, for designated high-risk roles, recorded in a tamper-resistant format. Recordings are retained per regulatory and contractual requirements. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-2, AU-12, AC-17(1) | | Phishing-resistant MFA is mandatory for all privileged authentication. Privileged authentication shall traverse a dedicated path (e.g., privileged access workstation or compliant device + conditional access for high-sensitivity targets). | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2(11) · [NIST 800-63](https://pages.nist.gov/800-63-3/)-3B AAL3 | | Separate privileged credentials from standard user credentials. Administrative work shall not be performed from the user's daily-driver account. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6(5) · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.5 | ### 6.3 Break-Glass / Emergency Access | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Maintain documented break-glass procedures for critical platforms (IdP, cloud control plane, OT control systems). Procedures define when break-glass is permitted, how to invoke it, who is notified, and the post-use review. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6, IR-4 | | Break-glass credentials shall be vaulted, dual-controlled, alarmed on use, and rotated after each use. The credential check-out and check-in shall be logged. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5 · [NIST CSF 2.0](https://www.nist.gov/cyberframework) PR.AA | | Test break-glass procedures at least annually. Document the test, validate the credential is usable, and confirm alerting fires. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-4 | --- ## 7. Remote, Vendor, and Third-Party Access ### 7.1 Remote Access | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | All remote access to organizational assets shall be authorized, MFA-enforced, logged, and routed through a documented secure path (VPN, zero-trust access broker, SSE, or equivalent). | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-17 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.12 | | Remote administrative access shall require additional controls: phishing-resistant MFA, compliant or managed endpoint, and where applicable, session recording. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-17(2)(3) · CIP-005-6 R2 | | Remote access to BES Cyber Systems shall traverse an Intermediate System per [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) and NERC-CIP CIP-005 R2 requirements. | Engineering / Governance | NERC-CIP CIP-005 R2 · [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | | Split-tunnel VPN configurations are prohibited for sessions accessing Restricted-tier data or privileged functions, unless a documented exception with compensating controls is approved. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-17(3) | ### 7.2 Vendor and Third-Party Access | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Vendor and third-party accounts shall be sponsored by an internal accountable manager, scope-limited, time-bound, and reviewed at least quarterly. Vendor accounts without an active engagement shall be disabled. | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PS-7, AC-2 · CIP-004-6 | | Vendor remote access to in-scope systems shall use phishing-resistant MFA, traverse the secure remote access path, and be logged with session attribution. Persistent vendor connections require Engineering and CISO approval. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-17 · CIP-005-6 R2 | | Vendor access to BES Cyber Systems, CUI environments, or [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems requires contractual security obligations matching this standard and is subject to additional approval per the applicable peer standard. | Governance / Risk | DFARS 252.204-7012 · CIP-013-2 | | Detect and alert on use of vendor credentials outside contracted maintenance windows or from anomalous source locations. | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4(2) · CIP-007-6 R4 | --- ## 8. Identity Lifecycle (Joiner / Mover / Leaver) ### 8.1 Joiner | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | New workforce identities shall be provisioned only after the authoritative source (HRIS / contractor system) records the relationship. Pre-start provisioning is permitted only where the workflow logs the future effective date. | Engineering / Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(1) | | Baseline access shall be limited to role-defined entitlements. Additional access requires the workflow-based request and approval process. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.5 | | Personnel screening required by contract or regulation (e.g., NERC-CIP CIP-004 PRA, CUI personnel screening) shall be completed and documented before access is granted. | Governance / HR | CIP-004-6 R3 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.9.1 | ### 8.2 Mover (Role Change) | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Role-change events from the authoritative source shall trigger an authorization review. Entitlements no longer required by the new role shall be revoked, not retained. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(2) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Movers into privileged roles trigger PAM enrollment, additional training, and SoD review. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-5, AC-6 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Long-duration accumulation of entitlements ("entitlement creep") is detected through the access review program and remediated. | Governance / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7) | ### 8.3 Leaver | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Workforce access shall be disabled on or before the documented separation date. For BES Cyber Systems, access revocation timelines comply with CIP-004 (24 hours for terminations). | Engineering | CIP-004-6 R4 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(3) | | Service accounts and tokens owned by the leaver shall be reassigned or decommissioned. Personally created automation, scripts, and API keys are inventoried and transitioned. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(3), IA-5 | | Federated and external system access (SaaS local accounts not behind SSO, third-party portals) shall be deprovisioned through documented run-books. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Termination involving suspected wrongdoing or hostile separation invokes the enhanced offboarding procedure (immediate revocation, session termination, evidence preservation). | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4, PS-4(2) | ### 8.4 Service Account Lifecycle | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Every service account shall have a documented owner, purpose, scope, and expiration / review date. Ownerless service accounts are remediated within the cycle defined in the access review program. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2, IA-2 | | Service-account credentials shall be vaulted in the secrets manager and rotated on a defined cadence appropriate to risk. Static, never-rotated credentials are an exception case. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.5.10 | | Service accounts shall not be used for interactive logins. Where vendor software requires interactive use of a service account, document the exception and apply session monitoring. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2, AU-2 | --- ## 9. Access Review and Recertification | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Conduct access reviews on a defined cadence per system tier: privileged roles (quarterly), Tier 1 systems / [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant (quarterly), Tier 2 systems (semi-annual), Tier 3 systems (annual). | Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7) · CIP-004-6 R4.2 | | Reviews require evidence of an active, attributable decision by the accountable manager or resource owner. "Rubber-stamp" approvals (single-click bulk approve without review) are non-compliant. | Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7) | | Review findings - terminated users with active access, role mismatches, SoD violations, dormant accounts - shall be remediated within the SLA defined in the access review procedure. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(3), AC-2(13) | | Recertify external (vendor / contractor) identities at least quarterly. Inactive external identities (no successful authentication in 60 days) are disabled pending sponsor confirmation. | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PS-7, AC-2 | | Maintain access-review evidence in the audit evidence library per regulatory retention requirements. | Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [CMMC](https://dodcio.defense.gov/CMMC/) CA.L2-3.12.4 | --- ## 10. Monitoring, Logging, and Detection | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Centralize identity-related logs from: IdP, MFA, PAM, directory services, conditional access, OAuth grant events, and Tier 1 SaaS authentication. Retain per regulatory requirement (minimum 12 months). | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-2, AU-11 | | Detect and alert on identity attack indicators: impossible travel, atypical sign-in, MFA fatigue patterns, legacy auth attempts, OAuth grant anomalies, password spray, token theft / replay, and privileged role assignments outside change windows. | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4(5), AU-6 · MITRE ATT&CK T1078 | | Detect and respond to dormant account use. Accounts inactive beyond a defined threshold shall be disabled automatically. | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(3) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Privileged role assignments, role-permission changes, and changes to MFA or conditional access policy shall generate alerts and be reconciled to an approved change ticket. | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-6, CM-3 | | Integrate identity telemetry with the SIEM and the centralized incident response process. Identity-detected events have defined containment playbooks (force sign-out, revoke session, disable account, reset credentials). | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4, SI-4 | --- --- ## 11. Non-Human Identity and Identity Threat Detection ### 11.1 Non-Human Identity (NHI) Management > **Service Accounts, API Keys, OAuth Tokens, Workload Identities, and Machine Credentials Are Identities Too** > NHIs frequently outnumber human identities 10:1 in modern estates. They authenticate to systems, access data, and can be abused for lateral movement. CERG treats NHI management with equivalent rigor to workforce identity. | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | All NHIs shall be inventoried in a central registry with: owner, purpose, scope, authentication method, rotation cadence, and expiration / review date. | Engineering / Governance | NIST 800-53 IA-2, AC-2 · NIST 800-171 3.5.10 | | NHI credentials (API keys, tokens, certificates, client secrets) shall be vaulted in an approved secrets manager. Plaintext NHI credentials in source repos, IaC, container images, CI variables, or chat tools are prohibited. | Engineering | NIST 800-53 IA-5(7) · OWASP ASVS | | NHIs shall use least-privilege, scoped permissions. Wildcard or admin-scoped NHIs require documented exception with compensating controls. | Engineering / Governance | NIST 800-53 AC-6 · NIST 800-171 3.1.5 | | NHI rotation: service-account keys ≤ 90 days; OAuth client secrets ≤ 180 days; workload identities (cloud managed) per platform rotation; certificates per CERG-STD-CR-001. Expired NHIs are auto-disabled. | Engineering | NIST 800-53 IA-5 · CIS Controls 4.5 | | NHIs shall not be used for interactive login. Vendor software requiring interactive NHI use shall be documented as exception with session monitoring. | Engineering / Risk | NIST 800-53 AC-2, AU-2 | | Cross-environment NHI federation (e.g., GitHub Actions → AWS workload identity, SaaS OAuth grants) shall be mapped in the NHI registry with trust boundaries documented. | Engineering | NIST 800-53 IA-8 · CSA CCM IAM-13 | ### 11.2 Identity Threat Detection & Response (ITDR) | **Requirement** | **CERG Owner** | **Regulatory Reference** | |---|---|---| | Deploy ITDR capabilities covering: impossible travel for NHIs, token replay/anomalous use, OAuth grant anomalies, privilege escalation via NHI, dormant NHI activation, and MFA bypass on service principals. | Risk | NIST 800-53 SI-4(5), AU-6 · MITRE ATT&CK T1078, T1550 | | Identity telemetry (IdP, MFA, PAM, cloud IAM, Tier 1 SaaS audit logs) shall be normalized and correlated in the SIEM. NHI activity shall be distinguishable from human activity in alerts. | Risk / Engineering | NIST 800-53 AU-2, AU-6, SI-4 | | Containment playbooks for NHI compromise: auto-revoke token, rotate secret, disable NHI, force re-authentication of dependent workloads, notify NHI owner. Mean time to containment target: ≤ 30 min for Critical NHI paths. | Risk | NIST 800-53 IR-4(1), IR-4(2) | | NHI risk posture reported quarterly to CISO: NHI count by type, rotation compliance, stale NHI count, ITDR alert volume and false-positive rate. | Risk / Governance | NIST CSF 2.0 DE.CM, GV.RR | --- ## 12. Regulatory and Framework Alignment Summary | **Requirement Area** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | **[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)** | **NERC-CIP** | **[CMMC L2](https://dodcio.defense.gov/CMMC/)** | **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC** | |---|---|---|---|---|---|---| | Identity Foundation / SSO | PR.AA | IA-2, IA-8, AC-2 | 3.5.1, 3.5.2 | CIP-004 R4 | IA.L2-3.5.1 | Access | | MFA & Authenticator Strength | PR.AA | IA-2(1)(2)(11) | 3.5.3 | CIP-005 R2 | IA.L2-3.5.3 | Access | | Credential & Secrets Mgmt | PR.AA | IA-5, IA-5(1)(7) | 3.5.7–3.5.10 | CIP-007 R5 | IA.L2-3.5.7 | Access | | Least Privilege & Authorization | PR.AA | AC-3, AC-6 | 3.1.5 | CIP-004 R4 | AC.L2-3.1.5 | Access / SoD | | Privileged Access (PAM, JIT) | PR.AA | AC-6(2)(5), AU-12 | 3.1.5 | CIP-007 R5 | AC.L2-3.1.5 | Access | | Remote & Vendor Access | PR.AA | AC-17, PS-7 | 3.1.12 | CIP-005 R2 | AC.L2-3.1.12 | Access | | Joiner / Mover / Leaver | PR.AA | AC-2(1)(2)(3) | 3.5.6 | CIP-004 R4 | AC.L2-3.5.6 | Access | | Access Review / Recert | GV.RR | AC-2(7) | 3.1.5 | CIP-004 R4.2 | AC.L2-3.1.5 | Access | | Monitoring & Detection | DE.CM | AU-6, SI-4 | 3.3.5 | CIP-007 R4 | AU.L2-3.3.5 | Logging | | Non-Human Identity Mgmt | PR.AA | IA-2, IA-5, AC-2 | 3.5.10 | CIP-007 R5 | IA.L2-3.5.7 | Access | | ITDR | DE.CM | AU-6, SI-4, IR-4 | 3.3.5 | CIP-007 R4 | AU.L2-3.3.5 | Logging | --- ## 13. Exceptions and Escalation | **Exception Type** | **Approval Required** | **Process** | **Review Cycle** | |---|---|---|---| | Standard exception (non-privileged, non-regulated) | Engineering Pillar Leader + Governance Pillar Leader | Risk register entry with compensating control documentation. | Annual | | Privileged access exception | CISO | PAM-bypass exceptions require enhanced session monitoring and quarterly review. | Quarterly | | Shared / vendor-required credential | Engineering Pillar Leader + Governance | Vault under PAM, document attribution model, monitor session use. | Annual | | MFA exception (workforce identity) | CISO | Permitted only for documented technical limitations; compensating controls required (e.g., source-IP restrictions, enhanced monitoring). | Quarterly | | Standing privileged access (no JIT) | CISO | Risk register entry; session recording required where technically feasible. | Quarterly | | BES Cyber System access exception | CISO + NERC-CIP deviation as applicable | Follow [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) §11 escalation. | Per CIP-mitigation milestones | | CUI-environment access exception | CISO; POA&M entry | Follow [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) §11. | Per POA&M plan | | Emergency / break-glass use | CISO post-hoc within 24 hours | Alerted at time of use; post-use review and credential rotation. | Per use | --- ## 14. Document Control | | | |---|---| | **Document ID** | CERG-STD-AC-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / Upon Significant Change | | **Change Log** | 1.0 - Initial publication. Identity, authentication, authorization, lifecycle. | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 DRAFT | 2026 | CERG Governance | Initial release - identity, authentication, authorization, lifecycle | ### Review Triggers - Material change to the organization's IdP, MFA, PAM, or secrets management platforms - Revisions to [NIST 800-63](https://pages.nist.gov/800-63-3/), 800-53, 800-171, NERC-CIP, [CMMC](https://dodcio.defense.gov/CMMC/), or [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC guidance that materially affect requirements - Significant identity-related incident - Internal audit or regulatory finding affecting access control - Direction from the CISO Governance owns this document. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - this standard is subordinate | | Grid and Control System Standard | [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Peer standard - BES Cyber System access provisions apply in addition | | IT (Hosted/Cloud/SaaS) Security Standard | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Peer standard - cloud/SaaS-specific provisions apply in addition | | CUI Handling Standard | [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) | Peer standard - CUI-specific access requirements apply in addition | | Access Management Runbook | [CERG-PRC-AC-002](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) | Operating procedure implementing this standard | --- ## ARTIFICIAL INTELLIGENCE SECURITY STANDARD ### AI Governance · Acceptable Use · Model and Data Risk · Prompt Injection · Shadow AI --- | | | |---|---| | **Document ID** | CERG-STD-AI-001 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Application Security) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) · [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Supporting Templates** | [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) · [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) · [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | | **Review Cycle** | Annual / On material change to AI use or AI regulation | | **Frameworks** | [NIST AI RMF 100-1](https://www.nist.gov/itl/ai-risk-management-framework) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) · ISO/IEC 42001 | | **Regulations** | CMMC L2 / 800-171r3 (where AI processes CUI) · SOX ITGC (where AI supports financial processes) · privacy regimes where applicable | | **Environments** | All CERG-managed use of AI systems: third-party AI services, embedded AI features, and in-house AI applications | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [AI Use Categories](#3-ai-use-categories) 4. [Acceptable Use of AI](#4-acceptable-use-of-ai) 5. [Data and AI](#5-data-and-ai) 6. [In-House and Embedded AI Systems](#6-in-house-and-embedded-ai-systems) 7. [AI-Specific Threats](#7-ai-specific-threats) 8. [Third-Party AI Services](#8-third-party-ai-services) 9. [Shadow AI](#9-shadow-ai) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope Artificial intelligence entered the organization faster than any technology before it, and it entered mostly without asking. Employees use AI assistants. Vendors embed AI features into software already in use. Teams build applications on top of AI models. Each of these creates security exposure that none of the existing CERG standards squarely owns: data leaving the organization in a prompt, decisions made by a model no one validated, an application vulnerable to attacks that did not exist three years ago. This standard establishes the requirements for the secure use of AI across CERG-managed environments: acceptable use, how data and AI interact, the security of in-house and embedded AI systems, the AI-specific threats the program must defend against, the assessment of third-party AI services, and the control of unsanctioned AI use. It applies to every use of AI by CERG-managed teams and systems: third-party AI services and assistants, AI features embedded in other software, and AI applications the organization builds itself. It is technology-neutral and is written to survive the rapid change in the AI field. > **AI Is Not Exempt From the Rest of CERG** > > An AI system is software. It runs on infrastructure, it processes data, it is accessed by identities, and it is built by developers. Everything CERG already requires still applies: an in-house AI application is governed by the secure development standard, the data it touches is governed by the data governance standard, its access is governed by the access standard. This standard does not replace those. It adds the requirements that are genuinely specific to AI, and it makes explicit that AI does not get a pass on the requirements that already exist. --- ## 2. Principles 1. **AI use is sanctioned use.** AI is used through services and tools the program has assessed and approved. Unsanctioned AI is shadow IT and is treated as such (Section 9). 2. **A prompt is an export.** Data placed into an AI system, especially a third-party one, has left the organization's control boundary as surely as if it were emailed out. It is governed by the data classification scheme. 3. **AI output is reviewed, not trusted.** AI output can be wrong, biased, or manipulated. A human reviews AI output before it is used for a consequential decision. Accountability for the decision stays with the human. 4. **AI does not decide alone where it matters.** An AI system does not make a final consequential decision, about a person, a safety action, a control system, without a human in the loop. 5. **AI risk is assessed before adoption.** An AI service or AI feature is risk-assessed before it is used, like any other technology, and reassessed as its capability changes. 6. **The same rules scale.** A five-person team and a sixty-person team both sanction AI tools, classify what goes into them, and review what comes out. The rigor scales; the principles do not. --- ## 3. AI Use Categories CERG governs three categories of AI use. The requirements differ by category. | **Category** | **What It Is** | **Primary Governing Sections** | |---|---|---| | **Consumed AI services** | Third-party AI assistants and services used as tools: chat assistants, coding assistants, content tools. | Sections 4, 5, 8, 9 | | **Embedded AI** | AI features built into other software the organization already uses. | Sections 5, 7, 8 | | **Built AI** | AI applications and integrations the organization develops itself, including systems built on third-party models. | Sections 5, 6, 7 | --- ## 4. Acceptable Use of AI 1. **Use sanctioned AI tools.** Employees use the AI services and tools the program has assessed and approved. The list of sanctioned AI tools is maintained by Governance using [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) or an equivalent local register and is visible to staff. 2. **Classify before you prompt.** Before data is placed into an AI tool, the user considers its classification per [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). Section 5 governs what may go where. 3. **Review AI output before relying on it.** AI-generated content, code, analysis, or recommendations are reviewed by a competent person before being used. AI-generated code additionally passes the gates in [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md); AI is not an exception to code review. 4. **Do not use AI to make prohibited decisions unaided.** AI does not unilaterally make decisions about employment, safety, control system operation, or anything else where Principle 4 applies. 5. **Attribute and disclose where required.** Where a regulator, a contract, or a customer requires disclosure that AI was used, that disclosure is made. --- ## 5. Data and AI This section applies the data classification scheme to AI use. It is the most important operational section of the standard. 1. **A prompt to a third-party AI service is treated as external sharing.** Placing data into a consumed AI service is governed by the external-sharing rules of [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) §6. 2. **Classification limits on AI input:** - **Public and Internal data** may be placed into sanctioned AI tools. - **Confidential data** may be placed only into AI services that have been assessed and approved for Confidential data, with contractual assurance that input is not used to train the provider's models and is handled to the program's bar. - **Restricted data**, including CUI and BES Cyber System Information, is not placed into a third-party AI service unless that service is explicitly authorized for that regulated category and an authorization is recorded. For CUI this means the service satisfies [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md). 3. **Training data is classified data.** Data used to train, fine-tune, or ground an in-house or embedded AI system carries its classification, and the resulting model is treated as carrying the classification of its most sensitive training data. 4. **AI interactions are logged where they touch sensitive data.** Use of AI systems that process Confidential or Restricted data is logged per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). > **The Prompt Is the Leak** > > The most common AI security failure is mundane: an employee pastes a sensitive document into a public AI assistant to summarize it. The data is now on a third party's infrastructure, possibly used to train a model, possibly retained indefinitely, and entirely outside the organization's control. No model was hacked. No clever attack occurred. Someone simply typed. CERG governs AI primarily by governing what goes into the prompt, because the prompt is where the data actually leaves. --- ## 6. In-House and Embedded AI Systems An AI application the organization builds is software and is fully governed by [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md). In addition: 1. **AI applications go through architecture review.** An AI application or integration is subject to project intake and architecture review per [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md), with the AI-specific threats in Section 7 explicitly in scope of the threat model. 2. **The model is an inventoried component.** A model, whether trained in-house or a third-party model the application depends on, is a component recorded in the asset inventory per [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md), the AI system and model register using [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) or an equivalent local record, and, where applicable, in the software bill of materials per [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) §8. 3. **Model provenance is known.** The source of any third-party or open model used is known and trusted. A model from an unverified source is a supply chain risk. 4. **AI applications enforce least privilege.** An AI system, and any agent or tool-using capability it has, operates with the least privilege required. An AI agent does not run with broad standing access on the assumption it will behave. 5. **AI output that triggers action is bounded.** Where an AI system can trigger an action, send a message, change a record, call an API, the actions it can take are constrained and high-consequence actions require human confirmation. --- ## 7. AI-Specific Threats CERG-built and embedded AI systems are designed and tested against the AI-specific threat classes below, aligned to the OWASP Top 10 for LLM Applications. These threats are explicitly in scope of the threat model required by [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md). | **Threat** | **What It Is** | **Required Mitigation Direction** | |---|---|---| | Prompt injection | Untrusted input manipulates the model into ignoring its instructions or acting maliciously. | Treat all model input as untrusted; separate instructions from data; constrain what the model can do. | | Sensitive information disclosure | The model reveals sensitive data from its training, context, or another user's session. | Control what data reaches the model; isolate sessions; filter output. | | Insecure output handling | Downstream systems trust model output as if it were safe code or commands. | Treat model output as untrusted input to anything downstream; validate and encode it. | | Excessive agency | An agent or tool-using model is granted more capability than needed and is induced to misuse it. | Least privilege for the model; bound and confirm consequential actions (Section 6). | | Training-data and model poisoning | Tampered training data or a tampered model produces attacker-influenced behavior. | Known model provenance; control and classify training data; validate model integrity. | | Supply chain risk in the model stack | A compromised model, dataset, or AI library enters the system. | Assess models and AI dependencies like any other component (Sections 6, 8). | --- ## 8. Third-Party AI Services 1. **AI services are assessed before adoption.** A consumed AI service or an AI-enabled vendor feature is risk-assessed before use through [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) and recorded through [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) or an equivalent local intake. The assessment covers, at minimum: what the provider does with input data, whether input trains the provider's models, data retention and location, and the provider's own security posture. 2. **Embedded AI features are assessed when they appear.** A vendor adding an AI feature to existing software is a material change to that vendor's risk profile and triggers reassessment. AI features that arrive silently in an update are caught by the reassessment cadence in [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). 3. **Approval is by data classification.** A service is approved for a maximum data classification per Section 5. Approval for Internal use is not approval for Confidential or Restricted use. 4. **The sanctioned list is maintained.** The outcome of assessment is the sanctioned AI tools list, maintained using [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) or an equivalent local register, which states each tool and the maximum classification it is approved for. --- ## 9. Shadow AI Shadow AI is the use of AI services that the program has not assessed or approved. It is the dominant AI risk in most organizations. 1. **Shadow AI is shadow IT.** Unsanctioned AI use is treated as unsanctioned technology under [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md). It is discovered, assessed, and then either sanctioned or stopped. 2. **Discovery looks for it.** The program actively looks for unsanctioned AI use, through network and SaaS discovery and through expense and procurement signals. AI use that is invisible cannot be governed. 3. **The response is a path to sanctioned use, not only a block.** When shadow AI is found, the program assesses whether the underlying need can be met by a sanctioned tool and provides one. A pure block with no sanctioned alternative drives the use further underground. This is the "yes, and..." model of [`CERG-GOV-FRM-001`](../governance/CERG-GOV-FRM-001_CERG_Framework.md) applied to AI: enable the need, on safe ground. 4. **Repeated or high-risk shadow AI is a risk register entry.** A pattern of shadow AI, or a single instance involving Confidential or Restricted data, is recorded and tracked per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). > **Banning AI Does Not Work. Governing It Does.** > > An organization that responds to AI by banning it does not eliminate AI use; it eliminates its visibility into AI use. Employees who see a genuine productivity gain will use AI on personal devices and personal accounts, where the organization has no assessment, no contract, and no control at all. The defensible position is the CERG position everywhere else: provide sanctioned tools that meet a real need, govern what data goes into them, and treat the unsanctioned use that remains as a finding to be brought into the light. --- ## 10. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **AI Security Responsibility** | |---|---| | **Application Security Engineer** | Owns this standard. Owns AI threat modeling, the security of built and embedded AI systems, the AI system and model register, and the AI-specific gate content in secure development. | | **Engineering Pillar Leader** | Accountable for AI security across the pillar; owns architecture review of AI applications. | | **Governance Pillar Leader** | Owns AI intake and sanctioning, the sanctioned AI tools list, the acceptable-use position, and AI governance reporting. | | **Vendor Risk Analyst** | Assesses third-party AI services and AI-enabled vendor features per [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). | | **Cloud Security Engineer** | Owns discovery of shadow AI through SaaS and network signals. | | **Detection Engineer** | Owns detection content for shadow AI use and for anomalous AI-system behavior. | | **Policy & Standards Manager** | Maintains this document; maintains the sanctioned AI tools list as a living reference. | | **CMMC / Federal Compliance Manager** | Confirms AI use touching CUI satisfies [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md). | | **Risk Register Owner** | Records shadow AI and AI-risk findings in the register. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST AI RMF 100-1 | Govern, Map, Measure, Manage functions | Sections 2, 6, 7, 8 | | OWASP Top 10 for LLM Applications | LLM01-LLM10 risk categories | Section 7 | | NIST 800-53r5 | RA-3 (risk assessment), SA-family (system and services acquisition), AC-family | Sections 6, 8 | | ISO/IEC 42001 | AI management system | Sections 2, 4, 9 | | NIST 800-171r3 / CMMC L2 | Where AI processes CUI | Section 5 | | SOX ITGC | Where AI supports financial processes | Sections 4, 6 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-AI-001 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Application Security) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to AI use or AI regulation | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST AI RMF 100-1; NIST 800-53r5; OWASP Top 10 for LLM Applications; ISO/IEC 42001 | | **Regulations** | CMMC L2 / 800-171r3 where applicable; SOX ITGC where applicable; privacy regimes where applicable | | **Environments** | All CERG-managed use of AI systems | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-17 | Cyber Engineering | Added references to the AI intake and sanctioning template, sanctioned AI tools register, and AI system and model register as the operational records that implement AI governance. | | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes three AI use categories, acceptable use of AI, the data-classification limits on AI input (a prompt is an export), security requirements for in-house and embedded AI, the AI-specific threat set aligned to the OWASP LLM Top 10, third-party AI service assessment, and the governance of shadow AI through a path to sanctioned use rather than a pure block. | ### Review Triggers - Material change to how the organization uses AI - New or changed AI regulation - Revision of the NIST AI Risk Management Framework or the OWASP LLM Top 10 - A significant AI-related security incident - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Application Security) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Classification scheme that governs AI input | | Secure Software Development and Application Security Standard | [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Built and embedded AI systems are governed software | | IT / Cloud / SaaS Security Standard | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Shadow AI treated as shadow IT | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Least privilege for AI systems and agents | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Logging of AI use touching sensitive data; shadow-AI detection | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Models as inventoried components | | CUI Handling Standard | [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md) | AI use touching CUI | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Architecture review of AI applications | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Assessment of third-party AI services | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Shadow AI and AI-risk findings | | AI Intake and Sanctioning Template | [`CERG-TMPL-AI-001`](../templates/CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | Intake and approval record for proposed AI use | | Sanctioned AI Tools Register Template | [`CERG-TMPL-AI-002`](../templates/CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) | Operational register for approved AI tools and data-classification limits | | AI System and Model Register Template | [`CERG-TMPL-AI-003`](../templates/CERG-TMPL-AI-003_AI_System_and_Model_Register_Template.md) | Inventory record for built and embedded AI systems, models, data sources, and agency boundaries | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `AI` domain | --- ## ASSET MANAGEMENT AND INVENTORY STANDARD ### Authoritative Inventory · Asset Classes · Ownership · Classification · Lifecycle · End-of-Life --- | | | |---|---| | **Document ID** | CERG-STD-AM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On material change to the asset estate or inventory tooling | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.AM) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CM-8, PM-5) · [CIS Controls v8](https://www.cisecurity.org/controls) (Controls 1 and 2) · ISO/IEC 27001 A.5.9 | | **Regulations** | NERC-CIP (CIP-002 BES Cyber System identification) · CMMC L2 / 800-171r3 (3.4.1, 3.4.2) · SOX ITGC (in-scope system inventory) | | **Environments** | All in-scope assets: owned, hybrid, cloud, SaaS, OT, and CUI | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Asset Classes](#3-asset-classes) 4. [The Authoritative Inventory](#4-the-authoritative-inventory) 5. [Required Attributes](#5-required-attributes) 6. [Asset Ownership](#6-asset-ownership) 7. [Asset Criticality and Classification](#7-asset-criticality-and-classification) 8. [The Asset Lifecycle](#8-the-asset-lifecycle) 9. [End-of-Life and Secure Disposal](#9-end-of-life-and-secure-disposal) 10. [Inventory Accuracy and Reconciliation](#10-inventory-accuracy-and-reconciliation) 11. [Roles and Responsibilities](#11-roles-and-responsibilities) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope Every other control in CERG assumes the program knows what it is protecting. Exposure management scans an asset list. Access management governs access to systems. The control baseline maps evidence to assets. Logging collects from sources. Each of those depends on an authoritative answer to a deceptively simple question: what do we have? Until this standard, CERG had no document that owned that question. This standard establishes the requirement for an authoritative asset inventory: the asset classes that must be tracked, the inventory itself, the attributes every asset record carries, how ownership is assigned, how assets are classified by criticality, and how assets move through a lifecycle from acquisition to secure disposal. It applies to every in-scope asset across every environment: owned hardware, cloud and hybrid infrastructure, SaaS, operational technology, and the data assets the rest of the estate exists to serve. > **You Cannot Protect, Detect, or Recover What You Have Not Named** > > An unknown asset is an uncontrolled asset. It is not patched, because exposure management does not know it exists. Its access is not reviewed, because access management has no record of it. It is not backed up, monitored, or hardened. Asset management is not paperwork; it is the precondition for every other thing CERG does. This is why NIST CSF places asset management first, in the IDENTIFY function, and why CIS makes it Control 1. --- ## 2. Principles 1. **One authoritative inventory.** There is exactly one authoritative source for each asset class. Spreadsheets maintained in parallel are not the inventory. Where multiple tools hold asset data, one is named authoritative and the others reconcile to it. 2. **Every asset has exactly one owner.** Ambiguous ownership is the root cause CERG exists to remove. An asset with no owner, or two owners, is a finding. 3. **The inventory is current, not annual.** An inventory that is accurate once a year is inaccurate the other 364 days. The inventory updates as assets change, driven by automation wherever possible. 4. **Discovery is continuous.** The program actively looks for assets it does not know about. An inventory built only from what teams choose to register will always be incomplete. 5. **Classification drives treatment.** An asset's criticality and data classification determine the controls applied to it. Asset management produces the classification; the other standards consume it. 6. **Disposal is part of the lifecycle.** An asset is tracked until it is securely disposed of, not until it stops being interesting. Forgotten assets at end-of-life are a common breach path. --- ## 3. Asset Classes CERG tracks five asset classes. Each has a named authoritative inventory. | **Class** | **What It Covers** | **Examples** | |---|---|---| | **Hardware** | Physical computing and network devices. | Servers, workstations, laptops, network gear, mobile devices, OT field devices. | | **Software** | Operating systems, applications, and firmware in use. | OS images, installed applications, in-house software per [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md), firmware versions. | | **Cloud and SaaS** | Cloud infrastructure resources and subscribed SaaS services. | Cloud compute, storage, managed services, accounts and subscriptions, SaaS tenants. | | **Data** | Information assets, governed for classification and handling. | Datasets, databases, document repositories. Handling is governed by [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). | | **Identity** | Accounts and service principals that act on the estate. | User accounts, service accounts, machine identities, API principals. Governed by [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md); inventoried here. | ### 3.1 Ephemeral Asset Pattern Containers, serverless functions (AWS Lambda, Azure Functions, GCP Cloud Functions), CI/CD pipeline runners, auto-scaling groups, and dynamically provisioned cloud resources do not have stable instance identities or persistent owners. The persistent-instance model in §3 does not apply; the following pattern governs instead. | Principle | Rule | Method | |-----------|------|--------| | **Tag-based inventory, not instance-based** | Assets are tracked by tags, labels, or annotations at build time, not by individual instance ID. The inventory records the *blueprint* (image, template, IaC module) and the *deployment pattern*, not each runtime instance. | CMDB records for container images, serverless function ARNs, CI/CD pipeline definitions; reconciled via CSPM/CNAPP API. | | **Owner by deployment pipeline, not by asset** | The deployment pipeline or project that creates the ephemeral asset is the accountable owner. The pipeline owner is recorded once; all instances created by that pipeline inherit the owner. | Pipeline manifest (CI/CD YAML, Terraform module, Helm chart) carries an `owner` label. | | **Pipeline-integrated baseline enforcement** | Security controls are enforced at the pipeline gate, not retroactively scanned. Admission control (OPA/Kyverno, IAM policy-as-code, IaC scanning) rejects non-compliant deployments before they reach production. | Policy-as-code gates in CI/CD: image vulnerability scan < threshold, DISH baseline checks, IAM least-privilege validation. | | **Scan-on-deploy, not scan-on-schedule** | Ephemeral assets are scanned at build/deploy time, not on a recurring schedule. A container that runs for 4 hours and terminates is scanned in the pipeline; a scheduled weekly scan would miss it entirely. | Pipeline vulnerability scan (trivy, grype, snyk) as a build step; CSPM runtime scanning for drift detection. | | **Evidence via pipeline logs, not manual collection** | Evidence of control operation for ephemeral assets is the pipeline execution log, not a manually collected artifact. The pipeline log proves the image was scanned, the admission policy passed, and the deployment was approved. | CI/CD pipeline artifact retention; SIEM ingestion of pipeline audit events. | > **Ephemeral ≠ Unmanaged.** Ephemeral assets are not exempt from inventory, ownership, scanning, or evidence. The method changes; the requirement does not. A container that runs for 60 seconds without an owner, without a scan, and without a baseline is as uncontrolled as a physical server racked without a ticket. > **OT Assets Are In Scope and Need Care** > > Operational technology assets are tracked like every other asset, but discovery against OT is constrained: active scanning can disrupt control systems. OT asset discovery uses passive and OT-safe methods per [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). The requirement to inventory OT assets is identical to any other class. The method of discovery is not. For NERC-CIP entities, the OT hardware inventory is also the basis of BES Cyber System identification under CIP-002. --- ## 4. The Authoritative Inventory 1. **Each asset class has one named authoritative inventory.** The authoritative inventory for each class is recorded, with its owner, in the organization profile or an organization-specific appendix to this standard. 2. **The inventory is a system, not a document.** For any estate beyond the smallest, the inventory is a tooled system fed by automated discovery, not a hand-maintained file. A five-person team may start with a structured file; it migrates to tooling as the estate grows. 3. **Inventories interconnect.** A software record references the hardware or cloud asset it runs on. A data asset references the system that hosts it. An identity references what it can access. The inventory is a graph, not five disconnected lists. 4. **The inventory feeds the program.** The inventory is the source list for exposure management scanning, the access-review population, the logging source catalog, and the control-baseline evidence mapping. Those consumers reconcile to the inventory; they do not maintain their own. --- ## 5. Required Attributes Every asset record, regardless of class, carries the following attributes at minimum. An asset record missing a required attribute is incomplete and is a reconciliation finding. | **Attribute** | **Meaning** | |---|---| | Asset identifier | A unique, stable identifier for the asset. | | Asset class | One of the five classes in Section 3. | | Description | What the asset is, in plain language. | | Owner | The single accountable owner, per Section 6. | | Custodian | The team or role operating the asset day to day, where different from the owner. | | Environment | Owned, hybrid, cloud, SaaS, OT, or CUI. | | Criticality | The criticality tier, per Section 7. | | Data classification | The highest classification of data the asset stores or processes. | | Lifecycle state | The current state, per Section 8. | | Location | Physical site, cloud region, or logical placement. | | Acquisition date | When the asset entered the estate. | | Last verified | When the record was last confirmed accurate, per Section 10. | Regulated scopes carry additional attributes: NERC-CIP assets carry their BES Cyber System categorization; CUI assets carry their CUI category. Those overlays are defined in the relevant operational package. --- ## 6. Asset Ownership 1. **Every asset has exactly one owner.** The owner is a named role accountable for the asset's security posture, its classification, and decisions about its lifecycle. The owner is not necessarily the person who operates it. 2. **Ownership is assigned at acquisition.** An asset does not enter the estate without an owner. The acquisition step of the lifecycle (Section 8) does not complete until ownership is recorded. 3. **Ownership is reassigned, never dropped.** When an owner leaves a role, the asset's ownership transfers to a named successor. An asset whose owner has left and has no successor is an orphaned asset and is a finding. 4. **The custodian is distinct from the owner.** A cloud platform team may operate a server an application team owns. The inventory records both. The owner decides; the custodian runs. > **An Orphaned Asset Is How Programs Get Breached** > > The asset no one owns is the asset no one patches, no one reviews, and no one decommissions. It runs an unsupported operating system for three years because removing it is no one's job. Orphaned assets are found in nearly every significant breach retrospective. CERG treats an asset with no current owner as an open finding, tracked in the risk register until ownership is restored. --- ## 7. Asset Criticality and Classification ### 7.1 Criticality Tiers Every asset is assigned a criticality tier. Criticality reflects the business and safety impact if the asset is compromised or unavailable. | **Tier** | **Definition** | |---|---| | **Critical** | Compromise or loss causes severe business, safety, regulatory, or financial impact. Includes BES Cyber Systems, SOX-relevant financial systems, and systems processing regulated data. | | **High** | Compromise or loss causes significant impact to a major business function. | | **Moderate** | Compromise or loss causes limited, contained impact. | | **Low** | Compromise or loss causes negligible impact. | ### 7.2 Data Classification Every asset carries the classification of the highest-classified data it stores or processes. The classification scheme itself is owned by [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). Assets in CUI scope also carry the CUI handling attributes required by [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md). ### 7.3 What Classification Drives The criticality tier and data classification of an asset determine, at minimum: its exposure remediation SLA under [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md), its access-review frequency under [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md), its logging requirements under [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), and its backup and recovery objectives under [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md). Asset management produces the classification once; every other standard consumes it. --- ## 8. The Asset Lifecycle Every asset moves through a defined lifecycle. The inventory records the asset's current state. | **State** | **What Happens** | **Security Requirement** | |---|---|---| | **Requested** | Acquisition is proposed. | Intake through [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) where the asset is part of a project. | | **Acquired** | The asset enters the estate. | Inventory record created; owner assigned; criticality and classification set. | | **Provisioned** | The asset is configured for use. | Secure configuration baseline applied per [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md). | | **Operational** | The asset is in service. | Subject to exposure management, access review, logging, and backup per its classification. | | **Decommissioning** | The asset is being retired. | Data securely removed; access revoked; dependencies migrated. | | **Disposed** | The asset has left the estate. | Secure disposal completed per Section 9; record retained for audit. | An asset record is never deleted. A disposed asset is marked Disposed and retained, so the inventory carries a complete history for audit. --- ## 9. End-of-Life and Secure Disposal 1. **End-of-life is planned, not discovered.** An asset approaching the end of vendor support is identified before support ends, and a replacement or extended-support decision is made deliberately. An asset running past end-of-support with no decision recorded is a finding and a risk register entry. 2. **Data is removed before disposal.** Before an asset leaves the estate, data on it is securely sanitized to a standard appropriate to the data's classification. Cryptographic erasure per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) is acceptable where keys can be destroyed; physical destruction is used where it cannot. 3. **Access and identity are revoked.** Decommissioning includes revoking the asset's own credentials and any access granted to it, per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). 4. **Disposal is evidenced.** Secure disposal produces a record: what asset, what sanitization method, when, and by whom. The record is retained as control evidence. For regulated assets, the disposal record is part of the regulatory evidence set. 5. **Cloud and SaaS disposal counts.** Decommissioning a cloud resource or terminating a SaaS tenant is disposal. Data deletion, key destruction, and confirmation of tenant closure are required exactly as for physical hardware. --- ## 10. Inventory Accuracy and Reconciliation An inventory is only as useful as it is accurate. Accuracy is maintained, not assumed. 1. **Continuous discovery runs against every environment.** Automated discovery identifies assets and compares them to the inventory. An asset found by discovery but absent from the inventory is an unmanaged asset and is investigated. 2. **Reconciliation runs on a defined cadence.** The inventory is reconciled against discovery output, against the consuming systems (vulnerability scanner, access platform, logging catalog), and against procurement records. Discrepancies are findings. 3. **An unmanaged asset is contained.** An asset discovered outside the inventory is either brought under management (owner assigned, baseline applied, record created) or removed from the estate. It is not left in an unknown state. 4. **Inventory completeness is a reported metric.** The percentage of the estate under management, and the count of unmanaged assets found, are reported per [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). A program that does not measure its inventory accuracy does not know it has one. > **The Inventory You Do Not Reconcile Is a Guess** > > Every inventory drifts. Assets are spun up outside process, shadow SaaS is subscribed with a credit card, a contractor leaves a virtual machine running. An inventory that is not actively reconciled against independent discovery slowly becomes fiction while still being trusted as fact, which is worse than having no inventory at all. Reconciliation is what keeps the inventory honest. --- ## 11. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Asset Management Responsibility** | |---|---| | **Engineering Pillar Leader** | Owns this standard. Accountable for the authoritative inventories and for continuous discovery across environments. | | **Cloud Security Engineer** | Owns discovery and inventory accuracy for the cloud and SaaS asset class. | | **OT Security Engineer** | Owns OT-safe discovery and inventory accuracy for OT hardware; supports BES Cyber System identification. | | **Endpoint Engineer** | Owns inventory accuracy for endpoint hardware and software. | | **Identity Engineer** | Owns the identity asset class inventory, in coordination with [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). | | **Asset Owners** | Named per asset. Accountable for their asset's posture, classification, lifecycle decisions, and end-of-life planning. | | **Exposure Management Lead** | Consumes the inventory as the scan population; reports inventory gaps found during scanning. | | **Governance Pillar Leader** | Tracks inventory-completeness metrics; cross-references this standard with the control baseline; tracks orphaned and end-of-life assets in the risk register. | | **Policy & Standards Manager** | Maintains this document, its version, and its review cycle. | --- ## 12. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST CSF 2.0 | ID.AM-01 through ID.AM-08 | Sections 3, 4, 5, 7, 8 | | NIST 800-53r5 | CM-8 (system component inventory), PM-5 (system inventory), MP-6 (media sanitization) | Sections 4, 5, 9 | | CIS Controls v8 | Control 1 (enterprise assets), Control 2 (software assets) | Sections 3, 4, 10 | | ISO/IEC 27001 | A.5.9 (inventory of information and assets), A.5.11 (return of assets) | Sections 4, 9 | | NERC-CIP | CIP-002 (BES Cyber System categorization) | Sections 3, 7 | | NIST 800-171r3 / CMMC L2 | 3.4.1, 3.4.2 (baseline configuration and inventory) | Sections 4, 5 | | SOX ITGC | In-scope system inventory | Sections 4, 7 | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-AM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to the asset estate or inventory tooling | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST CSF 2.0 (ID.AM); NIST 800-53r5 (CM-8, PM-5, MP-6); CIS Controls v8 (1, 2); ISO/IEC 27001 A.5 | | **Regulations** | NERC-CIP (CIP-002); CMMC L2 / 800-171r3; SOX ITGC | | **Environments** | All in-scope assets | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes the five asset classes, the authoritative inventory requirement, required asset attributes, single-owner asset ownership, criticality and data classification, the six-state asset lifecycle, end-of-life and secure disposal requirements, and continuous discovery with reconciliation. | ### Review Triggers - Material change to the asset estate, environments, or inventory tooling - Publication of the Data Governance and Classification Standard, which sets the classification scheme - Revision of NIST CSF, CIS Controls, or NERC-CIP CIP-002 - Internal audit or regulatory finding affecting asset inventory - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Platforms) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Baselines applied at the Provisioned lifecycle state | | IT / Cloud / SaaS Security Standard | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Cloud and SaaS asset controls | | Grid Control Systems Security Standard | [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT-safe discovery; BES Cyber System identification | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Identity asset class; access revocation at disposal | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Inventory feeds the logging source catalog | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Classification drives backup and recovery objectives | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Cryptographic erasure at disposal | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Inventory is the scan population | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Intake at the Requested lifecycle state | | Metrics, Dashboard, and Reporting | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Inventory-completeness reporting | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `AM` domain | --- ## CRYPTOGRAPHY AND KEY MANAGEMENT STANDARD ### Approved Algorithms · TLS · Certificates · Keys · Secrets · API Tokens · CMK · FIPS --- | | | |---|---| | **Document ID** | CERG-STD-CR-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-RES-001](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | | **Review Cycle** | Annual / On NIST FIPS publication change · On crypto algorithm deprecation | | **Frameworks** | NIST FIPS 140-3 · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (SC family) · [NIST 800-57](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) · [NIST 800-131A](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final) · NIST 800-175B | | **Regulations** | NERC-CIP (BCSI) · [CMMC L2](https://dodcio.defense.gov/CMMC/) / 800-171r3 (3.13.x) · SOX ITGC · FedRAMP | | **Environments** | All in-scope assets | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Approved and Prohibited Algorithms](#2-approved-and-prohibited-algorithms) 3. [Cryptographic Use Cases](#3-cryptographic-use-cases) 4. [TLS and Certificate Management](#4-tls-and-certificate-management) 5. [Key Management](#5-key-management) 6. [Customer-Managed Keys (CMK) Decision Guide](#6-customer-managed-keys-cmk-decision-guide) 7. [Secrets, API Keys, and Tokens](#7-secrets-api-keys-and-tokens) 8. [Rotation Cadence](#8-rotation-cadence) 9. [FIPS / FedRAMP / CUI Cryptography Checklist](#9-fips--fedramp--cui-cryptography-checklist) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope The Cybersecurity Policy requires encryption in transit and at rest. The IT, CUI, and Access standards each impose specific cryptographic requirements; the Risk Management Framework calls out FIPS-validated cryptography in CUI scope; the OT standard requires protection of BES Cyber System Information (BCSI). Until this standard, those requirements existed in fragments. This standard establishes a unified cryptographic policy: which algorithms are approved, which are prohibited, how TLS and certificates are managed, how keys / secrets / API tokens are stored and rotated, when customer-managed keys are required, and the FIPS profile for regulated scopes. It applies to every in-scope asset, every credential and secret used by CERG-managed systems, and every cryptographic use case, data at rest, data in transit, signing, integrity, authentication, and key wrapping. > **The Crypto Standard Reads Like a Floor, Not a Ceiling** > > The algorithms and key sizes named below are minimums. Where a regulator, vendor capability, or specific workload supports a stronger configuration (post-quantum-ready KEM hybrid, larger key size, shorter rotation), CERG adopts it. The standard is the worst the program is willing to accept. --- ## 2. Approved and Prohibited Algorithms ### 2.1 Approved ([NIST 800-131A](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final) current, FIPS 140-3 module where required) | **Use** | **Approved** | **Minimum Strength** | |---|---|---| | Symmetric encryption | AES-128, AES-192, AES-256 (GCM or CBC with HMAC) | AES-128 for non-Restricted; AES-256 for Restricted/CUI/BCSI | | Hashing | SHA-256, SHA-384, SHA-512 | SHA-256 | | HMAC | HMAC-SHA-256 and stronger | - | | Digital signature | RSA-PSS ≥ 3072; ECDSA P-256/P-384/P-521; Ed25519 | RSA 3072 / ECDSA P-256 | | Key agreement | ECDHE (P-256+), DH (3072+); ML-KEM hybrid where workloads support it | ECDHE P-256 | | Key derivation | HKDF, PBKDF2 (≥ 600,000 iterations), Argon2id | - | | Authenticated encryption | AES-GCM, ChaCha20-Poly1305 | - | | Random number generation | NIST 800-90A approved DRBG; OS CSPRNG | - | ### 2.2 Prohibited (Without Exception) | **Algorithm / Protocol** | **Why Prohibited** | |---|---| | DES, 3DES | Insufficient key strength; deprecated by [NIST 800-131A](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final). | | MD5 (any use) | Collision attacks make it unfit for any security purpose. | | SHA-1 (any new use) | Collisions demonstrated; permitted only for HMAC-SHA-1 in legacy compatibility, with a sunset plan. | | RC4, Blowfish, IDEA | Deprecated / cryptographically weak. | | SSL 2.0, SSL 3.0 | Deprecated; protocol-level breaks (POODLE et al.). | | TLS 1.0, TLS 1.1 | Deprecated by all major standards bodies. | | RSA < 2048 | Insufficient key strength. | | ECDSA / ECDH on non-NIST curves (other than Ed25519 / Curve25519) | Outside the approved set. | | ECB mode (any cipher) | Pattern-preserving; unsafe for general data. | | PKCS#1 v1.5 padding for new use | RSA-PSS required for new signatures. | | Static IV with stream ciphers / GCM | Catastrophic if reused. | | Plaintext credentials / secrets at rest | See Section 7. | | Custom / home-grown algorithms | Cryptographic agility requires reviewed standards. | > **Exception Requests for Prohibited Algorithms** > > Exceptions to the prohibited list are not entertained as compensating-control bargains. The path to using a prohibited algorithm runs through replacing the system, not through a risk acceptance. The only acceptable exception is a time-bounded transitional one with a named sunset date. ### 2.3 Deprecation and Sunset Tracker | **Algorithm** | **Status** | **Internal Sunset** | |---|---|---| | TLS 1.0 / 1.1 | Prohibited | Already retired - confirm via DISH scan | | SHA-1 (signing) | Prohibited new use | Transitional only - flag for replacement | | RSA-2048 | Approved (current); plan migration toward 3072 / EC / PQ-hybrid | Roadmap track | | Classical-only KEMs | Approved; plan ML-KEM hybrid adoption where supported | Roadmap track | --- ## 3. Cryptographic Use Cases CERG controls cryptography at four use cases. Each names the required algorithm class and the key source. ### 3.1 Data at Rest - **Volume / disk encryption:** AES-256 via OS or storage platform; keys in HSM or cloud KMS; rotation per Section 8. - **Database TDE / column-level encryption:** AES-256; CMK for Restricted/CUI/SOX in-scope; rotation per Section 8. - **Object storage:** server-side encryption with CMK for Restricted/CUI; client-side encryption optional where adversary model includes provider compromise. - **Backups:** AES-256; key separate from production credentials (see [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 4). ### 3.2 Data in Transit - **External / public-facing services:** TLS 1.2 minimum; TLS 1.3 preferred; HSTS enforced. - **Internal services:** TLS 1.2 minimum; mTLS where the workload supports it and exposure warrants. - **Service-to-service in cloud:** provider-native mTLS or service mesh-managed mTLS. - **Email:** TLS for SMTP transport; S/MIME or PGP for content where CUI or sensitive content is in scope. ### 3.3 Authentication - **Human authentication credentials:** see [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) (phishing-resistant MFA, password storage requirements). - **Machine identities:** certificates, signed JWTs, or workload identity (cloud-native), see Section 7. ### 3.4 Signing and Integrity - **Code signing:** RSA-PSS 3072+ or ECDSA P-256+; keys in HSM; access logged. - **Container image signing:** cosign / sigstore; signature verification enforced at admission per [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) Section 7. - **Log integrity:** WORM storage and / or signing per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). - **Document signing:** PKCS#7 / CAdES with RSA-PSS or ECDSA per use case. --- ## 4. TLS and Certificate Management ### 4.1 TLS Configuration | **Parameter** | **Public-Facing** | **Internal** | |---|---|---| | Minimum protocol | TLS 1.2 | TLS 1.2 | | Preferred protocol | TLS 1.3 | TLS 1.3 | | Cipher suites | [NIST 800-52r2](https://csrc.nist.gov/pubs/sp/800/52/r2/final) approved set, AEAD only | Same | | HSTS | Required | Where applicable | | Forward secrecy | Required (ECDHE) | Required | | Renegotiation | Secure renegotiation only | Same | | OCSP stapling | Required where supported | - | ### 4.2 Certificate Inventory and Lifecycle | **Step** | **Requirement** | |---|---| | Issuance | From an approved internal CA or commercial CA; named in approved-issuers list. | | Inventory | Authoritative certificate inventory (CA + endpoints + monitored expiry). | | Validity period | Public TLS ≤ 398 days; internal ≤ 825 days; code signing per HSM-residency policy. | | Renewal | Automated where supported; alert thresholds at 60 / 30 / 14 days. | | Revocation | Documented revocation procedure; CRL/OCSP exercised quarterly. | | Private key storage | HSM or platform key store; never plaintext on disk. | | Pinning | Limited to mobile and high-risk client/server pairs; pinning rotation procedure required. | | Wildcard | Avoided for high-value services; permitted with documented risk acceptance. | --- ## 5. Key Management ### 5.1 Key Hierarchy | **Key Type** | **Storage** | **Rotation (default)** | **Owner** | |---|---|---|---| | Root / signing CA keys | HSM (offline for offline root) | n/a (CA refresh ≥ 5y) | Engineering - Platforms | | Issuing CA keys | HSM | 1–2 years | Engineering - Platforms | | Data encryption keys (DEKs) | KMS / HSM-backed | Per platform default; ≤ 1 year | Engineering - Platforms | | Key encryption keys (KEKs) | KMS / HSM | 1 year | Engineering - Platforms | | Customer-Managed Keys (CMK) | Cloud KMS HSM-backed | Per Section 8 | Engineering - Platforms | | Code signing keys | HSM | n/a (key rotation triggers re-sign) | Engineering - Platforms / Release | | TLS certificate keys | HSM or platform key store | Per certificate lifecycle | Engineering - Platforms | ### 5.2 Key Operations - **Generation**: in HSM or platform KMS; never on developer workstations. - **Distribution**: via KMS APIs / agent enrollment; never email, chat, or ticket attachments. - **Storage**: encrypted under a KEK; access logged. - **Use**: least privilege; key admin separated from key user. - **Rotation**: scheduled and event-driven (see Section 8). - **Backup / escrow**: for keys that protect long-lived data, an escrow procedure exists; the escrow itself is HSM-resident and access-controlled. - **Destruction**: keys destroyed via crypto-shred procedures with documented evidence. ### 5.3 Separation of Duties | **Action** | **Performed By** | **Approved By** | CISO |---|---| | Generate root or issuing CA key | Two named operators | Engineering Pillar Leader | | Rotate KEK | Engineering - Platforms | Engineering Pillar Leader | | Generate CMK in production | Engineering - Platforms | Workload Owner + Engineering Pillar Leader | | Destroy / disable production key | Two named operators | Engineering Pillar Leader | | Export key material (rare; exceptional) | Two named operators | Engineering Pillar Leader + CISO | --- ## 6. Customer-Managed Keys (CMK) Decision Guide The CMK decision is about who controls the master key, the customer (us) or the provider. CERG requires CMK for the cases below; otherwise provider-managed keys are acceptable. ### 6.1 CMK Required - Data classified **Restricted** at rest. - **CUI** in cloud / SaaS scopes (where the regulator permits a provider-managed alternative, CERG defaults to CMK anyway for crypto independence). - **BCSI** stored in non-OT cloud / SaaS. - **SOX** in-scope data where the auditor expects independent key control. - **High-Impact** workloads where adversary model includes provider-side compromise. - Any workload subject to a **contractual obligation** requiring customer control of keys. ### 6.2 CMK Not Required - Internal-classification data in standard cloud/SaaS. - Non-production environments. - Workloads where the provider's default key management has been assessed and accepted via the [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Inheritance Evidence Package and risk-register entry. ### 6.3 CMK Operational Requirements - Keys generated in cloud KMS HSM-backed (FIPS 140-2/3 Level 2+). - Rotation per Section 8; rotation reuses prior key for read; new writes use new key. - Key policy and access reviewed quarterly. - Key material is **never** exported outside the HSM boundary except under the documented exception process. > **What Inheritance Looks Like When CMK Is Not Required** > > "We use the provider's default key management" is only acceptable when the Inheritance Evidence Package in [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 5 is on file. Provider attestation, shared responsibility line item, customer-side configuration prerequisites, and re-papering trigger, all six elements, or CMK is required. --- ## 7. Secrets, API Keys, and Tokens Plaintext secrets in source code, configuration files, environment variables on disk, or chat history are prohibited under this standard. The handling pattern below is the only acceptable approach. ### 7.1 Storage | **Secret Type** | **Storage** | |---|---| | Application secret (database password, API key consumed by an app) | Secrets manager (HashiCorp Vault, AWS Secrets Manager / Parameter Store, Azure Key Vault, GCP Secret Manager). | | OAuth client secret | Secrets manager. | | API token issued by an internal service | Issued by an IdP-integrated token service where possible; otherwise secrets manager. | | Service account credential | Workload identity (preferred); otherwise short-lived issued credential. | | Personal access token (PAT) for human use | Created via IdP, time-bounded, scope-bounded, logged. | | Break-glass credential | Vaulted per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). | ### 7.2 Distribution and Use - **Pull, never push.** Workloads retrieve secrets at runtime from the secrets manager; secrets are not baked into images or configs. - **Short-lived where possible.** Tokens issued by IdP or STS preferred over long-lived static credentials. - **Scope-bounded.** Each token is scoped to the minimum required resource and action. - **Logged.** Issuance, retrieval, and revocation events flow to SIEM. ### 7.3 Detection and Hygiene - Repositories scanned for committed secrets; finding revokes the secret and triggers credential reissue. - CI/CD pipelines instrumented with secret-scanning gates. - SBOMs reviewed for embedded secrets in third-party dependencies. --- ## 8. Rotation Cadence | **Item** | **Default Rotation** | **Tighter For Restricted/CUI/BES** | |---|---|---| | Human passwords (where still permitted) | Length and strength controls over rotation; rotate on compromise indicator only | Same | | Privileged interactive credentials | Same as above; PAM-mediated | PAM-mediated, vaulted, JIT | | Break-glass account credentials | 90 days or on use | 90 days or on use | | Service account passwords (where unavoidable) | 90 days | 60 days | | API keys (long-lived) | 90 days | 60 days | | OAuth client secrets | 180 days | 90 days | | Bearer tokens / session tokens | Per IdP / app session policy (short-lived) | Per IdP, short-lived | | Workload / machine identity certificates | 1 year | 1 year, mTLS preferred | | TLS server certificates (public) | ≤ 398 days | - | | TLS server certificates (internal) | ≤ 825 days | ≤ 398 days | | Data Encryption Keys (DEKs) | Per platform / annually | Annually | | Key Encryption Keys (KEKs) | Annually | Annually or per event | | Customer-Managed Keys (CMKs) | Annually + on event | Annually + on event | | Code-signing keys | Per HSM policy; rotated on suspected compromise | Per HSM policy | | Issuing CA keys | 1–2 years | Same | | Root CA keys | ≥ 5 years; offline | Same | ### 8.1 Event-Driven Rotation Triggers Rotation is also triggered by, not on a schedule alone: - Suspected key / secret / credential compromise. - Workforce changes affecting individuals with key access. - HSM / KMS administrative anomaly. - Vendor incident notification (per SCCT per [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md)). - Algorithm deprecation or policy update. --- ## 9. FIPS / FedRAMP / CUI Cryptography Checklist The checklist below is the minimum for any system in CUI scope, FedRAMP Moderate scope, or other regulatory scope that requires FIPS-validated cryptography. It is used at architecture review ([`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md)) and at [CMMC](https://dodcio.defense.gov/CMMC/) assessment readiness ([`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md)). | **Check** | **Required** | **Evidence** | |---|---|---| | Cryptographic module is FIPS 140-2 (Level 1+) or FIPS 140-3 validated | ✓ | CMVP certificate number recorded | | Module is operated in FIPS-approved mode | ✓ | Configuration screenshot / IaC declaration | | Algorithms in use are on the FIPS-approved list | ✓ | Crypto inventory | | Keys are HSM-resident or HSM-backed | ✓ | KMS/HSM configuration | | TLS termination uses FIPS-validated module | ✓ | Load balancer / gateway configuration | | Cloud provider's FIPS endpoints used where required | ✓ | Endpoint configuration evidence | | FedRAMP equivalency for CUI cloud / SaaS handled per [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Inheritance Evidence Package | ✓ | TPRM record | | CMK in use for CUI data at rest | ✓ (per Section 6) | KMS key inventory | | CUI data in transit uses FIPS-validated TLS | ✓ | Configuration evidence | | Secrets manager backing CUI workloads is FIPS-validated | ✓ | Vendor attestation | --- ## 10. Roles and Responsibilities | **Role** | **Cryptography Responsibility** | |---|---| | **Cyber Engineering - Platforms** | Owns this standard. Maintains the cryptographic inventory (algorithms in use, keys, certificates). Operates the KMS/HSM and secrets management platforms. Drives migrations off deprecated algorithms. | | **Identity Engineer** | Implements credential-side controls per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md); integrates IdP/PAM token issuance with this standard. | | **Cyber Risk** | Detects use of prohibited algorithms via DISH and other tooling; tracks deprecation risk in the risk register. | | **Cyber Governance** | Maintains exceptions register for transitional algorithms; tracks audit-facing evidence; cross-references with control library. | | **Asset Owners** | Choose CMK vs. provider-managed key per Section 6 with Engineering guidance; budget for HSM/KMS cost where applicable. | | **Procurement / TPRM** | Includes cryptographic conformance in vendor assessments; flags vendor advisories that affect cryptographic posture. | --- ## 11. Document Control | | | |---|---| | **Document ID** | CERG-STD-CR-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / on FIPS publication change / on algorithm deprecation | | **Change Log** | 1.0 - Initial publication. Approved/prohibited algorithms, TLS/cert lifecycle, key management, CMK decision guide, secrets/tokens, rotation cadence, FIPS profile. | --- ## CUI HANDLING STANDARD ### [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 · Federal Contract Information --- | | | |---|---| | **Document ID** | CERG-STD-CUI-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Significant Change / [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) Revision | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final) (and r3 transition) · [NIST 800-172](https://csrc.nist.gov/pubs/sp/800/172/final) · NIST RMF | | **Regulations** | [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 · DFARS 252.204-7012, -7019, -7020, -7021 · 32 CFR Part 2002 · FAR 52.204-21 (FCI) | | **Environments** | Any system that processes, stores, or transmits CUI or FCI - owned, hybrid, cloud, contractor | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [CERG Roles in CUI Environments](#2-cerg-roles-in-cui-environments) 3. [GOVERN, CUI Program Foundation](#3-govern--cui-program-foundation) 4. [IDENTIFY, Inventory, Boundary, and Flow](#4-identify--inventory-boundary-and-flow) 5. [PROTECT, Control Implementation for CUI](#5-protect--control-implementation-for-cui) 6. [DETECT, Monitoring CUI Environments](#6-detect--monitoring-cui-environments) 7. [RESPOND, Cyber Incident Reporting Under DFARS](#7-respond--cyber-incident-reporting-under-dfars) 8. [RECOVER, Recovery and Lessons Learned](#8-recover--recovery-and-lessons-learned) 9. [Training and Personnel](#9-training-and-personnel) 10. [Regulatory and Framework Alignment Summary](#10-regulatory-and-framework-alignment-summary) 11. [Exceptions, POA&M, and SSP Maintenance](#11-exceptions-poam-and-ssp-maintenance) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope This standard implements the foundational principles established in **CERG-POL-001** for systems that process, store, or transmit Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). It defines the specific, measurable security requirements drawn from **[NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)** (the source of [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 practices), **[NIST SP 800-172](https://csrc.nist.gov/pubs/sp/800/172/final)** (where enhanced protection is contractually required), and the cyber incident reporting and flow-down obligations established by **DFARS 252.204-7012** and the **[CMMC](https://dodcio.defense.gov/CMMC/)** program rule under DFARS 252.204-7021. This standard does not replace the System Security Plan (SSP), the Plan of Action and Milestones (POA&M), or the contract-specific requirements that may apply to a given award. It establishes the organization-wide requirements that every CUI-handling system shall meet, and the governance that translates those requirements into auditable evidence. ### 1.1 Scope This standard applies to: - All information systems that **process, store, or transmit CUI** as defined in 32 CFR Part 2002 and the CUI Registry - All information systems handling **Federal Contract Information (FCI)** under FAR 52.204-21 (subject to the more limited 15-control baseline) - All **contractor and subcontractor** systems with access to CUI on behalf of the organization, including managed service providers - All **cloud service providers (CSPs)** hosting CUI on the organization's behalf (FedRAMP Moderate equivalency or higher required per DFARS 252.204-7012(b)(2)(ii)(D)) - All **personnel** with authorized access to CUI, including employees, contractors, consultants, and authorized third parties ### 1.2 The [CMMC](https://dodcio.defense.gov/CMMC/) / DFARS Reality CUI obligations are contractual. Failure to meet them is not solely a security finding, it is a contract-compliance issue that can affect eligibility for award, payment, or continued performance. The DoD's [CMMC](https://dodcio.defense.gov/CMMC/) program operationalizes 800-171 compliance with third-party certification (C3PAO) at Level 2 for most contracts handling CUI. SPRS scoring is reported and visible to contracting officers. > **One Spreadsheet Away From a Finding** > > A single CUI document stored in an unapproved location (personal email, generic file share, unmanaged endpoint) places that system inside the assessment boundary, and exposes the organization to [CMMC](https://dodcio.defense.gov/CMMC/) findings, DFARS clawback, and contract eligibility risk. Scope discipline is the foundational control. Everything else depends on knowing where CUI is, and where it is not. ### 1.3 Relationship to Parent Policy This standard is subordinate to **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)**. It implements specific requirements; it does not limit any principle established in that policy. Where the Cloud / SaaS Standard ([CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md)) and this standard both apply, both shall be satisfied, and the more stringent requirement controls. Exceptions follow the process defined in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Section 7, with additional obligations defined in Section 11 of this standard. --- ## 2. CERG Roles in CUI Environments The three CERG pillars operate in CUI environments with the same structure as elsewhere, with adaptations for contractual compliance evidence. | **CERG Pillar** | **CUI-Specific Responsibilities** | |---|---| | **Engineering** | Architects the CUI enclave - the bounded set of systems, networks, services, and endpoints inside the assessment boundary. Designs and maintains the technical controls that satisfy each 800-171 requirement. Embeds CUI handling guardrails into endpoint, identity, collaboration, and cloud platforms. Produces the technical evidence artifacts (configurations, screenshots, exported policies) that support the SSP. | | **Risk** | Operates the exposure management program inside the CUI boundary. Conducts annual self-assessments against 800-171 and tracks SPRS scores. Manages the [CMMC](https://dodcio.defense.gov/CMMC/) pre-assessment readiness program and coordinates external C3PAO engagements. Tracks 800-171 control posture as a first-class risk register category. Assesses third parties handling CUI on the organization's behalf. | | **Governance** | Owns the **System Security Plan (SSP)**, **Plan of Action and Milestones (POA&M)**, and the **[CMMC](https://dodcio.defense.gov/CMMC/) evidence library**. Maintains this standard, the CUI Registry mapping, and the data classification authority for CUI. Manages **DFARS 252.204-7012 cyber incident reporting** to DC3 within 72 hours. Coordinates contractual flow-down to subcontractors. Maintains SPRS submissions and supports DoD assessor engagements. | > **The Evidence-as-Byproduct Rule for CUI** > > [CMMC](https://dodcio.defense.gov/CMMC/) assessors do not score intentions, they score implementation evidence. The CERG model treats SSP and POA&M maintenance as continuous, byproduct work of Engineering and Risk activities, not as a one-time pre-assessment scramble. If the only time the SSP is touched is in the 90 days before a C3PAO visit, the program is not yet operating at the maturity the regulation expects. --- ## 3. GOVERN: CUI Program Foundation ### 3.1 SSP, POA&M, and [CMMC](https://dodcio.defense.gov/CMMC/) Posture | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain a current System Security Plan (SSP) describing how each [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) requirement is satisfied, with documented control implementations, responsible parties, and evidence references. Update upon any material change to the CUI environment. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.4 · [CMMC](https://dodcio.defense.gov/CMMC/) CA.L2-3.12.4 | | Maintain a Plan of Action and Milestones (POA&M) for any 800-171 requirement not fully implemented. Each POA&M item shall have a documented remediation path, owner, and target closure date. POA&M items shall not exceed the closure window allowed by the current [CMMC](https://dodcio.defense.gov/CMMC/) rule. | All CUI | Governance / Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.2 · [CMMC](https://dodcio.defense.gov/CMMC/) CA.L2-3.12.2 | | Submit and maintain a current Supplier Performance Risk System (SPRS) score reflecting the organization's [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) self-assessment. Re-score upon any material change to the CUI environment. | All CUI | Governance | DFARS 252.204-7019, -7020 | | Maintain readiness for [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 third-party assessment (C3PAO). Engage C3PAO on the cadence required by the applicable contract or rule version. | All CUI | Governance / Risk | DFARS 252.204-7021 · [CMMC](https://dodcio.defense.gov/CMMC/) rule | | Designate a senior official (e.g., CISO) as the accountable executive for CUI compliance posture. Reporting cadence to leadership and the board shall include 800-171 score, open POA&M items, and assessment status. | All CUI | CISO / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.3 · [CMMC](https://dodcio.defense.gov/CMMC/) CA.L2-3.12.3 | ### 3.2 Third-Party and Flow-Down | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Flow DFARS 252.204-7012 (and [CMMC](https://dodcio.defense.gov/CMMC/) clauses as required) to all subcontractors and service providers handling CUI on behalf of the organization. Maintain a current register of flow-down recipients. | All CUI | Governance | DFARS 252.204-7012(m) | | Assess each third party handling CUI before onboarding and annually thereafter. Assessment shall cover 800-171 posture, incident reporting capability, and DFARS flow-down compliance. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.20 · [CMMC](https://dodcio.defense.gov/CMMC/) AC.L2-3.1.20 | | Cloud service providers hosting CUI shall meet FedRAMP Moderate baseline (or equivalent as authorized under DFARS 252.204-7012(b)(2)(ii)(D)). Maintain the equivalency documentation in the SSP. | All CUI (Cloud) | Risk / Governance | DFARS 252.204-7012(b)(2)(ii)(D) | | Contract clauses with CUI handlers shall include: 72-hour incident notification to the organization, mandatory cooperation with damage assessment, malicious software preservation, and right-to-audit provisions. | All CUI | Governance | DFARS 252.204-7012 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.20 | ### 3.3 Risk and Configuration Authorities | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Document all CUI-system risk acceptance decisions in the organizational risk register with: control reference, business justification, compensating controls, and expiration. CUI risk acceptances require CISO approval at minimum. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.11.1 · [CMMC](https://dodcio.defense.gov/CMMC/) RA.L2-3.11.1 | | Maintain documented Configuration Control Board (CCB) or equivalent authority for changes to CUI-system baselines. Changes shall be reviewed for impact on 800-171 control posture before approval. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.3 · [CMMC](https://dodcio.defense.gov/CMMC/) CM.L2-3.4.3 | | Maintain a CUI environment architecture diagram showing the boundary, all components inside, all external interfaces, and all data flows in/out of the boundary. Update upon material change. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.1 · [CMMC](https://dodcio.defense.gov/CMMC/) CM.L2-3.4.1 | --- ## 4. IDENTIFY: Inventory, Boundary, and Flow ### 4.1 CUI Identification and Boundary Definition > **CUI Scope Is Not Aspirational** > > The 800-171 control set applies to "the components of nonfederal information systems that process, store, or transmit CUI, or that provide security protection for such components." Every system inside the assessment boundary inherits the full obligation. Engineering and Governance define the boundary deliberately to minimize the assessment surface, and then enforce that boundary technically and procedurally. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Identify all CUI categories handled by the organization (e.g., CDI, ITAR, Export Control, Privacy, Procurement) per the CUI Registry. Document the contractual or regulatory basis for each. | All CUI | Governance | 32 CFR 2002 · CUI Registry | | Define and document the CUI assessment boundary. The boundary shall enumerate all systems, networks, services, endpoints, and personnel that fall inside scope. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.1 | | Inventory all components inside the CUI boundary: servers, workstations, mobile devices, cloud services, applications, network components, and removable media. Update inventory upon any in-scope change. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.1 · [CMMC](https://dodcio.defense.gov/CMMC/) CM.L2-3.4.1 | | Maintain a CUI data-flow map showing how CUI enters, moves within, and leaves the boundary, including any cross-domain interactions (e.g., to FCI systems, to non-CUI corporate systems, to subcontractors). | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.3, 3.13.1 | | Mark CUI per CUI Registry handling instructions on creation. Maintain labeling controls (e.g., document-level classification labels, container marking) in collaboration platforms inside the boundary. | All CUI | Governance / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.4 · 32 CFR 2002 | ### 4.2 Risk and Vulnerability Identification | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Periodically assess risk to CUI confidentiality, integrity, and availability. Document threat sources, vulnerabilities, likelihood, and impact. Output feeds the risk register and POA&M. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.11.1 · [CMMC](https://dodcio.defense.gov/CMMC/) RA.L2-3.11.1 | | Scan CUI environment systems for vulnerabilities at least monthly, and upon advisory of new significant vulnerabilities. Authenticated scans are required where technically feasible. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.11.2 · [CMMC](https://dodcio.defense.gov/CMMC/) RA.L2-3.11.2 | | Treat confirmed exposures in the CUI environment per the SLAs defined in **[CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)**. Where treatment cannot meet SLA, open a POA&M entry. | All CUI | Risk / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.11.3 · [CMMC](https://dodcio.defense.gov/CMMC/) RA.L2-3.11.3 | --- ## 5. PROTECT: Control Implementation for CUI The fourteen [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) control families collectively define the protection requirements. The tables below summarize the organization's implementation. Detailed implementation evidence is maintained in the SSP and the [CMMC](https://dodcio.defense.gov/CMMC/) evidence library. ### 5.1 Access Control (3.1) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Limit system access to authorized users, processes, and devices. Enforce least privilege; restrict access to CUI on a need-to-know basis. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.1, 3.1.2, 3.1.5 | | Control information flows so CUI is not transmitted outside the boundary except through approved channels. Separate duties to reduce risk of malicious activity without collusion. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.3, 3.1.4 | | Control and monitor remote access and wireless access to CUI systems. All remote access to CUI shall traverse a documented secure path (e.g., VPN with MFA, conditional access). | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.12–3.1.17 | | Encrypt CUI on mobile devices and removable media. Control the use of mobile devices in the CUI environment. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.18, 3.1.19 | | Establish usage restrictions and configuration controls for external systems handling CUI. Authorize use of external systems for CUI explicitly. | All CUI | Governance / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.20–3.1.22 | ### 5.2 Awareness and Training (3.2) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Provide security awareness training to all CUI users on the risks associated with their activities and the applicable policies, standards, and procedures. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.2.1, 3.2.2 | | Provide insider threat awareness training to all CUI users. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.2.3 | ### 5.3 Audit and Accountability (3.3) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Generate audit logs sufficient to support investigation. Protect audit information and audit logging functionality from unauthorized access, modification, and deletion. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.3.1, 3.3.8, 3.3.9 | | Correlate audit record review, analysis, and reporting processes. Provide a system capability to alert on inappropriate or unusual activity. | All CUI | Risk / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.3.5, 3.3.6 | | Ensure system clocks are synchronized for accurate audit records. Retain audit logs for the period required by contract or by the SSP, whichever is longer. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.3.7 | ### 5.4 Configuration Management (3.4) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Establish and maintain baseline configurations and inventories of CUI-system components. Enforce least functionality and prohibit unnecessary software and ports. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.1, 3.4.6, 3.4.7 | | Track, review, approve, and log changes to organizational systems. Analyze the security impact of changes prior to implementation. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.3, 3.4.4 | | Apply application allow-listing (deny-by-default) for CUI-system endpoints where technically feasible. Control user-installed software. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.4.8, 3.4.9 | ### 5.5 Identification and Authentication (3.5) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Uniquely identify and authenticate organizational users, processes acting on behalf of users, and devices. Use multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.5.1, 3.5.2, 3.5.3 | | Employ replay-resistant authentication mechanisms. Prevent reuse of identifiers for a defined period. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.5.4, 3.5.5 | | Enforce minimum password complexity, prohibit password reuse for a defined number of generations, and store and transmit only cryptographically protected passwords. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.5.7–3.5.10 | | Obscure feedback of authentication information. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.5.11 | ### 5.6 Incident Response (3.6) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | The standing Incident Response team (a separate function under CISO oversight per CERG-GOV-OM-001 §3.4) owns and maintains the operational incident-handling capability. CERG coordinates with the IR team by providing detection feeds, vulnerability context, asset documentation, and post-incident risk-register entries. Test participation follows the IR team's exercise schedule. | All CUI | Incident Response Team (CERG coordinates) | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.6.1, 3.6.3 | | Track, document, and report incidents to designated officials and authorities both internal and external (including DC3 under DFARS) - see Section 7. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.6.2 · DFARS 252.204-7012 | ### 5.7 Maintenance (3.7) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Perform maintenance on CUI systems using approved tools and techniques. Sanitize equipment removed for off-site maintenance. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.7.1, 3.7.3 | | Check media containing diagnostic and test programs for malicious code. Require MFA for nonlocal maintenance sessions and terminate them when complete. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.7.4, 3.7.5 | | Supervise maintenance activities performed by personnel without required access. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.7.6 | ### 5.8 Media Protection (3.8) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Protect CUI on system media - paper and digital - through marking, access controls, transport protections, and sanitization. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.1–3.8.4 | | Sanitize or destroy media containing CUI before disposal or reuse. Maintain records of media sanitization. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.3 · NIST 800-88 | | Encrypt CUI on portable storage media outside controlled areas. Control use of removable media on CUI systems. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.6–3.8.9 | ### 5.9 Personnel Security (3.9) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Screen individuals before authorizing access to CUI systems. Re-screen upon role change to higher-privilege CUI access. | All CUI | HR / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.9.1 | | Ensure CUI and CUI systems are protected during and after personnel actions such as termination and transfer (access revocation, asset recovery, exit interviews where appropriate). | All CUI | Engineering / HR | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.9.2 | ### 5.10 Physical Protection (3.10) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Limit physical access to CUI systems, equipment, and operating environments to authorized individuals. Escort visitors and monitor visitor activity. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.10.1, 3.10.3 | | Maintain audit logs of physical access. Control and manage physical access devices. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.10.2, 3.10.4, 3.10.5 | | Enforce safeguarding measures for CUI at alternate work sites (e.g., remote work). | All CUI | Governance / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.10.6 | ### 5.11 Risk Assessment (3.11) See Section 4.2 above. ### 5.12 Security Assessment (3.12) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Periodically assess security controls for effectiveness. Develop and implement POA&M to correct deficiencies. | All CUI | Risk / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.1, 3.12.2 | | Monitor security controls on an ongoing basis to ensure continued effectiveness. Develop, document, and periodically update the SSP. | All CUI | Risk / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.3, 3.12.4 | ### 5.13 System and Communications Protection (3.13) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Monitor, control, and protect communications at external boundaries and key internal boundaries of CUI systems. Employ subnetworks for publicly accessible system components, separated from internal networks. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.13.1, 3.13.5 | | Deny network communications traffic by default and allow by exception. Prevent unauthorized and unintended information transfer via shared resources. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.13.6, 3.13.4 | | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission and at rest. Use FIPS-validated cryptography where required. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.13.8, 3.13.11, 3.13.16 | | Terminate network connections at session end or after a defined period of inactivity. Establish and manage cryptographic keys for cryptography used in the system. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.13.9, 3.13.10 | | Control and monitor the use of mobile code and Voice over IP (VoIP) technologies. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.13.13, 3.13.14 | ### 5.14 System and Information Integrity (3.14) | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Identify, report, and correct system flaws in a timely manner. Provide protection from malicious code at designated locations. | All CUI | Risk / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.14.1, 3.14.2 | | Monitor system security alerts and advisories and take action in response. Update malicious code protection mechanisms when new releases are available. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.14.3, 3.14.4 | | Monitor CUI systems, including inbound and outbound communications, to detect attacks, indicators of potential attacks, and unauthorized use. Identify unauthorized use through monitoring. | All CUI | Risk / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.14.6, 3.14.7 | --- ## 6. DETECT: Monitoring CUI Environments | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Collect security event logs from all CUI-system components capable of generating them. Centralize logs in a SIEM or equivalent inside (or logically aligned with) the CUI boundary. | All CUI | Engineering / Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.3.1 · [CMMC](https://dodcio.defense.gov/CMMC/) AU.L2-3.3.1 | | Define alerts for CUI-relevant events: failed authentication patterns, privilege escalation, CUI exfiltration indicators, configuration changes, and anti-malware events. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.3.5, 3.14.6 | | Apply endpoint detection and response (EDR) tooling to all endpoints inside the CUI boundary. EDR shall include behavioral detection, not only signature-based AV. | All CUI | Engineering / Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.14.6 · [CMMC](https://dodcio.defense.gov/CMMC/) SI.L2-3.14.6 | | Subscribe to and act on relevant security alerts and advisories - including CISA, DC3, and applicable program-specific advisories. | All CUI | Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.14.3 | --- ## 7. RESPOND: Cyber Incident Reporting Under DFARS > **The 72-Hour Clock** > > DFARS 252.204-7012 requires reporting of any "cyber incident" affecting covered defense information or the contractor's ability to perform operationally critical support, to DoD via the DC3 reporting portal, within **72 hours of discovery**. The clock starts at discovery, not at confirmation. Reporting under DFARS does not waive contractual notification to the contracting officer or customer. ### 7.1 Cyber Incident Reporting | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain a cyber incident response procedure that includes the 72-hour DC3 reporting workflow, evidence preservation requirements, and damage assessment cooperation. | All CUI | Governance / Risk | DFARS 252.204-7012(c) | | Hold a current DoD-approved medium assurance certificate to submit incident reports through the DC3 portal (Defense Industrial Base Network / DIBNet). Validate certificate currency annually. | All CUI | Governance | DFARS 252.204-7012(c)(3) | | Upon a reportable cyber incident: preserve images of affected systems, malicious software (if detected), and packet capture for at least 90 days. Make available to DoD upon request. | All CUI | Risk / Engineering | DFARS 252.204-7012(d), (e) | | Cooperate with DoD damage assessment activities including providing access to additional information, equipment, or facilities as requested. | All CUI | Governance / Risk | DFARS 252.204-7012(f), (g) | | Notify the contracting officer in addition to DC3 reporting when required by the applicable contract. | All CUI | Governance | DFARS 252.204-7012 · contract-specific | ### 7.2 Incident Response Coordination This standard does not replace the master Incident Response Plan (**[CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md)**). CUI-specific procedures supplement that plan with: DC3 reporting playbook, evidence preservation procedure, subcontractor-flow notification template, and customer / contracting officer notification template. --- ## 8. RECOVER: Recovery and Lessons Learned | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain documented recovery procedures for CUI systems including backup restoration, system rebuild from approved baselines, and integrity validation post-recovery. | All CUI | Engineering / Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.9 · [CMMC](https://dodcio.defense.gov/CMMC/) MP.L2-3.8.9 | | Protect backups of CUI with the same controls as production CUI (encryption, access control, retention). Test restoration on a defined cadence. | All CUI | Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8.9, 3.13.11 | | Conduct post-incident reviews for any cyber incident affecting CUI. Document root cause, control failures, and corrective actions. Update SSP and POA&M as needed. | All CUI | Governance / Risk | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.6.1, 3.12.2 | --- ## 9. Training and Personnel | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All personnel with CUI access shall complete CUI-specific training before access is granted and annually thereafter. Training includes CUI marking, handling, transmission, storage, and incident reporting obligations. | All CUI | Governance / HR | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.2.1, 3.2.2 | | Personnel with privileged CUI-system roles shall complete role-based training covering the specific security responsibilities of their role. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.2.2 | | Personnel responsible for CUI incident reporting (DC3 submitters, IR leads) shall be trained on the 72-hour reporting procedure and shall validate their access to the DIBNet portal at least quarterly. | All CUI | Governance | DFARS 252.204-7012(c) | | Insider threat awareness training shall be provided to all CUI personnel and documented. | All CUI | Governance | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.2.3 · [CMMC](https://dodcio.defense.gov/CMMC/) AT.L2-3.2.3 | --- ## 10. Regulatory and Framework Alignment Summary | **800-171 Control Family** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Family** | **[CMMC L2](https://dodcio.defense.gov/CMMC/) Domain** | |---|---|---|---| | 3.1 Access Control | PR.AA | AC | AC | | 3.2 Awareness & Training | GV.RR | AT | AT | | 3.3 Audit & Accountability | DE.AE | AU | AU | | 3.4 Configuration Management | PR.PS | CM | CM | | 3.5 Identification & Authentication | PR.AA | IA | IA | | 3.6 Incident Response | RS / RC | IR | IR | | 3.7 Maintenance | PR.MA | MA | MA | | 3.8 Media Protection | PR.DS | MP | MP | | 3.9 Personnel Security | GV.RR | PS | PS | | 3.10 Physical Protection | PR.AA | PE | PE | | 3.11 Risk Assessment | ID.RA | RA | RA | | 3.12 Security Assessment | GV.SC, ID.IM | CA | CA | | 3.13 System & Communications Protection | PR.IR | SC | SC | | 3.14 System & Information Integrity | DE.CM, PR.PS | SI | SI | **Contract clauses:** DFARS 252.204-7012 (Safeguarding & cyber incident reporting), DFARS 252.204-7019 ([NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) DoD Assessment Requirements), DFARS 252.204-7020 ([NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) DoD Assessment Requirements, Offeror Submission), DFARS 252.204-7021 (Cybersecurity Maturity Model Certification Requirements). FAR 52.204-21 governs FCI for the 15-control subset. --- ## 11. Exceptions, POA&M, and SSP Maintenance CUI control deficiencies do not follow the ordinary exception process. Open deficiencies are tracked in the POA&M and reflected in the SPRS score. The exception process in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Section 7 applies in addition for organizational risk acceptance. | **Deficiency / Exception Type** | **Mechanism** | **Approval / Tracking** | **Review** | |---|---|---|---| | 800-171 requirement not fully implemented | POA&M entry in SSP | CISO + Governance | Until closed; [CMMC](https://dodcio.defense.gov/CMMC/) rule defines max open windows | | Compensating control in lieu of an 800-171 control | Documented in SSP with rationale | CISO; assessor judgment at C3PAO | Annual | | Risk acceptance for an open POA&M item beyond standard window | Risk register + POA&M annotation | CISO + executive sponsor | Quarterly | | Subcontractor flow-down gap | Contract amendment process; risk register entry | Governance + Legal + Procurement | Per contract cycle | | Emergency operational deviation (e.g., temporarily expanded access) | 24-hour formal exception + POA&M update | CISO post-hoc within 24 hours | 30 days maximum | --- ## 12. Document Control | | | |---|---| | **Document ID** | CERG-STD-CUI-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / Upon Significant Change / NIST 800-171 Revision | | **Change Log** | 1.0 - Initial publication. NIST 800-171r3, DFARS 252.204-7012, CMMC Level 2. | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 DRAFT | 2026 | CERG Governance | Initial release - [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final), DFARS 252.204-7012, [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 | ### Review Triggers This standard shall be reviewed annually and upon any of the following triggering events: - Revision to [NIST SP 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) (e.g., transition to Rev 3) or [NIST SP 800-172](https://csrc.nist.gov/pubs/sp/800/172/final) - Material change to the DFARS 252.204-7012 / -7019 / -7020 / -7021 clauses or the [CMMC](https://dodcio.defense.gov/CMMC/) rule - Material change to the CUI environment, boundary expansion, new CUI category, new subcontractor flow-down - A reportable cyber incident affecting CUI - DoD assessor or C3PAO finding requiring corrective action Governance owns this document. The Governance Pillar Leader ([CMMC](https://dodcio.defense.gov/CMMC/) / Federal Compliance) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - this standard is subordinate | | IT (Hosted/Cloud/SaaS) Security Standard | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Peer standard - applies in addition to this where CUI is hosted on cloud/SaaS | | Grid and Control System Standard | [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Peer standard - governs OT estates | | Access Management Standard | [CERG-STD-AC-001](CERG-STD-AC-001_Access_Management_Standard.md) | Peer standard - identity/access requirements applied inside CUI boundary | | Exposure Management Procedure | [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Exposure classification, treatment, patch hygiene, and remediation SLA source | | Risk Register and Exception Process | [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk acceptance and exception workflow for CUI-related residual risk | | CUI / CMMC Operational Package | [CERG-PLN-CUI-001](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | SSP, POA&M, SPRS, and assessment-readiness package | --- ## CYBER RESILIENCE AND BACKUP STANDARD ### Recovery Tiers · Backup Protection · Restoration Testing · Regulated Overlays · BCP Interface --- | | | |---|---| | **Document ID** | CERG-STD-RES-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Resilience) | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-CFG-001](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-CR-001](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-STD-LM-001](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On major platform change | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CP) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (RECOVER) · NIST 800-184 · ISO/IEC 27031 | | **Regulations** | NERC-CIP CIP-009 · [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.8 / 3.6) · SOX ITGC (Backups / Operations) | | **Environments** | Owned data center · IaaS / PaaS · SaaS Tier 1 · OT (BES and non-BES) · CUI scopes | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Boundary: Cyber Resilience vs. Enterprise BCP](#2-boundary-cyber-resilience-vs-enterprise-bcp) 3. [Recovery Tiers and RTO/RPO Model](#3-recovery-tiers-and-rtorpo-model) 4. [Backup Protection and Immutability](#4-backup-protection-and-immutability) 5. [Restoration Testing](#5-restoration-testing) 6. [Cloud and SaaS Recovery](#6-cloud-and-saas-recovery) 7. [OT Recovery and CIP-009](#7-ot-recovery-and-cip-009) 8. [CUI Recovery](#8-cui-recovery) 9. [SOX Availability Evidence](#9-sox-availability-evidence) 10. [Roles and BCP Interface](#10-roles-and-bcp-interface) 11. [Recovery Plan Template](#11-recovery-plan-template) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The policy, IT standard, OT standard, CUI standard, compliance matrix, and RMF all require documented and tested recovery plans, backup protection, and restoration evidence. Until this standard, those obligations had no shared executable definition, RTO/RPO tiers, immutability requirements, restoration evidence formats, and the boundary with enterprise BCP were left for each subordinate document to imply. This standard closes that gap. It applies to every in-scope asset that has data, configuration, or workload state worth recovering. > **Cyber Resilience Is Not BCP** > > Business continuity owns the *business* recovery: order processing keeps moving, customers are notified, alternate sites stand up. CERG owns the *cyber* recovery: the systems and data are restored from clean, immutable backups onto known-good baselines, with identity and detection re-enabled. The two programs coordinate; they do not substitute for each other. --- ## 2. Boundary: Cyber Resilience vs. Enterprise BCP | **Question** | **Owner** | |---|---| | Are critical backups taken, protected, and restorable? | CERG (this standard). | | Are systems restored to a clean, hardened state with known-good baselines? | CERG (this standard). | | Is identity, detection, and logging brought back online on the recovered system? | CERG (this standard). | | Are operational workarounds and customer communications in place during the outage? | Enterprise BCP. | | Is the business processing relocated to an alternate site / process? | Enterprise BCP. | | Are non-cyber dependencies (people, facilities, supplies) recovered? | Enterprise BCP. | CERG produces inputs to Enterprise BCP: tested cyber recovery plans, RTO/RPO actuals, and clean-restore preconditions. Enterprise BCP produces inputs to CERG: business criticality tiering, alternate-site cyber dependencies, and recovery priority calls during an event. --- ## 3. Recovery Tiers and RTO/RPO Model Every in-scope asset has a CERG recovery tier. The tier drives RTO/RPO targets, backup frequency, immutability requirements, and restoration test cadence. Tiering is owned by Engineering in partnership with the business and Enterprise BCP, the business sets criticality, CERG sets the cyber tier consistent with criticality. | **Tier** | **Description** | **RTO (Cyber)** | **RPO** | **Backup Frequency** | **Restoration Test** | |---|---|---|---|---|---| | **T1 - Mission-Critical** | Outage causes safety, regulatory, or material financial loss within hours. | ≤ 4 hours | ≤ 15 minutes | Continuous / near-continuous | Quarterly full restore; annual full DR exercise | | **T2 - Business-Critical** | Outage materially impairs operations within one business day. | ≤ 24 hours | ≤ 4 hours | Hourly to every 4 hours | Semi-annual restore; annual exercise | | **T3 - Important** | Outage degrades operations but is tolerable for a few days. | ≤ 72 hours | ≤ 24 hours | Daily | Annual restore | | **T4 - Standard** | Outage is inconvenient; standard business hours recovery acceptable. | ≤ 1 week | ≤ 24 hours | Daily | Annual restore | | **T5 - Non-Production** | Dev/test/sandbox. Recovery is rebuild from code/IaC. | Best effort | n/a | n/a (rebuild from IaC) | n/a | > **The RTO Number Is Honest or It Is Useless** > > A T1 RTO of 4 hours that has never been demonstrated by a real restoration is a number on a slide. CERG only certifies an asset to a tier after a restoration test demonstrates the RTO/RPO. Until then the asset is classified Tier "Aspirational" and tracked in the resilience register as a Planned control. --- ## 4. Backup Protection and Immutability Every backup of an in-scope asset meets the following requirements at minimum. Tier-specific tightening is named where it applies. ### 4.1 The Backup Protection Checklist | **Requirement** | **All Tiers** | **T1 / T2 / BES / CUI** | |---|---|---| | Backups taken at the frequency in Section 3 | ✓ | ✓ | | Backups encrypted at rest (CMK where Restricted/CUI per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md)) | ✓ | ✓ | | At least one copy stored on immutable storage (object-lock / WORM / air-gap) | ✓ | ✓ | | Backups stored in a separately-credentialled tenancy / account / domain | ✓ | ✓ | | Backup admin role separate from production admin role; MFA enforced | ✓ | ✓ | | Backup deletion / shortening requires two-person approval | - | ✓ | | Backup retention period meets the longer of: business need · regulatory minimum · 13 months default | ✓ | ✓ | | Backups validated for integrity at write and on a sample cadence | ✓ | ✓ | | Backup of configurations / firmware / logic / historian (OT scope) per Section 7 | n/a | ✓ (BES) | | One offline / "cold" copy of critical baselines and recovery preconditions | - | ✓ | ### 4.2 The Air-Gap and Immutability Rationale Ransomware tooling routinely attacks backup systems before triggering encryption. The immutability and credential separation requirements above exist specifically because production-attached, production-credentialled backups are not a defense. > **If the Backup Lives on Production, It's Not a Backup** > > A snapshot taken on the same storage system as production, accessible by the same credentials, is a convenience feature. It is not a cyber backup. The cyber backup lives somewhere a compromised production-domain identity cannot reach. --- ## 5. Restoration Testing A backup that has never been restored is a hope, not a control. Restoration tests produce evidence per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) control-to-evidence mapping. ### 5.1 Cadence | **Tier** | **Backup Integrity Check** | **Sample Restore** | **Full Restore Test** | **Full DR Exercise** | |---|---|---|---|---| | T1 | Continuous | Monthly | Quarterly | Annual | | T2 | Continuous | Quarterly | Semi-annual | Annual | | T3 | Daily | Quarterly | Annual | n/a | | T4 | Daily | Annual | Annual | n/a | | BES | Daily | Quarterly | Annual (CIP-009 R3) | Annual (CIP-009 R2) | | CUI | Daily | Quarterly | Annual | Annual | ### 5.2 Restoration Test Procedure Each full restoration test follows the procedure below and produces the evidence artifact in Section 5.3. 1. **Pre-test brief**, scope, success criteria, RTO/RPO targets, dependencies, business / OT owner notified. 2. **Isolate** the recovery environment from production where applicable (no risk of overwriting production). 3. **Restore** from immutable copy onto a clean baseline (DISH profile per [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md)). 4. **Bring up identity, logging, detection, and monitoring** before declaring the system available. 5. **Validate** data integrity against last known-good (hash, checksum, sample query). 6. **Measure** RTO actual and RPO actual against targets. Document deltas. 7. **Tear down** or promote per scope. 8. **Lessons learned** captured into the resilience register and, where applicable, the risk register. ### 5.3 Restoration Test Evidence | **Field** | **Required?** | **Notes** | |---|---|---| | Asset / System ID | ✓ | From asset inventory | | Tier | ✓ | Per Section 3 | | Backup Source (system, location, immutability evidence) | ✓ | - | | Date / Duration | ✓ | - | | Participants and roles | ✓ | - | | RTO Target / Actual | ✓ | - | | RPO Target / Actual | ✓ | - | | Baseline applied during recovery | ✓ | DISH tier reference | | Identity / logging / detection re-enabled | ✓ | Named systems | | Integrity check method and result | ✓ | - | | Issues encountered | ✓ | - | | Lessons learned and follow-up actions | ✓ | Risk register IDs if any | | Approver sign-off | ✓ | Engineering Pillar Leader + Asset Owner | --- ## 6. Cloud and SaaS Recovery Cloud and SaaS recovery is shaped by the shared-responsibility model. CERG does not assume provider recovery covers customer-side obligations. ### 6.1 Cloud-Native Workloads (IaaS / PaaS) - **IaC reconstruction**: production environments rebuildable from version-controlled IaC plus data backups. - **Account / subscription / project failure modes**: tested at the in-scope cadence, including region failure, account compromise, and IAM root account loss. - **Provider-side recovery contacts and escalation paths**: documented in the Recovery Plan; verified annually. - **Cross-region or cross-cloud failover**: where required by Tier, tested and evidenced. ### 6.2 Tier 1 SaaS Provider native restore is the first line; CERG-managed SaaS backup is added where provider native restore is insufficient or where regulator requires customer-controlled backup. | **Tier 1 SaaS** | **Provider Native Restore Sufficient?** | **CERG-Managed SaaS Backup?** | |---|---|---| | M365 (Exchange / SharePoint / OneDrive / Teams) | Limited (retention / point-in-time) | Yes - for CUI workspaces and SOX-relevant mailboxes/sites | | Salesforce | Limited | Yes - daily export for SOX in-scope orgs | | ServiceNow | Yes (provider managed) | Audit-only export quarterly | | Other Tier 1 | Decision per onboarding review | Documented in shared responsibility matrix | --- ## 7. OT Recovery and CIP-009 OT recovery is uniquely prescriptive. CERG implements CIP-009 fully and extends it where multiple operating segments demand more. ### 7.1 OT Artifacts That Must Be Backed Up CIP-009 R1 specifies recovery plans; CERG requires that the following OT artifacts are explicitly in backup scope: - Configuration files (SCADA, HMI, historian, jump server, network device, firewall) - Firmware images and versions in service (RTU, relay, OT switch, controller) - Software installers for the in-service OS, application, and engineering tool versions - Logic files (PLC ladder logic, RTU configuration, relay setting groups) - Historian data sets at the retention required for operational and regulatory needs - Relay setting groups with version, date, and operator metadata - Engineering tool images and licensing artifacts - Jump server images / known-good baselines - Documentation: as-built diagrams, ESP/EAP topology, vendor compatibility matrices ### 7.2 CIP-009 R1 / R2 / R3 Implementation - **R1, Recovery Plan Specifications:** documented per asset class; reviewed annually; includes roles, processes for backup management, and methods to preserve data essential for restoration. - **R2, Recovery Plan Implementation and Testing:** tested at least once every 15 months; one full operational exercise every 36 months (per CIP-009 R2.2). - **R3, Lessons Learned and Plan Updates:** documented within 90 days of any plan implementation or test. ### 7.3 OT Restoration Cautions > **OT Recovery Has Safety Implications** > > Restoring a misconfigured relay setting group from backup can shed load or trip a substation. OT restoration is supervised by an operator with substation-engineering authority, never by Cyber alone. The Recovery Plan names the operator role explicitly. --- ## 8. CUI Recovery CUI recovery aligns with [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.8 (Media Protection, backups) and 3.6 (Incident Response, recovery from incident affecting CUI). - **Backup encryption** uses FIPS-validated cryptography per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). - **Backup storage** stays within the CUI enclave or its provider-equivalent boundary; no cross-spillage to non-CUI environments. - **Restoration test** validates that CUI labeling, access control, and logging are intact after recovery. - **Post-incident updates** to SSP and POA&M per [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md). - **Incident-driven recovery**: if a CUI system is recovered following an incident, the recovery itself is documented as POA&M follow-up. --- ## 9. SOX Availability Evidence SOX-relevant systems (per [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) SOX-Relevant System Register) require evidence of backup, restoration, and availability controls reusable in the SOX cycle. | **SOX ITGC - Backup / Operations** | **Reused CERG Evidence** | |---|---| | Backups are taken | Backup tool report; failure logs | | Backups can be restored | Restoration test evidence (this standard, Section 5.3) | | Restoration is timely | RTO actual against tier target | | Failed jobs are remediated | Backup job ticket history | | Availability incidents are tracked | Incident records (per [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md)) with cyber annotation | SOX evidence reuses these artifacts; no duplicate "SOX-only" restoration test is performed. --- ## 10. Roles and BCP Interface | **Role** | **Resilience Responsibilities** | |---|---| | **CERG - Engineering (Resilience)** | Owns this standard. Maintains the resilience register (tier per asset, last test result, next test date). Coordinates restoration tests. Maintains Recovery Plans (Section 11) for in-scope assets. Provides clean-restore preconditions to BCP. | | **CERG - Risk** | Tracks resilience-related risks (untested plans, expired tests, T1 gaps). Adversarial validation may include backup/recovery as an attack target. | | **CERG - Governance** | Tracks evidence currency (control CP-2, CP-4, CP-9, CP-10 in [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md)). Liaises with auditors. | | **Asset / Business Owners** | Define business criticality. Participate in restoration tests. Approve Recovery Plan changes. | | **OT Operations** | Lead OT restoration; consume Recovery Plan; supervise restorations with operational safety authority. | | **Enterprise BCP** | Owns business recovery. Consumes CERG cyber readiness signals; provides recovery priority decisions during an event. | | **Incident Response** | Activates Recovery Plans during incidents; CERG provides clean-restore baselines and recovery support. | --- ## 11. Recovery Plan Template Every in-scope asset (or asset cluster) has a Recovery Plan in the format below. ``` RECOVERY PLAN - PLAN-RES-YYYY-NNNN 1. ASSET CONTEXT System ID(s) : Tier : (T1–T5) Business Owner : Engineering Owner : OT Operator (if OT) : Regulatory Scope : CUI / BES / SOX / None Dependencies : (named upstream/downstream systems) 2. TARGETS RTO (cyber) : RPO : Last Demonstrated RTO : Last Demonstrated RPO : Test Cadence : 3. BACKUP CONFIGURATION Backup System(s) : Frequency : Immutability Mechanism : Retention : Backup Credentials/Owner : (separately credentialled) Encryption / Key Source : (CMK ref per [CERG-STD-CR-001](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md)) 4. RESTORATION PROCEDURE Pre-test brief : (process / template) Restore steps : (ordered; reference runbooks) Identity / logging / detection re-enable steps Validation steps : Tear-down / promotion : 5. CIP-009 NOTES (if BES) R1 / R2 / R3 references : Operator role with restore authority : 6. CUI NOTES (if CUI) FIPS crypto evidence : POA&M update path : 7. SOX NOTES (if SOX in-scope) Evidence reuse mapping : (per Section 9) 8. INTERFACE TO ENTERPRISE BCP BCP Plan reference : Hand-off triggers : 9. CHANGE LOG ``` A populated example is maintained in the resilience program library; the template is reused without modification. --- ## 12. Document Control | | | |---|---| | **Document ID** | CERG-STD-RES-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / major platform change | | **Change Log** | 1.0 - Initial publication. Establishes recovery tiers, backup protection, restoration testing, regulated overlays, and BCP interface. | --- ## DATA GOVERNANCE AND CLASSIFICATION STANDARD ### Classification Scheme · Labeling · Handling · Retention · Data Loss Prevention · Data Lifecycle --- | | | |---|---| | **Document ID** | CERG-STD-DG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md) · [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On material change to data handling obligations | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (MP, SC-28, AC families) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.AM, PR.DS) · ISO/IEC 27001 A.5.12, A.5.13 · [CIS Controls v8](https://www.cisecurity.org/controls) (Control 3) | | **Regulations** | CMMC L2 / 800-171r3 (CUI) · SOX ITGC (financial data) · NERC-CIP (BES Cyber System Information) · privacy regimes where applicable | | **Environments** | All in-scope environments and all data CERG-managed systems store, process, or transmit | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [The Classification Scheme](#3-the-classification-scheme) 4. [Classifying Data](#4-classifying-data) 5. [Labeling](#5-labeling) 6. [Handling Requirements by Classification](#6-handling-requirements-by-classification) 7. [The Data Lifecycle](#7-the-data-lifecycle) 8. [Retention and Disposal](#8-retention-and-disposal) 9. [Data Loss Prevention](#9-data-loss-prevention) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope CERG protects data. Every other standard is, in the end, in service of keeping the right data confidential, intact, and available. Yet the program has had no general scheme for saying how sensitive a given piece of data is. The CUI Handling Standard governs one specific regulated category exhaustively; nothing governed the rest. The Asset Management Standard requires every asset to carry a data classification but pointed at a scheme that did not yet exist. This standard is that scheme. This standard establishes the general data governance framework for CERG: the classification scheme, how data is classified and labeled, the handling requirements each classification carries, the data lifecycle, retention and disposal, and data loss prevention. It applies to all data CERG-managed systems store, process, or transmit, in every environment. It does not replace [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md); CUI is a regulated category with its own exhaustive handling rules, and where data is CUI, the CUI standard governs. This standard provides the general scheme into which CUI fits as the most restrictive category. > **Classification Is Not About Labels. It Is About Treatment.** > > A classification scheme that produces labels and nothing else is a filing exercise. The point of classifying data is that the classification decides how the data is treated: who may access it, whether it is encrypted, how it is backed up, how long it is kept, and what happens if someone tries to send it outside. Section 6 is the part of this standard that matters. The scheme in Section 3 exists to drive it. --- ## 2. Principles 1. **All data has a classification.** Data is classified, explicitly or by a sensible default. Unclassified data is not a category; it is an unfinished task. 2. **Classify by impact.** Data's classification reflects the harm that would result from its unauthorized disclosure, alteration, or loss, not who created it or where it lives. 3. **The highest element sets the classification.** A collection of data carries the classification of the most sensitive element it contains. A report that mixes public figures with one Confidential number is Confidential. 4. **Classification drives treatment.** The classification is the input to access, encryption, backup, retention, and monitoring decisions in the other standards. This standard produces the classification once. 5. **Classification travels with the data.** When data is copied, exported, or moved, its classification and its handling requirements move with it. A copy is not a way to launder a classification away. 6. **Least data.** Data that is not collected cannot be breached. The program collects and retains the data it needs and disposes of data it no longer needs. --- ## 3. The Classification Scheme CERG uses four classification levels. An organization adopting CERG may rename the levels to fit its own conventions through [`CERG-GOV-VAR-001`](../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md), but the four-level structure and its meaning are fixed. | **Level** | **Definition** | **Examples** | |---|---|---| | **Public** | Disclosure causes no harm. Approved for release outside the organization. | Published marketing material, public filings, this document. | | **Internal** | For use within the organization. Disclosure causes minor harm. The default for ordinary business data. | Internal procedures, routine internal email, non-sensitive project material. | | **Confidential** | Disclosure causes significant harm to the organization, its people, or its partners. Access is limited to those with a need. | Financial data before release, contracts, personal data, security documentation, most regulated data. | | **Restricted** | Disclosure causes severe harm. Access is tightly limited and individually justified. | CUI, BES Cyber System Information, secrets and keys, the most sensitive personal and legal data. | > **Four Levels, Not Fourteen** > > The temptation in a classification scheme is to add levels until every shade of sensitivity has its own. A scheme with too many levels is one nobody can apply consistently, and an inconsistently applied scheme is worse than a coarse one. Four levels is enough to drive genuinely different treatment and few enough that every employee can learn them. Regulated categories like CUI are not new levels; they are Restricted data with additional handling rules layered on by their own standard. --- ## 4. Classifying Data 1. **The data owner classifies.** Every data asset has an owner, per [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md). The owner assigns the classification and is accountable for it being correct. 2. **Classify at creation.** Data is classified when it is created or acquired, not when someone later notices it is sensitive. 3. **The default is Internal.** Data created without an explicit classification is treated as Internal. The default is deliberately not Public; data is not exposed by omission. Data is not defaulted to Confidential either, because a default that over-classifies trains people to ignore the scheme. 4. **Regulated data is classified by its regime.** Data subject to a regulatory category, CUI, BES Cyber System Information, financial data in SOX scope, is classified at the level that regime requires, which is Confidential or Restricted, and handled additionally per the relevant standard or operational package. 5. **Reclassification is deliberate.** A classification changes only by a recorded decision of the data owner. Data is commonly declassified when it is approved for release, for example a financial figure once it is published. Lowering a classification is a decision, not a drift. --- ## 5. Labeling 1. **Confidential and Restricted data is labeled.** Data at the Confidential and Restricted levels carries a visible classification label wherever the format allows: document headers or footers, email subject or banner, dataset metadata. 2. **Internal and Public labeling is recommended, not required.** Labeling Internal and Public data is encouraged for clarity but not mandatory, so the labeling effort concentrates where it matters. 3. **Labels are machine-readable where possible.** Where the platform supports classification metadata, the label is applied as metadata, not only as visible text, so that data loss prevention (Section 9) and access controls can act on it. 4. **An unlabeled Confidential or Restricted item is a finding.** Discovering sensitive data with no label is a handling failure and is corrected. --- ## 6. Handling Requirements by Classification This table is the operative core of the standard. It states the minimum handling for each classification. The other standards implement these requirements; this table is the single place they are stated together. | **Handling Control** | **Public** | **Internal** | **Confidential** | **Restricted** | |---|---|---|---|---| | Access model | Open | All employees | Need-to-know, per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Individually justified, need-to-know | | Encryption in transit | Recommended | Required | Required | Required | | Encryption at rest | Optional | Recommended | Required | Required | | Storage location | Any approved | Approved internal or managed cloud | Approved, access-controlled repositories only | Approved, access-controlled, and monitored repositories only | | External sharing | Permitted | Approved business need | Approved, with recipient agreement and controls | Prohibited unless an explicit, recorded authorization exists | | Removable media | Permitted | Permitted | Discouraged; encrypted if used | Prohibited unless an exception is recorded | | Backup | Per asset class | Per asset class | Required, per [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Required, with recovery tested | | Logging of access | Optional | Recommended | Required, per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Required, access logged and reviewable | | Disposal | Standard | Standard | Secure disposal, evidenced | Secure disposal, evidenced, per [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) §9 | | Data loss prevention | Not monitored | Monitored | Monitored and enforced | Monitored and enforced | Encryption requirements are met using the algorithms and key management of [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). Where a regulated category imposes a stricter requirement than this table, the stricter requirement governs. --- ## 7. The Data Lifecycle Data moves through a lifecycle, and a handling requirement applies at each stage. | **Stage** | **What Happens** | **Handling Requirement** | |---|---|---| | **Create or acquire** | Data is generated or received. | Classified per Section 4; labeled per Section 5. | | **Store** | Data is held at rest. | Stored and encrypted per the Section 6 table for its classification. | | **Use and process** | Data is accessed and worked with. | Accessed on a need-to-know basis; access logged per classification. | | **Share and transmit** | Data moves between people, systems, or organizations. | Transmitted encrypted; external sharing constrained per Section 6; classification travels with it. | | **Archive** | Data is retained but no longer in active use. | Retained per Section 8; access narrowed; still classified and protected. | | **Dispose** | Data is destroyed at the end of retention. | Securely disposed per Section 8; disposal evidenced for Confidential and Restricted data. | --- ## 8. Retention and Disposal 1. **Data has a retention period.** Each category of data has a defined retention period, set by business need and by legal and regulatory obligation. The retention schedule is maintained by Governance. 2. **Retention is enforced.** Data is kept for its retention period and is disposed of at the end of it. Keeping data indefinitely "in case" is not a retention decision; it is the absence of one, and it grows the breach surface every year. 3. **Legal hold overrides retention.** Data subject to a legal hold is preserved regardless of its retention period until the hold is lifted. Legal hold is the one authorized reason to retain data past its schedule. 4. **Disposal is secure and evidenced.** Disposal of Confidential and Restricted data is secure, sanitization appropriate to the medium and classification, and produces a retained disposal record. Disposal of data assets is coordinated with asset disposal per [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) §9. 5. **Backups respect retention conceptually but follow their own cycle.** Backup copies follow the backup retention cycle in [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md). Where a regulation requires data to be provably destroyed everywhere, including backups, that requirement is handled through the relevant operational package. > **Data You No Longer Need Is Pure Liability** > > Old data has all of the breach exposure and almost none of the value. The customer records from a system retired six years ago cannot help the business, but they can absolutely be stolen. Retention discipline is one of the few security controls that reduces risk and reduces cost at the same time, because storing less data costs less and exposes less. CERG treats indefinite retention as a finding, not a safe default. --- ## 9. Data Loss Prevention 1. **DLP monitors Confidential and Restricted data.** Data loss prevention monitors for Confidential and Restricted data moving in ways its classification does not permit: leaving the organization by email, upload, or removable media. 2. **DLP enforces, it does not only observe.** For Confidential and Restricted data, DLP blocks or quarantines unauthorized movement, not merely logs it after the fact. 3. **DLP uses the classification labels.** DLP acts on the machine-readable labels from Section 5 and on content inspection. This is why labeling sensitive data is required, not optional. 4. **DLP events are detection signals.** A DLP block or alert is a signal delivered to the detection platform per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). A pattern of DLP events involving one user or one dataset is investigated. 5. **DLP coverage spans the data paths.** DLP covers the realistic exfiltration paths for the estate: email, web upload, cloud storage sync, and removable media. Coverage gaps are recorded as accepted risk until closed. --- ## 10. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Data Governance Responsibility** | |---|---| | **Governance Pillar Leader** | Owns this standard. Owns the classification scheme, the retention schedule, and the handling-requirements table. | | **Policy & Standards Manager** | Maintains this document; maintains the retention schedule; coordinates labeling guidance. | | **Asset Owners** | Classify the data assets they own; assign and maintain the classification; make reclassification decisions. | | **Identity Engineer** | Implements need-to-know access for Confidential and Restricted data per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). | | **Cloud Security Engineer** | Implements DLP on cloud and SaaS data paths; enforces approved storage locations. | | **Endpoint Engineer** | Implements DLP and removable-media control on endpoints per [`CERG-STD-EP-001`](CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md). | | **Cryptography Engineer** | Provides the encryption that the handling table requires. | | **Detection Engineer** | Owns detection content for DLP events and anomalous data access. | | **CMMC / Federal Compliance Manager** | Ensures CUI, as Restricted data, is also handled per [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md). | | **Evidence Librarian** | Retains disposal records and classification evidence for audit. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST 800-53r5 | RA-2 (security categorization), MP family (media protection), SC-28 (protection at rest), AC-3, AC-21 | Sections 3, 6, 8 | | NIST CSF 2.0 | ID.AM-05 (data classification), PR.DS (data security) | Sections 3, 6, 7 | | ISO/IEC 27001 | A.5.12 (classification of information), A.5.13 (labelling), A.5.14 (information transfer) | Sections 3, 5, 6 | | CIS Controls v8 | Control 3 (data protection) | Sections 6, 8, 9 | | NIST 800-171r3 / CMMC L2 | CUI as Restricted data; media protection 3.8.x | Sections 3, 6 | | SOX ITGC | Financial data confidentiality and retention | Sections 6, 8 | | NERC-CIP | BES Cyber System Information as Restricted data | Sections 3, 6 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-DG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to data handling obligations | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST 800-53r5 (MP, SC-28, AC); NIST CSF 2.0 (ID.AM, PR.DS); ISO/IEC 27001 A.5; CIS Controls v8 (3) | | **Regulations** | CMMC L2 / 800-171r3; SOX ITGC; NERC-CIP; privacy regimes where applicable | | **Environments** | All in-scope environments and data | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Governance | Initial release. Establishes the four-level classification scheme, how data is classified and labeled, the handling-requirements table that drives treatment across the other standards, the data lifecycle, retention and disposal with indefinite retention treated as a finding, and data loss prevention. Provides the general classification scheme that CERG-STD-AM-001 and CERG-STD-CUI-001 reference. | ### Review Triggers - New or changed regulatory data-handling obligation - Revision of relevant NIST or ISO data-protection guidance - A significant data-loss or data-exposure incident - Internal audit or regulatory finding affecting data governance - Direction from the CISO Cyber Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CUI Handling Standard | [`CERG-STD-CUI-001`](CERG-STD-CUI-001_CUI_Handling_Standard.md) | CUI is Restricted data with additional regulated handling | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Assets carry the classification this standard defines; data assets and disposal | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Need-to-know access for Confidential and Restricted data | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Encryption that the handling table requires | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Backup of Confidential and Restricted data | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Access logging and DLP detection content | | Endpoint and Mobile Security Standard | [`CERG-STD-EP-001`](CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md) | Endpoint DLP and removable-media control | | Organization Adaptation Profile | [`CERG-GOV-VAR-001`](../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) | Adopter may rename the classification levels | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `DG` domain | --- ## EMAIL AND MESSAGING SECURITY STANDARD ### Email Authentication · Anti-Phishing · Inbound and Outbound Protection · Collaboration Tools --- | | | |---|---| | **Document ID** | CERG-STD-MSG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On material change to the email or collaboration platform | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (SC, SI, AC families) · [NIST 800-177](https://csrc.nist.gov/pubs/sp/800/177/r1/final) (Trustworthy Email) · [CIS Controls v8](https://www.cisecurity.org/controls) (Control 9) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (PROTECT, DETECT) | | **Regulations** | CMMC L2 / 800-171r3 (3.13.x, 3.14.x) · SOX ITGC · privacy regimes where applicable | | **Environments** | All CERG-managed email and messaging: corporate email, business collaboration and messaging platforms | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Email Authentication](#3-email-authentication) 4. [Inbound Email Protection](#4-inbound-email-protection) 5. [Anti-Phishing](#5-anti-phishing) 6. [Outbound Email and Data Protection](#6-outbound-email-and-data-protection) 7. [Mailbox and Account Security](#7-mailbox-and-account-security) 8. [Collaboration and Messaging Platforms](#8-collaboration-and-messaging-platforms) 9. [Monitoring and Detection](#9-monitoring-and-detection) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope Email is the most attacked surface in nearly every organization. It is how most phishing arrives, how most credentials are stolen, how most business email compromise begins, and how a great deal of data quietly leaves. The IT, Access, and Data Governance standards each touch email at the edges; none of them owns it. This standard does. This standard establishes the requirements for email and messaging security across CERG-managed environments: how email is authenticated so the organization's domain cannot be trivially impersonated, how inbound email is filtered, how the organization defends against phishing, how outbound email is protected against data loss, how mailboxes are secured, and how business collaboration and messaging platforms are governed. It applies to corporate email and to the business messaging and collaboration platforms CERG-managed teams use. It does not govern incident response to a successful email-borne compromise, which is the standing Incident Response team's, per [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4; CERG provides the detections and the telemetry. > **Email Security Is Mostly About Two Directions** > > Email security comes down to two questions. Inbound: can a hostile message reach an employee, and if it does, can the employee tell? Outbound: can sensitive data leave in an email, and can the organization's own domain be used to attack others? Almost every control in this standard serves one of those two directions. A program that filters inbound well and ignores outbound has done half the job. --- ## 2. Principles 1. **Authenticate the domain.** The organization's email domains are configured so that mail claiming to be from them can be verified, and forgeries can be rejected. An unauthenticated domain is a free tool for every attacker. 2. **Filter before the inbox.** Hostile and unwanted mail is stopped before it reaches a person wherever a machine can judge it. Human vigilance is the last layer, not the first. 3. **Assume some phishing gets through.** No filter is perfect. The program prepares employees to recognize and report what gets through, and prepares to respond when someone clicks. 4. **A reported phish is a gift.** An employee who reports a suspicious message is doing security work. Reporting is made easy, and reporting is never punished, even when the employee also clicked. 5. **Outbound is a data-loss path.** Email is one of the most common ways sensitive data leaves. Outbound email is governed by the data classification scheme. 6. **Messaging platforms are email's equal.** Business chat and collaboration platforms carry the same data and the same attacks as email and are governed with the same seriousness. --- ## 3. Email Authentication The organization's email domains, including domains that are owned but not used to send mail, are configured with the three standard email authentication mechanisms. 1. **SPF.** A Sender Policy Framework record is published for every sending domain, listing the authorized sources of mail for that domain. 2. **DKIM.** DomainKeys Identified Mail signing is enabled so that outbound mail carries a verifiable cryptographic signature. DKIM keys are managed per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). 3. **DMARC.** A Domain-based Message Authentication, Reporting and Conformance policy is published. The DMARC policy is moved to an enforcing posture (reject, or at minimum quarantine) once SPF and DKIM are confirmed correct. A DMARC policy left permanently at "none" provides reporting but no protection and is not the end state. 4. **Parked domains are locked down.** Owned domains that send no mail publish records that tell the world they send no mail, so they cannot be impersonated. 5. **Inbound authentication is enforced.** The organization checks SPF, DKIM, and DMARC on inbound mail and acts on the results, so that other organizations' authentication protects the organization's people. > **DMARC at "none" Is a Smoke Detector With No Battery** > > Publishing a DMARC record in monitoring-only mode is a common and reasonable first step. Leaving it there forever is not. A DMARC policy at "none" tells the organization who is forging its domain but tells the receiving world to deliver the forgeries anyway. The protection only exists once the policy enforces. CERG treats reaching an enforcing DMARC policy as the completion of this control, and a domain stuck at "none" for longer than the rollout reasonably needs as a finding. --- ## 4. Inbound Email Protection 1. **Inbound mail is filtered.** Inbound email passes through filtering that screens for malware, malicious links, known-bad senders, and spam before delivery. 2. **Attachments are inspected.** Attachments are scanned for malware. High-risk attachment types are blocked or neutralized by default; exceptions are recorded. 3. **Links are protected.** Links in inbound mail are evaluated, and protection is applied at the time the user clicks, not only at the time the mail is delivered, because a link can be made malicious after delivery. 4. **External mail is marked.** Mail originating outside the organization is visibly marked, so an employee can see at a glance that a message claiming to be from a colleague actually came from outside. 5. **High-risk senders are constrained.** Mail that impersonates internal senders, executive names, or known partners is detected and constrained. Lookalike-domain and display-name impersonation are explicit detection targets. 6. **Quarantine is managed.** Quarantined mail is handled through a defined process. Users can see and request release of their own quarantined mail; release of mail that failed a security check is reviewed. --- ## 5. Anti-Phishing Filtering reduces phishing. It does not eliminate it. This section covers what the program does about the phishing that reaches a person. 1. **Reporting is one action.** Employees have a single, obvious way to report a suspicious message, and using it takes one action. A reporting mechanism that is hard to find is not used. 2. **Reports are triaged.** Reported messages are triaged on a defined cadence. A confirmed malicious message is removed from any other inbox it reached, and its indicators feed detection per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). 3. **Reporting is never punished.** An employee who reports a message they also interacted with is thanked, not disciplined. Punishing the honest report teaches everyone else to stay silent, which is the opposite of the goal. 4. **Phishing simulation is constructive, not a trap.** Where the organization runs phishing simulations, they are run to measure and improve, not to shame individuals. Results are used in aggregate. An employee who fails a simulation is offered help, not humiliation. 5. **A click triggers response, not blame.** When an employee clicks a real phish or enters credentials, the response is immediate and procedural: contain the account, reset the credential per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md), and hand off to the Incident Response team. The employee who reported their own mistake made the response possible. > **The Organization That Punishes Clicks Goes Blind** > > If clicking a phishing link, or admitting to it, gets an employee in trouble, employees stop admitting it. The credential theft still happened; the organization just does not hear about it until the attacker is well inside. Every hour between the click and the report is the attacker's. CERG makes reporting effortless and consequence-free precisely so that the organization hears about the click in minutes, not weeks. A blame-free reporting culture is a security control, and it is one of the most valuable in this standard. --- ## 6. Outbound Email and Data Protection 1. **Outbound email is a governed data path.** Email is one of the realistic exfiltration paths named in [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) §9, and data loss prevention covers it. 2. **Sensitive data outbound is constrained.** Email carrying Confidential or Restricted data outside the organization is monitored and, where it is unauthorized, blocked or quarantined, per the handling table in [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) §6. 3. **Sensitive mail is encrypted.** Email carrying Confidential or Restricted data to external recipients is encrypted, using the mechanisms approved in [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). 4. **Auto-forwarding to external addresses is controlled.** Automatic forwarding of mail to external addresses is disabled by default. It is a classic data-exfiltration and account-compromise technique. Exceptions are recorded. 5. **Mass and unusual sending is detected.** A mailbox suddenly sending at volume, or sending to many external recipients, is a signal of a compromised account or an insider exfiltrating data, and is detected (Section 9). --- ## 7. Mailbox and Account Security 1. **Email accounts are protected by strong authentication.** Access to email requires multi-factor authentication per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). The email account is, for most people, the reset path to every other account, so it is protected accordingly. 2. **Mailbox access is least-privilege.** Delegate and shared-mailbox access is granted on need, recorded, and reviewed on the access-review cadence. 3. **Mailbox rules are monitored.** Inbox rules that hide, delete, or forward mail are a hallmark of business email compromise. The creation of suspicious rules is detected. 4. **Legacy and weak authentication is disabled.** Email protocols that cannot enforce multi-factor authentication are disabled. They are a standing bypass of the account's protection. 5. **Email retention follows data governance.** Mailbox content is retained and disposed of per the retention schedule in [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) §8, and preserved under legal hold when one applies. --- ## 8. Collaboration and Messaging Platforms Business chat, messaging, and collaboration platforms are governed with the same seriousness as email. 1. **Messaging platforms are sanctioned and assessed.** The collaboration and messaging platforms in use are sanctioned, and assessed as SaaS per [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md). Unsanctioned messaging tools are shadow IT. 2. **Access and authentication apply equally.** Access to messaging platforms requires the same authentication and is governed by the same access controls as email. 3. **Data classification applies in chat.** Confidential and Restricted data shared in messaging platforms is governed by [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). Data loss prevention covers messaging where the platform supports it. 4. **External participation is controlled.** External guests, federated chat with other organizations, and public channels are controlled and visible. An external party in a channel is as significant as an external recipient on an email. 5. **Phishing happens in chat too.** Malicious links and social engineering arrive through messaging platforms. The reporting mechanism and the no-blame culture of Section 5 extend to messaging. 6. **Messaging is logged and retained.** Business messaging is logged per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) and retained per [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). --- ## 9. Monitoring and Detection 1. **Email and messaging telemetry reaches detection.** Email security events, authentication results, and messaging-platform logs are delivered to the platform governed by [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). 2. **Detection content covers the known patterns.** Detection use cases include business email compromise indicators: suspicious inbox rules, anomalous send volume, impossible-travel sign-ins to mailboxes, mass external forwarding, and lookalike-domain mail. 3. **Reported phishing feeds detection.** Indicators from triaged user reports (Section 5) become detection content, so the next instance of the same campaign is caught by a machine. 4. **CERG detects; the IR team responds.** Consistent with [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4, CERG owns the detection content and feeds confirmed email-borne incidents to the standing Incident Response team. --- ## 10. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Email and Messaging Responsibility** | |---|---| | **Engineering Pillar Leader** | Owns this standard. Accountable for the email and messaging platforms and their security configuration. | | **Cloud Security Engineer** | Operates the email and messaging platforms where they are SaaS; owns SPF, DKIM, DMARC configuration and the inbound and outbound filtering posture. | | **Cryptography Engineer** | Owns DKIM key management and the encryption mechanisms for sensitive outbound mail. | | **Identity Engineer** | Owns multi-factor authentication on email and messaging accounts and the disabling of legacy authentication. | | **Detection Engineer** | Owns email and messaging detection content; consumes the telemetry and the reported-phish indicators. | | **Governance Pillar Leader** | Owns the position on phishing simulation and the no-blame reporting culture; tracks email-security metrics; cross-references this standard with the control baseline. | | **Exposure Management Lead** | Tracks vulnerabilities in email and messaging infrastructure. | | **Policy & Standards Manager** | Maintains this document, its version, and its review cycle. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST 800-177 | Trustworthy Email: SPF, DKIM, DMARC, transport encryption | Sections 3, 4, 6 | | NIST 800-53r5 | SC-7, SC-8, SI-3, SI-4, SI-8, AC-4 | Sections 3, 4, 6, 9 | | CIS Controls v8 | Control 9 (email and web browser protections) | Sections 4, 5 | | NIST CSF 2.0 | PROTECT (PR.DS, PR.PS), DETECT (DE.CM) | Sections 4, 6, 9 | | NIST 800-171r3 / CMMC L2 | 3.13.x (transmission protection), 3.14.x (system integrity) | Sections 3, 4, 6 | | SOX ITGC | Email retention and access control | Sections 7, 8 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-MSG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to the email or collaboration platform | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST 800-53r5 (SC, SI, AC); NIST 800-177; CIS Controls v8 (9); NIST CSF 2.0 (PROTECT, DETECT) | | **Regulations** | CMMC L2 / 800-171r3; SOX ITGC; privacy regimes where applicable | | **Environments** | All CERG-managed email and messaging | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes email authentication (SPF, DKIM, DMARC to an enforcing policy), inbound email protection, anti-phishing built on effortless blame-free reporting, outbound email and data protection, mailbox and account security, governance of collaboration and messaging platforms, and email and messaging monitoring feeding the detection platform. | ### Review Triggers - Material change to the email or collaboration and messaging platform - Revision of NIST 800-177 or relevant NIST 800-53 controls - A significant phishing or business email compromise incident - Internal audit or regulatory finding affecting email security - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Platforms) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | IT / Cloud / SaaS Security Standard | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Email and messaging platforms assessed as SaaS | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Multi-factor authentication; credential reset on a click | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Outbound data loss prevention; retention | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | DKIM keys; sensitive-mail encryption | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Email and messaging detection content and telemetry | | Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | CERG detects; the standing IR team responds | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `MSG` domain | --- ## ENDPOINT AND MOBILE SECURITY STANDARD ### Endpoint Protection · EDR · Device Posture · Mobile Device Management · BYOD --- | | | |---|---| | **Document ID** | CERG-STD-EP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Endpoint) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | | **Review Cycle** | Annual / On material change to the endpoint or mobility estate | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CM, SI, AC families) · [NIST 800-124](https://csrc.nist.gov/pubs/sp/800/124/r2/final) (mobile device security) · [CIS Controls v8](https://www.cisecurity.org/controls) (Controls 1, 4, 10) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (PROTECT) | | **Regulations** | CMMC L2 / 800-171r3 (3.1.x, 3.4.x, 3.14.x) · NERC-CIP (Transient Cyber Assets) · SOX ITGC | | **Environments** | All CERG-managed endpoints and mobile devices: owned, corporate, and BYOD with access to in-scope resources | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Endpoint Classes](#3-endpoint-classes) 4. [Baseline Endpoint Protection](#4-baseline-endpoint-protection) 5. [Endpoint Detection and Response](#5-endpoint-detection-and-response) 6. [Device Posture](#6-device-posture) 7. [Mobile Device Management](#7-mobile-device-management) 8. [Bring Your Own Device](#8-bring-your-own-device) 9. [Transient and Removable Devices](#9-transient-and-removable-devices) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The endpoint is where the user meets the estate, and where most intrusions begin. A phishing click, a malicious document, a compromised laptop: the endpoint is the first system an attacker touches and the device from which they reach everything else. The Secure Configuration Baseline Standard hardens endpoints; the Access Management Standard governs who signs in. Neither owns the endpoint as a security surface in its own right. This standard does. This standard establishes the requirements for endpoint and mobile device security across CERG-managed environments: baseline endpoint protection, endpoint detection and response, the device posture signal other standards depend on, mobile device management, and the terms under which a personally owned device may access in-scope resources. It applies to every endpoint and mobile device that accesses in-scope resources: owned workstations and laptops, corporate mobile devices, and personally owned devices used under the bring-your-own-device terms in Section 8. > **The Endpoint Posture Signal Is Used Everywhere** > > This standard does more than protect laptops. It produces the device posture signal that the Network Security Standard consumes for zero-trust access decisions, that the Access Management Standard consumes for conditional access, and that remote access depends on. An endpoint estate with no reliable posture signal forces every other standard to fall back to trusting the network or the password alone. Endpoint security is a supplier to the rest of the program, not just a protector of devices. --- ## 2. Principles 1. **Every endpoint is managed or it has no access.** A device that accesses in-scope resources is enrolled in management and meets this standard, or it does not get access. There is no unmanaged-but-trusted category. 2. **The endpoint is inventoried.** Every endpoint is an asset in the inventory governed by [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md). An endpoint not in the inventory is an unmanaged asset and is contained. 3. **Posture is checked, not assumed.** A device's compliance with this standard is verified continuously and at the point of access, not assumed because the device was compliant once. 4. **Protect, detect, and respond on the device.** Endpoints carry preventive controls and a detection-and-response capability. Prevention fails; the endpoint must also be a place where compromise is seen and contained. 5. **BYOD is a deliberate, bounded decision.** Personal devices may access in-scope resources only under explicit terms that bound what they reach and what the organization controls. BYOD is never the absence of a rule. 6. **Loss of a device is not loss of the data.** Endpoint data is encrypted and remotely recoverable or erasable, so a lost or stolen device is an inconvenience, not a breach. --- ## 3. Endpoint Classes | **Class** | **What It Covers** | **Management Model** | |---|---|---| | **Workstation** | Owned desktops and laptops used for daily work. | Fully managed; full baseline. | | **Corporate mobile** | Organization-owned phones and tablets. | Fully managed via mobile device management (Section 7). | | **BYOD** | Personally owned devices accessing in-scope resources. | Bounded management of organization data only (Section 8). | | **Privileged-access endpoint** | Endpoints used for administrative access to infrastructure. | Fully managed; hardened beyond baseline; see Section 4.5. | | **Transient and removable** | Devices that connect briefly: contractor laptops, removable media, maintenance devices. | Controlled per Section 9. | OT field devices and OT engineering workstations are governed by [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md), not this standard. Where an OT engineering workstation is also a transient cyber asset, Section 9 and the OT standard are read together. --- ## 4. Baseline Endpoint Protection Every managed endpoint carries the following at minimum. 1. **Secure configuration baseline.** The endpoint is configured to the applicable baseline in [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md), and configuration drift is detected and corrected. 2. **Disk encryption.** Endpoint storage is encrypted at rest per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). Encryption is enforced by management, not left to the user. 3. **Patching.** The operating system and installed software are patched against the SLAs in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). The endpoint reports its patch state to management. 4. **Malware protection.** The endpoint runs current malware protection. 5. **Host firewall.** A host-based firewall is enabled and configured to default-deny inbound, consistent with [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md). 6. **Application control.** Tier-appropriate control over what software may execute. Privileged-access endpoints (Section 4.5) and endpoints handling regulated data enforce allowlisting; standard workstations enforce at minimum a block on known-bad and unsigned execution. 7. **Screen lock and authentication.** The endpoint enforces an automatic screen lock and authenticates the user per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). 8. **Local administrative rights are restricted.** Users do not hold standing local administrator rights on their workstations. Where elevation is needed it is granted just in time and recorded. ### 4.1 Privileged-Access Endpoints An endpoint used to administer infrastructure is a high-value target and is hardened beyond the baseline: application allowlisting is mandatory, the device is dedicated to administrative use and not used for email or general browsing, and it is segmented per [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md). Administering the estate from a general-purpose daily-use laptop is prohibited. > **Standing Local Admin Rights Are a Self-Inflicted Wound** > > When every user is a local administrator of their own machine, every phishing click runs with administrative privilege, every piece of malware installs cleanly, and the endpoint's own controls can be disabled by the very user the controls protect. Removing standing local admin rights is one of the highest-value, lowest-cost endpoint controls in existence. CERG mandates it, and grants elevation just in time when a genuine need arises. --- ## 5. Endpoint Detection and Response 1. **Every managed endpoint runs EDR.** An endpoint detection and response capability runs on every workstation, corporate mobile device where supported, and privileged-access endpoint. 2. **EDR telemetry reaches the detection platform.** EDR telemetry is delivered to the platform governed by [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), so endpoint events are visible alongside the rest of the estate. 3. **EDR supports containment.** The capability allows a compromised endpoint to be isolated from the network quickly, so a foothold can be contained without physically retrieving the device. 4. **EDR tampering is itself an alert.** An attempt to disable, uninstall, or evade EDR is a detection signal and is alerted on. 5. **CERG feeds, the IR team responds.** Consistent with [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4, CERG operates the EDR capability and feeds its telemetry and detections to the standing Incident Response team. CERG does not run incident response from this standard. --- ## 6. Device Posture Device posture is the set of facts about an endpoint that other standards use to make access decisions. This standard owns producing it. 1. **Posture is defined.** A device is in posture when it is enrolled in management, on a supported and patched operating system, encrypted, running current EDR and malware protection, and not flagged with an unresolved high-severity finding. 2. **Posture is evaluated continuously and at access.** Posture is checked continuously by management and again at the point a device requests access to a resource. 3. **Out-of-posture devices lose access.** A device that falls out of posture loses access to in-scope resources until it is brought back into posture. The loss of access is automatic, not a manual follow-up. 4. **Posture is the signal other standards consume.** The posture verdict is the input that [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) uses for zero-trust decisions and that [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) uses for conditional access. This standard is the authoritative producer of that signal. --- ## 7. Mobile Device Management 1. **Corporate mobile devices are enrolled in mobile device management.** Organization-owned phones and tablets are managed: configuration is enforced, security policy is pushed, and compliance is reported. 2. **Mobile baseline.** A managed mobile device enforces device encryption, a passcode or biometric unlock, automatic lock, current operating system, and a block on installing applications from untrusted sources. 3. **Organization data is containerized.** Organization email, files, and applications on a mobile device are held in a managed container separable from anything personal on the device. 4. **Remote lock and wipe.** A managed mobile device can be remotely locked and can have organization data remotely wiped. A lost corporate device is wiped. 5. **Jailbroken and rooted devices are blocked.** A device whose operating system integrity has been compromised does not access in-scope resources. --- ## 8. Bring Your Own Device BYOD is permitted only under the explicit terms in this section. An organization adopting CERG may decline BYOD entirely; if it permits BYOD, these terms apply. 1. **BYOD access is enrolled and bounded.** A personal device accessing in-scope resources is enrolled in management scoped to organization data only. The organization manages its container; it does not manage the user's personal device. 2. **The managed container is the boundary.** Organization email, files, and applications live in a managed, encrypted container. Organization data does not leave the container onto the personal device. 3. **Posture still applies.** A BYOD device meets the device posture definition in Section 6 for the managed container. An out-of-posture personal device loses access exactly as a corporate device does. 4. **Selective wipe, not full wipe.** The organization can wipe the managed container, removing organization data without touching the user's personal content. Offboarding a user or losing the device triggers a container wipe. 5. **What BYOD may not reach.** Personal devices do not reach privileged administrative interfaces, OT systems, or, unless an explicit risk acceptance is recorded, regulated data scopes such as CUI. Administrative and regulated access is from managed, organization-owned endpoints. 6. **The terms are agreed in writing.** A user using BYOD acknowledges the terms: the managed container, the organization's right to wipe it, and the posture requirements. BYOD without recorded user agreement is not permitted. > **BYOD Is a Trade, and the Trade Is Written Down** > > Bring-your-own-device trades convenience for a controlled reduction in assurance. That trade is acceptable when it is bounded and explicit, and dangerous when it is silent. The failure mode is the personal phone quietly syncing the entire mailbox with no container, no posture check, and no way to wipe it when the employee leaves. CERG permits BYOD only as a written, bounded arrangement: a managed container, a posture requirement, a selective-wipe right, and a clear list of what personal devices may never reach. --- ## 9. Transient and Removable Devices 1. **Transient devices are controlled before they connect.** A device that connects briefly to the estate, a contractor laptop, a maintenance device, is checked for posture before connection or is restricted to an isolated network segment per [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md). 2. **Removable media is controlled.** Use of removable storage is restricted by default. Where permitted, removable media is encrypted and scanned. Endpoints handling regulated data block removable storage unless an exception is recorded. 3. **Transient cyber assets in OT scope.** A transient device connecting to OT, including for maintenance, is a transient cyber asset and is governed by [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) and NERC-CIP requirements. Section 9 and the OT standard are read together for those devices. --- ## 10. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Endpoint and Mobile Responsibility** | |---|---| | **Endpoint Engineer** | Owns this standard. Owns endpoint and mobile baselines, the management and EDR platforms, and the device posture signal. | | **Engineering Pillar Leader** | Accountable for endpoint security across the pillar; approves BYOD terms and privileged-access endpoint design. | | **Identity Engineer** | Consumes the posture signal for conditional access; owns just-in-time elevation of local administrative rights. | | **Detection Engineer** | Owns endpoint detection content; consumes EDR telemetry. | | **OT Security Engineer** | Owns transient cyber asset control where devices connect to OT. | | **Exposure Management Lead** | Tracks endpoint patch state and endpoint vulnerability findings against SLAs. | | **Vendor Risk Analyst** | Coordinates transient contractor-device access with [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). | | **Governance Pillar Leader** | Tracks endpoint-management coverage metrics and BYOD exceptions; cross-references this standard with the control baseline. | | **Policy & Standards Manager** | Maintains this document, its version, and its review cycle. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST 800-53r5 | CM-7, SI-3, SI-4, AC-6, AC-19, MP-7 | Sections 4, 5, 8, 9 | | NIST 800-124 | Mobile device security and management | Sections 7, 8 | | CIS Controls v8 | Control 1 (assets), Control 4 (secure configuration), Control 10 (malware defenses) | Sections 3, 4, 5 | | NIST CSF 2.0 | PROTECT (PR.PS, PR.AA), DETECT (DE.CM) | Sections 4, 5, 6 | | NIST 800-171r3 / CMMC L2 | 3.1.x (access), 3.4.x (configuration), 3.14.x (system integrity), 3.8.x (media) | Sections 4, 8, 9 | | NERC-CIP | CIP-010 Transient Cyber Assets and Removable Media | Section 9 | | SOX ITGC | Endpoint access and configuration control | Sections 4, 6 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-EP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Endpoint) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to the endpoint or mobility estate | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST 800-53r5 (CM, SI, AC); NIST 800-124; CIS Controls v8 (1, 4, 10); NIST CSF 2.0 (PROTECT) | | **Regulations** | CMMC L2 / 800-171r3; NERC-CIP (Transient Cyber Assets); SOX ITGC | | **Environments** | All CERG-managed endpoints and mobile devices | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes endpoint classes, baseline endpoint protection including removal of standing local administrator rights, endpoint detection and response, the device posture signal consumed by the network and access standards, mobile device management, bounded bring-your-own-device terms, and control of transient and removable devices. | ### Review Triggers - Material change to the endpoint estate, mobility model, or BYOD policy - Revision of NIST 800-124 or relevant NIST 800-53 controls - A significant endpoint-originated security incident - Internal audit or regulatory finding affecting endpoint security - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Endpoint) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Endpoint configuration baselines | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Conditional access consuming device posture; just-in-time elevation | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Endpoints as inventoried assets | | Network Security and Segmentation Standard | [`CERG-STD-NET-001`](CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md) | Zero-trust decisions consuming device posture; transient-device segmentation | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Endpoint disk encryption | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | EDR telemetry and endpoint detection content | | Grid Control Systems Security Standard | [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT devices and transient cyber assets | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Endpoint patching SLAs | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Contractor transient devices | | Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | CERG feeds EDR telemetry; the IR team responds | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `EP` domain | --- ## GRID & CONTROL SYSTEMS CYBERSECURITY STANDARD ### BES and Non-BES Operational Technology Environments --- | | | |---|---| | **Document ID** | CERG-STD-OT-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (OT/NERC-CIP) | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Significant Change / CIP Standard Revision | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) · NIST RMF | | **Regulations** | NERC-CIP v6/v7 · IEC 62443 | | **Environments** | OT / ICS / BES / Non-BES Control Systems | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [CERG Roles in Grid and Control System Security](#2-cerg-roles-in-grid-and-control-system-security) 3. [GOVERN, Program Foundation and Risk Management](#3-govern--program-foundation-and-risk-management) 4. [IDENTIFY, Visibility Into Assets and Threats](#4-identify--visibility-into-assets-and-threats) 5. [PROTECT, Reduce Attack Surface and Limit Blast Radius](#5-protect--reduce-attack-surface-and-limit-blast-radius) 6. [DETECT, Find Threats Before They Find the Grid](#6-detect--find-threats-before-they-find-the-grid) 7. [RESPOND, React Without Making It Worse](#7-respond--react-without-making-it-worse) 8. [RECOVER, Restore Operations and Capture Learning](#8-recover--restore-operations-and-capture-learning) 9. [Training and Personnel Security](#9-training-and-personnel-security) 10. [Regulatory and Framework Alignment Summary](#10-regulatory-and-framework-alignment-summary) 11. [Exceptions and Escalation](#11-exceptions-and-escalation) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope This standard implements the foundational principles established in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) for grid and control system environments. It defines specific, measurable security requirements for all operational technology (OT), industrial control systems (ICS), and grid automation assets, regardless of whether those assets are classified as Bulk Electric System (BES) Cyber Systems under NERC-CIP or operate outside that regulatory scope. These requirements are organized around the NIST Cybersecurity Framework 2.0 functions, Govern, Identify, Protect, Detect, Respond, and Recover, and are cross-mapped to NERC-CIP standards, NIST SP 800-82 (Guide to OT Security), [NIST SP 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), and IEC 62443 where applicable. Where BES and non-BES requirements differ materially, both are stated explicitly. ### 1.1 Scope This standard applies to: - All BES Cyber Systems and BES Cyber Assets as categorized under NERC-CIP CIP-002 - All non-BES control systems, including distribution automation, advanced metering infrastructure (AMI), substation automation not meeting BES categorization thresholds, and generation assets below NERC registration thresholds - All Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCA) associated with BES Cyber Systems - All systems in the IT/OT convergence zone, including historian servers, data diodes, jump servers, and DMZ infrastructure serving OT environments - All personnel with authorized electronic or physical access to in-scope systems, including employees, contractors, integrators, and vendors ### 1.2 The BES / Non-BES Distinction > **How to Read BES vs. Non-BES Requirements** > > Throughout this standard, requirements that apply exclusively to BES Cyber Systems are marked **[BES ONLY]**. Requirements that apply to all in-scope OT systems carry no marker. Where BES systems have a more stringent version of a common requirement, both versions are stated. Never apply only the baseline to a BES system. The NERC-CIP CIP-002 asset categorization process determines which assets carry BES Cyber System obligations. This standard does not replace that process. Governance maintains the BES Cyber System inventory. Engineering ensures controls reflect each asset's classification. Risk validates compliance against both BES and non-BES requirements during exposure management and assessment activities. ### 1.3 Relationship to Parent Policy This standard is subordinate to [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md). It implements specific requirements; it does not limit any principle established in that policy. Where this standard is silent, the policy governs. Exceptions follow the process defined in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Section 7. BES Cyber System exceptions require CISO approval. --- ## 2. CERG Roles in Grid and Control System Security The three CERG pillars operate in grid and control system environments with the same structure as enterprise IT, with operational adaptations that reflect the unique risk profile of OT. | **CERG Pillar** | **OT-Specific Responsibilities** | |---|---| | **Engineering** | Architects and validates security controls for new and modified OT systems before deployment. Conducts pre-production security reviews for all OT integrations, grid modernization projects, and IT/OT convergence initiatives. Defines and maintains secure configuration baselines for each OT platform class. Serves as the OT security SME in vendor selection and system acquisition. Ensures CIP-010 configuration management controls are embedded in project delivery. | | **Risk** | Operates the OT exposure management program using passive monitoring, vendor-provided scan tools, and approved active scanning windows that do not introduce operational risk. Tracks OT patch compliance separately from IT, with NERC-CIP deviation workflows initiated when SLAs cannot be met. Conducts OT-specific adversarial testing coordinated with operational teams. Maintains ICS/OT-specific threat intelligence from E-ISAC, ICS-CERT, and vendor security advisories. Manages the CIP-013 supply chain risk program for OT vendors and integrators. | | **Governance** | Owns the NERC-CIP compliance program including BES Cyber System inventory (CIP-002), CIP deviation and mitigation plan processes, and the NERC-CIP evidence library. Maintains this standard and all subordinate OT procedures. Coordinates regulatory examinations and self-certifications. Produces implementation guidance that translates CIP requirements into actionable technical direction for Engineering and IT/OT operations teams. Tracks all OT security findings and remediation commitments in the risk register. | > **The Operational Priority Rule** > > In OT environments, the CERG model adjusts its default risk posture: availability of grid and control system operations takes precedence over confidentiality. This does not mean confidentiality and integrity controls are skipped, it means that when a control action or remediation activity would create operational risk, it is planned, coordinated, and executed during an approved maintenance window or with appropriate operational safeguards. Security events are never resolved by actions that could themselves cause a grid disturbance. --- ## 3. GOVERN: Program Foundation and Risk Management ### 3.1 Asset Categorization and Inventory All in-scope assets must be inventoried and categorized before security controls can be applied, compliance obligations determined, or risk assessed. This is the foundational requirement from which all others flow. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain a current inventory of all OT assets including make, model, firmware version, network connectivity, and physical location. | All OT | Engineering | [NIST CSF 2.0](https://www.nist.gov/cyberframework) GV.AM · 800-53 CM-8 · 800-82 §6.2 | | Perform CIP-002 BES Cyber System categorization annually and upon any change to the environment that could affect categorization. Document the rationale for each categorization decision. | **BES ONLY** | Governance | CIP-002-5.1a R1 | | Classify each BES Cyber System as High, Medium, or Low impact per CIP-002 Attachment 1 criteria. | **BES ONLY** | Governance | CIP-002-5.1a R1 | | Identify all EACMS, PACS, and PCAs associated with each BES Cyber System and include them in the asset register. | **BES ONLY** | Engineering / Governance | CIP-002-5.1a R1.3 | | Maintain an OT network topology diagram current within 90 days, including all Electronic Security Perimeters (ESPs) and Electronic Access Points (EAPs). | All OT | Engineering | CIP-005-6 R1 · [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.2 | | Track OT asset lifecycle from acquisition through decommission. Decommissioning must include secure data destruction and removal from all access control lists. | All OT | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-8(4) · CIP-004-6 R4 | ### 3.2 Risk Register and Risk Acceptance All identified security risks to grid and control systems must be documented in the organizational risk register. BES Cyber System risks require CISO approval for risk acceptance. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Document all OT security findings and unmitigated risks in the centralized risk register within 5 business days of identification. | All OT | Governance | [NIST CSF 2.0](https://www.nist.gov/cyberframework) GV.RM · 800-53 RA-3 | | Assign a risk owner to every open risk item. Risk owners are accountable for treatment plan execution. | All OT | Governance | NIST RMF Step 2 · 800-53 RA-3(1) | | Risk acceptance for BES Cyber System findings requires documented CISO approval and must be reviewed annually. Accepted risks do not close the finding - they suspend the SLA with documented rationale. | **BES ONLY** | Governance / CISO | CIP-007-6 · NIST RMF Step 4 | | Initiate a NERC-CIP deviation and mitigation plan when a CIP compliance obligation cannot be met on schedule. Notify the CISO immediately upon identification. | **BES ONLY** | Governance | NERC Rules of Procedure §410 | ### 3.3 Third-Party and Supply Chain Risk OT vendors, integrators, and managed service providers present significant supply chain risk. Compromised vendor software or hardware in a grid environment can affect physical operations. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All OT vendors and integrators must complete a security assessment before being granted access to in-scope systems. Assessment depth is tiered by access level and system criticality. | All OT | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SA-9 · IEC 62443-2-1 | | Implement and maintain a supply chain risk management plan for all OT software and hardware suppliers. The plan must address software integrity verification, hardware authenticity, and vendor incident notification requirements. | **BES ONLY** | Risk / Governance | CIP-013-2 | | Vendor contracts for OT systems must include: right-to-audit provisions, mandatory incident notification within 24 hours, software bill of materials (SBOM) requirements for new deployments, and security patch commitment timelines. | All OT | Governance / Risk | CIP-013-2 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SR-3 | | Verify software and firmware integrity before deployment using vendor-provided hashes or cryptographic signatures. Do not deploy unverified software to any OT system. | All OT | Engineering | CIP-013-2 R1.2 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SR-4 | --- ## 4. IDENTIFY: Visibility Into Assets and Threats ### 4.1 OT Network Monitoring Continuous visibility into OT network activity is essential for detecting threats that vulnerability scans cannot see. Monitoring in OT environments requires methods that do not introduce operational risk. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Deploy passive network monitoring for all OT network segments. Passive monitoring must not generate active probes or queries toward OT devices. | All OT | Risk / Engineering | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.3 · IEC 62443-3-3 SR 6.1 | | Collect security event logs from all OT assets capable of generating them. For assets that cannot forward logs natively, use syslog aggregators or protocol translators deployed in the OT DMZ. | **BES ONLY** | Engineering / Risk | CIP-007-6 R4 | | Retain OT security event logs for a minimum of 90 days immediately accessible and 12 months total. | **BES ONLY** | Engineering / Governance | CIP-007-6 R4.1.1 | | Integrate OT monitoring data with the enterprise SIEM via one-way data transfer controls through the OT DMZ. Do not create bidirectional monitoring connections into OT networks. | All OT | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4 · CIP-005-6 R1 | | Define and document alert thresholds for OT-specific anomalies: unexpected outbound connections from OT segments, unauthorized protocol usage, configuration changes outside maintenance windows, and communications with unknown external endpoints. | All OT | Risk | [NIST CSF 2.0](https://www.nist.gov/cyberframework) DE.CM · 800-53 SI-4(5) | ### 4.2 Vulnerability Identification OT exposure management operates under different constraints than IT. Scanning must be OT-safe. Patch timelines reflect vendor testing requirements and operational windows. The risk calculus weights availability alongside confidentiality and integrity. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Conduct OT vulnerability assessments at least annually using OT-safe methods: passive monitoring analysis, vendor-provided assessment tools, or active scanning during approved maintenance windows coordinated with the operational team. | All OT | Risk | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.4 · IEC 62443-2-1 | | Subscribe to and process vendor security advisories and CISA ICS-CERT advisories for all OT platforms in use. Advisories must be reviewed within 5 business days of publication. | **BES ONLY** | Risk / Engineering | CIP-007-6 R2 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-5 | | Track all identified OT vulnerabilities with CVSS scores and OT-specific impact assessment (operational, safety, reliability). CVSS scores alone are insufficient for OT prioritization - availability impact must be assessed separately. | All OT | Risk | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.4 · CIP-007-6 R2 | | OT exposure treatment and patch hygiene follow [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) with the BES schedule and CIP deviation overlay in [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md). When vendor-tested patches or OT-safe maintenance windows prevent treatment within the governing SLA, initiate risk acceptance and, for BES scope, the CIP deviation process. | **BES ONLY** | Risk / Governance | CIP-007-6 R2.2 | | Where patches cannot be applied, document compensating controls reviewed by Engineering and approved by the CISO. | All OT | Risk / Engineering | CIP-007-6 R2.3 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-2(6) | --- ## 5. PROTECT: Reduce Attack Surface and Limit Blast Radius ### 5.1 Network Segmentation and Electronic Security Perimeters Network segmentation is the primary architectural control in OT environments. It limits the blast radius of a compromise, prevents IT threats from crossing into OT, and is a non-negotiable NERC-CIP obligation for BES Cyber Systems. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Define and document all Electronic Security Perimeters (ESPs) surrounding BES Cyber Systems. ESPs must have a documented topology, all Electronic Access Points (EAPs) identified, and all permitted communications documented. | **BES ONLY** | Engineering / Governance | CIP-005-6 R1 | | All communication across an ESP boundary must traverse an EAP with access controls. No BES Cyber System shall have an uncontrolled path to an external network. | **BES ONLY** | Engineering | CIP-005-6 R1.3 | | All non-BES OT networks must be segmented from enterprise IT by a firewall or equivalent access control enforcing a default-deny posture. Permitted flows must be documented and reviewed annually. | All OT | Engineering | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.2 · IEC 62443-3-3 SR 5.1 | | Deploy an OT DMZ between enterprise IT and OT networks. The DMZ hosts historians, data aggregators, and systems requiring bidirectional IT/OT communication. No direct routed paths between IT and OT shall exist. | All OT | Engineering | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §5.4 · IEC 62443-3-2 | | Use unidirectional gateways (data diodes) for operationally one-directional data flows. Bidirectional connections must be justified and approved by Engineering and the CISO. | All OT | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-7(8) · IEC 62443-3-3 SR 5.2 | | Segment OT networks internally by function and criticality. Control networks (SCADA, DCS, RTU) must be isolated from OT support networks (engineering workstations, HMI, historian). Lateral movement between OT zones must traverse an access control point. | All OT | Engineering | IEC 62443-3-2 · [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §5.4 | | Wireless communications in OT environments require explicit Engineering approval, documented risk assessment, and compensating controls. No unapproved wireless access points shall be connected to any OT network. | All OT | Engineering / Risk | CIP-005-6 R2 · [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.5 | ### 5.2 Access Control and Identity Management Controlling who can reach OT systems, and what they can do when they get there, is as important as network segmentation. Privileged access to OT systems is high-consequence access. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Grant access to OT systems using least privilege. Personnel receive only the access required for their specific role. No shared accounts on BES Cyber Systems. | **BES ONLY** | Engineering / Governance | CIP-007-6 R5.1 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6 | | Implement and enforce a personnel risk assessment (PRA) program for all individuals with authorized access to BES Cyber Systems. PRAs must be completed before access is granted and renewed per CIP-004 requirements. | **BES ONLY** | Governance / Engineering | CIP-004-6 R3 | | Maintain access authorization lists for BES Cyber Systems current within 7 calendar days. Revoke access within 24 hours of personnel departures or role changes. | **BES ONLY** | Engineering / Governance | CIP-004-6 R4 | | Enforce multi-factor authentication (MFA) for all interactive remote access to BES Cyber Systems. Remote access must traverse an Intermediate System. | **BES ONLY** | Engineering | CIP-005-6 R2 | | Log all access to OT systems - electronic and physical. Logs must capture user identity, system accessed, date/time, and session duration. | **BES ONLY** | Engineering | CIP-006-6 R1 · CIP-007-6 R4 | | Conduct quarterly access reviews for all OT systems. Reviews must verify that access authorizations remain current, appropriate, and within least-privilege bounds. | All OT | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7) · CIP-004-6 R4.2 | | Prohibit the use of vendor default credentials on any OT system. Vendor-supplied default usernames and passwords must be changed before deployment or first connection to an OT network. | All OT | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5(1) · CIP-007-6 R5.5 | ### 5.3 System Hardening and Configuration Management OT systems must be hardened to their minimum required operational configuration. Unnecessary services, ports, and software expand the attack surface without adding operational value. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Enable only the ports, services, and software components required for operational function. Disable or remove all others. Document permitted ports and services per device class. | All OT | Engineering | CIP-007-6 R1 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-7 | | Establish and maintain a secure configuration baseline for each OT platform class (SCADA servers, HMIs, historian, RTUs, protection relays, engineering workstations). Baselines must be reviewed annually and upon significant change. | All OT | Engineering | CIP-010-3 R1 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-6 | | Detect and alert on unauthorized configuration changes to BES Cyber Systems within 35 days. Configuration change detection must be automated where technically feasible. | **BES ONLY** | Engineering / Risk | CIP-010-3 R1.4 | | Manage all authorized configuration changes through a formal change management process. Emergency changes to OT systems require post-hoc documentation within 24 hours. | All OT | Governance / Engineering | CIP-010-3 R1 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-3 | | Prohibit connecting removable media (USB drives, portable hard drives, maintenance laptops) to OT systems without an authorized malware scan and documented approval. | All OT | Engineering / Governance | CIP-010-3 R3 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) MP-7 | | Implement application whitelisting or equivalent execution control on OT systems where technically feasible. Where not feasible, document the technical limitation and implement compensating controls. | All OT | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-7(5) · IEC 62443-3-3 SR 3.2 | ### 5.4 Physical Security Cyber protections for OT systems are only as strong as the physical controls protecting the hardware. Physical security for BES Cyber Systems is a NERC-CIP compliance obligation, not a facilities management function. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Define and document Physical Security Perimeters (PSPs) for all locations containing High and Medium impact BES Cyber Systems. | **BES ONLY** | Governance / Engineering | CIP-006-6 R1 | | Control and log all physical access to PSPs. Access must be restricted to authorized personnel. Visitors require escort. | **BES ONLY** | Engineering / Governance | CIP-006-6 R1.1–R1.6 | | Protect all in-scope OT equipment - including substations, control rooms, and remote sites - with physical access controls appropriate to the criticality of housed assets: locked enclosures, controlled entry, and visitor logging at minimum. | All OT | Engineering / Governance | CIP-006-6 · [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.1 | | Conduct physical security reviews of all PSP locations annually and upon significant change. Review findings feed the risk register. | **BES ONLY** | Risk / Governance | CIP-006-6 R1.10 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PE-1 | --- ## 6. DETECT: Find Threats Before They Find the Grid ### 6.1 Security Event Monitoring Detection in OT environments requires purpose-built methods. Standard IT security tools applied naively to OT networks can cause operational disruptions. Monitoring must be passive-first and operationally coordinated. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Generate, collect, and review security event logs from all OT assets capable of log generation. Log collection must not rely on active polling of field devices where polling could affect device availability. | All OT | Risk / Engineering | CIP-007-6 R4 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-2 | | Define and document OT-specific security events that require alerting: unauthorized access attempts, account lockouts, failed authentication, service start/stop, configuration changes, and connections to unexpected endpoints. | All OT | Risk | CIP-007-6 R4.1 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4 | | Route OT security event alerts to analysts capable of evaluating both security and operational context. A SCADA server communicating with an unknown external endpoint requires both cybersecurity analysis and operational team notification. | All OT | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4 · CIP-008-6 | | Conduct security event log reviews on a defined and documented cycle. Reviews must include OT-specific anomaly detection analysis, not only signature-based alerting. | **BES ONLY** | Risk | CIP-007-6 R4.2 | ### 6.2 Threat Intelligence for OT Enterprise threat feeds optimized for IT adversaries provide incomplete coverage of ICS/OT threat actors and attack techniques. OT-specific sources are required. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain active subscriptions to ICS/OT-specific threat intelligence sources: CISA ICS-CERT advisories, E-ISAC (Electricity ISAC), and vendor security bulletins for all OT platforms in use. | All OT | Risk | [NIST CSF 2.0](https://www.nist.gov/cyberframework) DE.CM · CIP-013-2 | | Produce OT threat intelligence summaries for Engineering and Incident Response at least quarterly. Summaries must include relevant threat actor activity, newly disclosed ICS vulnerabilities, and intelligence specific to the organization's OT platforms. | All OT | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PM-16 · IEC 62443-2-1 | | Participate in E-ISAC information sharing. Report indicators of compromise related to BES Cyber Systems per E-ISAC and NERC requirements. | **BES ONLY** | Risk / Governance | NERC Rules of Procedure · CIP-008-6 | --- ## 7. RESPOND: React Without Making It Worse > **The OT Response Imperative** > > Response actions in OT environments carry consequences that IT incidents do not. Isolating a compromised IT server is a containment decision. Isolating a compromised SCADA workstation that controls generation dispatch or substation protection may affect grid reliability. Every response action in an OT environment must be evaluated for operational impact before execution. Response plans must be pre-coordinated with operational teams, not improvised during an incident. ### 7.1 Incident Response Planning | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain an OT Cybersecurity Incident Response Plan (IRP) that addresses: incident classification, notification and escalation paths, containment actions with operational impact assessment, evidence preservation, and recovery initiation. | All OT | Governance | [NIST CSF 2.0](https://www.nist.gov/cyberframework) RS · CIP-008-6 R1 | | The OT IRP must include pre-coordinated response playbooks for high-probability OT scenarios: ransomware impacting OT networks, unauthorized access to BES Cyber Systems, loss of SCADA visibility, and supply chain compromise. | All OT | Governance / Engineering | CIP-008-6 R1 · [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) §6.7 | | For BES Cyber System incidents, document and follow NERC-CIP CIP-008 reporting timelines. Personnel with reporting responsibilities must know the timelines and have them documented in the IRP. | **BES ONLY** | Governance | CIP-008-6 R1.3 | | Conduct OT incident response tabletop exercises at least annually involving operational team representation - not only cybersecurity personnel. Lessons learned must be documented and drive IRP updates. | All OT | Governance / Risk | CIP-008-6 R3 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-3 | --- ## 8. RECOVER: Restore Operations and Capture Learning ### 8.1 Recovery Planning for OT Systems | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain documented recovery plans for all in-scope OT systems including: restoration procedures, backup media locations, vendor contacts, and RTOs aligned with operational requirements. | All OT | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-2 · IEC 62443-2-1 | | BES Cyber System recovery plans must meet NERC-CIP CIP-009 requirements including documented plans, testing cadence, and plan update requirements. | **BES ONLY** | Governance | CIP-009-6 R1 | | Maintain offline, verified backups of all OT system configurations, firmware, software, and operational data required for restoration. Backups must be stored in a location not accessible from the OT network being backed up. | All OT | Engineering | CIP-009-6 R1.2 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-9 | | Test OT recovery plan procedures at least annually. Testing must validate that backups can be restored and that documented procedures produce a functional system. | **BES ONLY** | Governance / Engineering | CIP-009-6 R2 | | Conduct post-incident reviews within 30 days of any significant OT security event. Reviews must identify root cause, control failures, and corrective actions. Corrective actions feed the risk register. | All OT | Governance / Risk | CIP-009-6 R3 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4(4) | --- ## 9. Training and Personnel Security Personnel with access to OT systems must understand the unique risk environment they operate in. Security awareness for OT personnel must go beyond general enterprise training. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All personnel with authorized access to BES Cyber Systems must complete OT cybersecurity awareness training annually. Training must be documented and records retained. | **BES ONLY** | Governance | CIP-004-6 R2 | | All personnel with authorized access to any in-scope OT system must complete OT-specific security awareness training covering: social engineering in OT contexts, removable media risks, physical access procedures, and incident reporting. | All OT | Governance | CIP-004-6 R2 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-2 | | Personnel with OT incident response responsibilities must complete role-based training covering their specific response duties before being assigned incident response roles. | All OT | Governance | CIP-004-6 R2.4 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-3 | | CERG team members assigned to OT environments must maintain current knowledge of OT security principles, NERC-CIP requirements, and [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) / IEC 62443 guidance. Professional development plans must reflect this requirement. | All OT | Governance / CISO | CIP-004-6 · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-3 | --- ## 10. Regulatory and Framework Alignment Summary The following table maps this standard's major requirement areas to applicable regulatory frameworks and NIST controls. This is a compliance reference. Governance maintains the full NERC-CIP evidence matrix separately. | **Requirement Area** | **NERC-CIP** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | **[NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final)** | **IEC 62443** | |---|---|---|---|---|---| | Asset Inventory & Categorization | CIP-002-5.1a | GV.AM | CM-8 | §6.2 | SR 7.8 | | Network Segmentation & ESPs | CIP-005-6 | PR.IR | SC-7 | §5.4, 6.2 | SR 5.1, 5.2 | | Access Control | CIP-004/007-R5 | PR.AA | AC-2, AC-6 | §6.3 | SR 1.1–1.5 | | Remote Access | CIP-005-6 R2 | PR.AA | AC-17, IA-3 | §6.3 | SR 1.13 | | System Hardening | CIP-007-6 R1 | PR.PS | CM-6, CM-7 | §6.2 | SR 7.6 | | Configuration Management | CIP-010-3 | PR.PS | CM-3, CM-6 | §6.2 | SR 7.6 | | Patch Management | CIP-007-6 R2 | PR.PS | SI-2 | §6.4 | SR 3.3 | | Physical Security | CIP-006-6 | PR.AA | PE-2, PE-3 | §6.1 | SR 2.1 | | Security Monitoring | CIP-007-6 R4 | DE.CM | SI-4, AU-2 | §6.3 | SR 6.1, 6.2 | | Incident Response | CIP-008-6 | RS | IR-2, IR-4 | §6.7 | SR 6.1 | | Recovery Planning | CIP-009-6 | RC | CP-2, CP-9 | §6.7 | SR 7.3 | | Supply Chain Risk | CIP-013-2 | GV.SC | SA-9, SR-3 | §5.2 | SR 1.9 | | Personnel Training | CIP-004-6 | GV.RR | AT-2, AT-3 | §6.1 | SR 2.5 | | Exposure Management | CIP-007-6 R2 | ID.RA | RA-5, SI-2 | §6.4 | SR 3.2 | --- ## 11. Exceptions and Escalation No control in this standard may be waived without a documented exception. OT patch deferral and exposure-treatment deferral follow [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §7.4. Exceptions to BES Cyber System requirements carry additional obligations and may require a NERC-CIP deviation or mitigation plan in addition to CERG risk/exception records. | **Exception / Deferral Type** | **Approval Required** | **Process** | **Review Cycle** | |---|---|---|---| | Non-BES OT operational window | Risk Pillar Leader within PRC-VM flexibility; CISO if longer deferral or High/Critical residual risk | Schedule treatment in next approved OT maintenance window; document compensating controls, owner, and verification method. Longer deferral routes to Risk Acceptance Record under RMF-001 §9.7. | Next maintenance window; at least monthly until closure | | BES Cyber System - compliance posture unaffected | CISO + NERC-CIP Compliance Manager concurrence | Confirm no CIP compliance gap is created or extended; document BES asset identifier, CIP applicability note, compensating controls, and evidence-library location. | At least every 30 days until closure | | BES Cyber System - CIP compliance impact | CISO + NERC-CIP deviation process | Initiate CIP deviation and mitigation plan. Notify regulatory liaison as required. Risk acceptance does not replace the CIP deviation process. | Per mitigation plan milestones and regulatory deadline | | Emergency operational exception | CISO post-hoc within 24 hours | Operational team may delay or alter treatment only to prevent safety, reliability, or grid disturbance. Document immediately, preserve evidence, and convert to the appropriate non-BES/BES route if residual risk continues. | 30 days maximum unless converted to formal deferral / deviation path | Every OT deferral must state why non-patch treatment options (segmentation, path blocking, configuration change, compensating monitoring, vendor isolation, or service removal) cannot close the exposure sooner. Deferral does not close the finding; closure requires verified treatment or a reviewed risk/exception posture. --- ## 12. Document Control | | | |---|---| | **Document ID** | CERG-STD-OT-001 | | **Version** | 1.22 | | **Approved By** | CISO | | **Next Review** | Annual / Upon Significant Change / CIP Standard Revision | | **Change Log** | 1.22 - Added OT/BES patch deferral and exposure-treatment routing aligned to PRC-VM §7.4. 1.0 - Initial publication. BES and non-BES OT environments. | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.22 | 2026-06-18 | Governance Pillar Leader | Added explicit OT/BES deferral routes for non-BES maintenance windows, BES compliance-unaffected deferrals, BES compliance-impacting deviations, and emergency operational exceptions. | | 1.0 DRAFT | 2025 | CERG Governance | Initial release - BES and non-BES OT environments | ### Review Triggers This standard must be reviewed annually and upon any of the following triggering events: - Revision to any applicable NERC-CIP standard (CIP-002 through CIP-014) - Significant change to the OT environment, new BES Cyber System categorizations, major architecture changes, or significant new vendor deployments - A significant cybersecurity incident affecting any in-scope OT system - Changes to [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) or IEC 62443 that materially affect the requirements herein - Direction from the CISO or regulatory examination findings Governance owns this document. The Governance Pillar Leader (OT/NERC-CIP) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents References below use the canonical IDs in [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) Document Catalog. Where the catalog notes an artifact is embedded in a parent operational package for V1, the parent is the authoritative location. | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - this standard is subordinate | | Document Catalog and Naming Convention | [CERG-GOV-CAT-001](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Authoritative inventory of all CERG artifacts referenced here | | Unified Control Baseline | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control spine, overlay matrix, evidence mapping (BES overlay) | | NERC-CIP Operational Package | [CERG-PLN-CIP-001](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | OT/CIP operational binder - contains the NERC-CIP Evidence Library Procedure (formerly `CERG-GOV-CIP-001`), OT Exposure Management Procedure, BES access overlay, deviation template, CIP-013 plan, CIP-009 recovery package, and CIP-015 tracking | --- ## IT (HOSTED, CLOUD, AND SaaS) SECURITY STANDARD ### Owned Data Center · Leased Facility · IaaS · PaaS · SaaS --- | | | |---|---| | **Document ID** | CERG-STD-IT-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / Upon Significant Change / Material Cloud Service Adoption | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final) · [NIST 800-144](https://csrc.nist.gov/pubs/sp/800/144/final) · NIST RMF · CSA CCM v4 | | **Regulations** | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [CMMC L2](https://dodcio.defense.gov/CMMC/) (where applicable) · HIPAA (where applicable) | | **Environments** | Owned Data Center · Leased / Colocation · IaaS · PaaS · SaaS · Hybrid | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [CERG Roles in Hosted and Cloud Environments](#2-cerg-roles-in-hosted-and-cloud-environments) 3. [GOVERN, Cloud Program Foundation and Shared Responsibility](#3-govern--cloud-program-foundation-and-shared-responsibility) 4. [IDENTIFY, Visibility Across Estates](#4-identify--visibility-across-estates) 5. [PROTECT, Architecture, Identity, and Data](#5-protect--architecture-identity-and-data) 6. [DETECT, Cloud-Native and Cross-Estate Monitoring](#6-detect--cloud-native-and-cross-estate-monitoring) 7. [RESPOND, Containment Without Crossing Tenant Boundaries](#7-respond--containment-without-crossing-tenant-boundaries) 8. [RECOVER, Resilience in Multi-Tenant Environments](#8-recover--resilience-in-multi-tenant-environments) 9. [Training and Personnel](#9-training-and-personnel) 10. [Regulatory and Framework Alignment Summary](#10-regulatory-and-framework-alignment-summary) 11. [Exceptions and Escalation](#11-exceptions-and-escalation) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope This standard implements the foundational principles established in **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)** for information technology assets hosted in owned data centers, leased / colocation facilities, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) environments. It defines specific, measurable security requirements that apply regardless of whether the underlying infrastructure is owned, leased, rented, or consumed as a service. The intent is durable: as the organization continues to shift workloads between owned, hybrid, and fully cloud-native models, the security obligations do not change, only the implementation specifics do. This standard makes those implementation differences explicit while keeping the underlying control intent constant. ### 1.1 Scope This standard applies to: - All applications, services, and data hosted in **organization-owned data centers** - All systems housed in **leased / colocation** facilities, regardless of who provides the physical security - All **IaaS** workloads (e.g., AWS EC2, Azure VMs, GCP Compute, private cloud) - All **PaaS** services consumed by the organization (e.g., managed databases, container platforms, serverless functions) - All **SaaS** applications used to process organizational data, including productivity, collaboration, HR, finance, ITSM, and security tooling - All **hybrid** integrations between the above, including identity federation, VPN, ExpressRoute / Direct Connect, and API integrations - All personnel and third parties with administrative or privileged access to in-scope systems > **Note on OT and BES Cyber Systems** > > Grid and control system environments are governed by **[CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md)**. Where an enterprise IT system has direct or indirect connectivity to an OT environment, both standards apply, and the more stringent requirement controls. ### 1.2 The Shared Responsibility Reality Cloud and SaaS providers operate under a shared responsibility model. The provider is accountable for security *of* the cloud, physical facilities, hypervisor, base platform, and the organization remains accountable for security *in* the cloud, data, identity, configuration, application logic, and access. Outsourcing the workload does not outsource the accountability. > **The Shared Responsibility Trap** > > The single most common cause of cloud-related incidents is not a provider failure, it is a customer misunderstanding of which side of the line a given control sits on. Every cloud or SaaS service in use must have a documented shared responsibility mapping. Where the mapping is ambiguous, the organization assumes the obligation until the provider documents otherwise in writing. ### 1.3 Relationship to Parent Policy This standard is subordinate to **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)**. It implements specific requirements; it does not limit any principle established in that policy. Where this standard is silent, the policy governs. Exceptions follow the process defined in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Section 7. --- ## 2. CERG Roles in Hosted and Cloud Environments The three CERG pillars operate across all hosted and cloud estates with the same structure as on-premises IT, with adaptations that reflect the operating model of each environment. | **CERG Pillar** | **Hosted / Cloud / SaaS-Specific Responsibilities** | |---|---| | **Engineering** | Reviews and approves architecture for all cloud and SaaS adoptions before production. Defines and maintains secure landing zones, reference architectures, and configuration baselines for each cloud platform in use. Embeds security guardrails into infrastructure-as-code (IaC) pipelines. Conducts pre-production reviews of all new SaaS integrations and IaaS workloads. Owns the organization's shared responsibility matrix. | | **Risk** | Operates continuous configuration assessment (CSPM/SSPM) and exposure management across cloud and SaaS estates. Maintains the SaaS inventory and integration risk register. Conducts third-party risk assessments for all SaaS and cloud providers and tracks SOC 2 / ISO 27001 / FedRAMP attestation currency. Runs adversarial testing against cloud workloads and SaaS configurations on a defined cadence. | | **Governance** | Maintains this standard and all subordinate cloud and SaaS procedures. Owns the cloud governance framework - including approved provider list, data residency rules, and tenancy approval workflow. Tracks compliance posture against SOC 2 / ISO 27001 / [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) / [CMMC](https://dodcio.defense.gov/CMMC/) obligations for cloud and SaaS estates. Coordinates [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC evidence collection from cloud and SaaS systems supporting financial reporting. | > **The "Cloud Is Just Someone Else's Computer" Fallacy** > > Cloud and SaaS are not a free pass on security obligations, but they also are not equivalent to on-premises systems. Treating a SaaS app as "out of scope because the vendor handles security" produces real, exploitable gaps. Treating an IaaS workload as just a virtual machine ignores the cloud control plane, often the most attractive attack surface. CERG treats each environment on its own terms, with controls calibrated to the actual operating model. --- ## 3. GOVERN: Cloud Program Foundation and Shared Responsibility ### 3.1 Approved Provider and Service Catalog The organization shall not consume cloud or SaaS services that have not been assessed and approved through CERG. Shadow IT, services procured outside this process, is one of the most material sources of unmanaged risk in modern enterprises. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain an authoritative catalog of approved cloud platforms (IaaS/PaaS) and SaaS applications. New services may not enter production use without being added to the catalog. | All Cloud / SaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SA-9 · CSA CCM GRC-04 | | Assess every cloud or SaaS provider before onboarding. Assessment scope is tiered: Tier 1 (regulated data, broad access, financial reporting impact), Tier 2 (general business data), Tier 3 (low-sensitivity, narrow access). | All Cloud / SaaS | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SA-9 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC vendor | | Validate provider attestations - SOC 2 Type II, ISO 27001, FedRAMP, HITRUST, or equivalent - before onboarding and annually thereafter. Track expiration and re-attestation in the vendor risk register. | All Cloud / SaaS | Risk / Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.12.4 | | Document data residency, sub-processor disclosure, and right-to-audit clauses in every cloud and SaaS contract. Contracts without these provisions require CISO sign-off and documented compensating controls. | All Cloud / SaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SR-3 · GDPR Art 28 | | Maintain a written shared responsibility matrix for every approved cloud platform and SaaS application. Map each in-scope control to: provider, customer, or shared. Update upon any change in service model. | All Cloud / SaaS | Engineering / Governance | [NIST 800-144](https://csrc.nist.gov/pubs/sp/800/144/final) · CSA CCM | ### 3.2 Data Classification and Placement Where data lives determines what controls apply. Every workload and SaaS tenant shall be mapped to a documented data classification. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Classify all data processed in cloud and SaaS environments per the organization's data classification scheme: Public, Internal, Confidential, Restricted (CUI / PCI / PHI / financial). | All Cloud / SaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) RA-2 | | Prohibit storage or processing of Restricted-tier data in any cloud or SaaS service not explicitly approved for that classification. | All Cloud / SaaS | Governance / Engineering | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.3 · [CMMC](https://dodcio.defense.gov/CMMC/) AC.L2-3.1.3 | | Maintain a data flow inventory for each in-scope cloud workload and SaaS tenant documenting: data classes processed, ingress / egress endpoints, integration partners, and sub-processors. | All Cloud / SaaS | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SA-8 · GDPR Art 30 | | Where data residency restrictions apply (regulatory, contractual, customer commitment), configure provider region constraints and document the enforcement mechanism. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SA-9(5) | ### 3.3 Tenancy, Account, and Subscription Governance Cloud accounts and SaaS tenants are control boundaries. They are governed, not arbitrarily provisioned. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All cloud accounts (AWS accounts, Azure subscriptions, GCP projects) shall be provisioned through the organization-approved landing zone with embedded guardrails, logging, and identity federation. Manual root account creation is prohibited. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2 · CSA CCM IAM-09 | | Root, global administrator, and tenant owner accounts shall be protected by phishing-resistant MFA, vaulted credentials, break-glass procedures, and continuous monitoring. Use of these accounts shall trigger an alert. | All Cloud / SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2(11) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | SaaS tenants procured for production use shall be registered to organizational identity (SSO/SCIM), placed under contract with the central procurement process, and inventoried in the SaaS catalog. Free-tier or personal-account use of SaaS for organizational work is prohibited. | All SaaS | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Decommission unused accounts, subscriptions, projects, and SaaS tenants on a documented schedule. Idle resources are an unmonitored attack surface and a cost liability. | All Cloud / SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-8(3) | --- ## 4. IDENTIFY: Visibility Across Estates ### 4.1 Inventory and Configuration Visibility | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain a real-time inventory of all cloud resources across all approved cloud platforms, populated via provider APIs (e.g., AWS Config, Azure Resource Graph, GCP Asset Inventory). Static spreadsheets are not acceptable. | IaaS / PaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-8 · [NIST CSF 2.0](https://www.nist.gov/cyberframework) ID.AM | | Maintain a SaaS inventory populated from at minimum: SSO/IdP logs, expense data, and SaaS discovery tooling. Reconcile monthly. | All SaaS | Risk / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-8 · CSA CCM AIS-04 | | Deploy continuous cloud security posture management (CSPM) covering all production cloud accounts and subscriptions. Posture findings flow to the centralized vulnerability program. | IaaS / PaaS | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CA-7 · CSA CCM IVS-09 | | Deploy SaaS security posture management (SSPM) for all Tier 1 SaaS applications and for any SaaS storing Restricted-tier data. | All SaaS (Tier 1) | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CA-7 | | Tag every cloud resource with: owner, environment (prod/non-prod), data classification, cost center, and application identifier. Untagged resources are flagged for owner identification and remediation. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-8 | ### 4.2 Vulnerability and Configuration Drift Identification | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Scan all IaaS workloads (VMs, containers, serverless functions) for OS, library, and runtime vulnerabilities on a defined cadence. Container images shall be scanned in the build pipeline and before promotion to production. | IaaS / PaaS | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) RA-5 · CIS Top 18 | | Detect drift from approved configuration baselines for cloud control-plane resources (e.g., security groups, IAM policies, storage bucket ACLs, encryption settings) within 24 hours. | IaaS / PaaS | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-2(7), CM-6(1) | | Exposure treatment and patch hygiene follow the canonical classification and SLA table in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). This standard does not restate SLA values; PRC-VM-001 governs PPR, confirmed exposure, compensated flaw, and hygiene debt timing. | IaaS / PaaS | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-2 · CISA KEV | | Where a vulnerability cannot be remediated within SLA, document compensating controls and obtain risk acceptance per [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Section 7. | All Cloud | Risk / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-2(6) | --- ## 5. PROTECT: Architecture, Identity, and Data ### 5.1 Identity and Access > **Identity Is the New Perimeter** > > In cloud and SaaS, traditional network boundaries are advisory at best. Identity, who is making this API call, from where, on what device, is the actual enforcement point. Identity controls in cloud environments must be treated with the same operational priority as firewall rules were in the data-center era. | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All workforce access to cloud and SaaS shall be brokered through the central identity provider (IdP) using SSO. Direct local accounts on cloud platforms or SaaS apps are prohibited except for documented break-glass and emergency cases. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2, IA-8 · [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) | | Enforce phishing-resistant MFA (FIDO2, platform authenticators, or equivalent) for all administrative access to cloud and SaaS. Standard MFA (TOTP, push) is the minimum for general user access. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-2(11) · [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) AAL2/AAL3 | | Apply just-in-time (JIT) elevation for cloud and SaaS privileged roles. Standing administrative access is prohibited except for documented exceptions reviewed quarterly. | IaaS / PaaS / Tier 1 SaaS | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-6(2), AC-6(5) | | Conditional access policies shall evaluate at minimum: device compliance, location / network risk, user risk signals, and session sensitivity. Sensitive admin paths require compliant managed devices. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(12), AC-17 | | Automate identity lifecycle (joiner / mover / leaver) via SCIM, IdP groups, or equivalent. Manual deprovisioning is not an acceptable primary control for Tier 1 systems. | All Cloud / SaaS | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(1) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | | Conduct quarterly access reviews for Tier 1 SaaS, cloud control-plane access, and any system supporting financial reporting. Reviews shall be evidenced and retained per [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC requirements. | Tier 1 SaaS / IaaS / PaaS | Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-2(7) | ### 5.2 Network and Architecture | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All production IaaS workloads shall be deployed into a documented landing zone with: hub-and-spoke or equivalent network architecture, egress filtering, default-deny security groups, and centralized DNS / logging. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-7 · CSA CCM IVS-06 | | Public exposure of resources (cloud storage, databases, management endpoints) is prohibited unless explicitly justified, documented, and protected by compensating controls. CSPM shall continuously detect and alert on public exposure of in-scope resource types. | IaaS / PaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-7 · CIS Benchmarks | | All administrative access to cloud control planes and SaaS admin consoles shall traverse the organization's secure access path (e.g., conditional access + privileged access workstation, or equivalent). | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-17 · [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) 3.1.12 | | Where a cloud environment must interconnect with on-premises systems, the connection (VPN, ExpressRoute, Direct Connect, Cloud Interconnect) shall be terminated in a documented transit network with egress / ingress filtering and traffic logging. | Hybrid | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-7(3), SC-8 | | IT systems shall not establish direct routed connectivity to OT environments. All IT/OT data flows transit the OT DMZ per [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) and require Engineering approval. | Hybrid | Engineering | [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) §5.1 | ### 5.3 Data Protection | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Encrypt data in transit using TLS 1.2 or higher with approved cipher suites for all in-scope cloud and SaaS communications. Disable legacy protocols (SSLv3, TLS 1.0/1.1) on customer-managed endpoints. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-8 · [NIST 800-52r2](https://csrc.nist.gov/pubs/sp/800/52/r2/final) | | Encrypt data at rest for Confidential and Restricted classifications using provider-native encryption or customer-managed keys. Customer-managed keys (CMK) are required for Restricted data. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-28 · [CMMC](https://dodcio.defense.gov/CMMC/) SC.L2-3.13.8 | | Manage encryption keys in a dedicated key management service (KMS / HSM-backed). Key rotation, separation of duties, and key access logging are required. Key custody for Restricted data shall reside with the customer, not the provider. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SC-12 · FIPS 140-2/3 | | Apply DLP controls to Tier 1 SaaS and to outbound cloud data flows where Restricted-tier data is present. DLP policies shall block, alert, or quarantine per the data classification scheme. | All Cloud / SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC-23, SI-4(4) | | Backups of Restricted-tier and [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant data shall be encrypted, isolated (separate trust boundary or immutable storage), and tested for restoration per Section 8.2. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-9 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | ### 5.4 Hardening and Secure Build | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain documented secure configuration baselines for: each cloud platform's control plane, each VM OS image, each container base image, and each major PaaS service in use. Baselines align to CIS Benchmarks where available. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-6 · CIS Benchmarks | | Production cloud workloads shall be deployed via infrastructure-as-code (IaC) with mandatory pre-merge security checks (static analysis, policy-as-code). Manual production changes are exception cases. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-3 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC change | | Container images shall be built from approved base images, scanned for vulnerabilities, and signed. Production clusters shall enforce admission policies that reject unsigned or unscanned images. | PaaS (containers) | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-7, SI-2 · [NIST 800-190](https://csrc.nist.gov/pubs/sp/800/190/final) | | Secrets (API keys, database credentials, signing keys) shall be stored in a dedicated secrets manager and consumed at runtime. Plaintext secrets in source repositories, configuration files, or IaC are prohibited and shall be detected by automated scanning. | IaaS / PaaS / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IA-5 · OWASP ASVS | | Tier 1 SaaS applications shall be configured against documented hardening baselines (e.g., M365 Secure Score, Salesforce Health Check, Google Workspace baseline). Baseline drift is detected by SSPM and remediated within SLA. | Tier 1 SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM-6 · CIS Benchmarks | | Tier 2 SaaS (Restricted/CUI data) shall enforce: SSO via IdP, phishing-resistant MFA for admin, DLP policies, audit log export to SIEM, admin role review quarterly, tenant baseline scan (CIS / vendor). | Tier 2 SaaS | Engineering / Risk | NIST 800-53 IA-2, AC-2, CM-6, AU-2 · CIS SaaS Benchmarks | | Tier 3 SaaS (Internal data, narrow access) shall enforce: SSO via IdP, MFA for admin, admin role review semi-annually, tenant baseline scan annually. | Tier 3 SaaS | Engineering / Governance | NIST 800-53 IA-2, AC-2 · CIS SaaS Benchmarks | | Shadow IT discovery: SSPM / CASB / IdP log analysis shall run continuously. Unapproved SaaS with organizational data triggers 30-day remediation or block. | All SaaS | Risk / Governance | NIST 800-53 CM-8, CA-7 | | OAuth / third-party app grants in Tier 1/2 SaaS shall be inventoried, risk-ranked, and reviewed quarterly. High-risk grants (broad scopes, external publishers) require CISO approval. | Tier 1/2 SaaS | Engineering / Risk | NIST 800-53 AC-21 · CSA CCM IAM-13 | --- ### 5.5 SaaS Tenant Hardening Baselines Each Tier 1 SaaS tenant shall maintain a documented baseline covering: | **Tenant** | **Baseline Source** | **Key Controls** | **Drift SLA** | |---|---|---|---| | Microsoft 365 | CIS M365 Foundations L1/L2 + CERG overrides | Secure Score ≥ 80%, Conditional Access policies, Defender for Office P2, Audit log retention ≥ 1 yr, Phishing-resistant MFA for all admin | 30 days | | Salesforce | CIS Salesforce / Salesforce Health Check + CERG | SSO mandatory, MFA phishing-resistant, Field-level security, Event Monitoring → SIEM, Permission set review quarterly | 30 days | | ServiceNow | CERG baseline (no CIS) | SSO mandatory, OAuth client secret rotation, Admin role review quarterly, Audit/log export → SIEM, Domain separation documented | 30 days | | GitHub / GitLab | CERG baseline | SSO, MFA, Branch protection, Dependabot/secret scanning, Runner isolation, Audit log → SIEM | 30 days | | Google Workspace | CIS Google Workspace + CERG | SSO, MFA, Admin activity alerts, Drive DLP, Audit log retention | 30 days | Baseline drift detected by SSPM → finding in PRC-VM-001 pipeline → remediation per SLA. Baseline changes require Engineering approval and evidence update. ## 6. DETECT: Cloud-Native and Cross-Estate Monitoring ### 6.1 Logging | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Enable cloud control-plane audit logging (CloudTrail, Azure Activity Logs, GCP Audit Logs) in all accounts / subscriptions / projects. Logs route to a centralized, tamper-resistant log archive separate from the originating account. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-2, AU-9 · CIS Cloud | | Capture admin and authentication logs from all Tier 1 SaaS via provider APIs or SIEM connectors. Where the provider does not expose required event types, raise a risk-accepted gap with quarterly review. | Tier 1 SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-2 | | Retain audit logs for in-scope cloud and SaaS environments for a minimum of 12 months, with at least 90 days hot / immediately searchable. Longer retention applies where regulation requires (e.g., [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), HIPAA). | All Cloud / SaaS | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-11 · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) | | Protect log archives with write-once / immutable storage controls and dedicated access roles. Log deletion or modification requires CISO approval and shall trigger an alert. | All Cloud / SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU-9(2), AU-9(3) | ### 6.2 Detection Engineering | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Operate a centralized SIEM (or equivalent) that ingests cloud audit logs, SaaS audit logs, EDR telemetry, IdP / SSO events, and network telemetry. Detection rules cover cloud-specific TTPs (e.g., MITRE ATT&CK for Cloud). | All Cloud / SaaS | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4 · MITRE ATT&CK | | Deploy CSPM and SSPM continuous detection rules covering at minimum: public exposure, disabled logging, weakened encryption, privilege escalation paths, anomalous admin behavior, and identity-provider tampering. | All Cloud / SaaS | Risk / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SI-4(5), CA-7 | | Subscribe to and integrate cloud-relevant threat intelligence (CISA advisories, provider security bulletins, ISAC feeds). Translate relevant intelligence into detection rules and posture checks. | All Cloud / SaaS | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PM-16, SI-5 | | Test detections quarterly through purple-team exercises or automated adversary emulation (e.g., Stratus Red Team, AWS / Azure attack simulation tooling) in non-production accounts. | IaaS / PaaS | Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CA-8 · MITRE ATT&CK | --- ## 7. RESPOND: Containment Without Crossing Tenant Boundaries > **Cloud Response Has Different Rules** > > Response actions in cloud environments operate inside a multi-tenant control plane owned by the provider. Containment that would be straightforward on-premises, pulling a cable, isolating a VLAN, must be executed through provider APIs and with awareness of shared responsibility limits. Forensic acquisition in cloud and SaaS depends on what the provider exposes. Plans must be built around those realities, not against them. ### 7.1 Cloud and SaaS Incident Response | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain documented response playbooks for cloud and SaaS incident classes including, at minimum: compromised cloud credential, malicious IaC change, exposed storage / database, SaaS account takeover, OAuth grant abuse, and supply chain compromise of a SaaS dependency. | All Cloud / SaaS | Governance / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4, IR-8 | | Pre-stage cloud-native isolation actions (e.g., quarantine IAM policies, account-suspend automation, network ACL templates) in approved IaC and validate quarterly. Improvisation during an incident is not acceptable for Tier 1 systems. | IaaS / PaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4(1), IR-4(2) | | Document forensic acquisition procedures per provider, including which artifacts are obtainable, retention windows, and the formal request channels for provider-side data. Validate annually with each Tier 1 provider. | All Cloud / SaaS | Risk / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4(6), AU-12 | | Confirm and document provider incident notification SLAs. Where a provider's SLA is insufficient for organizational regulatory obligations, compensating monitoring controls shall be implemented. | All Cloud / SaaS | Governance / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-6 · GDPR Art 33 | | Integrate cloud and SaaS response into the master Incident Response Plan (**[CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md)**). Notification timelines for [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204), breach laws, contractual customer commitments, and regulator obligations shall be documented per data class. | All Cloud / SaaS | Governance | [CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | --- ## 8. RECOVER: Resilience in Multi-Tenant Environments ### 8.1 Recovery Planning | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Maintain documented recovery plans for all Tier 1 cloud workloads and SaaS applications, including: RTO, RPO, dependencies, restoration procedures, and provider escalation contacts. | All Cloud / SaaS | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-2 · ISO 22301 | | Define a tiered availability strategy per workload (e.g., multi-AZ, multi-region, multi-cloud) commensurate with business criticality. The chosen strategy shall be tested, not assumed. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-7 · CSA CCM BCR | | For SaaS systems with no provider-side restore option, the organization shall operate independent backups (e.g., third-party SaaS backup for M365, Google Workspace, Salesforce). Provider replication is not equivalent to a backup. | Tier 1 SaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-9 · CSA CCM BCR-08 | | For [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems, document backup integrity, retention, and restoration testing as ITGC evidence. Restoration testing shall occur at least annually with results retained. | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant | Engineering / Governance | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-9(1) | ### 8.2 Backup Testing and Restoration | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | Test restoration of Tier 1 cloud workloads at least annually from production-equivalent backups. Test results shall be documented as audit evidence. | IaaS / PaaS | Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-9(1), CP-10 | | Validate that recovery procedures account for cloud-specific failure modes: region outage, provider account compromise, IAM lockout, and dependency-chain SaaS unavailability. | All Cloud / SaaS | Engineering / Risk | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CP-2(2), CP-2(5) | | Conduct post-incident reviews within 30 days of any significant availability or security event affecting an in-scope system. Lessons learned feed Engineering, Risk, and Governance backlog items. | All Cloud / SaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) IR-4(4) | --- ## 9. Training and Personnel | **Requirement** | **Applies To** | **CERG Owner** | **Regulatory Reference** | |---|---|---|---| | All personnel with cloud administrative roles shall complete role-appropriate cloud security training within 60 days of assignment and annually thereafter. | IaaS / PaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-2, AT-3 | | SaaS administrators for Tier 1 applications shall complete platform-specific security configuration training and stay current with provider security release notes. | Tier 1 SaaS | Governance / Engineering | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-3 | | All workforce members shall complete annual security awareness training that includes SaaS-specific risks: phishing, OAuth grants, third-party app authorization, and shadow IT. | All Cloud / SaaS | Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-2 · [CMMC](https://dodcio.defense.gov/CMMC/) AT.L2-3.2.1 | | Engineering personnel responsible for IaC and pipeline security shall maintain current knowledge of cloud-native attack patterns and provider security advisories. | IaaS / PaaS | Engineering / Governance | [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AT-3 | --- ## 10. Regulatory and Framework Alignment Summary | **Requirement Area** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | **[NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final)** | **CSA CCM v4** | **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC** | |---|---|---|---|---|---| | Approved Provider / Vendor Mgmt | GV.SC | SA-9, SR-3 | 3.1.20 | STA-01 to STA-09 | Vendor mgmt | | Data Classification & Residency | GV.OC | RA-2, SA-9(5) | 3.1.3, 3.8.x | DSP-01 to DSP-19 | - | | Identity / SSO / MFA | PR.AA | IA-2, IA-5, AC-2 | 3.5.1–3.5.11 | IAM-01 to IAM-16 | Access | | Privileged Access (JIT, PIM) | PR.AA | AC-6, AC-2(7) | 3.1.5 | IAM-04, IAM-09 | Access | | Network & Landing Zone | PR.IR | SC-7, SC-8 | 3.13.1, 3.13.5 | IVS-06, IVS-09 | - | | Encryption & Key Mgmt | PR.DS | SC-12, SC-28 | 3.13.10, 3.13.11 | CEK-01 to CEK-21 | - | | Hardening / IaC / Pipelines | PR.PS | CM-3, CM-6 | 3.4.x | CCC-01 to CCC-09 | Change mgmt | | CSPM / SSPM / Vulnerability | ID.RA, DE.CM | CA-7, RA-5, SI-2 | 3.11.2, 3.14.1 | TVM-01 to TVM-10 | - | | Logging & SIEM | DE.AE | AU-2, AU-9, SI-4 | 3.3.1, 3.14.6 | LOG-01 to LOG-13 | Logging | | Cloud Incident Response | RS | IR-4, IR-6, IR-8 | 3.6.1–3.6.3 | SEF-01 to SEF-08 | - | | Recovery & Resilience | RC | CP-2, CP-9, CP-10 | 3.6.x | BCR-01 to BCR-11 | Availability | | Personnel Training | GV.RR | AT-2, AT-3 | 3.2.1–3.2.3 | HRS-01 to HRS-13 | - | --- ## 11. Exceptions and Escalation No control in this standard may be waived without a documented exception. Exceptions to controls supporting [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC, [CMMC](https://dodcio.defense.gov/CMMC/), or Restricted-data handling carry additional obligations. | **Exception Type** | **Approval Required** | **Process** | **Review Cycle** | |---|---|---|---| | Standard exception (Internal-data SaaS / non-prod IaaS) | Engineering Pillar Leader + Governance | Submit risk acceptance via risk register with compensating control documentation. | Annual | | Tier 1 SaaS / production IaaS | CISO | Risk register entry with compensating controls. Governance reviews shared-responsibility implications. | Annual | | Restricted-data placement exception | CISO + Data Owner | Risk register + data classification review. CUI placements additionally subject to [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md). | Annual | | [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant system control gap | CISO + CFO designee | Risk register + ITGC compensating control documentation. External audit notification as required. | Quarterly until closed | | Emergency exception (operational necessity) | CISO (post-hoc within 24 hours) | Engineering may take emergency action; document immediately, formal exception within 24 hours. | 30 days maximum | --- ## 12. Document Control | | | |---|---| | **Document ID** | CERG-STD-IT-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / Upon Significant Change / Material Cloud Service Adoption | | **Change Log** | 1.0 - Initial publication. Owned data center, leased, IaaS, PaaS, SaaS. | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 DRAFT | 2026 | CERG Governance | Initial release - owned data center, leased, IaaS, PaaS, SaaS | ### Review Triggers This standard shall be reviewed annually and upon any of the following triggering events: - Material change to the organization's cloud or SaaS estate, new platform adoption, major migration, or significant provider consolidation - Release of materially updated provider shared-responsibility documentation - Significant cybersecurity incident affecting any in-scope cloud or SaaS system - Changes to [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), 800-171, CSA CCM, or [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC guidance that materially affect requirements herein - Direction from the CISO, internal audit findings, or external regulatory examination Governance owns this document. The Governance Pillar Leader (Enterprise IT/Cloud) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - this standard is subordinate | | Grid and Control System Standard | [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Peer standard - governs OT estates and IT/OT boundary | | CUI Handling Standard | [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) | Peer standard - applies in addition where CUI is present | | Access Management Standard | [CERG-STD-AC-001](CERG-STD-AC-001_Access_Management_Standard.md) | Peer standard - identity and access requirements apply across IT, cloud, and SaaS environments | | Third-Party and Supply Chain Risk Procedure | [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | SaaS onboarding, vendor evidence, and shared responsibility interface | --- ## LOGGING, MONITORING, AND DETECTION STANDARD ### Mandatory Log Sources · SIEM Onboarding · Day-One Detection Set · OT and CUI Overlays · Triage and Tuning --- | | | |---|---| | **Document ID** | CERG-STD-LM-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader (Detection Engineering) | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-CR-001](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | | **Supporting Procedures** | [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) · [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / On SIEM platform change / On MITRE ATT&CK matrix update | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (DETECT) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (AU, SI) · [NIST 800-92](https://csrc.nist.gov/pubs/sp/800/92/final) · MITRE ATT&CK Enterprise / Cloud / ICS · MITRE D3FEND | | **Regulations** | NERC-CIP CIP-007 R4 · [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.3.x) · SOX ITGC (Operations) · CIP-015 (forward-looking) | | **Environments** | All in-scope assets - IT · cloud · SaaS · OT · CUI · identity · network | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Operating Principles](#2-operating-principles) 3. [Mandatory Log Sources](#3-mandatory-log-sources) 4. [Log Routing, Protection, and Retention](#4-log-routing-protection-and-retention) 5. [SIEM Onboarding](#5-siem-onboarding) 6. [Day-One Detection Set](#6-day-one-detection-set) 7. [Detection Lifecycle and Validation](#7-detection-lifecycle-and-validation) 8. [Alert Triage and Tuning](#8-alert-triage-and-tuning) 9. [OT Monitoring Overlay](#9-ot-monitoring-overlay) 10. [CUI Monitoring Overlay](#10-cui-monitoring-overlay) 11. [Identity Detection Use Case Pack](#11-identity-detection-use-case-pack) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope The policy requires privileged-access logging, log protection, retention, SIEM (or equivalent) monitoring, OT-safe collection methods, and threat-intelligence integration. The IT, OT, CUI, and Access standards each impose more specific log and detection requirements. Until this standard, those requirements existed in fragments, no consolidated list of mandatory log sources, no day-one detection set, no triage procedure. This standard consolidates those requirements. It defines the log sources every in-scope environment must onboard, how those logs are routed and retained, the detection set the SIEM must implement on day one, and how detections are validated and tuned over time. It applies to every in-scope asset and every CERG-managed detection platform. > **Detection Coverage Is a Product, Not a Project** > > Onboarding a SIEM is a project. Detection coverage is the ongoing measurement of whether the detections that should be firing actually do, for the threats that matter to *this* environment. CERG instruments coverage as a metric (`DT-001` in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md)) and treats anything below the target as an incident-readiness gap. --- ## 2. Operating Principles 1. **MITRE ATT&CK is the threat reference.** Detection scope and prioritization use ATT&CK Enterprise (IT/cloud/SaaS), ATT&CK for ICS (OT), and ATT&CK for Cloud sub-matrices. 2. **Day-One Set is non-negotiable.** Every in-scope environment has the minimum detection set in Section 6 enabled within 30 days of onboarding (`CERG-X-05`). 3. **Coverage over count.** A SIEM with 4,000 rules and 35% real ATT&CK coverage is worse than a SIEM with 400 rules and 80% real ATT&CK coverage. 4. **Tune to signal, not silence.** A muted alert that should have fired is an incident. Tuning suppresses noise, not findings. 5. **Logs are immutable.** No production identity can edit or delete a log inside its retention period. 6. **OT collection is passive by default.** Collection methods that risk OT availability are prohibited without engineering approval. --- ## 3. Mandatory Log Sources The list below is the minimum every CERG-managed environment must onboard. Anything not listed may still be required by a subordinate standard; nothing in this list may be waived without an approved exception per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). ### 3.1 Identity, Endpoint, and Application | **Source** | **What Must Be Collected** | |---|---| | Identity Provider (IdP) | All authentication events (success/fail), MFA events, conditional access decisions, admin actions on tenants/users/roles, federation/trust events. | | IGA / Identity Governance | Account lifecycle (create/modify/disable/delete), entitlement assignments, recertification events. | | Privileged Access Management (PAM) | Vault retrieve, session start/stop, command execution metadata, break-glass usage, policy changes. | | Directory Services (AD, Entra ID, etc.) | Authentication, privileged group changes, GPO / policy changes, DCSync / DCShadow indicators. | | OAuth / OIDC application logs | Consent grants, token issuance, scope changes, suspicious app installs (M365 / Workspace). | | Endpoint Detection and Response (EDR) | Process events, persistence indicators, lateral-movement indicators, EDR tamper events. | | Email / collaboration platform | Sign-in events, mailbox/forwarding rule changes, suspicious attachment / link events, anomalous OAuth grants. | | MDM / device compliance | Compliance status, enrollment / un-enrollment events, posture changes. | ### 3.2 Cloud and SaaS | **Source** | **What Must Be Collected** | |---|---| | Cloud control plane (CloudTrail / Activity Log / Audit Logs) | All admin events org-wide; tenant-isolation, IAM, networking, KMS, logging-config changes. | | Cloud workload | OS audit, container runtime, function invocation logs (where in scope). | | CSPM / SSPM | Misconfiguration findings, drift, posture changes. | | Tier 1 SaaS admin/auth logs | Per [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) Section 9; minimally: admin actions, auth events, data export, sharing events. | | KMS / HSM | Key administrative events, policy changes, usage events for keys protecting Restricted/CUI. | | Secrets manager | Retrieval, write, policy change events. | ### 3.3 Network, Vulnerability, and Telemetry | **Source** | **What Must Be Collected** | |---|---| | Firewall (edge and segment) | Session metadata, threat events, rule changes. | | Network device (switch/router) | Configuration changes, AAA events. | | DNS resolver | Query logs (sampled or full per environment), tunneling indicators. | | Web proxy / SSE / SWG | URL/category, blocked actions, file upload/download. | | NDR / network sensor | Detection events; metadata flows where retained. | | VPN / remote access gateway | Session start/stop, posture decisions, geographic anomalies. | | Vulnerability scanner | DISH scan output, scan run metadata, exception annotations. | ### 3.4 OT (See Also §9) | **Source** | **What Must Be Collected** | |---|---| | OT passive monitoring (e.g., span/tap-fed sensor) | Asset inventory deltas, protocol anomalies, baseline deviations. | | SCADA / HMI | Authentication, configuration changes, alarm history, operator console actions. | | Historian | Authentication, admin actions, integrity-relevant events. | | OT jump server | Session events, file transfer, command history. | | OT firewall / EAP enforcement device | Session, rule change, denied flow events. | | Engineering workstation | Authentication, USB / removable media events, application execution. | ### 3.5 CUI (See Also §10) | **Source** | **What Must Be Collected** | |---|---| | CUI workstation / VDI | Auth, file access events for CUI, USB/media activity, EDR. | | CUI file repositories | Access events, share/permission changes, large or anomalous export. | | CUI cloud enclave (GCC High / FedRAMP equivalent) | Tenant audit, DLP findings. | | CUI DLP | Policy match events, blocked/allowed transfers, override events. | --- ## 4. Log Routing, Protection, and Retention ### 4.1 Routing - IT/cloud/SaaS logs route to the enterprise SIEM via supported native connectors or log shippers. - OT logs route via the **one-way** transfer pattern specified in [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) and Section 9 below. No bidirectional pulls from OT. - CUI logs route to a SIEM tenancy / index that aligns with the CUI boundary and supports FIPS-validated transport ([`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md)). ### 4.2 Protection - Logs are written to immutable / WORM storage for the retention period. - Administrative actions on logs (delete, retention change, export) are themselves logged and reviewed. - Log access follows least privilege per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md); privileged log access uses PAM. ### 4.3 Retention | **Scope** | **Hot / Searchable** | **Cold / Archive** | |---|---|---| | Default | 13 months | 7 years (or per regulatory requirement, whichever longer) | | BES Cyber Systems | 90 days searchable minimum | 12 months total minimum (CIP-007 R4.3); CERG default exceeds | | CUI | 13 months hot | 7 years per [CMMC L2](https://dodcio.defense.gov/CMMC/) / DFARS | | SOX-relevant | 13 months hot | 7 years per SOX requirement | --- ## 5. SIEM Onboarding Onboarding follows a fixed checklist. The output is a SIEM Onboarding Record per environment. ### 5.1 SIEM Onboarding Checklist | **Step** | **Done When** | |---|---| | Source inventory | Every mandatory source per Section 3 is named and accounted for. | | Connector deployed | Native connector or log shipper deployed in supported configuration. | | Parsing validated | Logs are parsed to the expected schema and timestamp normalized to UTC. | | Field mapping | Identity, asset, action, source/destination fields mapped to the SIEM's data model. | | Volume baselined | Steady-state volume known; alert on volume drop > X% (Section 5.2). | | Retention configured | Hot and cold retention per Section 4.3. | | Access controlled | RBAC for analysts; PAM for admins. | | Day-One detections enabled | Per Section 6 for the environment type. | | Detection coverage report generated | Per [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) metric DT-001. | | Operations handoff | Triage runbook (Section 8) in place; on-call rotation aware. | ### 5.2 Source Health Monitoring Each onboarded source is itself monitored. CERG alerts on: - Source silence (no events for > expected interval). - Volume drop > 30% week-over-week (configurable per source). - Parsing failure rate > 1%. - Connector error or authentication failure. These alerts are treated as high-priority operational items, not as detections in their own right. --- ## 6. Day-One Detection Set The Day-One Detection Set is the minimum coverage required in any in-scope environment within 30 days of onboarding. The set is curated against MITRE ATT&CK with ATT&CK Enterprise as the IT spine, ATT&CK for Cloud sub-techniques for cloud/SaaS scopes, and ATT&CK for ICS for OT scopes. ### 6.1 Day-One: IT / Cloud / SaaS / Identity | **Category** | **Detection Intent** | **ATT&CK Mapping (examples)** | |---|---|---| | Initial Access | Anomalous geographic sign-in; impossible-travel; suspicious OAuth consent | T1078, T1566, T1199 | | Execution | Suspicious script execution; PowerShell encoded commands | T1059.001, T1204 | | Persistence | Mailbox forwarding / inbox rule additions; new scheduled task; new local admin | T1098, T1136, T1547 | | Privilege Escalation | Local privilege escalation indicators; cloud role assumption anomalies | T1068, T1078.004 | | Defense Evasion | EDR tamper events; cloud trail / activity log disable; security group change | T1562, T1027 | | Credential Access | Brute force; password spray; ASREP roast / Kerberoasting | T1110, T1558 | | Discovery | Cloud account / role enumeration; AD reconnaissance from low-priv account | T1087, T1069 | | Lateral Movement | Pass-the-hash / pass-the-ticket indicators; remote service exploitation | T1550, T1021 | | Collection | Mass mailbox download; high-volume SharePoint / Drive download | T1114, T1213 | | Exfiltration | Anomalous outbound volume; new exfil destinations | T1041, T1567 | | Impact | Mass file modification (ransomware indicators); resource deletion in cloud | T1485, T1486 | ### 6.2 Day-One: OT | **Category** | **Detection Intent** | **ATT&CK for ICS Mapping** | |---|---|---| | Initial Access | External engineering-tool connection; jump-server anomaly | T0817, T0822 | | Execution | New process on HMI / SCADA server; engineering-tool execution off-hours | T0871 | | Persistence | New service / scheduled task on OT host; firmware change | T0857 | | Lateral Movement | Cross-segment traffic between ESPs; new flow patterns | T0883 | | Inhibit Response Function | Alarm suppression; logging disabled | T0878, T0837 | | Impair Process Control | Setpoint changes off normal range; relay setting group change | T0855 | ### 6.3 Day-One: CUI CUI overlay (see Section 10) adds CUI-specific detections (export, share, label changes, classified-data movement to non-CUI destinations). ### 6.4 Coverage Reporting - Coverage is computed as the % of ATT&CK techniques within the in-scope sub-matrix that have at least one detection authored, tested, and operating. Reported as DT-001 in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). - **CERG coverage target: 70% of in-scope ATT&CK sub-matrix techniques with at least one operating detection.** Below 70% is reported red on the CISO dashboard and treated as an incident-readiness gap until closed. - The detection inventory is exported monthly and reviewed quarterly against the in-scope sub-matrix. --- ## 7. Detection Lifecycle and Validation Every detection has a lifecycle from `Proposed` through `Retired`. Detection metadata is recorded in the detection inventory. | **State** | **Means** | |---|---| | Proposed | Drafted by detection engineer. | | In Test | Running in non-prod; tuning underway. | | In Production | Active; routed to triage queue. | | Suspended | Temporarily disabled (data-quality issue, tool change); time-boxed. | | Retired | Removed; rationale captured. | ### 7.1 Detection Metadata Each production detection has: - ID and name - ATT&CK technique(s) and tactic(s) - Data sources used - Logic summary (no proprietary leakage outside detection eng) - Severity / triage queue routing - Expected fire rate (per env) - False-positive notes and tuning history - Last purple-test validation date and result - Owner ### 7.2 Validation - Detections are validated quarterly via the purple-team procedure in [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) §6. - Validation result feeds metric DT-002. - Failed validations open a risk register entry per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) until restored. --- ## 8. Alert Triage and Tuning ### 8.1 Triage Queue Model - **P1, Critical:** business impact suspected; SOC engages immediately and pages IR per [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md). - **P2, High:** likely true positive worth examining within hours. - **P3, Medium:** worth examining within the shift. - **P4, Low:** examined for trends; bulk-tuned where appropriate. ### 8.2 Triage SLA | **Priority** | **Acknowledge** | **First Action** | **Disposition** | |---|---|---|---| | P1 | ≤ 15 minutes | ≤ 30 minutes | per IR | | P2 | ≤ 2 hours | ≤ 4 hours | within shift | | P3 | within shift | within 24 hours | within 48 hours | | P4 | within 48 hours | within 5 business days | within 10 business days | ### 8.3 Tuning Discipline - Tuning suppresses noise; tuning never suppresses findings. - Every tuning change records: detection ID, reason, suppressed condition, expiration / review date. - Tuning changes are reviewed monthly; expired tunings are reinstated unless renewed with justification. > **The Bar for Suppressing an Alert** > > If a tuning suppresses a condition that has ever yielded a real finding in this environment, peer organization, or current threat intelligence, the tuning needs a different shape, a different field condition, a different threshold, not a blanket suppression. --- ## 9. OT Monitoring Overlay OT monitoring adds to the IT pattern; it does not replace it. - **Passive monitoring is the default.** Span / tap / mirror-fed sensors capture protocol-aware traffic for asset inventory, anomaly, and detection. - **Engineering-supervised authenticated checks** allowed in defined windows for endpoint health, configuration capture. - **One-way transfer to SIEM.** Data diodes or filtered one-way pipelines per [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). - **OT-specific detection set** per Section 6.2. - **OT alerts route through a queue that the SOC and OT operations both see** to avoid loss of fidelity in handoff. - **No active scanning** of live OT surfaces without an approved scope and time window per [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md). - **CIP-015 (forward-looking).** As CIP-015 finalizes, the BES INSM detection set in Section 6.2 is the foundation; additional CIP-015 detections are added when the standard is approved. --- ## 10. CUI Monitoring Overlay - **CUI labeling enforcement.** Data classified as CUI is labeled in source systems; movement of labeled data is monitored. - **CUI exfiltration alerts.** Outbound transfers of CUI to non-CUI destinations trigger P2 minimum. - **CUI workspace boundary** alerts on any cross-boundary access attempts. - **EDR on CUI endpoints** has CUI-aware policies (USB lockdown, application allowlist). - **Threat advisories** relevant to CUI (DFARS / DC3 advisories) are routed to detection engineering and incorporated where applicable. --- ## 11. Identity Detection Use Case Pack Identity is the most common attack surface; CERG names a use case pack explicitly. | **Use Case** | **Signal** | |---|---| | Phishing-resistant MFA bypass | Successful auth via legacy MFA when phishing-resistant policy applies. | | OAuth consent grant abuse | Unusual or risky app consent in M365 / Workspace. | | Privilege escalation in IdP | Unexpected addition to high-privilege groups. | | Service account anomaly | Service account auth from new ASN or new endpoint. | | Session token theft indicators | Auth from new device with valid refresh token. | | Federation tampering | Trust / claim / certificate changes in IdP federation. | | Conditional access policy change | Any change to CA policy in M365 / Entra. | | Break-glass account use | Any successful auth on a break-glass account. | | Dormant account reactivation | Auth on a disabled / dormant account. | | Impossible travel / geo anomalies | Two successful auths from geographically inconsistent locations. | --- ## 12. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Section** | **Where in This Standard** | |---|---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AU / SI | AU-2, AU-6, AU-9, AU-11, SI-4 | All sections | | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) DETECT | DE.CM, DE.AE | All sections | | [NIST 800-92](https://csrc.nist.gov/pubs/sp/800/92/final) | All | Sections 3–4 | | MITRE ATT&CK Enterprise / Cloud / ICS | All | Sections 6, 7 | | NERC-CIP CIP-007 R4 | Security Event Monitoring | Sections 3.4, 4.3, 9 | | NERC-CIP CIP-015 (draft) | INSM | Section 9 | | [CMMC L2](https://dodcio.defense.gov/CMMC/) / 800-171r3 | 3.3.x | Section 10 | | SOX ITGC | Operations / Monitoring | Sections 3, 4 | --- ## 13. Document Control | | | |---|---| | **Document ID** | CERG-STD-LM-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / SIEM platform change / ATT&CK matrix update | | **Change Log** | 1.0 - Initial publication. Mandatory log sources, retention, SIEM onboarding, day-one detection set anchored to MITRE ATT&CK, OT/CUI/identity overlays, triage and tuning. | --- ## NETWORK SECURITY AND SEGMENTATION STANDARD ### Zero-Trust Principles · Segmentation · Boundary Control · IT/OT Separation · Remote Access --- | | | |---|---| | **Document ID** | CERG-STD-NET-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On material change to network architecture | | **Frameworks** | [NIST 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) (Zero Trust Architecture) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (SC, AC families) · [CIS Controls v8](https://www.cisecurity.org/controls) (Controls 12, 13) · [IEC 62443](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards) (zones and conduits) | | **Regulations** | NERC-CIP (CIP-005 electronic security perimeter) · CMMC L2 / 800-171r3 (3.13.x) · SOX ITGC | | **Environments** | All in-scope networks: owned, hybrid, cloud, SaaS access paths, and OT | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Zero-Trust Architecture](#3-zero-trust-architecture) 4. [Network Segmentation](#4-network-segmentation) 5. [Boundary Control](#5-boundary-control) 6. [The IT/OT Boundary](#6-the-itot-boundary) 7. [Remote Access](#7-remote-access) 8. [Cloud Network Security](#8-cloud-network-security) 9. [Network Monitoring](#9-network-monitoring) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The network is where an intruder moves. A foothold on one system becomes a breach of the estate only if the network lets the intruder travel. The IT, OT, and Access standards each impose network-adjacent requirements; none of them owns the network itself. This standard does. This standard establishes the requirements for network security across CERG-managed environments: the zero-trust principles that govern how access to network resources is decided, how the estate is segmented, how boundaries between segments are controlled, how the IT and OT networks are separated, how remote access is granted, and how networks are monitored. It applies to every network CERG-managed systems use: physical and virtual networks in owned data centers, cloud virtual networks, the network paths to SaaS, and operational technology networks. > **Segmentation Is What Turns an Incident Into a Contained Incident** > > Every significant breach retrospective contains the same sentence in some form: the attacker moved laterally from the initial foothold. Lateral movement is a network event. A flat network means one compromised laptop can reach the domain controller, the financial system, and the control network. A segmented network means the compromised laptop reaches the things that laptop legitimately needs and nothing else. Segmentation does not prevent the incident. It decides how bad the incident gets. --- ## 2. Principles 1. **The network is not a trust boundary.** Being on the internal network grants nothing. Access to a resource is decided per request against identity, device posture, and context, not by network location. 2. **Default deny.** Network paths are denied unless explicitly allowed. A segment, a firewall, a security group starts closed. Connectivity is added deliberately and recorded. 3. **Segment by function and criticality.** Systems are grouped into segments by what they do and how critical they are, per the criticality tiers in [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md). A breach in one segment does not become a breach of another for free. 4. **The boundary is enforced and watched.** Every boundary between segments is enforced by a control and monitored. An unenforced boundary is not a boundary. 5. **OT is separated, not just segmented.** The boundary between the IT network and the OT network is the most consequential boundary in the estate and is held to a higher bar than any other. 6. **Every allowed path has an owner and a reason.** A firewall rule, a security group entry, a peering connection exists because someone needed it and someone owns it. Rules with no owner and no recorded reason are removed. --- ## 3. Zero-Trust Architecture CERG networks are designed toward the zero-trust model in NIST 800-207. The estate does not have to reach a fully mature zero-trust architecture on day one; it does have to move deliberately in that direction and never away from it. 1. **Access is per-session and per-resource.** A user or service is granted access to a specific resource for a specific session, not to a network zone indefinitely. 2. **Every access decision uses identity and device posture.** Access decisions combine the authenticated identity per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) with the posture of the device making the request per [`CERG-STD-EP-001`](CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md). 3. **Encryption in transit is assumed everywhere.** Traffic is encrypted in transit per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md), including traffic between internal segments. The network is treated as hostile. 4. **The policy decision point is logged.** Every access decision a zero-trust enforcement point makes is logged per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). > **Zero Trust Is a Direction, Not a Product** > > No purchase makes an organization zero-trust. Zero trust is an architecture an estate moves toward over years: removing implicit network trust, adding identity and posture to access decisions, encrypting internal traffic, shrinking segments. CERG asks one thing of every network change: does it move the estate toward the zero-trust model, or away from it? Changes that move away from it are exceptions and are filed as such. --- ## 4. Network Segmentation 1. **The estate is segmented.** The network is divided into segments. A single flat network for the whole estate is not permitted for any environment beyond a trivial one. 2. **Segments are defined by function and criticality.** At minimum the estate separates: user endpoints, servers and production workloads, management and administrative interfaces, infrastructure and security tooling, untrusted and guest networks, and OT (Section 6). Critical-tier systems are segmented from lower-tier systems. 3. **Management interfaces are isolated.** Administrative and management interfaces of infrastructure are placed in a dedicated management segment reachable only through controlled paths. A management plane reachable from the user network is a finding. 4. **Inter-segment traffic is default-deny.** Traffic between segments is denied unless an explicit, owned rule allows it (Section 5). 5. **Segmentation is documented.** The segment map, what each segment contains and which segments may talk to which, is documented and kept current as an architecture artifact. An undocumented network cannot be reasoned about. --- ## 5. Boundary Control 1. **Every inter-segment boundary is enforced.** A boundary between segments is enforced by a firewall, a cloud security group, an access control list, or an equivalent control. The enforcement point is itself a Critical or High asset per [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md). 2. **Rules are least-privilege.** A boundary rule allows the narrowest source, destination, port, and protocol that satisfies the need. Any-to-any rules are prohibited except at a deliberately open boundary, and that exception is recorded. 3. **Every rule has an owner and a reason.** Each rule records who owns it and why it exists. A rule traceable to neither is removed. 4. **Rules are reviewed.** The boundary rule set is reviewed at least annually. The review removes rules that are no longer needed, tightens rules that are broader than needed, and confirms each remaining rule still has an owner. Stale rules accumulate; the review is how they are removed. 5. **Rule changes are change-controlled.** A change to a boundary rule set follows change management. For SOX-relevant boundaries, the change record is audit evidence. 6. **The internet boundary is hardened.** The boundary between the estate and the internet enforces both ingress and egress control. Unrestricted outbound traffic is a data-exfiltration path; egress is filtered and monitored. --- ## 6. The IT/OT Boundary This section applies to organizations that operate operational technology. For NERC-CIP entities, it operates alongside the electronic security perimeter requirements in [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md); where the two are read together, the stricter requirement governs. 1. **IT and OT networks are separated.** The OT network is not a segment of the IT network. It is a separate network joined to IT only through a controlled, monitored boundary. 2. **The boundary is a single, defined set of crossing points.** Traffic crosses the IT/OT boundary only through a defined, minimal set of crossing points. Every crossing point is documented, enforced, and monitored. Undocumented crossings are findings of the highest severity. 3. **The boundary is default-deny and minimal.** Only the specific flows an operational need requires cross the boundary. The direction of each flow is constrained; data flowing out of OT for monitoring is not a path for traffic to flow into OT. 4. **No direct internet path to OT.** OT systems do not have a direct path to or from the internet. Remote access to OT follows Section 7 and the additional constraints of [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). 5. **The boundary is designed with IEC 62443 zones and conduits.** The IT/OT boundary and the segmentation within OT use the zones-and-conduits model of IEC 62443. > **The IT/OT Boundary Is the Most Important Boundary in the Estate** > > A compromise that crosses from IT into OT moves from a data problem to a physical and safety problem. The IT/OT boundary is held to a higher standard than any other boundary in CERG: fewer crossing points, tighter rules, stricter direction control, and continuous monitoring. When the IT/OT boundary requirement here and the electronic security perimeter requirement in the OT standard appear to differ, the stricter one is followed. There is no acceptable reason to relax this boundary for convenience. --- ## 7. Remote Access 1. **Remote access is identified, authenticated, and authorized.** Every remote connection into the estate authenticates the identity per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md), including multi-factor authentication, and is authorized to a specific set of resources. 2. **Remote access is least-privilege.** A remote session reaches the resources the session needs, not the whole internal network. Remote access that drops a user onto a flat internal network is prohibited. 3. **Device posture is checked.** A device connecting remotely is checked for posture before access is granted, per [`CERG-STD-EP-001`](CERG-STD-EP-001_Endpoint_and_Mobile_Security_Standard.md). 4. **Remote administrative access is brokered and recorded.** Privileged remote access to infrastructure goes through a privileged access broker per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). Privileged remote sessions are recorded. 5. **Vendor and third-party remote access is time-bound and supervised.** A vendor granted remote access receives it for a defined window, scoped to defined systems, and the access is removed when the window closes. Standing vendor access is prohibited. This aligns with [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). 6. **Remote access to OT is exceptional.** Remote access into the OT network is granted only where operationally necessary, is brokered, is supervised in real time where it affects control systems, and follows [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). --- ## 8. Cloud Network Security 1. **Cloud virtual networks are segmented.** The principles in Sections 4 and 5 apply to cloud virtual networks: function-based segmentation, default-deny between subnets, least-privilege security groups, and owned rules. 2. **The cloud landing zone enforces network baseline.** Network segmentation, boundary defaults, and egress control are part of the cloud landing zone governed by [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) and are enforced through infrastructure-as-code per [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md). 3. **Cloud-to-on-premises connectivity is a controlled boundary.** A private interconnect or VPN between cloud and owned environments is an inter-segment boundary and is governed by Section 5. 4. **Public exposure is deliberate.** A cloud resource is reachable from the internet only by an explicit, owned decision. Inadvertent public exposure of storage, databases, or management interfaces is a finding. --- ## 9. Network Monitoring 1. **Boundary enforcement points log.** Firewalls, security groups, and other enforcement points send logs to the platform governed by [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). 2. **East-west traffic is visible.** Monitoring covers traffic between internal segments, not only traffic crossing the internet boundary. Lateral movement is an east-west event; monitoring that sees only the perimeter does not see it. 3. **The IT/OT boundary is continuously monitored.** Every crossing point of the IT/OT boundary is monitored continuously, using OT-safe methods per [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). 4. **Detection content covers the network.** Detection use cases include network-based indicators: anomalous inter-segment traffic, boundary rule violations, and unexpected egress. Detection content is owned per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). --- ## 10. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Network Security Responsibility** | |---|---| | **Engineering Pillar Leader** | Owns this standard. Accountable for network architecture, the segment map, and the zero-trust trajectory. | | **Cloud Security Engineer** | Owns cloud network security: virtual network segmentation, security groups, landing-zone network baseline, and cloud interconnects. | | **OT Security Engineer** | Owns the IT/OT boundary design and the OT network segmentation, in coordination with [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). | | **Identity Engineer** | Owns the identity and device-posture inputs to zero-trust access decisions and the privileged access broker for remote administrative access. | | **Endpoint Engineer** | Provides the device posture signal used in remote access and zero-trust decisions. | | **Detection Engineer** | Owns network-based detection content; consumes boundary and east-west logs. | | **Exposure Management Lead** | Tracks network-device vulnerabilities and exposed-service findings. | | **Vendor Risk Analyst** | Coordinates time-bound vendor remote access with [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). | | **Governance Pillar Leader** | Tracks boundary-rule review completion and exceptions; cross-references this standard with the control baseline. | | **Policy & Standards Manager** | Maintains this document, its version, and its review cycle. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST 800-207 | Zero Trust Architecture tenets | Section 3 | | NIST 800-53r5 | SC-7 (boundary protection), AC-17 (remote access), SC-8 (transmission), AC-4 (information flow) | Sections 5, 6, 7 | | CIS Controls v8 | Control 12 (network infrastructure), Control 13 (network monitoring and defense) | Sections 4, 5, 9 | | IEC 62443 | Zones and conduits model | Section 6 | | NERC-CIP | CIP-005 (electronic security perimeter and remote access) | Sections 6, 7 | | NIST 800-171r3 / CMMC L2 | 3.13.1, 3.13.5, 3.13.6 (boundary protection and network separation) | Sections 4, 5, 6 | | SOX ITGC | Network boundary change control | Section 5 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-NET-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to network architecture | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST 800-207; NIST 800-53r5 (SC, AC); CIS Controls v8 (12, 13); IEC 62443 | | **Regulations** | NERC-CIP (CIP-005); CMMC L2 / 800-171r3; SOX ITGC | | **Environments** | All in-scope networks | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes zero-trust architecture direction, network segmentation by function and criticality, boundary control with owned and reviewed rules, the elevated-bar IT/OT boundary, remote access requirements including time-bound vendor access, cloud network security, and network monitoring including east-west visibility. | ### Review Triggers - Material change to network architecture or to the cloud landing zone - Revision of NIST 800-207, NERC-CIP CIP-005, or IEC 62443 - A significant incident involving lateral movement or boundary failure - Internal audit or regulatory finding affecting network security - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Platforms) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | IT / Cloud / SaaS Security Standard | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Cloud landing-zone network baseline | | Grid Control Systems Security Standard | [`CERG-STD-OT-001`](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | Electronic security perimeter; OT network constraints | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Identity for zero-trust decisions; privileged access broker | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Criticality tiers that drive segmentation | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Hardening of network devices | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Encryption in transit | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Boundary logging; network detection content | | Secure Software Development and Application Security Standard | [`CERG-STD-SDL-001`](CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Infrastructure-as-code enforcement of network baseline | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor remote access | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `NET` domain | --- ## SECURE CONFIGURATION BASELINE STANDARD: DISH ### Defensive Infrastructure System Hardening · IT and OT Hardening Profile --- | | | |---|---| | **Document ID** | CERG-STD-CFG-001 | | **Version** | 1.21 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Platforms) | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-LM-001](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-CR-001](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | | **Review Cycle** | Annual / Upon CIS Benchmark version change or new platform class | | **Frameworks** | CIS Benchmarks v8+ · CIS Controls v8 · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CM family) · [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) (OT) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · IEC 62443-3-3 / 4-2 | | **Regulations** | NERC-CIP v7 CIP-007/CIP-010 · [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.4.x) · SOX ITGC (Change/Operations) | | **Environments** | Owned data center · IaaS / PaaS · SaaS (Tier 1) · OT (BES and non-BES) · Endpoint · Network · Cloud control plane · Container/K8s | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The DISH Profile](#2-the-dish-profile) 3. [Baseline Tiers and When Each Applies](#3-baseline-tiers-and-when-each-applies) 4. [Baseline Catalog](#4-baseline-catalog) 5. [IT Platform Baselines](#5-it-platform-baselines) 6. [Cloud Baselines](#6-cloud-baselines) 7. [Container and Kubernetes Baseline](#7-container-and-kubernetes-baseline) 8. [Network and Firewall Baselines](#8-network-and-firewall-baselines) 9. [SaaS Tier 1 Baselines](#9-saas-tier-1-baselines) 10. [OT Platform Baselines](#10-ot-platform-baselines) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) requires approved baselines per asset class. The Operating Model names baselines, IaC, and policy-as-code as core Engineering activities. The IT, OT, and CUI standards each independently call for baselines. Until this standard, those requirements existed without a unified implementation set, which made hardening impossible to delegate or assess. This standard establishes the **DISH** profile - **D**efensive **I**nfrastructure **S**ystem **H**ardening - applicable to every in-scope asset class, IT and OT, with a single hardening minimum, an elevated tier for High-Impact and BES systems, and explicit fallbacks where CIS does not apply. The acronym is used throughout the CERG document library to refer to the baselines, scan profiles, and drift-detection signals derived from this standard; it is defined here and in [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) §3. > **Hardening Is Not Optional** > > A baseline that exists "in policy" but cannot be enumerated, scanned, or remediated is not a baseline. CERG treats hardening as a deliverable artifact (the baseline document), a scan profile (DISH), and a continuous control (drift detection). All three are required or the asset is non-compliant. ### 1.1 Scope Applies to every in-scope asset class: - Windows Server, Linux server, workstation/endpoint, mobile (MDM-managed) - Network device (switch/router), firewall, load balancer - Cloud landing zone and control plane (AWS, Azure, GCP) - Container and Kubernetes (cluster + workload) - Tier 1 SaaS (M365, Salesforce, ServiceNow, etc.) - SCADA server, HMI, historian, RTU, relay, engineering workstation, OT jump server - Identity systems (IdP, IGA, PAM), see also [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) --- ## 2. The DISH Profile DISH is the CERG-native, IT-and-OT-spanning hardening scan profile. It is implemented in the vulnerability scanning platform as a custom scan template that aggregates the requirements below. ### 2.1 Composition | **Source** | **Role in DISH** | |---|---| | **CIS Benchmark Level 1** | Inescapable floor for every in-scope asset where a CIS Benchmark exists. | | **CIS Benchmark Level 2** | Required for High-Impact systems, BES Cyber Systems, CUI components. | | **[NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final)** | Authoritative for ICS/OT where CIS does not apply or contradicts safe OT operation. | | **IEC 62443-3-3 (SR) and 62443-4-2 (CR)** | Authoritative for OT component-level requirements, including vendor-supplied systems. | | **[NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final)** | Authoritative for CUI-component-specific parameters. | | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM family parameters** | Authoritative for any control where [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) names a parameter (timeouts, lockouts, retention). | | **CERG-specific overrides** | Documented in this standard. Overrides are an exception to CIS, not a relaxation - they are tighter than CIS, never looser. | > **Why a Named Profile** > > DISH gives Engineering, Risk, and the Audit team a single label they all mean the same thing by. "Did this asset pass DISH?" is a yes/no auditable question. "Is this asset hardened?" is not. ### 2.2 DISH Scan Output The DISH scan produces, per asset: 1. Pass/fail per check, with CIS/NIST/IEC citation. 2. CERG-X-03 compliance status (`Implemented` / `Partially Implemented`). 3. Severity-weighted score for trending (used by [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) CM-001). 4. Exception annotation for any check covered by an approved exception in the Exception Register. --- ## 3. Baseline Tiers and When Each Applies | **Tier** | **DISH Profile** | **Applies To** | |---|---|---| | **Tier 0 - Standard** | CIS L1 (or [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) / IEC 62443 fallback) | Every in-scope asset with no overlay. | | **Tier 1 - High-Impact** | CIS L2 (or [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) / IEC 62443 strict) | Systems whose loss would materially impact operations or safety. | | **Tier 2 - BES** | CIS L2 (or [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) / IEC 62443 strict) + CIP-007 R1–R5 + CIP-010 R1 parameters | Medium/High Impact BES Cyber Systems and their EACMS, PACS, and PCAs. | | **Tier 3 - CUI** | CIS L2 + 800-171r3 parameters + FIPS crypto profile (via [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md)) | CUI in-scope assets. | | **Tier 4 - OT Safety** | [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) / IEC 62443 strict + change-management lockdown | OT systems whose disruption can cause safety impact. | Multiple tiers may apply (a BES Cyber System that processes CUI is Tier 2 + Tier 3); the tighter parameter wins per control. --- ## 4. Baseline Catalog The catalog below names each baseline, points at the authoritative source, and identifies CERG overrides where they exist. Each row corresponds to one DISH scan policy in the VM tool. | **Baseline** | **Authoritative Source** | **DISH Tier(s)** | **CERG Overrides?** | |---|---|---|---| | Windows Server 2019/2022 | CIS Microsoft Windows Server Benchmark | T0 / T1 / T3 | Yes - Section 5.1 | | Linux Server (Ubuntu LTS, RHEL 8/9) | CIS Distribution Benchmarks | T0 / T1 / T3 | Yes - Section 5.2 | | Windows 10/11 Workstation | CIS Windows 10/11 Benchmark | T0 | Yes - Section 5.3 | | macOS Endpoint | CIS macOS Benchmark | T0 | Limited - Section 5.3 | | Network Device - Switch/Router (Cisco IOS/NX-OS) | CIS Cisco Benchmark | T0 / T1 | Yes - Section 8.1 | | Firewall (Palo Alto, Fortinet, Cisco FTD) | CIS Vendor Benchmarks | T0 / T1 | Yes - Section 8.2 | | AWS Account / Landing Zone | CIS AWS Foundations Benchmark | T0 / T1 / T3 | Yes - Section 6.1 | | AWS Control Plane | CIS AWS Foundations + CERG | T0 / T1 / T3 | Yes - Section 6.1 | | Azure Subscription / Landing Zone | CIS Microsoft Azure Foundations Benchmark | T0 / T1 / T3 | Yes - Section 6.2 | | GCP Project / Landing Zone | CIS GCP Foundations Benchmark | T0 / T1 / T3 | Yes - Section 6.3 | | Kubernetes Cluster (CNCF) | CIS Kubernetes Benchmark | T0 / T1 / T3 | Yes - Section 7 | | Container Image | CIS Docker Benchmark + CERG | T0 / T1 / T3 | Yes - Section 7 | | M365 Tenant | CIS M365 Foundations Benchmark | T0 / T1 / T3 | Yes - Section 9.1 | | Salesforce Org | CIS or CERG-equivalent baseline | T0 / T1 | Yes - Section 9.2 | | ServiceNow Instance | CERG baseline (no CIS) | T0 / T1 | - Section 9.3 | | Other Tier 1 SaaS | CERG SaaS Baseline Pattern | T0 / T1 | Section 9 pattern | | SCADA Server | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) + IEC 62443-3-3 | T2 / T4 | Yes - Section 10.1 | | HMI | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) + IEC 62443-4-2 | T2 / T4 | Yes - Section 10.2 | | Historian | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) + CIS (where Win/Linux) | T2 / T4 | Yes - Section 10.3 | | RTU / Relay | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) + IEC 62443-4-2 + vendor hardening | T2 / T4 | Yes - Section 10.4 | | Engineering Workstation | CIS Windows + 800-82r3 add-ons | T2 / T4 | Yes - Section 10.5 | | OT Jump Server | CIS Windows L2 + CERG | T2 / T4 | Yes - Section 10.6 | --- ## 5. IT Platform Baselines ### 5.1 Windows Server The Windows Server baseline is CIS L1 (Tier 0) or L2 (Tier 1 / 3) with the following CERG overrides: - **Local administrator** disabled; named administrative accounts only, via PAM JIT per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). - **SMBv1 disabled** without exception (override is a hard fail; exceptions must be reviewed annually). - **LM/NTLMv1 disabled**; NTLMv2 only as transitional with documented sunset. - **Audit policy** matches the mandatory log source list in [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md), specifically Process Creation, Logon, Object Access (privileged file shares), and PowerShell ScriptBlock logging enabled and forwarded to SIEM. - **PowerShell** Constrained Language Mode for non-admin sessions; signed script enforcement for admin sessions. - **Time** synchronized to authoritative time source; drift > 5 minutes is a finding. - **CMK / disk encryption** per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) for any system holding Restricted or CUI. ### 5.2 Linux Server CIS L1 / L2 with CERG overrides: - **Root SSH** prohibited; key-based authentication; password authentication disabled. - **sudoers** scoped via named groups; no NOPASSWD escalations outside of break-glass accounts. - **`auditd`** enabled with rules covering identity events, sudo, privileged file access, and process execution; forwarded to SIEM. - **Time, hostname, syslog destination, package repository allowlist** managed by configuration management. - **Kernel module load** restricted via signed-module enforcement where supported. - **Disk encryption** for any system holding Restricted or CUI. ### 5.3 Workstation / Endpoint CIS L1 with the additional CERG requirements: - **EDR agent installed, healthy, and tamper-protected.** - **Full-disk encryption** with key escrow. - **Local admin** removed for standard users; administrative tasks via just-in-time elevation. - **Conditional access** binds device posture to access. - **USB mass storage controlled** (allowlist / read-only / blocked per data classification). --- ## 6. Cloud Baselines CERG hardens both **landing zone** (account / subscription / project provisioning) and **control plane** (IAM, logging, networking, key management). ### 6.1 AWS CIS AWS Foundations Benchmark L1 (Tier 0) / L2 (Tier 1+) with CERG overrides: - **Org-level Service Control Policies (SCPs)** enforce: deny root access keys; deny region pinning except approved regions; deny disabling of CloudTrail / GuardDuty / Config / Security Hub; deny public S3 by default. - **CloudTrail** multi-region, organization trail, log-file integrity validation enabled, KMS-encrypted, immutable storage. - **GuardDuty / Security Hub / Config / Inspector** enabled in every account. - **IAM**: no root usage; IAM Identity Center as the only human-access path; permissions boundaries on workload roles; access keys disabled for human users. - **Networking**: no default VPC use in production; egress allowlist; VPC flow logs enabled and routed to SIEM. - **KMS**: CMK for any data classified Restricted or CUI; rotation per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). ### 6.2 Azure CIS Azure Foundations Benchmark L1 / L2 with CERG overrides: - **Management group hierarchy** enforces policy inheritance; Azure Policy initiatives are mandatory. - **Microsoft Defender for Cloud** enabled at Standard tier for in-scope subscriptions. - **Activity Logs / Diagnostic Settings** routed to immutable Log Analytics workspace and SIEM. - **Entra ID**: privileged access via PIM only; Conditional Access for all administrative roles; phishing-resistant MFA for all admins; legacy authentication blocked. - **Storage Accounts**: public access disabled by default; CMK for Restricted/CUI workloads. ### 6.3 GCP CIS GCP Foundations Benchmark L1 / L2 with CERG overrides: - **Organization Policies** enforce: domain-restricted sharing; uniform bucket-level access; require OS Login; disable service-account key creation by default. - **Security Command Center** Premium tier in-scope. - **Cloud Audit Logs**: admin activity + data access enabled and exported to immutable destination + SIEM. - **CMEK** for Restricted/CUI workloads. --- ## 7. Container and Kubernetes Baseline CIS Kubernetes Benchmark for control plane and worker node, plus CERG application-layer requirements: - **Pod Security Standards**: `restricted` for production namespaces. - **Network Policies**: default-deny ingress and egress; explicit allowlists per service. - **Admission controllers** enforce signed images (cosign / sigstore), no privileged pods, no host network/PID, no `:latest` tags. - **Image provenance**: images built only from approved base images; SBOM produced at build; scan results gate promotion. - **Secrets**: Kubernetes secrets disabled or encrypted via external secrets manager per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). - **Cluster audit log** routed to SIEM. --- ## 8. Network and Firewall Baselines ### 8.1 Switches / Routers CIS Cisco IOS/NX-OS L1 / L2 with CERG overrides: - **Management plane**: out-of-band management network; SSH only; TACACS+/RADIUS via central IdP; local accounts only as break-glass per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). - **Control plane policing** enabled with documented thresholds. - **Logging** to syslog and SIEM; NTP authenticated. - **Unused services** disabled (CDP/LLDP scoped, HTTP server off, etc.). - **Configuration management** under version control; out-of-band changes detected and alerted. ### 8.2 Firewalls CIS vendor benchmark plus CERG overrides: - **Default deny** ingress and egress; explicit allowlists. - **Rule lifecycle**: every rule has owner, business justification, and review date; review cadence ≤ 12 months. - **TLS inspection** policy aligned with [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) and data classification. - **Log forwarding** to SIEM with session-level and threat-event-level detail. --- ## 9. SaaS Tier 1 Baselines ### 9.1 M365 Tenant CIS M365 Foundations Benchmark L1 / L2 with CERG overrides: - **Phishing-resistant MFA** for all admin roles, enforced by Conditional Access. - **External sharing**: domain allowlist or full lockdown by default; SharePoint anonymous links disabled. - **Defender for Office 365** Plan 2 features enabled (Safe Links, Safe Attachments, anti-phish). - **Audit log retention** ≥ 1 year (advanced audit license); routed to SIEM. - **CUI Enclave (if applicable)** uses GCC High or FedRAMP-equivalent tenant per [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md). ### 9.2 Salesforce CIS or vendor baseline plus CERG overrides: - **SSO mandatory** for human users; legacy username/password disabled except as documented break-glass. - **MFA** phishing-resistant where supported. - **Field-level / record-level access** restricted to least privilege; permission set assignments reviewed quarterly. - **Event Monitoring** enabled with logs forwarded to SIEM. ### 9.3 ServiceNow CERG baseline (no CIS): - **SSO** mandatory; admin role assignments reviewed quarterly. - **Inbound integrations** scoped via OAuth with rotated client secrets per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). - **Audit & system logs** forwarded to SIEM. - **Domain separation** documented when shared with vendors or sub-orgs. ### 9.4 Pattern for Other Tier 1 SaaS Where no published baseline exists, the CERG SaaS Baseline Pattern (Section 9 generic) requires: SSO + MFA + admin role review + audit log export + tenancy isolation + CMK or BYOK for Restricted/CUI + documented shared responsibility matrix. --- ## 10. OT Platform Baselines OT baselines lead with [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) and IEC 62443; CIS is used where the underlying OS supports it (typically engineering workstations and historian servers). > **Active Scanning is Forbidden in OT Without Engineering Approval** > > DISH for OT is delivered via passive monitoring, configuration capture, vendor management interfaces, and engineering-supervised authenticated checks. Active vulnerability scanning of a live SCADA or RTU surface is not permitted under this standard except under an approved scope and time window per [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md). ### 10.1 SCADA Server - Underlying OS hardened to CIS L2 with vendor compatibility exceptions documented and risk-accepted per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). - Application allowlisting enforced; only vendor-approved SCADA application binaries permitted. - Local accounts via PAM; vendor accounts gated by approved workflow per [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md). - Anti-malware where vendor-supported; otherwise compensating controls per IEC 62443-3-3 SR 3.2. - Logging to one-way SIEM transfer per [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). - Patch posture per OT VM procedure in [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md). ### 10.2 HMI - Locked-down kiosk-style desktop; standard Windows hardening minus features that interfere with operator workflow (documented). - USB and removable media controlled, read-only or disabled outside maintenance windows. - Screen-lock parameters appropriate to operator console operating context (per safety analysis). ### 10.3 Historian - Hardened to CIS L2 for Windows/Linux base. - Database engine hardening (SQL Server / time-series engine) per vendor + CERG. - Backups per [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md), including historian data sets. ### 10.4 RTU / Relay - Vendor hardening guidance applied as a minimum; CERG overrides only where they tighten. - Disable unused protocols; restrict management interfaces; rotate default credentials. - Firmware version pinned; updates per [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) CIP-010 procedure. - Configuration captured to backup per [`CERG-STD-RES-001`](CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) (configurations, firmware, logic files). ### 10.5 Engineering Workstation - CIS Windows L2 baseline. - Dedicated to OT use only; no general business workload. - USB / removable media policy stricter than enterprise default; tool-import policy documented. - Application allowlist of engineering tools and supporting libraries. ### 10.6 OT Jump Server - CIS Windows L2 baseline + CERG hardening above general workstation. - Brokered session recording for all sessions to OT. - MFA on entry; no clipboard / file transfer beyond named workflow. --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Section(s)** | **Where in This Standard** | |---|---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CM family | CM-2, CM-6, CM-7 | Sections 2 – 11 | | [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) | 3.4.x | Tier 3 in Section 3, parameters in Sections 5, 6, 9 | | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) | All | Tier 4 in Section 3; Section 10 | | IEC 62443-3-3 / 4-2 | SR / CR families | Section 10 | | CIS Controls v8 | Controls 4, 12 | Sections 5–9 | | NERC-CIP CIP-007 R1, R2, R5 | Ports, patching, accounts | Section 10 + `CERG-PLN-CIP-001` | | NERC-CIP CIP-010 R1 | Baseline configuration | All sections, especially Section 11 | | [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.4.x) | Configuration management | Tier 3 in Section 3; Section 5–9 | | SOX ITGC | Change / Operations | Section 11 | --- ## 12. Document Control | | | |---|---| | **Document ID** | CERG-STD-CFG-001 | | **Version** | 1.21 | | **Approved By** | CISO | | **Next Review** | Annual / CIS Benchmark or [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) revision | | **Change Log** | 1.0 - Initial publication. Establishes DISH profile, baseline catalog, and platform-specific baselines for IT, cloud, container, SaaS, and OT. | --- ## SECURE SOFTWARE DEVELOPMENT AND APPLICATION SECURITY STANDARD ### Secure SDLC · Code Review Gates · SAST/DAST/SCA · Secrets · Dependencies and SBOM · Pipeline Security --- | | | |---|---| | **Document ID** | CERG-STD-SDL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Application Security) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [`CERG-STD-IT-001`](CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | | **Review Cycle** | Annual / On NIST SSDF revision · On material toolchain change | | **Frameworks** | [NIST SSDF 800-218](https://csrc.nist.gov/pubs/sp/800/218/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (SA, SI, CM families) · [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) · OWASP SAMM · [NIST 800-161r1](https://csrc.nist.gov/pubs/sp/800/161/r1/final) (software supply chain) · [SLSA](https://slsa.dev/) | | **Regulations** | CMMC L2 / 800-171r3 (3.4.x, 3.13.x, 3.14.x) · SOX ITGC (change management) · NERC-CIP (where software supports BES Cyber Systems) | | **Environments** | All CERG-managed software: in-house applications, scripts, infrastructure-as-code, integration code, and automation | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [The Secure SDLC](#3-the-secure-sdlc) 4. [Security Gates](#4-security-gates) 5. [Code Review Requirements](#5-code-review-requirements) 6. [Automated Security Testing: SAST, DAST, SCA](#6-automated-security-testing-sast-dast-sca) 7. [Secrets in Code](#7-secrets-in-code) 8. [Dependencies and Software Bill of Materials](#8-dependencies-and-software-bill-of-materials) 9. [Pipeline and Build Security](#9-pipeline-and-build-security) 10. [Infrastructure as Code](#10-infrastructure-as-code) 11. [Vulnerability Handling for Software](#11-vulnerability-handling-for-software) 12. [Roles and Responsibilities](#12-roles-and-responsibilities) 13. [Regulatory and Framework Alignment Summary](#13-regulatory-and-framework-alignment-summary) 14. [Document Control](#14-document-control) --- ## 1. Purpose and Scope The Cyber Engineering pillar exists to build securely. Its mission statement, set in [`CERG-GOV-FRM-001`](../governance/CERG-GOV-FRM-001_CERG_Framework.md), is "build securely, deploy confidently, consult continuously." Until this standard, the program had no document that said what building securely actually requires. The architecture review procedure [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) governs the engagement; this standard governs the code. This standard establishes the requirements for secure software development across the CERG-managed estate: how software moves through a secure development lifecycle, the security gates it passes, the code review and automated testing it is subject to, how secrets and dependencies are handled, and how the build pipeline that produces it is itself secured. It applies to every piece of software CERG-managed teams write or materially modify: customer-facing and internal applications, microservices and APIs, scripts and automation, integration and glue code, and infrastructure-as-code. It does not govern the security of purchased software, which is handled by [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md), except where purchased components are embedded as dependencies (Section 8). > **The Standard Is a Floor, Applied by Risk Tier** > > Not every script needs a penetration test. This standard sets the minimum bar for all software and then scales the rigor by the risk tier of what is being built. A throwaway internal report generator and an internet-facing application that processes regulated data are both in scope; they are not subject to the same gate intensity. Section 3.2 defines the tiers. The floor is never zero, and it is never optional. --- ## 2. Principles Six principles govern secure development in CERG. 1. **Shift left, but do not shift blind.** Security findings are cheapest to fix before code is written and most expensive after release. Testing, review, and threat modeling happen as early as the lifecycle allows. But early testing that no one acts on is theater; every gate has an owner and a consequence. 2. **The pipeline is the enforcement point.** A requirement that depends on a developer remembering it will be forgotten. Security requirements are enforced by the build pipeline wherever a machine can enforce them. Human review is reserved for what a machine cannot judge. 3. **Build securely; do not own the result.** Consistent with the Engineering pillar mission, Engineering builds software securely and hands it off. Engineering does not become the permanent operator of every application it helps build. Security posture travels with the handoff. 4. **A finding is a risk until it is closed or accepted.** An open security finding is not a backlog item that quietly ages out. It is closed, or it is risk-accepted through [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). There is no third option. 5. **Provenance is part of the product.** Software that cannot be traced to its source, its dependencies, and its build is not trusted. Every release carries a Software Bill of Materials and a verifiable build provenance. 6. **Secrets never live in code.** This principle is absolute and has no risk-tier exception. Section 7. --- ## 3. The Secure SDLC ### 3.1 Lifecycle Phases Secure development is not a phase bolted onto delivery. Security activity is defined for every phase of the lifecycle. | **Phase** | **Security Activity** | **Primary Owner** | |---|---|---| | Requirements | Security and abuse-case requirements captured; data classification per [`CERG-STD-DG-001`](CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) identified. | Application Security Engineer | | Design | Threat modeling; architecture review intake per [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | Application Security Engineer | | Implementation | Secure coding practice; SAST and SCA in the developer loop; secrets scanning. | Engineering Pillar Leader | | Verification | DAST; code review gate; pre-production review per [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | Pre-production Reviewer | | Release | Build provenance and SBOM generated; release gate cleared. | Application Security Engineer | | Operation and handoff | Security posture documented; dependency monitoring active; ownership transferred. | Engineering Pillar Leader | ### 3.2 Software Risk Tiers The intensity of the gates in Section 4 scales by software risk tier. The tier is assigned at requirements and confirmed at design review. | **Tier** | **Definition** | **Examples** | |---|---|---| | **Tier 1 - Critical** | Internet-facing, or processes regulated or Confidential data, or supports a BES Cyber System or a SOX-relevant financial process. | Customer portal; API handling CUI; software in NERC-CIP scope. | | **Tier 2 - Standard** | Internal application or service not in Tier 1, handling internal-classified data. | Internal workflow tool; internal reporting service. | | **Tier 3 - Minimal** | Low-impact internal automation, scripts, and tooling with no regulated data and no production blast radius. | A scheduled internal report generator; a developer utility. | > **Tier Is Assigned, Not Assumed** > > A team does not get to call its own software Tier 3 to avoid the gates. The tier is proposed by the building team and confirmed by the Application Security Engineer at design review. When in doubt, the higher tier applies. Disagreements are resolved by the Engineering Pillar Leader, and a tier decision that lowers rigor is recorded. --- ## 4. Security Gates A security gate is a checkpoint software must clear to advance. Gates are enforced by the pipeline (Section 9) wherever automatable. ### 4.1 The Gate Set | **Gate** | **Tier 1** | **Tier 2** | **Tier 3** | **Blocks On** | |---|---|---|---|---| | Threat model complete | Required | Required | Recommended | Missing or stale threat model | | SAST clean | Required | Required | Required | Any unresolved High or Critical finding | | SCA clean | Required | Required | Required | Any dependency with a known High or Critical vulnerability and no exception | | Secrets scan clean | Required | Required | Required | Any detected secret (no exception) | | Code review approved | Required, 2 reviewers | Required, 1 reviewer | Required, 1 reviewer | Unapproved change to a protected branch | | DAST clean | Required | Recommended | Not required | Any unresolved High or Critical finding | | SBOM generated | Required | Required | Required | Missing SBOM | | Build provenance attested | Required | Required | Recommended | Unverifiable build | | Pre-production review signed | Required | Required | Not required | Unsigned go-live readiness per [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | ### 4.2 Gate Bypass A gate is bypassed only through a risk exception filed under [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). The exception names the gate, the reason, the compensating control, and an expiry. A bypassed gate without a filed exception is a control failure, and the build is not released. The secrets-scan gate is the one gate that is never bypassed. --- ## 5. Code Review Requirements 1. **Every change to a protected branch is reviewed.** No change reaches a release branch without at least one approving review from someone other than the author. Tier 1 software requires two approving reviewers. 2. **The reviewer is competent in the change.** A review approval asserts the reviewer understood the change and saw no security defect. An approval given without reading the change is a falsified control. 3. **Author cannot self-approve.** The person who wrote the change cannot be a required approver of it. This holds even on a small team; if only one other person can review, that person reviews. 4. **Security-sensitive changes pull in Application Security.** Changes to authentication, authorization, cryptography, input handling, or data export require an Application Security Engineer among the reviewers, regardless of tier. 5. **Review evidence is retained.** The review record (who approved, when, against which commit) is retained as control evidence and is auditable. > **Small Teams Still Separate Author From Approver** > > On a five-person team the temptation is to let a developer merge their own code because "there is no one else." There is someone else. The separation of author from approver is the single most effective software control CERG mandates, and it does not scale away. If genuinely only one person can review a given change, that one person reviews it. The author still does not approve their own work. --- ## 6. Automated Security Testing: SAST, DAST, SCA ### 6.1 Static Application Security Testing (SAST) SAST runs on every commit to a protected branch and in the developer loop where the toolchain supports it. SAST findings at High or Critical block the SAST gate. The SAST ruleset is owned by the Application Security Engineer and reviewed at least annually. False positives are suppressed with a recorded, reviewable justification, not by disabling the rule. ### 6.2 Dynamic Application Security Testing (DAST) DAST runs against a deployed pre-production instance for Tier 1 software and is recommended for Tier 2. DAST covers the OWASP application risk categories at minimum. High and Critical DAST findings block the DAST gate. ### 6.3 Software Composition Analysis (SCA) SCA inventories third-party and open-source dependencies and checks them against known-vulnerability data. SCA runs on every build. A dependency carrying a known High or Critical vulnerability blocks the SCA gate until the dependency is updated, replaced, or an exception is filed. SCA output feeds the SBOM in Section 8. ### 6.4 Tooling Discipline The specific tools are an implementation choice and are not named in this standard, so the standard survives a toolchain change. What the standard fixes is that SAST, DAST, and SCA capability exists, runs in the pipeline, and gates releases. An organization adopting CERG selects tools that meet that bar; the [`CERG-GOV-VAR-001`](../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) profile is the right place to record the selected toolchain. --- ## 7. Secrets in Code This section has no risk-tier exception and no gate bypass. 1. **Secrets are never committed.** Passwords, API keys, tokens, private keys, connection strings, and any other credential are never written into source code, configuration files in the repository, build scripts, or container images. 2. **Secrets scanning is mandatory.** A secrets scanner runs on every commit and on the full repository history. A detected secret blocks the build. 3. **A detected secret is treated as compromised.** A secret that reaches a repository, even a private one, even briefly, is considered exposed. It is rotated immediately per [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md), and the exposure is logged. Removing the commit does not undo the exposure. 4. **Secrets come from a secrets manager at runtime.** Software retrieves credentials at runtime from the secrets management platform governed by [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). Build-time injection from a secrets manager is acceptable; hard-coding is not. > **A Secret in Git History Is a Secret in Production** > > The most common rationalization is "it was only in a private repo" or "I removed the commit." Neither matters. A secret that touched version control has been copied to every clone, every fork, every backup, and every CI cache that ever pulled the repository. The only safe response is rotation. CERG treats a committed secret as a confirmed exposure, every time. --- ## 8. Dependencies and Software Bill of Materials 1. **Every release carries an SBOM.** A Software Bill of Materials listing every component and its version is generated for every release of Tier 1 and Tier 2 software, and for Tier 3 where the pipeline supports it. The SBOM is retained as a release artifact. 2. **Dependencies are pinned.** Builds resolve dependencies to specific, recorded versions. A build that resolves "latest" is not reproducible and is not permitted for Tier 1 or Tier 2. 3. **Dependencies are monitored after release.** A new vulnerability disclosed against a dependency already in production is a software vulnerability, handled per Section 11. SBOMs make this monitoring possible; that is their operational purpose. 4. **New dependencies are assessed before adoption.** Before a new third-party or open-source dependency is introduced, it is checked for maintenance health, known vulnerabilities, and license compatibility. A dependency with no recent maintenance is a supply chain risk. 5. **Internal components are inventoried too.** Reusable internal libraries are dependencies. They appear in the SBOM and are monitored like any other component. --- ## 9. Pipeline and Build Security The build pipeline produces trusted software. A compromised pipeline produces compromised software that passes every other gate. The pipeline is therefore protected as a Tier 1 system regardless of what it builds. 1. **Pipeline access is least-privilege and reviewed.** Access to modify pipeline configuration, build steps, or deployment credentials follows [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) and is reviewed on the access-review cadence. 2. **Build steps are defined as code and reviewed.** Pipeline definitions are version-controlled and subject to the code review requirements in Section 5. A change to how software is built is a security-sensitive change. 3. **Builds are isolated.** Build jobs run in ephemeral, isolated environments. A build does not run with standing production credentials. 4. **Build provenance is attested.** Tier 1 and Tier 2 releases carry verifiable provenance: what source commit, what build steps, what environment produced the artifact. This aligns with SLSA build-integrity levels. 5. **Artifacts are integrity-protected.** Released artifacts are signed or hashed so the deployment target can verify it is deploying what the pipeline produced. 6. **Pipeline activity is logged.** Build and deployment events are logged to the platform governed by [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). --- ## 10. Infrastructure as Code Infrastructure-as-code is software and is governed by this standard. Specifically: 1. IaC is subject to code review (Section 5) and to SAST-equivalent scanning for misconfiguration before apply. 2. IaC must not contain secrets (Section 7). 3. IaC that provisions production infrastructure is Tier 1 or Tier 2 by the same risk-tier logic in Section 3.2. 4. IaC-provisioned configuration must satisfy the secure configuration baselines in [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md). IaC is the preferred mechanism for enforcing those baselines consistently. --- ## 11. Vulnerability Handling for Software A security finding in CERG-managed software, whether found by SAST, DAST, SCA, code review, adversarial validation, or post-release disclosure, is a vulnerability. 1. **Pre-production findings are engineering inputs.** A finding caught before go-live is remediated before go-live, or the go-live is risk-accepted per [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). This is the pre-production versus post-production distinction from [`CERG-GOV-FRM-001`](../governance/CERG-GOV-FRM-001_CERG_Framework.md) §4.3. 2. **Post-production findings follow the VM procedure.** A finding in released, operating software is a managed vulnerability and is remediated against the SLAs in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). 3. **No silent aging.** A software finding is closed or risk-accepted. It is never simply moved down a backlog until it is forgotten. This is Principle 4. --- ## 12. Roles and Responsibilities Roles below are the canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Secure Development Responsibility** | |---|---| | **Application Security Engineer** | Owns this standard. Owns the SAST/DAST/SCA rulesets, threat modeling, the gate definitions, and the software risk-tier decision. Reviews security-sensitive changes. | | **Engineering Pillar Leader** | Accountable for secure development across the pillar. Owns implementation-phase practice and the operation-and-handoff phase. Resolves risk-tier disputes. | | **Pre-production Reviewer** | Owns the verification-phase pre-production review and signs go-live readiness for Tier 1 and Tier 2 software. | | **Cloud Security Engineer** | Owns pipeline and build security where the pipeline runs on cloud infrastructure; owns IaC misconfiguration scanning. | | **Cryptography Engineer** | Owns the secrets management platform that software retrieves credentials from; supports rotation of exposed secrets. | | **Exposure Management Lead** | Operates the post-production software vulnerability SLAs per [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md). | | **Governance Pillar Leader** | Maintains the exceptions register for gate bypasses; tracks audit-facing evidence; cross-references this standard with the control baseline. | | **Policy & Standards Manager** | Maintains this document, its version, and its review cycle. | --- ## 13. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Standard** | |---|---|---| | NIST SSDF 800-218 | PO, PS, PW, RV practice groups | Sections 3, 4, 6, 8, 11 | | NIST 800-53r5 | SA-11, SA-15, SA-22, SI-2, SI-10, CM-3, CM-4 | Sections 4, 5, 6, 9, 11 | | NIST 800-171r3 / CMMC L2 | 3.4.x (configuration), 3.13.x (system protection), 3.14.x (system integrity) | Sections 9, 10, 11 | | NIST 800-161r1 | Software supply chain | Sections 8, 9 | | OWASP ASVS / SAMM | Verification levels; maturity practices | Sections 4, 6 | | SLSA | Build provenance and integrity levels | Section 9 | | SOX ITGC | Change management; segregation of duties | Sections 5, 9 | --- ## 14. Document Control | Field | Value | |---|---| | **Document ID** | CERG-STD-SDL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-21 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader (Application Security) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on NIST SSDF revision or material toolchain change | | **Next Scheduled Review** | 2027-05-21 | | **Frameworks** | NIST SSDF 800-218; NIST 800-53r5 (SA, SI, CM); OWASP ASVS / SAMM; NIST 800-161r1; SLSA | | **Regulations** | CMMC L2 / 800-171r3; SOX ITGC; NERC-CIP where applicable | | **Environments** | All CERG-managed software | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-21 | Cyber Engineering | Initial release. Establishes the secure SDLC, software risk tiers, the security gate set, code review requirements, SAST/DAST/SCA testing requirements, the absolute no-secrets-in-code rule, dependency and SBOM requirements, pipeline and build security, infrastructure-as-code coverage, and software vulnerability handling. | ### Review Triggers - Revision of the NIST Secure Software Development Framework (800-218) - Material change to the organization's build toolchain or CI/CD platform - A significant software-related security incident - Internal audit or regulatory finding affecting software development - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader (Application Security) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Framework | [`CERG-GOV-FRM-001`](../governance/CERG-GOV-FRM-001_CERG_Framework.md) | Engineering pillar mission and the pre/post-production risk distinction | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Governs the engagement; this standard governs the code | | Exposure Management Procedure | [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Post-production software vulnerability SLAs | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Gate-bypass exceptions | | Cryptography and Key Management Standard | [`CERG-STD-CR-001`](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Secrets management platform; secret rotation | | Access Management Standard | [`CERG-STD-AC-001`](CERG-STD-AC-001_Access_Management_Standard.md) | Pipeline access control | | Secure Configuration Baseline Standard (DISH) | [`CERG-STD-CFG-001`](CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Baselines that infrastructure-as-code must satisfy | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Pipeline activity logging | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Purchased software; vendor component risk | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `SDL` domain | --- ## ACCESS MANAGEMENT RUNBOOK ### JML · Access Requests · Recertification · PAM · Break-Glass · Service Accounts · Secrets · Vendor Access · MFA --- | | | |---|---| | **Document ID** | CERG-PRC-AC-002 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Identity Engineer | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Standard** | [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) - Access Management Standard | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-AUD-001](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Review Cycle** | Annual / On IAM tooling change | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (AC, IA, AU) · [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (PROTECT) | | **Regulations** | NERC-CIP CIP-004 / CIP-005 · [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.1, 3.5) · SOX ITGC (Access) | | **Environments** | All in-scope identities - human, machine, service, vendor | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [The Two Operating Models, CERG-Owned vs. Cyber-Contributing](#2-the-two-operating-models--cerg-owned-vs-cyber-contributing) 3. [Joiner / Mover / Leaver](#3-joiner--mover--leaver) 4. [Access Request and Approval](#4-access-request-and-approval) 5. [Access Review and Recertification](#5-access-review-and-recertification) 6. [Privileged Access Management (PAM)](#6-privileged-access-management-pam) 7. [Break-Glass Access](#7-break-glass-access) 8. [Service Accounts and Machine Identities](#8-service-accounts-and-machine-identities) 9. [Secrets, API Keys, and Tokens](#9-secrets-api-keys-and-tokens) 10. [Vendor Access](#10-vendor-access) 11. [MFA Enrollment and Exception](#11-mfa-enrollment-and-exception) 12. [Roles and Responsibilities](#12-roles-and-responsibilities) 13. [Regulatory and Framework Alignment Summary](#13-regulatory-and-framework-alignment-summary) 14. [Document Control](#14-document-control) --- ## 1. Purpose and Scope The Access Management Standard explicitly says implementation details, IdP baselines, MFA enrollment, PAM workflows, recertification runbooks, are maintained separately. This runbook is that "separately." It defines the executable workflows behind every identity decision [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) requires. The runbook covers every identity in the environment: human (employee, contractor), machine (system, service, agent), and vendor / third-party. > **One Runbook, Two Owners** > > Many organizations run IAM under IT (not Cyber). The runbook is written so it is complete under either operating model: where IAM reports into CERG, this is the operational manual; where IAM reports outside CERG, this is the cyber-required content the IAM team must implement or formally diverge from with documented compensating controls. --- ## 2. The Two Operating Models: CERG-Owned vs. Cyber-Contributing | **Aspect** | **CERG-Owned IAM** | **CERG-Contributing IAM** | |---|---|---| | Procedural authority | CERG owns this runbook and the IAM operations team. | IAM team owns operations; CERG provides cyber requirements via this runbook. | | Tooling decisions | CERG-driven. | IAM-driven with CERG sign-off where security-material. | | Day-to-day operations | CERG. | IAM. | | Recertification execution | CERG runs. | IAM runs; CERG audits. | | Detection / monitoring | CERG (always). | CERG (always). | | Audit interface | CERG. | Shared. | Where IAM is outside CERG, every requirement below is either implemented by the IAM team, or a formal documented divergence is recorded in the risk register per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). --- ## 3. Joiner / Mover / Leaver ### 3.1 Joiner | **Step** | **Trigger / Owner / SLA** | |---|---| | HR record created in HRIS | HR - at offer signed | | Account provisioned by IGA from HRIS | IGA system - within 1 business day of start date | | Baseline entitlements assigned by role | IGA via role / SoD model | | MFA enrollment notification | IdP - at first sign-in | | Required training assignment | Awareness function | | Phishing-resistant MFA enrolled before privileged use | User + Identity Engineer | | Hardware token issued (where required by role) | Identity Engineer | | Privileged role(s) requested separately | Manager + named approver per role | ### 3.2 Mover | **Step** | **Trigger / Owner / SLA** | |---|---| | Role / department change in HRIS | HR | | IGA recalculates entitlements; out-of-role accesses flagged | IGA - within 1 business day | | Out-of-role accesses removed by default; retained only by exception with new manager approval | Manager - within 5 business days | | Privileged roles re-justified | Manager + role owner - within 5 business days | | Recertification triggered for new role | IGA - within 30 days of move | ### 3.3 Leaver | **Step** | **Trigger / Owner / SLA** | |---|---| | HR termination event in HRIS | HR - same day | | Active sessions terminated | IdP - within 1 hour | | Account disabled | IGA - within 1 business day (within 1 hour for involuntary) | | Privileged credentials and secrets attributed to user rotated | PAM + Engineering - within 1 business day | | MFA tokens / hardware deauthorized | Identity Engineer - within 1 business day | | Mailbox and data retention applied per Legal | Engineering - IT | | Account permanently deleted | IGA - after retention period | ### 3.4 Involuntary or High-Sensitivity Leavers Same as 3.3 with all SLAs collapsed to "immediately" and the SOC alerted to monitor for credential reuse and data exfiltration. --- ## 4. Access Request and Approval ### 4.1 Request Patterns | **Pattern** | **Use** | |---|---| | Role / role-bundle request | Standard entitlements bundled into roles aligned to job function. | | Birthright role | Auto-assigned based on HRIS attributes. | | Project / time-bound role | Access for a defined project, with expiration. | | Privileged role | Always separately requested; PAM-mediated. | | Sensitive system role | System owner approval required. | | Vendor / external | See Section 10. | ### 4.2 Approval Chain | **Access Class** | **Approvers** | |---|---| | Standard role | Direct manager | | Sensitive role | Direct manager + system owner | | Privileged role | Direct manager + role owner + Identity Engineer | | Vendor / external | Sponsor + Identity Engineer + TPRM record | | Break-glass | Per Section 7 | ### 4.3 Approval Discipline - Approvers are accountable parties; rubber-stamping is detected via approval-velocity metrics. - Requests that violate SoD rules are blocked at submission; override requires named additional approver. - Time-bound roles auto-expire; no implicit renewal. --- ## 5. Access Review and Recertification ### 5.1 Cadence | **Scope** | **Cadence** | |---|---| | All standard accounts | Annual (full base) | | SOX-relevant access | Quarterly | | CUI scope access | Quarterly | | BES Cyber System access | Quarterly (CIP-004 alignment, 15-month cap) | | Privileged access (any) | Quarterly | | High-blast-radius admin roles | Monthly attestation | | Service accounts / non-human | Semi-annual | | Vendor / external | Quarterly + per project closeout | ### 5.2 Recertification Workflow 1. **Campaign launched** via IGA with named reviewers. 2. **Reviewers presented with**: identity, current entitlements, last-used dates, role rationale. 3. **Decision** per entitlement: Certify · Modify · Remove. "Bulk Certify" is permitted only where reviewer has reviewed actual access patterns. 4. **Auto-removal** of Removed entitlements within 5 business days. 5. **Audit log** captured per IGA for the cycle. 6. **Exceptions** flagged to Engineering, Identity for follow-up. ### 5.3 Anti-Rubber-Stamp Controls - Reviewers who certify > X% of items in < Y minutes are flagged for sampling-audit. - Certifications of dormant accounts (> 60 days unused) require explicit justification. - Reviewers who never modify or remove are sampled. ### 5.4 Privileged Access Review Evidence Checklist Every quarterly privileged access review evidence package must be complete enough for an auditor, the Evidence Librarian, or a future reviewer to reperform the review without asking the reviewer what they meant. Store the package as an **Access Review Record** / **Evidence Index Entry** per [`CERG-GOV-CAT-002`](../governance/CERG-GOV-CAT-002_Record_Catalog.md) and evidence quality rules in [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). | Evidence element | Required content | Minimum evidence | |---|---|---| | Population | Complete privileged-user and privileged-group population in scope, including administrators, break-glass accounts, service principals with admin-equivalent rights, vendor privileged accounts, and emergency roles. | Timestamped export from IdP, PAM, IGA, directory, SaaS admin console, or CMDB source of truth. | | Scope | Systems, applications, environments, privileged roles, data classes, and regulatory scope covered by the review. | Scope statement tied to system owner / application owner and control IDs AC-2 / AC-6. | | Review period | Start and end date of the access population and activity period reviewed. | Campaign metadata, export timestamp, and period label in file name or evidence index. | | Reviewer | Named reviewer for each system, role, or entitlement group. | Reviewer assignment list or IGA campaign owner mapping. | | Reviewer authority | Proof that the reviewer is authorized to approve or remove the access being reviewed. | System owner list, role owner map, manager mapping, or approved delegation record. | | Review decisions | Per-user / per-entitlement decision: certify, remove, modify, investigate, or exception. Bulk certify is allowed only with retained population detail. | IGA decision export, signed spreadsheet, or workflow report with decision timestamps. | | Removals and modifications | All removed or modified entitlements, target completion date, actual completion date, and implementer. | Removal ticket, IGA fulfillment log, IdP/PAM change log, or change record. | | Post-removal validation | Evidence that removals/modifications actually took effect. | Timestamped post-change export or before/after comparison showing entitlement removed or changed. | | Exceptions | Any retained access that violates role, SoD, dormant, standing privilege, MFA, or PAM requirements. | Security Exception Record or Risk Acceptance Record with owner, rationale, compensating controls, expiration, and RMF authority where applicable. | | Evidence-library location | Single pointer to the complete review package and all supporting exports. | Evidence Index Entry with system, period, owner, quality tier, and retention label. | A privileged access review is incomplete if the population is missing, the reviewer lacks authority, decisions are not recorded at entitlement level, removals are not validated after implementation, or exceptions are retained only in email/chat rather than the exception or risk process. --- ## 6. Privileged Access Management (PAM) ### 6.1 Coverage Every privileged action across the in-scope estate is mediated by PAM. Specifically: - Domain admin / cloud root / SaaS tenant admin. - Network device, firewall, hypervisor, storage admin. - Database privileged accounts. - OT engineering interfaces and jump-server access. - CUI workspace admin. ### 6.2 PAM Workflow | **Step** | **Detail** | |---|---| | Onboard the privileged credential into PAM | Credential never returned to a human; PAM brokers the session. | | Just-in-time (JIT) elevation | User requests; approval where required; time-bound. | | Session brokered | RDP / SSH / web session through PAM; session recorded; commands logged. | | Session ended | Credentials rotated if vaulted-and-checked-out pattern. | | Logs and recordings retained per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | ### 6.3 PAM Operating Disciplines - No direct admin password use; PAM-only. - Standing privileged access avoided where JIT is supported. - Quarterly audit of dormant privileged accounts. - Session recordings sampled by Risk on a quarterly cadence; high-risk roles sampled monthly. --- ## 7. Break-Glass Access ### 7.1 Definition Break-glass accounts are the credentials of last resort, used only when normal identity systems are unavailable or compromised. Misuse is a P1 detection per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) Section 11. ### 7.2 Operating Rules | **Rule** | **Detail** | |---|---| | Existence | Documented break-glass per system / domain / cloud root. | | Storage | Vaulted in PAM or sealed envelope in physical safe; access logged. | | Two-person retrieval | Two named operators required to retrieve credential. | | Rotation | After every use; rotation completed within 24 hours of use. | | Monitoring | Any successful authentication generates a P1 alert. | | Quarterly hygiene check | Verify credential current, rotation works, retrieval procedure rehearsed. | | Annual exercise | Tabletop or real exercise of break-glass retrieval and use. | --- ## 8. Service Accounts and Machine Identities ### 8.1 Preference Order 1. **Workload identity** (cloud-native): managed identities, IRSA, workload identity federation. Preferred. 2. **Short-lived issued credentials** via STS / IdP-integrated token service. 3. **Long-lived static credentials in secrets manager**, only when 1–2 are infeasible. ### 8.2 Lifecycle | **Step** | **Owner** | |---|---| | Request via service-account intake | Owner team + Identity Engineer | | Named human owner required | Owner team | | Scope and entitlements minimized | Identity Engineer | | Stored in PAM / secrets manager per [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Identity Engineer | | Detection on anomalous use | Detection Engineer | | Recertification semi-annual | Identity Engineer | | Rotation per [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) Section 8 | Identity Engineer / Workload owner | | Decommission on system retirement | Identity Engineer | ### 8.3 Service Account Disciplines - No human use of service accounts. - No interactive logon for service accounts; flagged and alerted if observed. - No service accounts in default admin groups (Domain Admins, etc.). - Service accounts in OT scope follow tighter restrictions and engineering review. --- ## 9. Secrets, API Keys, and Tokens This section operationalizes [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) Section 7. See that standard for storage and rotation requirements. | **Action** | **Path** | |---|---| | Request a new secret | Through secrets manager / IdP token service - never via ticket. | | Retrieve at runtime | Workload pulls; never stored in repo or container image. | | Rotate | Schedule + event triggers (compromise indicator, vendor incident, workforce change). | | Revoke | On detection of compromise, on user departure, on service retirement. | | Audit | Continuous via SIEM; quarterly review of long-lived static credentials with bias toward replacement. | --- ## 10. Vendor Access ### 10.1 Onboarding | **Step** | **Owner** | |---|---| | Vendor record created in TPRM with tier and country-of-access | Vendor Risk Analyst | | Sponsor identified (named human in our org) | Business / Sponsor | | Access scope defined - minimum required entitlements, time-bounded | Identity Engineer | | MFA enrolled - phishing-resistant required for privileged | Identity Engineer | | Sessions brokered through PAM where privileged | Identity Engineer | | Country-of-access validated against Country Risk Register ([`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Section 10) | Vendor Risk Analyst | | Time-boxed: explicit expiration; renewal requires re-justification | Identity Engineer | ### 10.2 Monitoring - Vendor sessions recorded per PAM policy. - Geographic anomalies trigger alerts. - Quarterly review of all active vendor access. - Off-boarding triggered by project closeout, vendor termination, or country reclassification. --- ## 11. MFA Enrollment and Exception ### 11.1 Enrollment | **Step** | **Detail** | |---|---| | Default factor | Phishing-resistant (FIDO2 security key, platform authenticator with attestation, certificate-based). | | Backup factor | A second phishing-resistant factor where possible; one-time recovery code as fallback. | | Enrollment moment | At first sign-in or pre-issued via secure handoff. | | Privileged roles | Phishing-resistant only; SMS / voice prohibited. | | Hardware tokens | Inventoried; loss reported and revoked within 4 hours. | | Re-enrollment | On factor loss, suspected compromise, or 24-month routine refresh. | ### 11.2 Exceptions MFA exceptions are time-bounded and tracked. | **Exception Case** | **Treatment** | |---|---| | Legacy system unable to support phishing-resistant MFA | Time-boxed transitional exception with compensating controls (network segmentation, monitoring) per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) §7. | | Operational technology operator console | Engineering review required; compensating controls per [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). | | Vendor unable to use phishing-resistant factor | Renegotiate; if unavoidable, time-bound exception with detection routing. | Phishing-resistant MFA coverage is reported as `ID-001` in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). --- ## 12. Roles and Responsibilities | **Role** | **Responsibility** | |---|---| | **Identity Engineer** | Owns this runbook. Designs, implements, and maintains the identity infrastructure including IGA, IdP, PAM, and secrets management. Ensures JML workflows execute within SLAs. Manages MFA enrollment, service account lifecycle, and vendor access provisioning. | | **Manager / Approver** | Reviews and approves access requests for direct reports. Validates business need and role alignment. Participates in recertification campaigns; certifies, modifies, or removes entitlements with accountability. Initiates mover and leaver notifications to HR/IGA. | | **System Owner** | Approves access to sensitive systems under their ownership. Defines role requirements and entitlement baselines for their systems. Participates in recertification for system-specific access. Ensures service accounts under their systems have named human owners. | | **PAM Administrator** | Operates the PAM platform. Onboards privileged credentials, brokers sessions, manages session recording and retention. Executes credential rotation on checkout and post-use. Maintains break-glass credentials and coordinates quarterly hygiene checks. | | **Vendor Risk Analyst** | Owns the vendor access lifecycle from a risk perspective. Creates and maintains vendor records in TPRM. Validates country-of-access against the Country Risk Register. Ensures vendor access is time-bounded, scoped to minimum required, and terminated on project closeout. | | **User** | Uses only approved authentication factors. Reports MFA token loss immediately. Does not share credentials or service accounts. Completes required security awareness training before first access. Complies with access request and recertification requirements. | | **SOC / Detection Engineer** | Monitors identity events for anomalies per [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). Detects and escalates break-glass misuse, service account interactive logon, credential reuse, and geographic anomalies. Tunes detection rules in coordination with the Identity Engineer. | | **CISO** | Endorses this runbook. Resolves disputes escalated beyond the Identity Engineer and Cyber Engineering Pillar Leader. Approves risk acceptances for MFA exceptions and compensating controls beyond standard tolerance. Signs off on annual recertification program results. | --- ## 13. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Runbook** | |---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) AC / IA | All sections | | [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) | Section 11 | | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) PROTECT | All sections | | NERC-CIP CIP-004 R4/R5, CIP-005 R2 | Sections 3, 5, 6, 10 | | [CMMC L2](https://dodcio.defense.gov/CMMC/) / 800-171r3 (3.1, 3.5) | All sections | | SOX ITGC (Access) | Sections 3, 4, 5, 6 | --- ## 14. Document Control | | | |---|---| | **Document ID** | CERG-PRC-AC-002 | | **Version** | 1.1 | | **Approved By** | CISO | | **Next Review** | Annual / IAM tooling change | | **Change Log** | 1.1 - Added privileged access review evidence checklist and PRC-AUD evidence linkage. 1.0 - Initial publication. JML, access request, recertification, PAM, break-glass, service accounts, secrets, vendor access, MFA. Dual operating model preserved. | --- ## ADVERSARIAL VALIDATION PROCEDURE ### Pen Test · Red Team · Purple Team · Cloud Attack Sim · App Test · OT Safety · Finding-to-Closure --- | | | |---|---| | **Document ID** | CERG-PRC-AV-001 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Adversarial Testing Lead | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-PRC-VM-001](CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) · [CERG-GOV-CEF-001](../governance/CERG-GOV-CEF-001_Control_Effectiveness_Framework.md) · [CERG-GOV-IMPREG-001](../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) · [CERG-PRC-LL-001](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) | | **Review Cycle** | Annual / On material program change | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CA-8) · NIST 800-115 · PTES · MITRE ATT&CK · MITRE D3FEND · OWASP WSTG / MASTG | | **Regulations** | NERC-CIP CIP-007 (vulnerability assessment) · [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.11.2) · SOX (indirect via control testing) | | **Environments** | All - IT · cloud · SaaS · OT (with safety constraints) · application · identity | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Engagement Types](#2-engagement-types) 3. [Annual Cadence and Scoping](#3-annual-cadence-and-scoping) 4. [Rules of Engagement (RoE) Template](#4-rules-of-engagement-roe-template) 5. [Red-Team Engagement Charter](#5-red-team-engagement-charter) 6. [Purple-Team Detection Validation](#6-purple-team-detection-validation) 7. [Cloud Attack Simulation](#7-cloud-attack-simulation) 8. [Application Penetration Test Checklist](#8-application-penetration-test-checklist) 9. [OT Adversarial Assessment, Safety Protocol](#9-ot-adversarial-assessment--safety-protocol) 10. [Finding Rating, Routing, and Retest](#10-finding-rating-routing-and-retest) 11. [Systemic Analysis and Program Feedback Loop](#11-systemic-analysis-and-program-feedback-loop) 12. [Roles and Responsibilities](#12-roles-and-responsibilities) 13. [Evidence Retention](#13-evidence-retention) 14. [Regulatory and Framework Alignment Summary](#14-regulatory-and-framework-alignment-summary) 15. [Document Control](#15-document-control) --- ## 1. Purpose and Scope The Cybersecurity Policy requires periodic adversarial testing. The exposure management procedure names the adversarial activities CERG performs. The risk taxonomy distinguishes adversarial testing from vulnerability scanning. Until this procedure, the operating model, scope, rules, safety, finding routing, evidence, for adversarial validation was implicit. This procedure makes it explicit. It applies to every CERG-led or CERG-overseen adversarial engagement: external pen test, internal pen test, cloud red-team / attack simulation, web/mobile/API pen test, OT adversarial assessment, purple-team detection validation, and social-engineering work conducted with the adjacent Awareness function. In CERG, penetration testing is one engagement type within the broader adversarial validation capability. It does not replace red-team operations, purple-team detection validation, cloud attack simulation, OT-safe assessment, or other authorized testing where those activities are in scope. > **Adversarial Validation Is the Antidote to Drift** > > A control library that exists on paper but has never been tested is a hope. Adversarial validation tests the assumption that the control library implements actual defense. CERG runs it on a cadence; documents the rules; routes findings into exposure management or the risk register; and uses purple-team work to upgrade detection, not just to score the team. --- ## 2. Engagement Types | **Type** | **Goal** | **Default Frequency** | **Adversary Model** | |---|---|---|---| | External Pen Test | Validate the perimeter - internet-facing surface, edge identity, public services. | Annual | Unauthenticated external attacker. | | Internal Pen Test | Validate post-foothold lateral movement, privilege escalation, segmentation. | Annual | Authenticated low-privilege user / compromised workstation. | | Cloud Red Team / Attack Sim | Validate cloud control plane, identity, KMS, logging detection. | Annual + on material cloud change | Compromised cloud identity / supply-chain attack on cloud workloads. | | Application Pen Test | Validate web / mobile / API surface of in-scope applications. | Annual for T1/T2 apps; risk-based for others; pre-launch for new apps. | Authenticated and unauthenticated. | | OT Adversarial Assessment | Validate OT boundary, ESP/EAP, jump server, OT detection set. | Per CIP-007 cadence (at least every 15 months for BES) | Compromised IT-side identity attempting OT pivot; vendor-channel compromise. | | Purple-Team Detection Validation | Validate the day-one + tuned detection set fires as designed. | Quarterly | ATT&CK technique emulation. | | Social Engineering | Validate identity and awareness controls; phishing-resistance. | Per Awareness program | External commodity + targeted scenarios. | | Tabletop / Crisis Simulation | Validate IR plan + CERG interfaces during a simulated incident. | Annual | Scenario-driven. | --- ### 2.1 External Tester Management When adversarial validation is conducted by an external firm rather than internal staff, the following requirements apply. #### Minimum Tester Qualifications | **Engagement Type** | **Minimum Qualification** | |---|---| | Network / infrastructure penetration test | OSCP, GPEN, or equivalent; 2+ years of hands-on testing experience | | Web application penetration test | OSWE, GWAPT, or equivalent; demonstrated web app testing portfolio | | Red team engagement | GXPN, OSEP, or equivalent; 5+ years of adversarial emulation experience | | Cloud security assessment | Cloud-specific certification (AWS Security, Azure Security, GCP Professional Security) or equivalent | | OT / ICS assessment | GICSP, GRID, or equivalent; operational technology experience with safety-aware methodology | | Social engineering engagement | SE-specific training or certification; understanding of legal and ethical boundaries | #### Selection and Vetting Requirements | **Requirement** | **Detail** | |---|---| | Conflict of interest disclosure | Firm must disclose any prior or current relationship with the organization's competitors, vendors, or key personnel that could compromise objectivity | | Background checks | All testers assigned to the engagement must have passed a background check within the last 12 months; evidence of clearance retained by the Vendor Risk Analyst | | Insurance | Firm must carry professional liability / errors and omissions insurance appropriate to the engagement scope; certificate of insurance on file | | References | At least two references from engagements of comparable scope and sensitivity in the last 24 months | #### Vendor Rotation Policy - External testing vendors are rotated at minimum every 3 years for each scope area (network, application, cloud, OT, social engineering). - Rotation applies to the firm, not individual testers. - Exceptions require CISO approval and are documented in the risk register. #### Contractual Requirements - Non-disclosure agreement (NDA) covering all findings, data accessed, and methods used - Data handling: all customer data accessed during testing is treated as Restricted; no data leaves the organization's control without explicit authorization - Evidence destruction: upon engagement closure or within 30 days, the firm certifies destruction of all engagement data, findings drafts, and tool output in their possession - Right-to-audit: the organization reserves the right to audit the firm's handling of engagement data - Notification of subcontractors: the firm must disclose any subcontractors and their qualifications before engagement start --- ## 3. Annual Cadence and Scoping CERG produces an annual Adversarial Validation Plan that schedules the engagements above against the in-scope environments. The plan is reviewed and approved by the CISO; it is updated quarterly to reflect emerging threats and program priorities. Scoping inputs: - Highest-residual-score risks in the register. - Recently introduced systems and architectures ([`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) Phase 5 records). - Regulatory cadence requirements (CIP, [CMMC](https://dodcio.defense.gov/CMMC/)). - ATT&CK coverage gaps identified by detection engineering. - Threat intelligence pointing at adversary activity relevant to the organization. --- ## 4. Rules of Engagement (RoE) Template Every engagement has a signed RoE before any activity begins. The template: ``` RULES OF ENGAGEMENT - AV-YYYY-NNNN 1. ENGAGEMENT IDENTITY Type : (External / Internal / Cloud / App / OT / Purple / SE / TT) Sponsor (named role) : Test Lead : Period : Time Windows : 2. OBJECTIVES What we are testing : Success criteria : Risk-register / control gaps this engagement is intended to validate 3. SCOPE - IN IPs / URLs / Apps / Cloud accounts / OT segments / Identity tenants explicitly in scope 4. SCOPE - OUT Explicit out-of-scope: e.g., production-impacting denial-of-service, mass account lockouts, third-party-hosted out-of-scope assets 5. PROHIBITED ACTIONS (Defaults below; engagement may add. None may be removed.) - No denial-of-service against production - No data destruction or modification - No persistence beyond engagement window - No exfiltration of regulated data (CUI / BCSI / PHI / PII); proof-of-concept counts; data is staged and discarded - No exploitation of safety-impacting OT systems (Section 9) - No social engineering of named C-suite without explicit prior approval - No physical intrusion outside agreed scope 6. SAFETY AND ABORT Stop conditions : (defined; e.g., OT process alarms, anomalous business impact) Abort signal : (named individual + backup; mechanism - phone / Signal channel) Operator on-call (OT) : (if OT) Incident handoff path : if findings cross the "test" → "real incident" threshold 7. AUTHORIZATION Authorization letter signed by : Distribution : Authority to act in our environment 8. COMMUNICATIONS SOC informed? : Yes - passive (no detection assistance) / Yes - active (purple) Liaison on Tester side: Liaison on CERG side : Reporting cadence : (daily standups / weekly status / final report) 9. EVIDENCE COLLECTION What is captured : How it's stored : What is sanitized in final report 10. CONFIDENTIALITY Findings classification (default: Restricted) Handling : encrypted at rest, named distribution, no email of unredacted 11. SIGNATURES Tester Lead : CERG Sponsor : System / Business Owner : CISO (red team / OT / cloud red team) : ``` --- ## 5. Red-Team Engagement Charter Red-team engagements are scope-broader, time-longer, goal-driven simulations of a realistic adversary. Each red team has a Charter in addition to its RoE. ``` RED-TEAM CHARTER - AV-YYYY-NNNN A. ADVERSARY MODEL Threat actor profile : Capability : (commodity / advanced / nation-state-equivalent) Resourcing (time, tools, ops infrastructure) B. OBJECTIVES - IN PRIORITY ORDER Crown Jewel(s) to attempt to reach Detection escape required? : Persistence required? : Specific TTPs to emulate : (ATT&CK technique IDs) C. ENGAGEMENT WINDOW Start / End : No-Op windows : (financial close, regulatory exam, major event) D. PRE-AGREED LIMITS Production-impact threshold : OT touch : (forbidden unless explicit) E. WHITE-CELL Named coordinators on both sides; channels for clarification without breaking the test ``` --- ## 6. Purple-Team Detection Validation Purple work is the collaboration between offensive and detection engineering. It is **not** a graded exam of the SOC; it is a measurement of detection coverage and the basis for upgrading rules and baselines. ### 6.1 Cadence and Coverage - Quarterly purple-team cycle covering a rotating slice of the ATT&CK matrix in scope. - Annual full-scope purple-team across the IT spine; semi-annual on cloud sub-matrix; annual on OT sub-matrix. - Each cycle has 8–20 techniques tested; the cycle's selection is risk-driven (recent threat intel, recent infrastructure changes, prior-cycle failures). ### 6.2 Validation Workflow 1. **Plan**, choose techniques (ATT&CK IDs); map to expected detections in the SIEM; document expected alert. 2. **Execute**, emulate technique in non-production where possible; in production with controlled, documented action where required. 3. **Observe**, did the expected detection fire? With expected priority? In expected time? 4. **Classify**, Pass · Pass-with-Latency · Pass-with-Tuning-Needed · Fail (no detection) · Fail-Suppressed (existed but suppressed). 5. **Action**, Pass: no change. Pass-with-Tuning: tune. Fail / Fail-Suppressed: open detection backlog item + risk register entry until restored. 6. **Reflect**, feed result into detection inventory; update DT-002 metric in [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). ### 6.3 Purple-Team Outcome to Baseline > **The Purple Cycle Updates Detection, Not Just the Scorecard** > > If a technique fires nine times out of ten because logs were missing for one source, the fix is to fix the source, not to re-grade the test. If a technique fires reliably but the alert routes to the wrong queue, the fix is the queue. Purple cycles end with a list of concrete changes to the detection set; if they don't, the cycle is incomplete. --- ## 7. Cloud Attack Simulation Cloud engagements emulate adversary activity at the cloud control plane and identity layer, historically the most-attacked surface in modern enterprises. | **Focus** | **Examples** | |---|---| | Identity | OAuth consent grant abuse; consent phishing; token theft; federation tampering. | | Cloud control plane | IAM privilege enumeration and escalation; CloudTrail / Activity Log disable attempts; key policy changes; cross-account assumption. | | KMS / Secrets | Unauthorized key access; envelope-encryption bypass attempts. | | Workloads | Container escape; metadata service abuse; misconfigured serverless. | | Logging / monitoring | Visibility evasion - disable, alter, route around. | Cloud engagements explicitly include detection validation; CSPM/SSPM signals and cloud-native detection (GuardDuty, Defender for Cloud, Security Command Center) are exercised. --- ## 8. Application Penetration Test Checklist Application tests use OWASP WSTG (web), MASTG (mobile), and API Security Top 10 as the technical reference. The checklist below is the minimum coverage at scoping; specific apps may need more. | **Domain** | **Coverage** | |---|---| | Authentication | MFA enforcement, credential stuffing resistance, password-reset flow, session handling. | | Authorization | IDOR, function-level access, multi-tenant isolation, RBAC enforcement. | | Input handling | Injection (SQL, command, template), deserialization, file upload, SSRF. | | Output / data exposure | Information disclosure, sensitive data in responses, error verbosity. | | Configuration | Headers (HSTS, CSP, etc.), TLS conformance to [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md), exposed admin endpoints. | | Business logic | Workflow bypass, race conditions, abuse of intended functionality. | | API | OWASP API Top 10: object-level, function-level, mass assignment, rate limiting, etc. | | Mobile | OWASP MASTG: storage, transport, platform interaction, code quality, resilience. | --- ### 8.1 Social Engineering Engagements Social engineering tests the human layer of security controls. These engagements carry unique legal, ethical, and operational risks that require explicit guardrails. #### Scope Definition | **Engagement Subtype** | **Description** | **Typical Scope** | |---|---|---| | Phishing simulation | Simulated phishing email campaign to test user awareness and reporting behavior | Organization-wide or targeted departments | | Vishing (voice phishing) | Simulated phone-based social engineering to extract information or credentials | Named individuals or departments with CISO approval | | Smishing (SMS phishing) | Simulated text message-based social engineering | Named individuals or departments with CISO approval | | Physical social engineering | Tailgating, badge cloning, or pretext-based physical access attempts | Named facilities with Facility Security coordination | | USB drop | Simulated malicious USB devices placed in common areas | Named facilities with Facility Security coordination | #### Pretexting Rules and Limitations - Pretexts must not impersonate law enforcement, government officials, or regulatory authorities. - Pretexts must not exploit personal tragedy, medical conditions, or family emergencies. - Pretexts must not target minors or non-employees. - Pretexts must not threaten employment status, compensation, or benefits. - All pretexts are defined in the RoE and approved by the Engagement Sponsor. #### Prohibited Targets (require explicit CISO approval) - C-suite executives and their direct administrative staff - Board members - Legal counsel (internal and external) - Human Resources personnel - Personnel on leave (medical, family, or other protected leave) #### Coordination Protocol | **Stakeholder** | **When** | **Purpose** | |---|---|---| | Legal | Before RoE approval | Review pretexts for legal risk; confirm no violation of wiretapping, recording, or privacy laws | | HR | Before RoE approval | Confirm no employee relations risk | | Facility Security | Before physical or USB engagements | Coordinate access testing; prevent alarm triggers or law enforcement response | | SOC / Detection Team | Before go-live | Prevent the engagement from being treated as a real incident | | Incident Commander | Before go-live | Pre-brief: if engagement triggers detection, the IC knows it's a test | #### Reporting Requirements Social engineering findings are reported separately from technical findings. The report includes: - Engagement subtype and scope - Number of targets and interactions - Success rate per subtype and per department - Root cause themes (e.g., lack of verification procedure, urgency exploitation, authority bias) - Recommended awareness and control improvements - Comparison to prior social engineering engagements (if applicable) --- ## 9. OT Adversarial Assessment: Safety Protocol OT testing is uniquely constrained. Safety overrides any test objective. ### 9.1 Prohibited Without Explicit Approval The following are prohibited absent a documented exception with engineering and operations sign-off: - **Active scanning of live SCADA/HMI/RTU/relay surfaces.** Passive monitoring and engineering-supervised authenticated checks only. - **Exploitation that could affect setpoints, alarms, relays, breakers, or control logic.** - **Denial-of-service against any OT segment, including saturation testing.** - **Disabling of OT monitoring or logging.** - **Persistence on OT systems.** - **Engagement during operational events**: storms, demand peaks, planned outages, regulatory windows. ### 9.2 Permitted Approaches - IT-side validation of paths into OT (jump server, vendor remote access, IT/OT crossing). - Lab / digital-twin replication of OT systems for offensive testing. - Passive observation and documentation of OT exposure. - Engineering-supervised authenticated checks in a defined window. - Tabletop / scenario-based assessment with OT operators. ### 9.3 Authority and Safety Officer Every OT engagement has a named OT Safety Officer (an operator with substation / process engineering authority) who can stop the test for any reason without justification. The Safety Officer's "stop" is binding. > **The Cost of Getting OT Testing Wrong** > > A pen-test misstep on an enterprise web app produces a ticket. A misstep on a relay setting group can shed load or trip a substation. CERG conducts OT adversarial work with the same care a power engineer applies in the field, and structures the engagement so the engineer's call always wins. --- ## 10. Finding Rating, Routing, and Retest ### 10.1 Rating Findings are rated using a uniform schema regardless of engagement type, aligning to [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) severity bands so they can co-route into exposure management: | **Severity** | **Definition** | |---|---| | Critical | Direct path to Crown Jewel, regulated data, safety impact, or persistent foothold. | | High | Significant escalation or material exposure of sensitive data; widespread bypass of a control. | | Medium | Notable control gap with limited exploitability or limited scope. | | Low | Hygiene or hardening recommendation. | | Informational | Observations and recommended improvements not tied to a control gap. | ### 10.2 Routing | **Source of Finding** | **Routes To** | |---|---| | Specific software / asset vulnerability | [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) finding + risk register entry per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) if Critical/High | | Control / design weakness | Risk register entry directly per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | Detection gap | Detection backlog + risk register if material | | Process / runbook weakness | Owning procedure (AR / IR / TPRM) + risk register if material | | Vendor / supply chain weakness | TPRM record per [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | OT-specific weakness | OT exposure management workflow per [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) §4.3 and §6.3 + risk register | ### 10.3 Retest and Closure - Critical findings retested within 30 days of remediation claim. - High findings retested within 60 days. - Medium/Low retested at next routine engagement or by sampled VM scan. - A finding moves to Closed only after retest demonstrates remediation; a finding that cannot be remediated moves through the risk register acceptance path with explicit Approver. - Closed findings inform the threat model for the affected system at next architecture review. ### 10.4 Escalation for Stalled Remediation When remediation stalls beyond the retest window, the finding escalates. #### Escalation Triggers | **Trigger** | **Action** | |---|---| | Critical finding not remediated at 30 days | Adversarial Testing Lead escalates to Risk Pillar Leader | | Critical finding not remediated at 45 days | Risk Pillar Leader escalates to CISO | | Critical finding not remediated at 60 days | CISO escalates to Executive; risk acceptance required | | High finding not remediated at 60 days | Adversarial Testing Lead escalates to Risk Pillar Leader | | High finding not remediated at 90 days | Risk Pillar Leader escalates to CISO | | Medium finding not remediated at 120 days | Adversarial Testing Lead escalates to system owner's pillar leader | #### Escalation Ladder Adversarial Testing Lead → Risk Pillar Leader → CISO → Executive Sponsor At each level, the responsible party must either (a) produce a credible remediation plan with a committed date, (b) initiate a risk acceptance through [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), or (c) provide a written rationale. Non-response at any level automatically escalates after 5 business days. #### Risk Acceptance as the Only Alternative When remediation is not feasible, risk acceptance requires: a written risk statement per PRC-RM-001 §4.1, documented compensating controls, approval per the authority matrix, and a scheduled re-review date. A finding that is neither remediated nor risk-accepted is a program gap, not an operational delay. --- ### 10.5 Adversarial Validation Final Report Every engagement produces a Final Report - the authoritative record of what was tested, found, and recommended. #### Required Sections | **Section** | **Content** | |---|---| | Executive Summary | Engagement type, scope, dates; findings summary by severity; top three risks; overall posture assessment; recommended next actions | | Engagement Overview | RoE reference; scope (systems, networks, applications); out-of-scope items; timeline; tester(s); methodology summary | | Methodology | Reconnaissance and enumeration techniques; exploitation approach; post-exploitation and lateral movement; tools and frameworks used | | Findings | Each finding includes ID, severity, title, description, affected assets, evidence (annotated screenshots, command output), risk statement, remediation recommendation, references (CVE, ATT&CK, CWE) | | Systemic Analysis | Patterns across findings; control themes that failed; root cause candidates | | Trend Analysis (if applicable) | Comparison to prior engagements; findings closed since last engagement; new vs. recurring findings; trend direction | | Appendices | Evidence artifacts, exploit code references (sanitized), timeline of key events, tools inventory | #### Evidence Artifact Standards - **Screenshots**: Annotated with arrows or captions highlighting relevant detail; include timestamp and host identifier - **Command output**: Full command and output with timestamp; truncation acceptable with notation - **Packet captures**: Time-stamped with source/destination; filtered to relevant conversation - **Exploit code**: Referenced by tool and version, not reproduced in full --- ### 10.6 Inter-Rater Reliability for Finding Ratings Different testers may rate the same finding differently. The following process ensures severity ratings are consistent and defensible. #### Peer Review for High-Severity Findings All Critical and High findings receive a peer review by a second qualified tester before the finding is finalized. The peer reviewer validates: - The severity rating against the definitions in Section 10.1 - That the evidence supports the severity determination - That the finding is not a duplicate of a known issue If the peer reviewer disagrees with the severity, the Adversarial Testing Lead facilitates resolution. The final severity is the consensus rating, or the higher of the two if consensus cannot be reached. #### Calibration Sessions Quarterly calibration sessions are conducted using a sample of anonymized findings from recent engagements. All testers independently rate each finding. Results are compared and discussed. The purpose is to: - Align severity interpretation across testers - Identify systematic over-rating or under-rating patterns - Refine severity definitions where ambiguity is found The Adversarial Testing Lead facilitates calibration and documents outcomes. Calibration results inform tester development and, where appropriate, updates to this procedure's severity definitions. #### Dispute Resolution | **Dispute** | **Resolution** | |---|---| | Tester and peer reviewer disagree on severity | Adversarial Testing Lead facilitates; default to higher severity if unresolved | | Tester and system owner disagree on severity | Risk Pillar Leader reviews; severity determined by risk to the organization, not by remediation difficulty | | Tester and CISO disagree on Critical classification | CISO makes final determination; rationale documented | --- ## 11. Systemic Analysis and Program Feedback Loop An Adaptive program does not stop at fixing individual pen-test findings. It asks: why did four of six DMZ servers share the same misconfiguration? What standard or procedure failed to prevent this? How do we change the program so the next engagement does not repeat the same class of finding? This section defines the post-engagement systemic analysis that converts adversarial validation findings into program improvements. ### 11.1 Post-Engagement Systemic Analysis After every adversarial validation engagement, the Adversarial Testing Lead produces two outputs: a findings report (existing) and a systemic analysis (new). The systemic analysis answers four questions: 1. **Which findings share a common root cause?** Example: four findings relate to default credentials on newly provisioned systems : the provisioning process does not enforce credential rotation. This is not four separate problems; it is one systemic weakness manifesting in four locations. 2. **Which findings indicate a standard or procedure gap?** Example: DMZ web servers all had the same TLS misconfiguration : STD-CFG-001 or STD-NET-001 does not specify DMZ TLS requirements clearly enough. 3. **Which findings indicate a control effectiveness gap?** Example: WAF was deployed per CB-001 but three bypass techniques worked : the WAF control is Implemented but not effective (per CEF-001). 4. **Which findings indicate a detection gap?** Example: testers pivoted laterally for four hours without an alert : detection rules need updating for the observed technique chain. ### 11.2 Systemic Finding Routing Each systemic finding is routed to the appropriate owner for program-level action: | Systemic Finding Type | Routed To | Tracking Mechanism | |---|---|---| | Standard or procedure gap | Governance Pillar Leader (Policy & Standards Manager) | IMPREG-001 (Type: Standard revision or Procedure update) | | Control effectiveness gap | Accountable pillar leader (per CB-001) | IMPREG-001 (Type: Control amendment) + CEF-001 control failure analysis | | Detection gap | Risk Pillar Leader (Detection Engineer) | Detection backlog per LM-001 + IMPREG-001 if systemic | | Process gap | Accountable procedure owner (per RAC-001) | IMPREG-001 (Type: Procedure update) | | Tooling or capability gap | Relevant pillar leader | IMPREG-001 (Type: New capability) + CISO if budget required | Routed systemic findings are tracked in the improvement register (IMPREG-001) per the improvement lifecycle. The source field records the engagement ID and date. ### 11.3 Prevention Verification At the next adversarial validation engagement of the same type, scope, or target environment, the engagement plan includes re-testing the systemic weaknesses identified in the prior engagement. - If the same class of finding does NOT recur: the systemic improvement is verified Effective in IMPREG-001. - If the same class of finding recurs: the improvement is marked Ineffective or Partially Effective, re-opened in IMPREG-001, and the root cause analysis is re-examined. The fact that a deliberate program change did not prevent recurrence is itself a critical lesson. > **The Recurrence Test** > > An assessor reviewing two consecutive pen test reports should see: (a) the specific vulnerabilities from the prior test are closed, AND (b) the systemic weakness that produced them no longer produces new findings of the same class. If the second report finds different specific vulnerabilities but the same systemic root cause : different default credentials on different systems : the improvement failed. The program that only fixes individual findings and never the systemic cause is operating at Repeatable, not Adaptive. ### 11.4 Annual Trend Analysis Annually, the Adversarial Testing Lead produces an adversarial validation trend analysis covering all engagements in the trailing 12 months: - Are total findings increasing or decreasing? Segmented by severity. - Are systemic weaknesses repeating across engagements? - Which control families (per CB-001) produce the most findings? The most Critical and High findings? - Which control families show improvement (fewer findings year-over-year)? - How many systemic findings were routed to IMPREG-001, and what was their verification outcome? The trend analysis feeds into: - The control effectiveness program (CEF-001): control families with persistently high finding rates trigger a control failure analysis - The risk appetite calibration (RMF-001): a finding-rate trend that undermines a risk appetite assumption triggers recalibration - The annual maturity assessment (MAT-001): finding-rate trends are evidence of control effectiveness or ineffectiveness --- ## 12. Roles and Responsibilities | Role | Responsibility | |---|---| | **Adversarial Testing Lead** | Owns this procedure. Produces the annual plan, engagement RoE/Charter, findings report, and systemic analysis. Routes systemic findings. Produces the annual trend analysis. | | **Risk Pillar Leader** | Accountable for the adversarial validation program. Approves the annual plan. Reviews systemic analysis outputs. | | **CISO** | Approves the annual plan. Authorizes red-team and OT engagements. Receives Critical finding notifications. | | **Engineering Pillar Leader** | Receives and acts on design, architecture, and configuration systemic findings. Participates in scoping. | | **Governance Pillar Leader** | Receives standard and procedure gap systemic findings. Coordinates catalog amendments resulting from systemic improvements. | | **Detection Engineer** | Receives detection gap findings. Updates detection rules and reports on coverage improvement. | | **Exposure Management Lead** | Receives specific vulnerability findings. Tracks remediation to closure per PRC-VM-001. | | **Risk Register Owner** | Records material findings as risk register entries. Links risk entries to improvement entries when systemic. | | **OT Safety Officer** | Named for each OT engagement. Holds binding stop authority. Reviews OT scope and safety constraints. | --- ## 13. Evidence Retention | **Artifact** | **Retention** | **Access** | |---|---|---| | Signed RoE | Engagement + 7 years | Sponsor, CISO, Audit | | Signed Charter (red team) | Engagement + 7 years | Sponsor, CISO, Audit | | Engagement plan / scope | Engagement + 5 years | Sponsor, Test Lead, CISO | | Tester daily logs / standup notes | Engagement + 2 years | Test Lead, CERG sponsor | | Final report (sanitized) | Engagement + 7 years | Distribution per RoE | | Final report (full / unsanitized) | Engagement + 5 years | Named distribution only | | Detection validation results (purple) | Engagement + 3 years | Detection eng + audit | | Finding records | Per VM tool retention; closed findings retained per audit retention | - | | Retest evidence | Per finding record retention | - | Final reports are distributed under the confidentiality terms in the RoE. Full reports are not emailed; access is via a controlled location with audit logging. > **Findings Carry Sensitive Information About How to Compromise Us** > > An unsanitized pen-test report is a road map for attackers and should be treated as Restricted. Distribution is named, encrypted, and audited; "wider sharing" requests are reviewed by the Engagement Sponsor. --- ## 14. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Procedure** | |---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) CA-8 | All sections | | NIST 800-115 | All sections | | PTES | Sections 3–4 | | MITRE ATT&CK | Sections 6, 7 | | OWASP WSTG / MASTG / API Top 10 | Section 8 | | NERC-CIP CIP-007 R3.2 (vulnerability assessment) | Sections 9, 10 | | [CMMC L2](https://dodcio.defense.gov/CMMC/) (3.11.2) | Sections 3, 8 | --- ## 15. Document Control | | | |---|---| | **Document ID** | CERG-PRC-AV-001 | | **Version** | 1.2 | | **Approved By** | CISO | | **Next Review** | Annual / on material program change | | **Change Log** | 1.0 - Initial publication. Engagement types, RoE, charter, purple, cloud, app, OT safety, rating/routing, evidence retention. · 1.1 - Added Section 11 Systemic Analysis and Program Feedback Loop: post-engagement systemic analysis, systemic finding routing, prevention verification, and annual trend analysis. · 1.2 - Restored Section 12 Roles and Responsibilities. Renumbered Evidence Retention to Section 13, Regulatory to 14, Document Control to 15. | --- ## ARCHITECTURE REVIEW AND PROJECT INTAKE PROCEDURE ### Intake · Review · Threat Model · Pre-Production · Handoff · Go-Live Risk Acceptance --- | | | |---|---| | **Document ID** | CERG-PRC-AR-001 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-PRC-TM-001](CERG-PRC-TM-001_Threat_Modeling_Procedure.md) · [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Review Cycle** | Annual / On platform or process change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (PL, SA, SC) · NIST 800-160 · NIST SSDF · CSA STAR | | **Regulations** | [CMMC L2](https://dodcio.defense.gov/CMMC/) · NERC-CIP CIP-005/CIP-010 · SOX ITGC (Change) | | **Environments** | All in-scope projects - IT, cloud, SaaS, OT, hybrid | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Roles and Responsibilities](#2-roles-and-responsibilities) 3. [The Five-Phase Engagement Model](#3-the-five-phase-engagement-model) 4. [Who Needs a Review, and Who Doesn't](#4-who-needs-a-review--and-who-doesnt) 5. [Phase 1, Intake](#5-phase-1--intake) 6. [Phase 2, Architecture Review and Threat Model](#6-phase-2--architecture-review-and-threat-model) 7. [Phase 3, Build-Time Engagement](#7-phase-3--build-time-engagement) 8. [Phase 4, Pre-Production Security Review](#8-phase-4--pre-production-security-review) 9. [Phase 5, Production Handoff and Go-Live](#9-phase-5--production-handoff-and-go-live) 10. [Required Diagrams](#10-required-diagrams) 11. [Templates](#11-templates) 12. [Metrics](#12-metrics) 13. [Regulatory and Framework Alignment Summary](#13-regulatory-and-framework-alignment-summary) 14. [Pre-Approved Architecture Patterns](#14-pre-approved-architecture-patterns) 15. [Document Control](#15-document-control) --- ## 1. Purpose and Scope The Operating Model makes Engineering project engagement a core CERG delivery model. The RMF Phase 3 describes concept, design, build, pre-production, and production handoff outputs. Until this procedure, the intake forms, review checklists, threat modeling guidance, signoff criteria, and handoff packages those phases require existed implicitly. This procedure defines how a project enters CERG attention, how Engineering reviews it, how Risk threat-models it, how findings flow to remediation or risk acceptance, and how the system enters production with the right documentation, baselines, monitoring, and accepted exceptions. The standalone [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) is the canonical front-door intake form for Phase 1. This procedure remains authoritative for the Phase 2 architecture review record, Phase 4 pre-production security review record, Phase 5 production handoff package, and go-live risk acceptance packet. > **Engineering's Job Is to Be in the Room Early** > > Architecture review is not a gate that bolts security onto a project at the end. It is the discipline of having Engineering in the design conversation early enough to change the design cheaply. A review that consistently surfaces "we have to redo the data flow now" is a review that came too late. --- ## 2. Roles and Responsibilities | **Role** | **Responsibility** | |---|---| | **Project Sponsor / Business Owner** | Submits intake. Owns the project's residual risk. Approves go-live decisions for their scope. | | **Project / Technical Lead** | Produces the architecture artifacts and answers reviewer questions. Drives remediation between reviews. | | **CERG - Pre-production Reviewer** | Conducts Engineering review, maintains the review record, determines Engineering findings, and recommends handoff disposition. | | **Application Security Engineer** | Provides application, API, SDLC, and software architecture review input. Supports threat modeling with technical context and records application-security findings. | | **Risk Pillar Leader / assigned Risk reviewer** | Leads threat modeling per [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md), contributes adversary context, and ensures threat-model findings receive a disposition. | | **Vendor Risk Analyst** | Performs third-party and supply-chain assessment per [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) when vendors, SaaS providers, MSPs, software suppliers, or external integrations are involved. | | **Governance Pillar Leader** | Maps the project into the regulatory scope (CUI / BES / SOX) and triggers the relevant overlay reviewers. | | **Engineering Pillar Leader** | Approves Engineering disposition, validates proposed compensating controls, and routes any residual-risk acceptance to the authority named in [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) §8 and [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. | | **CISO** | Approves High / Critical risk acceptances at go-live where required by the canonical authority table. | | **IT Change Advisory Board (CAB)** | Hosts the go-live conversation; CERG review status is a CAB input, not a substitute for change management. | --- ## 3. The Five-Phase Engagement Model CERG engagement with a project follows five phases. Not every project hits every phase, Section 4 names the carve-outs. 1. **Intake**, register the project; classify scope; determine review depth. 2. **Architecture Review and Threat Model**, design-stage review; threats and controls aligned to [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md). 3. **Build-Time Engagement**, secure SDLC checks, IaC review, baseline conformance. 4. **Pre-Production Security Review**, readiness against the review findings, baselines, monitoring, and recovery. 5. **Production Handoff and Go-Live**, handoff package complete, risk acceptances approved, asset added to inventory and recurring controls. --- ## 4. Who Needs a Review: and Who Doesn't Reviewing every Power App or low-code workflow is how Engineering loses a quarter to busywork. Waving them all through is how Shadow IT eats the enterprise. CERG's answer is: **review the platform once, then trust the guardrails the platform enforces.** ### 4.1 Mandatory Review CERG Architecture Review is mandatory for projects that meet any of the following: - Introduces a new IaaS / PaaS / cloud account, subscription, or project. - Introduces a new SaaS service (any tier) handling business data. - Touches OT / BES Cyber Systems or the IT/OT boundary (per [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md)). - Handles CUI (storage, processing, transmission) or changes the CUI boundary. - Handles SOX-relevant financial data or process flows. - Introduces or changes a third-party network connection. - Modifies the production identity provider, federation, or PAM topology. - Introduces a new authentication path to a system holding Restricted data. - Crosses a trust boundary (network, identity, tenant, region, organization). - Introduces a new data classification or regulatory scope into the environment. ### 4.2 Lightweight Review (Engineering Self-Service) A lightweight, self-service review pattern (intake form + checklist + Engineering sign-off without full Phase 2) is acceptable for projects that: - Reuse an already-reviewed pattern (e.g., new microservice on an already-reviewed Kubernetes cluster). - Add capacity to an already-reviewed system. - Use a pre-approved IaC module or service catalog template. ### 4.3 Citizen-Development Carve-Out Citizen-development platforms (Power Platform, low-code app builders, business-managed automation) are not reviewed *per app*. They are reviewed once, at platform onboarding, with the assessment focused on the platform's guardrails, then trusted to police the apps that run on it. | **Citizen-Dev Platform Assessment** | **Required at Platform Onboarding** | |---|---| | Identity and access | SSO + MFA + role-based admin model + audit log to SIEM | | Data egress | Data Loss Prevention policy on connectors; sensitive connectors restricted | | Data classification awareness | Sensitivity labels surfaced to citizen developers; export restrictions enforced | | External sharing | Disabled by default; named exception path | | Lifecycle | App lifecycle policy: ownership required, dormant apps culled, transfer-on-departure | | Telemetry | Audit log forwarded to SIEM; admin actions monitored | | Detection set | Day-one detections per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Apps built on the platform are governed by these guardrails. Where an app needs to step outside the guardrails (e.g., a new connector, an unusual data classification), it triggers Mandatory Review per Section 4.1. > **The Test** > > If a citizen-development app cannot do anything outside the platform's guardrails, CERG does not need to review it. If a platform's guardrails are weaker than CERG's standards, the platform is unsuitable for the data classification it's hosting. Apps get reviewed only when they need to step outside the boundary. ### 4.4 What Does Not Need CERG Review - Pure UX or visual changes to an existing system that don't touch authentication, data classification, scope, or interfaces. - Routine patching covered by [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md). - Routine configuration changes within the DISH-conformant pattern that don't change trust boundaries. ### 4.5 Approved Pattern Register Lightweight review depends on knowing which patterns are already approved. Engineering maintains an Approved Pattern Register as part of the architecture review record set. A pattern may be a reference architecture, IaC module, landing-zone template, CI/CD pipeline profile, SaaS configuration pattern, citizen-development guardrail set, or service-catalog template. Each approved pattern records: | **Field** | **Purpose** | |---|---| | Pattern ID and name | Stable reference used by intake and project records. | | Pattern owner | Engineering role accountable for keeping the pattern current. | | Approved use cases | What the pattern may be used for without full re-review. | | Approved data classifications / regulatory scopes | Maximum data and regulatory scope allowed under the pattern. | | Required controls and evidence | Baselines, guardrails, logging, detection, recovery, and evidence links. | | Known limitations | Conditions that trigger mandatory review instead of reuse. | | Last review / next review | Currency of the approval. | | Review triggers | Events that require re-review: major platform change, control failure, new regulatory scope, material finding, or threat intelligence change. | A project claiming lightweight review must cite the approved pattern it reuses and confirm it stays inside the pattern's approved scope. If the project changes the pattern, extends it to a higher data classification, crosses a new trust boundary, or disables a required guardrail, it becomes Mandatory Review. --- ## 5. Phase 1: Intake Intake is fast (< 5 business days) and produces a Scope Determination that drives every subsequent phase. ### 5.1 Security Project Intake Form (Template) Use [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) for the authoritative Phase 1 intake form. The structure below is retained as the procedure-level minimum content model and for adopters embedding intake directly into a ticketing system. ``` SECURITY PROJECT INTAKE - AR-YYYY-NNNN A. PROJECT IDENTITY Project Name : Sponsor (named role) : Technical Lead : Business Outcome : Target Production Date : B. SCOPE Data Classifications Handled : Public / Internal / Restricted / CUI / BCSI Regulatory Scope : None / CUI / BES / SOX (multi-select) Operating Units Impacted : Environments : IT / Cloud / SaaS / OT / Hybrid Geographies : (countries; flag non-US access) Trust Boundaries Crossed : (network / identity / tenant / org) C. TECHNOLOGY New SaaS introduced? : Y/N - name(s) - vendor(s) New cloud account/sub/proj? : Y/N New OT touch / IT/OT bridge? : Y/N New external connection? : Y/N New identity / federation? : Y/N D. THIRD PARTIES Vendors involved : list Vendor tier (per TPRM) : International access? : Y/N - countries E. CHANGE CONTEXT New build / migrate / retire / extend Existing CERG-tracked asset IDs (if extension) F. INITIAL SECURITY CONCERNS (from project team) What worries us most : What we know is unresolved : G. ASKS What CERG help do we need at design stage? ``` ### 5.2 Scope Determination Output The Intake reviewer (CERG Engineering) determines: - Review path: **Mandatory** (Phase 2 full), **Lightweight** (self-service checklist), or **Out of Scope**. - Overlay reviewers required: CUI, BES, SOX, OT, each named by [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md). - Threat modeling required: Y/N (default Y for Mandatory; conditional for Lightweight). - TPRM engagement required: Y/N (default Y if any vendor is new or tier > business default). - Estimated Phase 2–5 effort and target dates. A Scope Determination is recorded against the project and visible to the team within five business days. ### 5.3 Review Path and SLC Tier Crosswalk The review path determines how much review is required. The SLC tier determines the response clock published to the business in [`CERG-GOV-SLC-001`](../governance/CERG-GOV-SLC-001_CERG_Service_Level_Commitments.md). Intake records both values. | **AR Review Path** | **Default SLC Tier** | **Examples** | **Notes** | |---|---|---|---| | Mandatory | Tier 1 | OT / BES, CUI, Restricted-data SaaS, new cloud account, new internet-facing service, AI with sensitive data | Use Tier 2 only if the mandatory trigger is narrow, low-blast-radius, and non-regulated. | | Mandatory | Tier 2 | Standard internal application, material change to an existing non-regulated system, new vendor integration without Restricted data | Full review required, but lower urgency / complexity than Tier 1. | | Lightweight | Tier 3 | Reuse of approved pattern, pre-approved IaC module, added capacity to reviewed system | Checklist and evidence review; no full Phase 2 unless the reviewer escalates. | | Out of Scope | N/A | Pure UX change, routine patching, configuration change within approved baseline | Record disposition only; no SLC review clock beyond intake acknowledgement. | Where the review path and SLC tier appear to disagree, the Engineering Pillar Leader records the rationale. Regulated scope, new trust boundaries, and Restricted-data placement always bias upward. --- ## 6. Phase 2: Architecture Review and Threat Model ### 6.1 Architecture Review Checklist The reviewer works through the checklist below; findings are recorded with severity and routed per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | **Area** | **Review Item** | **Standard Reference** | |---|---|---| | Identity | SSO + MFA + role model + JIT for privileged + service account pattern | STD-AC-001 | | Authorization | Least privilege; SoD where applicable; tenant / record / field scoping | STD-AC-001 / GOV-CB-001 AC-5 | | Data classification | Classification recorded; controls match classification | STD-CUI-001 / STD-IT-001 | | Cryptography | Algorithms approved; CMK where required; secrets pattern; FIPS where applicable | STD-CR-001 | | Network | Segmentation; default deny; logging; trust boundaries marked | STD-IT-001 / STD-OT-001 | | Configuration | DISH tier; baseline applied; drift detection | STD-CFG-001 | | Logging | Mandatory sources onboarded; retention; immutability | STD-LM-001 | | Detection | Day-one detection set committed for environment | STD-LM-001 | | Exposure management | Observation sources and authenticated scanning in scope; classification and treatment SLAs agreed | PRC-VM-001 | | Resilience | RTO/RPO tier; backup; restoration test plan | STD-RES-001 | | Third party | Vendor tier; evidence by tier; SCCT in workflow; international access guardrail | PRC-TPRM-001 | | OT (if applicable) | Active scan rules; passive monitoring; safety review; CIP applicability | STD-OT-001 / PLN-CIP-001 | | CUI (if applicable) | Boundary marked; FIPS crypto; flow-down; FedRAMP equivalency captured | STD-CUI-001 / PLN-CUI-001 | | SOX (if applicable) | ITGC mapping; evidence reuse | PLN-SOX-001 | | Citizen-dev (if applicable) | Built on approved platform with guardrails; data classification compatible | This procedure §4.3 | | Diagrams provided | Context · Data flow · Network · Identity · Trust boundary · OT boundary (where applicable) | This procedure §10 | | Risk register entries | All findings entered; treatment proposed | PRC-RM-001 | ### 6.2 Threat Model The threat model is owned by CERG Risk in collaboration with the project. It uses STRIDE as the default decomposition for IT and a STRIDE-LM (with Lateral Movement) variant for OT. The format is a short Markdown document with the following structure: ``` THREAT MODEL - AR-YYYY-NNNN - TM-001 1. ASSETS AND DATA - what's worth protecting, with classification 2. ACTORS AND ENTRY POINTS - humans, machines, external services 3. TRUST BOUNDARIES - drawn on the diagram; named in text 4. THREATS BY BOUNDARY - STRIDE per boundary; OT add Lateral Movement 5. EXISTING CONTROLS - what mitigates each threat 6. RESIDUAL - what remains, mapped to risk register entries 7. ATTACK SIMULATION CANDIDATES - for purple / red engagements (PRC-AV-001) ``` > **The Threat Model Earns Its Keep When It Changes the Design** > > A threat model that documents what was already decided is paperwork. A threat model that surfaces a control the design missed, a missing boundary, a misplaced trust, is the reason the review exists. ### 6.3 Phase 2 SLA Phase 2 review (Architecture Review and Threat Model) follows the SLC tier assigned at intake: Tier 1 within 10 business days, Tier 2 within 7 business days, and Tier 3 within 5 business days where Phase 2 is required. Extensions may be granted by the Engineering Pillar Leader for complex systems (e.g., multi-cloud, OT-integrated, or CUI-scope systems with novel architecture). The project team is notified of any extension with rationale within the original SLA window. ### 6.4 Phase 2 Output - Architecture Review record with status `Approved` / `Approved-with-Conditions` / `Not Approved`. - Threat model attached. - Findings in the risk register, scored. - Build-time conditions for Phase 3. --- ## 7. Phase 3: Build-Time Engagement Build-time engagement is the period between design approval and pre-production. CERG differentiates between routine and novel builds. ### 7.1 Routine vs. Novel Builds | **Build Type** | **Definition** | **CERG Posture** | |---|---|---| | Routine | Deploys a pre-approved architecture pattern or IaC module without modification; uses an existing pipeline with all gates active; no new trust boundary, data path, or integration | Light-touch: CERG does not actively review unless pipeline gate failures trigger review | | Novel | Introduces a new IaC module, a new service pattern, a new integration, or a material change from the Phase 2 architecture; or is the first deployment of a new application stack | CERG actively reviews the build artifacts | The Engineering Pillar Leader determines whether a build is routine or novel based on the Phase 2 architecture review record and the project's pipeline configuration. ### 7.2 CERG Review Checklist for Novel Builds | **Check** | **Pass Criteria** | **Evidence** | |---|---|---| | IaC conformance | IaC modules match the approved architecture per Phase 2; no material deviations | IaC diff or module reference | | Pipeline gates active | DISH baseline scan, container image signing, SBOM generation, and vulnerability scan are all enforced (not optional) in the CI/CD pipeline | Pipeline configuration | | Secrets scanning | No secrets detected in repository, build artifacts, or container images; secrets manager integration is wired and tested | Secrets scan output | | SBOM generated | Software Bill of Materials is produced for every build; SBOM is stored with the build artifact | SBOM artifact | | Image signing | Container images are signed per [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | Image signature verification | | Exposure scan gate | Build fails if Critical or High application or dependency exposures are detected; Medium and below are flagged for tracking | Pipeline scan output | ### 7.3 Acceptance Criteria for Build-Time Gates | **Gate** | **Blocking** | **Non-Blocking** | |---|---|---| | DISH baseline conformance | Non-conformance on Critical or High severity settings | Low severity or informational deviations (flagged) | | Exposure scan | Critical or High application dependency exposures | Medium or Low findings (tracked in exposure backlog) | | Secrets scanning | Any confirmed secret detected | False positive (documented and suppressed) | | Image signing | Unsigned image in a pipeline that requires signing | - | ### 7.4 Escalation for Build-Time Findings Build-time findings are escalated within the development team first, then to CERG: | **Trigger** | **Action** | |---|---| | Pipeline gate failure (Critical/High) | Development team must resolve before build proceeds; CERG notified | | Repeated gate failure (≥ 3 builds) | CERG reviews; may trigger conditional re-review under Phase 2 | | Disabling or bypassing a security gate | Treated as a security incident; CISO notified | ### 7.5 SLA for Build-Time Review CERG completes novel-build review within 3 business days of notification. If the review cannot be completed within SLA, Engineering documents the delay, schedules the follow-up review, and notifies the project team. A build may proceed only if no blocking security gate has failed; any residual risk created by proceeding is routed through the risk acceptance process. Engineering does not accept business risk on behalf of the owner. The artifacts produced during build include: IaC review for new modules and patterns; pipeline gates enforcing DISH baseline conformance, container image signing, SBOM generation, and exposure scanning; secrets checking; and conditional re-review if material design changes happen between Phase 2 and Phase 4. --- ## 8. Phase 4: Pre-Production Security Review Pre-Production review is a focused, time-boxed readiness check. It produces a Pre-Production Security Review Record. ### 8.1 Pre-Production Checklist | **Check** | **Pass Criteria** | **Evidence** | |---|---|---| | DISH baseline applied | Pass against the asset's tier in [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | DISH scan output | | Exposure posture | No unremediated, unaccepted Critical exposures; High open ≤ approved exception count from Phase 2 | Exposure pipeline report | | Identity wired | SSO + MFA enforced; PAM model in place; service accounts via approved pattern | IdP / PAM policy export | | Logging | Mandatory sources onboarded; SIEM ingest verified; retention configured | SIEM source inventory | | Detection | Day-one detection set enabled in the environment | Detection coverage report | | Cryptography | TLS configuration matches [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md); CMK where required; secrets pattern in use | Configuration evidence | | Resilience | Backups configured per tier; first restoration test scheduled | Backup config; resilience register entry | | Vendor / TPRM | Vendor records current; evidence-by-tier complete; SCCT in workflow | TPRM tool entries | | Regulatory overlay artifacts | CUI / BES / SOX artifacts populated per relevant package | Per overlay | | Phase 2 conditions cleared | All conditions either met or accepted through the risk process | Phase 2 record annotations | | Asset inventory | System added; ownership recorded | Asset inventory | | Run-book / on-call | Service has documented on-call and run-book | Run-book reference | | Change management | Go-live aligned with CAB cadence | Change record | ### 8.2 Phase 4 SLA Pre-Production Security Review is completed within 5 business days of the project team submitting the Pre-Production checklist evidence. Extensions may be granted by the Risk Pillar Leader where evidence review requires additional subject matter expertise. ### 8.3 Outcome - **Ready**: go-live disposition in Phase 5. - **Ready-with-Risk-Acceptance**: outstanding findings have risk register entries with approved exceptions per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) §7. - **Not Ready**: go-live blocked until specific items close. --- ## 9. Phase 5: Production Handoff and Go-Live ### 9.1 Production Handoff Package The handoff package is the single artifact that goes into the asset's record. It is a Markdown bundle with the contents below. ``` PRODUCTION HANDOFF PACKAGE - AR-YYYY-NNNN - PHP-001 1. SYSTEM IDENTITY Asset ID(s) · Tier · Owners · Regulatory scope 2. CERG REVIEW RECORD Phase 1 Intake reference Phase 2 Architecture Review record (link) Phase 2 Threat Model (link) Phase 3 build conditions cleared (yes/no) Phase 4 Pre-Production record (link) 3. CONTROL POSTURE AT GO-LIVE Control-by-control state per [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) (Implemented / Partial / Inherited / Planned / Risk Accepted / N/A) Inheritance Evidence Packages on file (cloud / SaaS providers) 4. EVIDENCE POINTERS DISH scan output (latest) Exposure scan / pipeline output (latest) Identity / detection / logging configuration Backup configuration and first restoration test plan 5. RISK ACCEPTANCES AT GO-LIVE Exception IDs and approvers Treatment plans and expiration dates 6. ONGOING CONTROL OBLIGATIONS Recurring controls (scan cadence, recert cadence, restoration test cadence) Owners for each recurring control 7. RUN-BOOK AND ON-CALL References 8. SIGN-OFFS Engineering Reviewer Risk Reviewer Governance (overlay) Reviewer(s) - CUI / BES / SOX as applicable Engineering Pillar Leader CISO (if High / Critical risk acceptance) Business Owner ``` ### 9.2 Go-Live Risk Acceptance Packet A separate packet is produced only if go-live ships with one or more risk acceptances. It is the document the Business Owner and required approvers sign per the canonical authority table. ``` GO-LIVE RISK ACCEPTANCE PACKET - AR-YYYY-NNNN - GLR-001 Each accepted risk: - Risk Statement (per [CERG-TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md)) - Linked control(s) - Compensating controls in place at go-live - Residual score and band - Expiration / re-review date - Treatment plan that retires the acceptance - Approver (per PRC-RM-001 §8) Aggregate: - Combined residual score - Top three watch-list items - First post-go-live review date (≤ 90 days for Critical / High) ``` ### 9.3 Phase 5 SLA Production Handoff and Go-Live is completed within 3 business days of Phase 4 Ready disposition. The handoff package is the gate; go-live proceeds when the package is complete and signed. ### 9.4 Post-Go-Live Watch Period - Critical / High risk acceptances trigger a post-go-live watch period of ≤ 90 days with a scheduled re-review. - Detection telemetry is reviewed at 30 days for unexpected behavior tied to the accepted risk. - Findings from the watch period feed back into the risk register and, where appropriate, the threat model. --- ### 9.5 Dispute and Appeal Process If a project team disagrees with a finding, disposition, or outcome from any phase of the architecture review, the following appeal path is available. #### Appeal Triggers An appeal may be filed for: - A finding the project team believes is inaccurate, inapplicable, or overstated - A "Not Approved" disposition on a Phase 2 review - A "Not Ready" disposition on a Phase 4 pre-production review - A go-live condition the project team believes is unreasonable or infeasible #### Appeal Process | **Step** | **Action** | **Timing** | |---|---|---| | 1 | Project team submits written appeal to the CERG Pre-Production Reviewer, stating the specific finding or disposition being appealed, the rationale, and any supporting evidence | Within 5 business days of the original decision | | 2 | CERG Pre-Production Reviewer re-evaluates with the project team; may consult additional subject matter experts | Within 5 business days | | 3 | If resolved: decision is updated and recorded. If not resolved: escalates to Risk Pillar Leader. | - | | 4 | Risk Pillar Leader reviews the appeal and the CERG position; makes a determination or escalates to CISO | Within 5 business days | | 5 | CISO makes final determination. CISO's decision is binding and is recorded in the review record. | Within 10 business days of escalation | #### Criteria for Overturning a Decision A decision may be overturned if: - New or overlooked evidence demonstrates the finding is inapplicable - The project team proposes an alternative compensating control that achieves equivalent or superior risk reduction - The original decision was based on a misinterpretation of a standard or control requirement - The business impact of the decision is disproportionate to the risk it addresses #### Documentation Every appeal is documented in the review record, including: the appealed finding or disposition, the appellant's rationale, the resolution, and the final decision-maker. Appeal outcomes inform program improvement per [CERG-PRC-LL-001](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md). --- ## 10. Required Diagrams Every Mandatory Review delivers the diagram set below. Diagrams are produced in a tool that exports to durable formats; the latest version lives with the review record. | **Diagram** | **Required For** | **Shows** | |---|---|---| | **Context** | All | The system, its users, and the systems it depends on. One page. | | **Data Flow** | All | What data moves where, classified; arrows annotated with protocol and trust boundary crossings. | | **Network** | All non-pure-SaaS | Network paths, segmentation, ingress/egress, public exposure. | | **Identity** | All | Identity sources, federation, SSO, MFA enforcement points, service accounts and machine identities. | | **Trust Boundary** | All | Drawn over the data flow / network diagrams: tenant, network, identity, regulatory boundaries. | | **OT Boundary** | OT or IT/OT bridge | ESP, EAP, BCS, BCSI flows, control room/operator interface. | | **CUI Boundary** | CUI scope | Where CUI is processed, stored, and transmitted; FedRAMP-equivalent service edge. | | **Backup / Recovery** | Tier 1/2 and any BES/CUI scope | Backup source, target, immutability boundary, restoration target. | Where a diagram is implicit (e.g., a pure SaaS service has no on-prem network), the review record notes "Not Applicable" with rationale rather than omitting silently. --- ## 11. Templates Architecture review uses one standalone intake template and several procedure-owned record patterns. Authority is split as follows: | **Artifact** | **Authoritative Source** | **Purpose** | |---|---|---| | Phase 1 Architecture and Project Intake Form | [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) | Opens the engagement, records scope determination, and routes follow-on records. | | Phase 2 Architecture Review Record | This procedure §6.4 and worked example Appendix A | Records findings, conditions, and Engineering disposition. | | Phase 2 Threat Model Record | This procedure §6.2 and [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Records threats, assumptions, residual risks, and simulation candidates. | | Phase 4 Pre-Production Security Review Record | This procedure §8 | Confirms readiness evidence and records Ready / Ready-with-Risk-Acceptance / Not Ready disposition. | | Phase 5 Production Handoff Package | This procedure §9.1 | Consolidates review records, control posture, evidence pointers, recurring obligations, and sign-offs for the asset record. | | Go-Live Risk Acceptance Packet | This procedure §9.2 and [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Documents accepted residual risk at go-live when required by the canonical risk authority path. | A completed [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) is not evidence that Phase 2, Phase 4, or Phase 5 has been completed. It is the intake and routing record that starts the chain. --- ## 12. Metrics | **KPI** | **Formula** | **Data Source** | **Refresh** | **Green** | **Amber** | **Red** | |---|---|---|---|---|---|---| | **Average Time - Phase 1 (Intake)** | Mean business days from intake submission to Scope Determination recorded | Intake tracker | Monthly | ≤ 3 days | 4–5 days | > 5 days | | **Average Time - Phase 2 (Arch Review)** | Mean business days from Phase 2 start to review record disposition | Review tracker | Monthly | ≤ 7 days | 8–10 days | > 10 days | | **Average Time - Phase 3 (Build-Time)** | Mean business days per build-time review cycle | Pipeline / review tracker | Monthly | ≤ 2 days | 3 days | > 3 days | | **Average Time - Phase 4 (Pre-Prod)** | Mean business days from Phase 4 start to disposition (Ready / Ready-with-Acceptance / Not Ready) | Review tracker | Monthly | ≤ 4 days | 5 days | > 5 days | | **Average Time - Phase 5 (Handoff)** | Mean business days from Pre-Prod Ready to handoff package signed | Review tracker | Monthly | ≤ 2 days | 3 days | > 3 days | | **Review Backlog Count** | Number of open reviews past their target disposition date | Review tracker | Weekly | ≤ 2 | 3–5 | > 5 | | **Finding Severity Distribution** | Count of findings by severity (Critical / High / Medium / Low / Info) recorded across all active reviews | Risk register | Monthly | Baseline to be established in first year of operation | | | | **Threat Model Coverage Rate** | % of Mandatory Review projects with completed threat model attached to the review record | Review tracker + TM repo | Quarterly | ≥ 95% | 85–94% | < 85% | | **Handoff Package Completion Rate** | % of projects in Phase 5 with all handoff package sections complete at go-live | Review tracker | Quarterly | ≥ 100% | 90–99% | < 90% | | **Risk Acceptance Aging** | Mean and maximum age (days) of open risk acceptances raised through the review process | Risk register | Monthly | Mean ≤ 90 days, Max ≤ 180 days | Mean 91–180 days, Max 181–270 days | Mean > 180 days, Max > 270 days | | **Review SLA Compliance Rate** | % of reviews meeting the SLA for their review path (Mandatory / Lightweight) | Review tracker | Monthly | ≥ 90% | 80–89% | < 80% | > **Baseline Establishment** > > Where a metric is marked "Baseline to be established in first year of operation," the CERG Risk Pillar collects 12 months of data and proposes Green/Amber/Red thresholds at the next annual review. Prior to baseline, the metric is reported without RAG coloring. --- ## 13. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Procedure** | |---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) PL / SA / SC | All phases | | NIST 800-160 (Systems Security Engineering) | Phases 2–5 | | NIST SSDF | Phase 3 | | NERC-CIP CIP-005 / CIP-010 | Phase 2 OT scope, Phase 4 baseline | | [CMMC L2](https://dodcio.defense.gov/CMMC/) | CUI scope determination in Phase 1; FIPS check in Phase 2/4 | | SOX ITGC | SOX scope in Phase 1; change-management interface in Phase 5 | --- ## 14. Pre-Approved Architecture Patterns Good governance makes projects faster because teams can design correctly before vendor selection. The patterns below are pre-approved for architecture review at the "Light-Touch" tier if the described conditions are met. Engineering signs off; Governance and Risk are not required to engage unless the project exceeds the pattern's boundaries. | Pattern | Required Controls | Evidence | Expected Approval | When to Escalate | |---------|------------------|----------|-------------------|------------------| | **New SaaS — no sensitive data** | SSO via IdP; OAuth app review; data classification verified as Internal or lower | IdP config, OAuth grant list, data classification record | 1 business day | Data classification changes; CUI/Restricted data discovered; vendor fails SSPM baseline | | **New SaaS — SSO only** | SSO enforced; no local accounts; OAuth scope review; tenant admin account secured via PAM | IdP config, PAM configuration | 2 business days | SaaS holds sensitive data; provider lacks SOC 2; tenant admin not under PAM | | **SaaS with Restricted / CUI data** | Full TPRM pipeline per [TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md); FedRAMP equivalency evidence; CUI flow-down; shared responsibility matrix | SSP report, FedRAMP package, contract clauses, SRM | 10 business days | FedRAMP not available; CUI stored outside authorized boundary | | **Public web app** | WAF; DDoS protection; TLS 1.3; authenticated scan coverage; external pen test before go-live | WAF config, TLS scan, pen test report | 5 business days | App handles authentication; app stores Restricted data; app is customer-facing Tier 1 | | **Internal API** | mTLS or API gateway auth; rate limiting; input validation; logging to SIEM | API gateway config, SIEM source verification | 3 business days | API is Internet-facing; API handles payments; API accesses crown-jewel data | | **Vendor remote access** | PAM-brokered only per [STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md); session recording; named accounts; kill-switch tested; no standing access | PAM config, session logs, kill-switch test record | 5 business days | Vendor requires standing access; vendor is OT/ICS; vendor accesses BES Cyber Systems | | **MSP privileged access** | Full MSP hard requirements per [TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) §6.2: PAM, named accounts, no global admin, customer-owned logs, break-glass, kill-switch | All eight MSP requirement verifications | 10 business days | Any MSP requirement cannot be met; MSP is primary IT operations provider | | **OT remote maintenance** | Engineering-controlled remote access; session recording; operational sign-off per maintenance window; CIP-007 alignment | Access log, session record, operational approval | Per maintenance window | Vendor requires always-on connection; BES Cyber System without CIP overlay | | **AI assistant with internal data** | Data classification verified; AI acceptable use policy acknowledged; prompt injection mitigations; data egress monitored per [STD-AI-001](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | AI policy acknowledgment, DLP configuration, data classification | 3 business days | AI tool ingests Restricted/CUI data; AI tool is customer-facing; model training on org data | | **CI/CD integration** | Pipeline access control; secrets management; signed commits; SBOM generation; build-time SCA/SAST | Pipeline config, secret store audit, SBOM, scan results | 3 business days | Integration touches production deployment; integration has external contributors | | **Cloud workload with Internet ingress** | WAF or cloud-native equivalent; TLS 1.3; DDoS protection; authenticated external scan; CSPM continuous monitoring | WAF config, TLS scan, CSPM posture, external scan report | 5 business days | Workload handles authentication directly; workload is in regulated scope | **Common exceptions across patterns:** | Exception | Compensating Control | Review Path | |-----------|---------------------|-------------| | SSO not available (legacy SaaS) | IP restriction; session monitoring; quarterly access review | Governance exception workflow | | PAM not feasible (vendor tool limitation) | Session recording; named accounts; quarterly access review; kill-switch | Risk assessment + CISO approval | | Pen test cannot be completed pre-launch | Scheduled within 30 days of go-live; compensating monitoring active during gap | Governance exception with expiration | | WAF bypass required (application compatibility) | Layer-7 monitoring; IPS rule; quarterly pen test of bypass path | Engineering review + Governance exception | **Governance principle:** Pre-approved patterns reduce review time by eliminating the discovery phase. If a project fits a pattern exactly, Engineering signs off and the project proceeds. If it deviates in any material way, it escalates to the review tier specified by the deviation. Patterns are reviewed annually and updated when standards change. --- ## 15. Document Control | | | |---|---| | **Document ID** | CERG-PRC-AR-001 | | **Version** | 1.2 | | **Approved By** | CISO | | **Next Review** | Annual / on platform or process change | | **Change Log** | 1.2 - Clarified standalone intake template authority and procedure-owned closure records. 1.1 - Added Appendix A worked example. 1.0 - Initial publication. Establishes intake, review, threat-model, build-time, pre-prod, and handoff phases with the citizen-development carve-out. | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-18 | Engineering Pillar Leader | Reconciled TMPL-AR-001 as the Phase 1 front-door intake form and clarified that PRC-AR-001 owns Phase 2-5 review, handoff, and go-live risk records. | | 1.1 | 2026-06-13 | Engineering Pillar Leader | Added Appendix A worked example. | | 1.0 | 2026-05-22 | Cyber Governance | Initial publication. Establishes intake, review, threat-model, build-time, pre-prod, and handoff phases with the citizen-development carve-out. | ### Review Triggers - Change to architecture review intake, routing, or SLC tiers. - Change to the standalone intake template or procedure-owned review record structure. - Change to go-live risk acceptance authority. - Audit, assessment, or tabletop finding related to project review evidence. ### Related Documents - [`CERG-TMPL-AR-001`](../templates/CERG-TMPL-AR-001_Architecture_and_Project_Intake_Form.md) - Architecture and Project Intake Form - [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md) - Threat Modeling Procedure - [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process - [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - Third Party and Supply Chain Risk Procedure --- ## Appendix A. Worked Example: CloudApp Migration > **Purpose** > > This appendix walks a fictitious project — "CloudApp Migration" — through all five phases of the architecture review process. It shows what each artifact looks like when populated, so first-time adopters have a concrete reference. ### A.1 Scenario **Profile:** Contoso Energy Solutions, a mid-market utility ($1.2B revenue). NERC-CIP Low impact, SOX ITGC scope. **Project:** Migrate the internal billing application ("CloudApp") from on-premises to AWS. CloudApp processes customer billing data (Internal classification), interfaces with the financial ERP (SOX-scoped), and exposes a REST API to an external collections vendor. **Team:** 1 Cloud Security Engineer (reviewer), 1 Risk Analyst (threat model), 1 Governance Pillar Leader (SOX overlay), 1 Project Technical Lead, 1 Business Owner (CFO designee). ### A.2 Completed Intake Form (Phase 1) ``` SECURITY PROJECT INTAKE - AR-2026-0001 A. PROJECT IDENTITY Project Name : CloudApp Migration to AWS Sponsor (named role) : CFO Designee (Business Owner) Technical Lead : Sr. Cloud Engineer, IT Operations Business Outcome : Reduce datacenter footprint, enable auto-scaling Target Production Date : 2026-09-30 B. SCOPE Data Classifications Handled : Internal (billing records) Regulatory Scope : SOX (via ERP integration) Operating Units Impacted : Finance, IT Operations Environments : Cloud (AWS) Geographies : US only Trust Boundaries Crossed : Network (on-prem to cloud), Identity (IdP federation), Organization (vendor API) C. TECHNOLOGY New SaaS introduced? : Y - Twilio SendGrid (transactional email vendor) - tier assessment needed New cloud account/sub/proj? : Y - new AWS production account New OT touch / IT/OT bridge? : N New external connection? : Y - collections vendor API (Tier 2 per TPRM) New identity / federation? : Y - AWS IAM Identity Center federation with Azure AD D. THIRD PARTIES Vendors involved : AWS, Twilio SendGrid, Collections Vendor (ABC Collect Inc.) Vendor tier (per TPRM) : AWS = Tier 1, SendGrid = Tier 2, ABC Collect = Tier 2 International access? : N E. CHANGE CONTEXT New build / migrate / retire / extend : Migrate + Extend (vendor API integration is new) Existing CERG-tracked asset IDs : On-prem billing server (ASSET-00101) F. INITIAL SECURITY CONCERNS (from project team) What worries us most : SOX evidence continuity during migration; vendor API authentication What we know is unresolved : ERP integration will use a private link; encryption cert renewal timeline G. ASKS What CERG help do we need at design stage? : VPC design review, identity federation pattern, SOX evidence requirements ``` ### A.3 Scope Determination Output | **Field** | **Determination** | |---|---| | Review Path | **Mandatory** — new cloud account, external connection, SOX scope | | Overlay Reviewers | SOX ITGC Lead (ERP integration), Vendor Risk Analyst (SendGrid + ABC Collect) | | Threat Modeling Required | Yes | | TPRM Engagement Required | Yes — SendGrid (Tier 2) and ABC Collect (Tier 2) need assessment | | SLC Tier | Tier 2 (standard urgency, non-regulated project with SOX adjacency) | | Estimated Effort | Phase 2: 7 business days; Phase 4: 5 business days | ### A.4 Architecture Review Record (Phase 2) **Status:** Approved-with-Conditions | **Finding ID** | **Area** | **Finding** | **Severity** | **Disposition** | |---|---|---|---|---| | AR-2026-0001-F01 | Identity | AWS IAM Role for ERP integration grants full DynamoDB access instead of least-privilege per table | High | Fix before go-live: scope IAM policy to specific DynamoDB tables | | AR-2026-0001-F02 | Network | VPC flow logs enabled but not shipped to SIEM; retention set to 7 days instead of 365 | High | Fix before go-live: configure VPC flow log delivery to SIEM; set retention to 365 days | | AR-2026-0001-F03 | Logging | Application logs write to CloudWatch with 14-day retention; no forwarding to central SIEM | Medium | Fix within 30 days of go-live: configure CloudWatch subscription filter to SIEM; extend retention to 1 year | | AR-2026-0001-F04 | Cryptography | KMS key for RDS encryption uses automatic key rotation but no CMK; key material is AWS-managed | Medium | Accept with condition: document SOX-relevant controls to confirm CMK not required; reassess at SOX evidence cycle | | AR-2026-0001-F05 | Third Party | SendGrid API key stored in application config file, not secrets manager | High | Fix before go-live: migrate to AWS Secrets Manager with automatic rotation | **Conditions for Phase 2 approval:** - High findings (F01, F02, F05) must be remediated before Phase 4 pre-production review - Medium findings (F03, F04) must have treatment plan with owner and target date by go-live ### A.5 Threat Model Record (Phase 2) ``` THREAT MODEL - CloudApp Migration AR-2026-0001 - TM-001 1. ASSETS AND DATA - Customer billing records (Internal classification) - ERP financial transaction data (SOX-scoped) - AWS IAM roles, KMS keys, CloudTrail audit logs 2. ACTORS AND ENTRY POINTS - Internal users (Finance team) via Azure AD SSO - Collections vendor (ABC Collect) via REST API + API key - AWS managed services (RDS, DynamoDB, S3) - provider trust model 3. TRUST BOUNDARIES - On-premises Azure AD <-> AWS IAM Identity Center (identity boundary) - AWS VPC <-> On-premises ERP via AWS PrivateLink (network boundary) - CloudApp API <-> ABC Collect (external organizational boundary) 4. THREATS BY BOUNDARY Identity Boundary: [Spoofing] Compromised Azure AD account could assume AWS role -> Control: Conditional Access MFA, JIT elevation via PAM Network Boundary: [Tampering] Man-in-the-middle on PrivateLink connection -> Control: TLS 1.2 minimum, mutual TLS for ERP integration External Boundary: [Info Disclosure] ABC Collect API key leak could expose billing data -> Control: API key in Secrets Manager, IP whitelisting, rate limiting 5. EXISTING CONTROLS - Azure AD MFA for all internal users - AWS CloudTrail enabled across all accounts - AWS Config rules for baseline drift detection - VPCs with default-deny routing, limited egress 6. RESIDUAL RISKS (to risk register) - TM-R01: Vendor API compromise could allow data exfiltration [Medium] - TM-R02: SOX evidence chain depends on CloudTrail integrity [Low] 7. ATTACK SIMULATION CANDIDATES - Purple team: "Assume API key compromised — can attacker pivot to cloud control plane?" ``` ### A.6 Pre-Production Security Review (Phase 4) **Disposition:** Ready-with-Risk-Acceptance | **Check** | **Result** | **Evidence** | |---|---|---| | DISH baseline applied | Pass — AWS account scans at DISH Enhanced tier; no Critical/High deviations | DISH scan AR-2026-0001-001 | | Exposure posture | 2 Medium findings open (both accepted with risk register entries) | Exposure pipeline report | | Identity wired | SSO + MFA enforced; AWS IAM Identity Center synced from Azure AD; PAM not required for this asset class | IdP policy export | | Logging | CloudTrail + VPC Flow Logs + CloudWatch shipped to SIEM; retention 365 days | SIEM source inventory | | Detection | CloudApp added to detection coverage: GuardDuty + Security Hub + custom CIS rules | Detection coverage report | | Cryptography | TLS 1.2 minimum on ALB; KMS with automatic key rotation; Secrets Manager for all secrets | TLS scan, KMS key config | | Resilience | RTO 4h / RPO 1h via multi-AZ RDS; restoration test scheduled for Day +14 post-go-live | Backup config, resilience register | | Vendor / TPRM | AWS Tier 1 evidence current; SendGrid Tier 2 assessment complete — SOC 2 accepted with CUEC mapping; ABC Collect assessment in progress — conditional acceptance granted with 90-day re-review | TPRM tool entries | | SOX overlay artifacts | ERP integration controls mapped to ITGC CM-2, CM-3, CM-4; compensating control memo for KMS key type accepted by SOX ITGC Lead | SOX control mapping | | Phase 2 conditions cleared | F01 (IAM scoping) resolved — IAM policy updated; F02 (flow logs) resolved — SIEM delivery confirmed; F05 (Secrets Manager) resolved — SendGrid key migrated; F03 (logging retention) on track for 30-day target | Phase 2 record annotations | | Asset inventory | CloudApp added as ASSET-00201 (AWS): owner = IT Operations, tier = Production Tier 2, SOX scope = yes | Asset inventory | ### A.7 Production Handoff Summary (Phase 5) | **Section** | **Status** | |---|---| | System Identity | ASSET-00201 — CloudApp (AWS); Tier: Production Tier 2; Owner: IT Operations; Regulatory: SOX | | Review Records | Intake AR-2026-0001, Architecture Review AR-2026-0001-F01–F05, Threat Model TM-001, Pre-Production Record PP-2026-0001 | | Control Posture | 30 controls Implemented, 2 Partial (logging retention, vendor assessment), 1 Risk Accepted (KMS key type) | | Evidence Pointers | DISH scan, SIEM source list, Secrets Manager audit, Backup config, CloudTrail integrity verification | | Risk Acceptances | RA-2026-0001 (KMS key type — expiration 2027-06-30); RA-2026-0002 (SendGrid assessment conditional — re-review 2026-12-31) | | Ongoing Controls | Weekly exposure scan, monthly access review, quarterly SOX control evidence refresh, annual pen test | | Run-book | Confluence link: RUN-CloudApp-001; On-call: IT Ops rotation via PagerDuty | | Sign-offs | Engineering Reviewer: Cloud Security Engineer; Risk Reviewer: Risk Analyst; Governance (SOX): SOX ITGC Lead; Engineering Pillar Leader; CISO (KMS risk acceptance); Business Owner: CFO Designee | ### A.8 Key Takeaways for First-Time Adopters 1. **Start early.** The intake form surfaced the SOX evidence concern on day one, which gave Governance time to map controls before go-live. 2. **Threat modeling changed the design.** The vendor API risk (TM-R01) prompted adding IP whitelisting and rate limiting that were not in the original architecture. 3. **Pre-approved patterns reduce Phase 2 time.** The AWS VPC landing-zone pattern was pre-approved; the team skipped the VPC design review and focused on application-layer controls. 4. **Risk acceptance is not failure.** The KMS key type acceptance was a deliberate decision after documented analysis — SOX auditibility was preserved via compensating controls. 5. **Evidence continuity from day one.** CloudTrail was configured before the first workload deployment, ensuring no gap in SOX evidence during migration. --- ## AUDIT AND EVIDENCE MANAGEMENT PROCEDURE ### Evidence Library · Control Testing · Audit Intake · Auditor Response · Finding Tracking --- | | | |---|---| | **Document ID** | CERG-PRC-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) · [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-GOV-CMX-001`](../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) · [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) · [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) · [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) · [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | | **Review Cycle** | Annual / After major audit, assessor, or regulator feedback | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CA, PM, AU) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · ISO/IEC 27001 A.5, A.8 · CIS Controls v8 | | **Regulations** | CMMC L2 / 800-171r3 · NERC-CIP · SOX ITGC · privacy and contractual audit obligations where applicable | | **Environments** | All CERG-managed control evidence, audits, assessments, and regulator or customer requests | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Evidence Library Structure](#3-evidence-library-structure) 4. [Evidence Types and Quality Bar](#4-evidence-types-and-quality-bar) 5. [Evidence Collection Cadence](#5-evidence-collection-cadence) 6. [Control Testing](#6-control-testing) 7. [Audit Intake and Response](#7-audit-intake-and-response) 8. [Findings and Corrective Actions](#8-findings-and-corrective-actions) 9. [Metrics](#9-metrics) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope The README assigns audit response and control evidence to Cyber Governance. The Unified Control Baseline names evidence for controls. The compliance matrix maps intent to frameworks. The operational packages for CUI, NERC-CIP, and SOX depend on durable evidence. What was missing was the operating procedure that tells the organization how evidence is collected, stored, tested, produced to auditors, and tracked when it fails. This procedure provides that machinery. This procedure governs CERG's evidence library, control-testing cadence, audit intake, evidence production, auditor response, and finding tracking. It applies to every control framework CERG supports and to every audit, assessor request, regulator request, customer security review, and internal control test that depends on CERG evidence. `CERG-GOV-AUD-001` governs evidence quality, freshness, and sampling expectations. This procedure governs the operational workflow for collecting, storing, testing, producing, and correcting evidence. Where this procedure needs to judge whether evidence is acceptable, `CERG-GOV-AUD-001` governs. > **Evidence Is Produced by Running the Program** > > CERG does not create evidence by staging screenshots the week before an audit. Evidence is the exhaust of a working program: access reviews completed on schedule, vulnerabilities remediated or accepted, backups tested, keys rotated, risks reviewed, exceptions approved, controls measured. A program that runs well produces evidence naturally. A program that does not run well produces scramble folders. --- ## 2. Principles 1. **Evidence is collected continuously.** Audit readiness is a steady-state operating condition, not a seasonal project. 2. **Evidence maps to controls.** Every retained evidence item maps to at least one control, framework requirement, or audit request. 3. **Evidence is attributable.** Evidence shows who produced it, when, from what system or process, and what period it covers. 4. **Evidence is reproducible.** A reasonable reviewer can understand how the evidence was produced and, where possible, reproduce it. 5. **Evidence is protected.** Evidence often contains sensitive configuration, user, asset, or vulnerability data. It is classified and handled under [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). 6. **One evidence item can serve many frameworks.** The same access-review record can support CMMC, SOX, ISO, and NIST. CERG collects once and maps many times. --- ## 3. Evidence Library Structure The Evidence Librarian maintains the evidence library. The exact platform may vary by adopting organization, but the structure is fixed. ```text /evidence /control-baseline / / /frameworks /cmmc /nerc-cip /sox-itgc /iso-27001 /audits / /requests /responses /submitted /findings /metrics /exceptions /attestations ``` The control-baseline view is the source view. Framework views may link to or reference the same evidence. The audit view contains exactly what was requested, what was submitted, when, and by whom. > **Collect Once, Map Many Times** > > The control does not care which auditor asked the question. Access reviews, backup tests, vulnerability remediation, and risk reviews are real control activity. CERG stores evidence by control first, then maps it to CMMC, NERC-CIP, SOX, ISO, customer questionnaires, or internal audit. That prevents duplicate collection and prevents different audit teams from getting different versions of the truth. --- ## 4. Evidence Types and Quality Bar ### 4.1 Evidence Types | **Type** | **Examples** | |---|---| | System-generated records | Export from identity provider, vulnerability platform, backup system, ticketing system, CI/CD platform, cloud control plane. | | Approved artifacts | Policies, standards, procedures, plans, risk acceptances, exceptions, architecture reviews. | | Review records | Access reviews, risk reviews, vendor reviews, control tests, change approvals. | | Attestations | Signed owner confirmations where system evidence is not available. | | Meeting records | Agendas, minutes, decision logs, oversight briefings. | | Test results | Backup restore test, disaster recovery test, control test, adversarial validation, configuration validation. | ### 4.2 Quality Bar Evidence quality is governed by [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md). Operationally, evidence is acceptable only if it is complete enough to support the control claim. At minimum it shows: - what control or request it supports; - what period it covers; - source system or process; - date generated or approved; - owner or approver; - scope, including included and excluded systems; - result, decision, or conclusion; - any exceptions or limitations. A screenshot without date, scope, and source is weak evidence. A spreadsheet with no source and no owner is weak evidence. A ticket with approval, scope, timestamp, and closure is usually stronger than a polished narrative. ### 4.3 Evidence Retention Evidence is retained according to the following schedule. Retention periods are driven by the most stringent applicable regulatory requirement for that evidence type. | **Evidence Type** | **Minimum Retention** | **Regulatory Driver** | **Disposition After Retention** | |---|---|---|---| | SOX ITGC evidence (access reviews, change approvals, control tests) | 7 years | SOX (SEC 17 CFR 210.2-06) | Secure deletion; certificate of destruction | | CMMC / NIST 800-171 assessment evidence | 3 years | CMMC (32 CFR 170); DFARS 252.204-7012 | Secure deletion | | NERC-CIP compliance evidence | 3–5 years (audit cycle + 1) | NERC-CIP (CIP-003 R2); NERC Rules of Procedure | Secure deletion | | General control evidence (non-regulated) | 3 years | ISO 27001, organizational policy | Secure deletion | | Incident response evidence | 7 years or duration of legal hold | Litigation hold; breach notification statutes | Secure deletion after legal hold release | | Risk register history | Permanently (append-only) | NIST RMF; organizational policy | Not disposed; append-only audit trail | #### Disposal Process 1. **Trigger**: Evidence retention period expired, system decommissioned, or legal hold released. 2. **Authorization**: Evidence Librarian confirms no active audit, investigation, or legal hold referencing the evidence. Governance Pillar Leader authorizes disposal. 3. **Disposal Method**: Evidence is securely deleted using methods appropriate to the storage medium (cryptographic erasure for cloud storage, secure overwrite for on-premises, physical destruction for removable media). A certificate of destruction is produced and retained. 4. **Logging**: Disposal is recorded in the evidence library audit log including: evidence ID, disposal date, authorizing party, method, and certificate of destruction reference. > **Legal Hold Supersedes Retention Schedule** > > When a legal hold is in effect, evidence subject to the hold is preserved regardless of the retention schedule. The Evidence Librarian coordinates with Legal to identify and preserve evidence subject to hold, and disposal is suspended until Legal releases the hold in writing. ### 4.4 Evidence Integrity and Chain of Custody Evidence must be protected from tampering, loss, or unauthorized modification throughout its lifecycle. The integrity of evidence is foundational to audit credibility and, in some cases, legal defensibility. #### Integrity Controls | **Control** | **Requirement** | **Implementation** | |---|---|---| | Checksums / hashes | Every evidence artifact is hashed (SHA-256 minimum) at ingestion | Evidence library computes and stores hash at upload; hash is verified on retrieval | | Write-once / append-only storage | Evidence, once ingested, cannot be modified | Evidence library implements immutable storage or legal-hold policies on the underlying storage platform | | Tamper detection | Any modification or hash mismatch generates an alert | Evidence library compares stored hash against current hash on access; mismatches trigger Evidence Librarian and Governance investigation | | Access logging | Every access to evidence (read, copy, export) is logged | Evidence library records: who, what, when, source IP, and purpose | | Retention of original format | Evidence is retained in its original format; exports or transforms are stored alongside, not replacing, the original | Evidence library preserves original file; derived views (PDF exports, screenshots) are linked as supplementary | #### Chain of Custody | **Event** | **Documentation Required** | |---|---| | Ingestion | Evidence ID, source system, date ingested, hash, ingested by, control(s) supported | | Access / retrieval | Evidence ID, accessed by, date, purpose (audit response, control test, investigation) | | Transfer (to auditor, assessor, legal) | Evidence ID(s), recipient, date transferred, transfer method, hash verification at transfer | | Return / re-ingestion | Evidence ID(s), returned by, date, hash verified against original | | Disposal | Evidence ID, date, method, authorized by, certificate reference | --- ## 5. Evidence Collection Cadence Evidence cadence follows the control's operating cadence. Evidence is not all collected at year-end. | **Cadence** | **Examples** | **Owner** | |---|---|---| | Continuous or event-driven | Change approvals, exposure findings, risk entries, security exceptions, incidents handed off to IR. | Process owner. | | Monthly | Exposure posture, risk register review, key metrics, backup-job review where applicable. | Relevant pillar owner. | | Quarterly | Access reviews, control owner attestations, metric package, evidence completeness review. | Evidence Librarian with control owners. | | Semiannual | Disaster recovery or restore tests where applicable, privileged-access review if not quarterly. | Relevant Engineering owner. | | Annual | Policy and standard review, risk assessment, operational package refresh, major control test. | Governance Pillar Leader. | The Evidence Librarian maintains the evidence calendar and follows up with owners before due dates. --- ## 6. Control Testing Control testing confirms that a control is not only documented but operating. ### 6.1 Test Plan Each test plan records: - control or requirement tested; - population and sample method, if sampling is used; - period under review; - evidence used; - expected result; - test steps; - tester; - result; - exceptions and corrective actions. ### 6.2 Sampling Methodology Sampling for control testing follows the canonical sampling standard in [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) §5. This procedure does not maintain a separate sample-size table. The control test plan records: - population definition and size; - sampling method and rationale; - sample size and how it was determined; - selected items, including random seed or selection tool where random sampling is used; - test results per sampled item; - exceptions, substitutions, or untestable items; - regulatory, assessor, or auditor-specific sampling requirements that override the CERG default; - limitations or caveats. If a regulator, assessor, auditor, or framework-specific operational package requires a different sampling method for an engagement, the engagement-specific requirement governs and the rationale is recorded in the test plan. ### 6.3 Testing Outcomes | **Outcome** | **Meaning** | |---|---| | Effective | Evidence supports that the control operated as designed. | | Effective with observation | Control operated, but improvement is warranted. | | Deficient | Control did not operate as designed or evidence is insufficient. | | Not tested | Test could not be completed; reason and next step required. | Deficient controls create corrective actions under Section 8. A repeated evidence failure is treated as a control failure, not an administrative miss. --- ## 7. Audit Intake and Response ### 7.1 Intake Every audit, assessor, regulator, customer, or internal evidence request enters through Governance and is recorded in the audit intake log. Minimum intake fields: | **Field** | **Purpose** | |---|---| | Request name and source | Identifies the audit or request. | | Framework or obligation | CMMC, NERC-CIP, SOX, customer, internal audit, other. | | Due date and priority | Drives response planning. | | Requested evidence | Exact request text. | | Scope | Systems, controls, period, environment. | | Owner | Governance role accountable for response. | | Producing roles | Engineering, Risk, or Governance roles that must supply evidence. | | Submission status | Open, in review, submitted, accepted, rejected, closed. | ### 7.2 Response Rules 1. **Answer the request asked.** Do not over-produce. Extra evidence creates extra review surface. 2. **Submit through Governance.** Evidence leaves the library through Governance so the organization knows what was provided. 3. **Preserve the submitted set.** The exact package submitted is retained in the audit view, including date and submitter. 4. **Do not alter evidence to satisfy a request.** If the evidence is weak, record the weakness. Manufacturing better-looking evidence is a governance failure. 5. **Escalate ambiguous or broad requests.** Requests with unclear scope or excessive breadth are clarified before production. > **Do Not Feed the Audit Monster** > > Auditors and assessors need evidence, not a data dump. Over-sharing wastes time, creates contradictions, and invites questions that were never in scope. CERG responds precisely: the requested control, the requested period, the requested population, the evidence that proves it, and nothing theatrical. Discipline in evidence production is a security control and a legal hygiene practice. --- ## 8. Findings and Corrective Actions Audit findings, control-test deficiencies, rejected evidence, and repeated evidence misses are tracked to closure. | **Finding Type** | **Tracking Path** | |---|---| | Control deficiency | Corrective action plan owned by the control owner; risk register entry where residual risk remains. | | Evidence deficiency | Evidence Librarian opens corrective action with the producing owner. | | Policy or standard gap | Policy & Standards Manager opens document update action. | | Technical control gap | Relevant Engineering or Risk owner opens remediation action. | | Accepted residual risk | Risk Register Owner tracks through [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | A corrective action records owner, due date, remediation plan, verification method, and closure evidence. Closure requires evidence that the condition was corrected, not merely a statement that it was. --- ### 8.1 Plan of Action and Milestones (POA&M) A Plan of Action and Milestones (POA&M) is the formal artifact for tracking and resolving control deficiencies, particularly those affecting CMMC assessment posture. POA&M requirements derive from NIST 800-171 and CMMC assessment guidance. #### When a POA&M Is Required A POA&M entry is required for: - Any CMMC assessment finding (regardless of score impact) - Any control rated "Deficient" in a control test affecting a CUI environment - Any control gap identified during a formal CMMC assessment, self-assessment, or pre-assessment - Any finding from a regulator, customer, or internal audit that maps to a CMMC practice - Significant findings (Critical or High) in non-CMMC environments, at the CISO's direction #### POA&M Required Fields | **Field** | **Description** | |---|---| | POA&M ID | Unique identifier (POAM-YYYY-NNNN) | | Weakness Description | Clear description of the control deficiency or finding | | Affected CMMC Practice(s) | Reference to specific CMMC practices (e.g., AC.L2-3.1.1) | | Severity | Finding severity (Critical / High / Medium / Low) | | Remediation Plan | Specific actions to close the deficiency, with milestones | | Milestones | Discrete, measurable steps with target dates | | Responsible Party | Named individual accountable for each milestone | | Resources Required | Funding, staffing, tooling, or external support needed | | Scheduled Completion Date | Target date for full remediation | | Actual Completion Date | Date the deficiency was resolved | | Status | Open / In Progress / Completed / Deferred | | Disposition | How the finding was resolved (remediated, risk-accepted, control changed) | | Evidence of Closure | Reference to evidence demonstrating the deficiency is resolved | | Last Updated | Date of most recent status update | #### POA&M Tracking and Status Updates - POA&M entries are reviewed monthly by the CMMC / Federal Compliance Manager - Status updates are recorded in the POA&M at each milestone or at minimum quarterly - Overdue milestones are escalated to the Governance Pillar Leader - The CISO reviews the full POA&M at the quarterly CISO-level risk review #### POA&M Closure Criteria A POA&M entry may be closed when: 1. The deficiency has been remediated and closure evidence is on file, OR 2. The deficiency has been formally risk-accepted through [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) with CISO approval, OR 3. The affected system has been decommissioned and the deficiency is no longer applicable Closure requires sign-off by the CMMC / Federal Compliance Manager and the Governance Pillar Leader. Closure evidence is retained in the evidence library per Section 4.3. --- ## 9. Metrics Audit and evidence metrics are reported through [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md). | **Metric** | **Purpose** | |---|---| | Evidence completeness by control | Shows which controls are audit-ready. | | Evidence items overdue | Shows collection discipline. | | Audit requests open by due date | Shows response workload and urgency. | | Evidence rejected or returned for rework | Shows evidence quality. | | Control tests completed on schedule | Shows testing discipline. | | Deficient controls by severity and age | Shows unresolved control exposure. | | Corrective actions closed on time | Shows follow-through. | | Repeat findings | Shows whether the program learns. | --- ## 10. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Audit and Evidence Responsibility** | |---|---| | **Governance Pillar Leader** | Accountable for this procedure, audit response, compliance posture, and CISO reporting. | | **Evidence Librarian** | Operates the evidence library, evidence calendar, evidence completeness review, and submitted-package archive. | | **Policy & Standards Manager** | Maintains evidence-related document updates and ensures catalog and artifact references remain current. | | **CMMC / Federal Compliance Manager** | Leads CMMC and CUI evidence mapping and assessor response. | | **NERC-CIP Compliance Manager** | Leads NERC-CIP evidence mapping and audit response. | | **SOX ITGC Lead** | Leads SOX ITGC evidence mapping, control testing coordination, and audit response. | | **Risk Register Owner** | Records residual risks and accepted exceptions arising from audit findings or evidence deficiencies. | | **Engineering Pillar Leader** | Ensures Engineering control evidence is produced and corrected when deficient. | | **Risk Pillar Leader** | Ensures Risk control evidence is produced and corrected when deficient. | | **Chief Information Security Officer (CISO)** | Receives material audit findings, posture reporting, and escalations. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Procedure** | |---|---|---| | NIST 800-53r5 | CA, PM, AU families | Sections 3, 4, 6, 8 | | NIST CSF 2.0 | GOVERN function | Sections 5, 7, 9 | | ISO/IEC 27001 | A.5 and A.8 evidence and control operation | Sections 3, 6, 8 | | CMMC L2 / NIST 800-171r3 | Evidence for assessment and POA&M support | Sections 3, 7, 8 | | NERC-CIP | Compliance evidence, audit response, and finding closure | Sections 3, 7, 8 | | SOX ITGC | ITGC control evidence and testing | Sections 5, 6, 7 | | CIS Controls v8 | Control implementation evidence | Sections 3, 6 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and after major audit, assessor, or regulator feedback | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-53r5 (CA, PM, AU); NIST CSF 2.0 (GOVERN); ISO/IEC 27001 A.5 and A.8; CIS Controls v8 | | **Regulations** | CMMC L2 / 800-171r3; NERC-CIP; SOX ITGC; privacy and contractual audit obligations where applicable | | **Environments** | All CERG-managed control evidence, audits, assessments, and regulator or customer requests | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes the evidence library structure, evidence quality bar, collection cadence, control testing outcomes, audit intake and response rules, finding and corrective-action tracking, metrics, and canonical role responsibilities for audit and evidence management. | ### Review Triggers - Major audit, assessor, regulator, or customer evidence feedback - Significant evidence rejection or repeated finding - Change to CERG operational packages or control baseline - New framework or regulatory evidence obligation - Direction from the CISO Cyber Governance owns this document. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Evidence Quality Standard | [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | Authoritative evidence quality, freshness, and sampling standard | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control and evidence source | | Compliance Matrix | [`CERG-GOV-CMX-001`](../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) | Cross-framework mapping | | Metrics and Reporting | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Audit and evidence metrics reporting | | Consolidated Roles, Responsibilities, and RACI Instrument | [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Role accountability reference | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Residual risk and exception tracking | | CUI / CMMC Operational Package | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | CMMC evidence mapping | | NERC-CIP Operational Package | [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) | NERC-CIP evidence mapping | | SOX ITGC Operational Package | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | SOX evidence mapping | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `AUD` domain | --- ## EXPOSURE MANAGEMENT PROCEDURE ### From Scanner Observation to Managed Risk · Six-Step Model · Patch Hygiene --- | | | |---|---| | **Document ID** | CERG-PRC-VM-001 | | **Version** | 2.02 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Exposure Management Lead | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | | **Review Cycle** | Annual / Upon Significant Change / Major Tooling Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · NIST 800-40r4 · NIST RMF | | **Regulations** | NERC-CIP CIP-007 R2 · CMMC RA.L2 · SOX ITGC | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT | --- ## Table of Contents 1. [Purpose and Philosophy](#1-purpose-and-philosophy) 2. [The Exposure State Model](#2-the-exposure-state-model) 3. [Roles and Responsibilities](#3-roles-and-responsibilities) 4. [Step 1 — Collect Observations](#4-step-1--collect-observations) 5. [Step 2 — Validate Asset and Condition](#5-step-2--validate-asset-and-condition) 6. [Step 3 — Validate Exposure Path](#6-step-3--validate-exposure-path) 7. [Step 4 — Classify](#7-step-4--classify) 8. [Step 5 — Select Treatment](#8-step-5--select-treatment) 9. [Step 6 — Verify Closure](#9-step-6--verify-closure) 10. [Patch Hygiene](#10-patch-hygiene) 11. [Risk Acceptance and Exceptions](#11-risk-acceptance-and-exceptions) 12. [Adversarial Validation](#12-adversarial-validation) 13. [Reporting and Metrics](#13-reporting-and-metrics) 14. [Regulatory and Framework Alignment](#14-regulatory-and-framework-alignment-summary) 15. [Procedure Control](#15-procedure-control) --- ## 1. Purpose and Philosophy This procedure establishes CERG's exposure management program — the discipline of understanding which weaknesses actually threaten the organization, not which ones a scanner reports. ### 1.1 The Operating Premise > **A scanner report is inventory data. It is not the exposure management program.** > > CERG does not measure its security posture by how many vulnerabilities a scanner finds. It measures posture by confirmed reachable exposure, by how quickly observations are triaged into decisions, and by whether treatment actually closes the exposure path. A program that reduces total findings while leaving Internet-exposed critical exposures open is not improving — it is reorganizing failure. This procedure operationalizes Principle 5 of [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) through a fundamentally different lens than traditional scanner-driven vulnerability programs. The program does not start with "scan, score, SLA, patch/accept." It starts with the observation that most scanner output is noise, and the signal worth acting on is confirmed reachable exposure. ### 1.2 What This Procedure Replaces This is version 2.0 of `CERG-PRC-VM-001`. The move to Exposure Management is deliberate. The core model has shifted from: | Old Model | New Model | |-----------|-----------| | Scan → Score → SLA → Patch/Accept | Collect observations → Validate exposure → Classify → Treat → Verify | | CVSS bands drive priority | Exposure path + asset criticality + KEV drive priority | | "Critical" means CVSS ≥ 9.0 | "Material risk" means confirmed reachable exposure on a crown jewel | | Patching is the default treatment | Treatment is selected from remove/block/config/patch/compensate/redesign/accept/transfer | | Scanner report = vulnerability program | Scanner report = input signal requiring triage | ### 1.3 Scope This procedure governs all in-scope assets: enterprise IT, cloud, SaaS, OT, CUI environments. Environment-specific overlays implement operational-safety adaptations for OT and evidence requirements for regulated environments. --- ## 2. The Exposure State Model Every observation moves through a defined state pipeline. Progress between states is gated by explicit validation, not by elapsed time. ### 2.1 State Definitions | State | Definition | Example | |-------|-----------|---------| | **Observed** | A tool-reported condition. No validation has occurred. | Scanner reports Apache CVE-2024-XXXX, CVSS 9.9, on host `web-07`. | | **Validated** | The asset is confirmed real, in scope, and the affected software is present. | Host `web-07` is in inventory. Apache 2.4.51 is installed. | | **Reachability Assessed** | The exposure path has been evaluated: is the service running? Reachable? Authenticated? Segmented? | Apache on `web-07` listens on port 8080, which is blocked at the firewall; only accessible from internal admin subnet. | | **Exposure Confirmed** | A reachable, useful exploitation path exists. | The service is Internet-reachable, no WAF, authenticated API endpoint with known bypass. | | **Treatment Selected** | A specific treatment has been chosen and assigned. | Engineering will apply patch ASF-2024-03 within 48 hours. | | **Closure Verified** | The treatment has been applied and independently verified. | Re-scan confirms Apache 2.4.52. Reachability test confirms path closed. | ### 2.2 The Apache Example > A CVSS 9.9 Apache finding on a host where Apache is not running, ports 80/443 are blocked, and no reachable service path exists is not a material vulnerability. It is a scanner observation until exposure is confirmed. > > A scanner can be technically correct — Apache 2.4.51 is installed, and CVE-2024-XXXX applies to that version — and still not identify exploitable exposure. The word "false positive" is the wrong bucket for many of these cases. The scanner was right about the software version. It was wrong about the risk. > > Use states, not a binary "real/false" toggle. ### 2.3 The "False Positive" Problem A finding classed as a "false positive" in a traditional VM program may actually be: | Reality | Traditional Label | CERG State | |---------|------------------|------------| | Software present, not running | False positive | Validated, not reachable | | Software present, blocked at firewall | False positive | Validated, reachability assessed — not exposed | | Software present, compensating control prevents exploitation | False positive | Validated, reachable — compensated | | Scanner version-only match, fix backported | False positive | Scanner artifact — non-issue | | Feature not in use | False positive | Validated, not applicable | Each of these has different operational and audit implications. Collapsing them all into "false positive" loses the signal that distinguishes "this is fine" from "this isn't fine but we have a control." --- ## 3. Roles and Responsibilities | Role | Exposure Management Responsibility | |------|-----------------------------------| | **Exposure Management Lead** | Owns this procedure. Operates observation collection, triage, classification, and tracking. Publishes exposure posture. Drives treatment cadence. Owns SLAs. | | **Engineering Pillar Leader** | Implements treatments on assets it owns or supports. Defines secure configuration baselines. Provides architectural guidance for compensating controls. | | **System / Asset Owners** | Accountable for treatment of exposures on assets they own. Approve maintenance windows, accept residual risk. | | **IT / OT Operations Teams** | Execute treatment actions. Coordinate maintenance windows. Validate restoration. | | **CISO** | Approves High and Critical risk acceptances where required by the canonical RMF authority table. Reviews exposure posture on defined cadence. | --- ## 4. Step 1 — Collect Observations Observations arrive from many sources. They are aggregated into a single pipeline but are NOT called "findings" until validated. An observation is a signal that requires triage; it is not yet a fact. ### 4.1 Observation Sources | Source | Description | Owner | |--------|------------|-------| | Authenticated vulnerability scans | Network-based scans of servers, endpoints, network devices | Risk | | Container & image scans | Build-time and registry scans | Risk / Engineering | | Cloud posture (CSPM) | Cloud control-plane misconfigurations | Risk | | SaaS posture (SSPM) | Tier 1 SaaS configuration drift | Risk | | Software composition analysis (SCA) | Open-source and library vulnerabilities | Engineering / Risk | | SAST / DAST | Source-code and runtime application findings | Engineering / Risk | | OT passive monitoring | Vulnerabilities from passive OT network analysis | Risk | | Vendor advisories | Patches, fixes, bulletins | Risk | | ISAC / regulator feeds | E-ISAC, CISA, ICS-CERT | Risk | | Adversarial validation | Pen test, red-team, purple-team, cloud, OT-safe, or other authorized adversarial findings | Risk | | Bug bounty / external researcher | Responsible disclosure | Risk | | Incident-driven discovery | Vulnerabilities identified during/after incidents | Risk / Engineering | | SBOM | Vulnerabilities in third-party components | Risk | ### 4.2 Observation Intake All observations enter the pipeline with source metadata, a timestamp, and the raw severity/score reported by the tool. No SLA clock starts at this point. The clock starts at confirmation (Step 4). ### 4.3 External Reports and Supply Chain External researcher reports and supply-chain advisories follow the same pipeline. See Sections 3.1 and 3.2 of the prior version for detailed intake workflows — those processes are unchanged and remain in force as operational sub-procedures. --- ## 5. Step 2 — Validate Asset and Condition Before asking "is this dangerous," ask "is this real?" ### 5.1 Validation Criteria | Question | Owner | Action if No | |----------|-------|-------------| | Is the asset in the authoritative inventory? | Risk | Escalate to CMDB owner; observe until inventory resolved | | Is the asset in scope for exposure management? | Risk | Close as out-of-scope with rationale | | Is the reported software/service/configuration present on the asset? | Risk / Engineering | Close as scanner artifact | | Is the reported version accurate? (Check for backported fixes) | Engineering | Adjust version; re-evaluate | ### 5.2 Validation Timing | Observation Severity | Validation Required Within | |---------------------|--------------------------| | KEV-listed or actively exploited | 4 hours | | CVSS ≥ 9.0 | 24 hours | | CVSS 7.0–8.9 | 3 business days | | CVSS < 7.0 | 5 business days | --- ## 6. Step 3 — Validate Exposure Path A validated condition is not automatically an exposure. This step asks: can an attacker actually reach this? ### 6.1 Exposure Path Assessment | Question | Signals | |----------|---------| | Is the service running? | Process list, port scan, service status | | Is it reachable? | Network path from Internet, from user population, from adjacent trust zones | | Is authentication required? | Anonymous access vs. authenticated-only | | Is the asset segmented? | Network ACLs, microsegmentation, jump-host-only access | | Is there a compensating control? | WAF rule, EDR detection, IPS signature | | Is there a plausible path to data, privilege, disruption, or lateral movement? | Data classification on asset, privilege level, blast radius | ### 6.2 KEV Acceleration If the observation matches a CISA Known Exploited Vulnerabilities (KEV) entry and the asset is confirmed real, the exposure path assessment is accelerated regardless of CVSS score. A KEV entry means active exploitation exists in the wild — the assessment shifts from "is this exploitable" to "is this already being exploited against us." --- ## 7. Step 4 — Classify After validation and reachability assessment, every observation is classified into exactly one category. This classification drives treatment priority, not CVSS score. ### 7.1 Classification Taxonomy | Classification | Definition | Treatment Approach | SLA Driver | |---------------|-----------|-------------------|------------| | **Non-issue / Scanner Artifact** | The observation does not represent a real condition (backported fix, version-only match, scanner error) | Close with evidence | N/A | | **Hygiene Debt** | A real weakness exists but no reachable exposure path has been confirmed | Track; address in patch cycle | Patch hygiene cadence | | **Confirmed Flaw, Not Currently Exposed** | The flaw exists on a reachable asset but a compensating control blocks exploitation | Monitor control; plan remediation | Next maintenance window | | **Confirmed Exposure** | A reachable, exploitable path exists | Treat per SLA | Severity-tiered SLA (see §7.2) | | **Material Risk** | Confirmed exposure on a crown jewel, regulated system, or asset with Restricted data; OR active exploitation observed | Emergency treatment | PPR tier | ### 7.2 Treatment SLAs (Canonical) SLAs are measured from classification to verified closure. The SLA tier is driven by classification and exposure context, not by raw CVSS. | Classification | Context | SLA | |---------------|---------|-----| | **Material Risk — PPR** | KEV-listed, active exploitation, or crown-jewel exposure | **48 hours** (Internet-facing) / **72 hours** (internal) | | **Confirmed Exposure — Critical** | Internet-reachable, no compensating control | **3 days** | | **Confirmed Exposure — High** | Internal reachable, or Internet-reachable with limited impact | **15 days** | | **Confirmed Exposure — Medium** | Limited reachability or impact | **30 days** | | **Confirmed Flaw, Not Exposed** | Compensated or segmented | **90 days** (align with maintenance) | | **Hygiene Debt** | No confirmed exposure path | Per patch hygiene cadence (§10) | ### 7.3 Environment Overlays | Environment | Overlay | |-------------|---------| | **OT — BES Cyber Systems** | CIP-007 R2 governs (35-day evaluation cadence). Operational windowing flexibility; deviations managed per [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md). | | **OT — non-BES** | Default SLAs with ≤25% windowing flexibility. Extensions require Risk acceptance (§11). | | **CUI Environment** | SLA breaches require POA&M entry per [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md). | | **SOX-Relevant Systems** | Remediation evidence captured for ITGC. | | **Tier 1 SaaS Posture Drift** | Provider-responsible: finding stays open against provider; escalation via vendor incident channel. | ### 7.4 OT/BES Patch Deferral Routing OT patch deferral is a routing decision, not a blanket waiver from exposure treatment. Use the table below when a vendor-tested patch, operational maintenance window, safety constraint, or reliability concern prevents treatment within the governing SLA. | Scenario | Required route | Required records / evidence | Approval and review | |---|---|---|---| | **Non-BES OT, operational window needed** | Schedule treatment in the next approved OT maintenance window; preserve compensating controls until completion. | Finding Record or Exposure Backlog Item; maintenance-window date; compensating-control validation; owner attestation. | Risk Pillar Leader may approve windowing within the ≤25% flexibility. Longer deferral requires Risk Acceptance Record under RMF-001 §9.7. | | **BES Cyber System, CIP compliance unaffected** | Confirm that the deferral does not create or extend a CIP compliance gap; track treatment and evidence in the NERC-CIP evidence library. | Finding Record; BES asset identifier; CIP applicability note; compensating-control evidence; Evidence Index Entry. | CISO approval with Governance/NERC-CIP Compliance Manager concurrence; review at least every 30 days until closure. | | **BES Cyber System, CIP compliance impacted** | Initiate CIP deviation / mitigation plan in addition to the exposure record. Do not treat the risk acceptance path as a substitute for CIP deviation. | Finding Record; NERC-CIP deviation or mitigation plan; Risk Register Entry; compensating-control validation; regulatory evidence package. | CISO + NERC-CIP Compliance Manager; milestones follow the mitigation plan and any applicable regulatory deadline. | | **Emergency operational exception** | Operations may delay or alter treatment only to prevent safety, reliability, or grid disturbance. Document immediately and formalize within 24 hours. | Emergency decision log; Finding Record; operational impact rationale; post-hoc Security Exception Record or Risk Acceptance Record if residual risk continues. | CISO post-hoc approval within 24 hours; maximum 30-day review window unless converted to the BES/CIP route above. | For every OT deferral, document why a non-patch treatment (path block, segmentation, configuration change, monitoring, vendor isolation, or service removal) cannot close the exposure sooner. Deferral does not close the finding; closure requires verified treatment or a valid, reviewed risk/exception posture. --- ## 8. Step 5 — Select Treatment Treatment is chosen based on the most effective path to close confirmed exposure, not the most familiar one. Patching is one tool among many. ### 8.1 Treatment Options | Treatment | When to Use | Example | |-----------|------------|---------| | **Remove service** | The vulnerable component is not needed | Uninstall unused Apache instance | | **Block path** | The exposure is reachable but the service must stay | Firewall rule, ACL, WAF | | **Change configuration** | A config change eliminates the exposure without a patch | Disable TLS 1.0, restrict cipher suite | | **Patch / update** | A vendor fix is available and tested | Apply OS security update | | **Add compensating control** | Patching is not feasible (legacy, OT, vendor delay) | EDR rule, MFA requirement, network isolation | | **Redesign** | The architecture itself creates the exposure | Move admin interface to jump-host-only network | | **Accept residual risk** | Treatment is infeasible or disproportionate | Documented risk acceptance per §11 | | **Transfer** | The risk belongs to a vendor/partner | Contractual obligation, shared responsibility matrix | ### 8.2 Patching Is Not the Center > Patching is important. It is not the same as risk reduction. > > A program that patches everything on schedule but leaves an Internet-exposed, unauthenticated API on a crown jewel is failing. A program that cannot patch a legacy OT controller but has verified that the controller is air-gapped, monitored, and on a replacement roadmap is succeeding. > > Measure outcomes, not activity. --- ## 9. Step 6 — Verify Closure A treatment is not complete until independently verified. ### 9.1 Verification Methods | Method | When Required | |--------|--------------| | Authenticated re-scan | All Confirmed Exposures (Critical, High) | | Configuration evidence | Configuration changes, blocking rules | | Reachability test | When treatment was "block path" | | Compensating control validation | When treatment involved compensating controls | | Owner attestation | Hygiene debt resolution | ### 9.2 Verification Timing Verification must occur within 5 business days of treatment completion. Unverified treatments are treated as open exposures. A treatment that passes verification but the exposure re-appears within 90 days triggers a root-cause review. --- ## 10. Patch Hygiene Patch hygiene is a distinct discipline from exposure management. It is necessary. It is not sufficient. ### 10.1 What Patch Hygiene Is Patch hygiene keeps platforms supportable, reduces configuration drift, prevents known-weakness accumulation, and satisfies compliance requirements that mandate currency. It is a maintenance function — like oil changes for a vehicle. It prevents future problems; it does not fix today's exposures. ### 10.2 Patch Hygiene Cadence | Platform Class | Cadence | Owner | |---------------|---------|-------| | Windows Server | Monthly (Patch Tuesday + 14 days) | IT Operations | | Linux Server | Monthly | IT Operations | | Network devices | Quarterly (or vendor advisory-driven) | Network Operations | | Endpoints | Monthly (auto-update) | Endpoint Engineering | | OT — BES Cyber Systems | Per CIP-007 R2 (35-day evaluation) | OT Operations | | Cloud PaaS / managed services | Provider-managed; verify currency monthly | Cloud Engineering | ### 10.3 Patch Hygiene Metrics | Metric | Definition | |--------|-----------| | Patch currency rate | % of assets within their platform-class cadence window | | Platform end-of-support count | Assets running software past vendor end-of-support | | Hygiene debt by platform | Count of unresolved observations classified as Hygiene Debt, by platform | These are reported separately from exposure management metrics. Conflating patch hygiene with exposure reduction produces vanity metrics. --- ## 11. Risk Acceptance and Exceptions ### 11.1 Policy Exception vs. Risk Acceptance These are different things and follow different paths. | Scenario | Type | Path | |----------|------|------| | "We cannot meet password length because legacy system maxes at 12 characters" | Policy / control exception | Governance-owned exception workflow | | "The legacy system is Internet-reachable, privileged, and has weak auth" | Risk | Risk-owned residual risk analysis | | "We will isolate it, broker access, monitor sessions, and retire by Q3" | Treatment | Engineering + Risk | | "The VP of Operations accepts the residual risk until Q3" | Business risk acceptance | Business owner accepts | Governance owns the exception workflow. Risk owns residual risk analysis. Business owns the consequence. Security does not own the business consequence. ### 11.2 Risk Acceptance Process When treatment cannot meet SLA, the owning team requests risk acceptance through [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). Documentation must include: - Observation identifier, asset, environment, classification - Reason treatment is not feasible within SLA - Compensating controls in place and their verified status - Risk owner (business) and approver - Expiration date and re-evaluation triggers **PPR-tier exposures are not eligible for ordinary risk acceptance.** The only exception is OT operational windowing under §7.4. For BES Cyber Systems, the CIP deviation / mitigation route is mandatory when compliance is impacted and cannot be replaced by a generic acceptance memo. --- ## 12. Adversarial Validation Scanning identifies what is misconfigured or unpatched. Adversarial validation tests whether controls actually function under attack. Findings from adversarial engagements enter the observation pipeline at Step 1 and follow the full state model. | Activity | Cadence | Scope | |----------|---------|-------| | Internal penetration test | Annual minimum | Representative production | | External penetration test | Annual minimum | Internet-facing attack surface | | Cloud red-team / attack simulation | Annual minimum | Production cloud accounts | | Application penetration test | Pre-release + annual | Tier 1 applications | | OT adversarial assessment | Per STD-OT-001 | OT environments | | Purple-team detection validation | Quarterly minimum | Detection rule validation | --- ## 13. Reporting and Metrics ### 13.1 Exposure Management Metrics (Primary) These metrics measure exposure reduction, not scanner activity. | ID | Metric | Definition | G / A / R | |----|--------|-----------|-----------| | EM-001 | Confirmed Reachable Critical Exposure | Count of exposures in state "Exposure Confirmed" with Critical/PPR classification AND Internet-facing reachability | 0 / 1–3 / > 3 | | EM-002 | Scanner Observations Not Yet Triaged | Count of observations in "Observed" state past validation SLA | ≤ 5% / 6–15% / > 15% | | EM-003 | Observations Downgraded After Context | % of Critical/High CVSS observations reclassified to Hygiene Debt or lower after Steps 2-3 | Informational; no control target | | EM-004 | KEV with Reachable Path | Count of KEV-matched observations in "Exposure Confirmed" or "Material Risk" state | 0 / 1–5 / > 5 | | EM-005 | KEV Blocked by Verified Control | Count of KEV-matched observations classified as "Confirmed Flaw, Not Exposed" due to verified compensating controls | Watchlist; no control target | | EM-006 | Exposures on Crown Jewels | Count of confirmed exposures on crown-jewel-classified assets | 0 / 1–2 / > 2 | | EM-007 | SLA Misses with Compensating Controls | Exposures past SLA where a verified compensating control exists | ≤ 5 / 6–15 / > 15 | | EM-008 | SLA Misses with No Controls | Exposures past SLA with no compensating control | 0 / 1–3 / > 3 | | EM-009 | Median Time: Observation to Exposure Decision | Median days from observation intake to classification | ≤ 3d / 4–7d / > 7d | | EM-010 | Median Time: Exposure Decision to Treatment Decision | Median days from classification to treatment selection | ≤ 2d / 3–5d / > 5d | ### 13.2 Patch Hygiene Metrics (Secondary) | ID | Metric | Definition | G / A / R | |----|--------|-----------|-----------| | PH-001 | Patch Currency Rate | % of assets within platform-class patch cadence window | ≥ 95% / 85–95% / < 85% | | PH-002 | Hygiene Debt by Platform | Count of Hygiene Debt observations, grouped by platform class | Trend-only; no control target | | PH-003 | End-of-Support Count | Assets on software past vendor end-of-support date | 0 / 1–10 / > 10 | ### 13.3 Reporting Cadence | Report | Audience | Cadence | |--------|----------|---------| | Exposure posture — Confirmed Exposure + Material Risk, SLA status, KEV exposure | CISO + executive leadership | Monthly | | Observation triage backlog — observations awaiting validation, by age | Exposure Management Lead | Weekly | | Asset-owner treatment queue | Asset owners / Engineering managers | Weekly | | OT exposure posture | OT operations + CISO | Monthly | | CUI environment posture (POA&M support) | Governance | Monthly | | Patch hygiene dashboard | IT/OT Operations | Monthly | | Adversarial validation findings | CISO + board (annual summary) | Per engagement; annual aggregate | ### 13.4 Escalation Triggers Immediate escalation to CISO: - Active exploitation observed against an in-scope asset (auto-promotes to Material Risk — PPR) - Any PPR-tier exposure open beyond its SLA - A confirmed exposure on a BES Cyber System that risks NERC-CIP non-compliance - A confirmed exposure in a CUI environment that materially affects SSP posture - Adversarial validation finding demonstrating a successful path to Restricted-tier data or operational disruption --- ## 14. Regulatory and Framework Alignment Summary | Regulation / Framework | Where in This Procedure | |------------------------|------------------------| | NIST CSF 2.0 IDENTIFY, PROTECT, RESPOND | Steps 1–9; observation collection through verification | | NIST 800-53r5 RA-5, SI-2, SI-3, SI-4, SI-5 | Steps 4–9; discovery, prioritization, treatment, verification | | NIST 800-171r3 3.11, 3.14 | Steps 4–11; risk assessment, system integrity | | NIST 800-40r4 (Patch Management) | Section 10; patch hygiene | | NIST RMF | Steps 7–11; risk-based classification, treatment, acceptance | | NERC-CIP CIP-007 R2 | Steps 7.3, 10; OT overlay, patch evaluation | | CMMC RA.L2 | Steps 7, 11; risk assessment, acceptance | | SOX ITGC | Steps 8–9, 11; treatment, verification, acceptance | --- ## 15. Procedure Control | | | |---|---| | **Document ID** | CERG-PRC-VM-001 | | **Version** | 2.02 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Exposure Management Lead | | **Approved By** | CISO | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Semi-Annual | | **Next Scheduled Review** | 2026-12-17 | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 | | **Regulations** | NERC-CIP · CMMC L2 · SOX ITGC | | **Environments** | All in-scope environments | ### Revision History | Version | Date | Author | Change Summary | |---------|------|--------|---------------| | 2.02 | 2026-06-18 | Governance Pillar Leader | Added OT/BES patch deferral routing for non-BES OT, BES compliance-unaffected deferrals, BES compliance-impacting deviations, and emergency operational exceptions. | | 2.01 | 2026-06-14 | Governance Pillar Leader | Aligned CISO risk-acceptance role language to the canonical RMF authority table. | | 2.0 | 2026-06 | CERG Risk | Major revision: shift from exposure management to exposure management. Introduced 6-step state model (Observed→Verified), classification taxonomy (Non-issue/Hygiene Debt/Confirmed Flaw/Confirmed Exposure/Material Risk), separation of patch hygiene from exposure management, new exposure-focused metrics. | | 1.0 | 2026-05 | CERG Risk | Initial release | ### Review Triggers Annual review or upon: material tooling change, regulatory SLA change, internal audit finding, CISO direction, or significant change to asset tiering. ### Related Documents | Document | ID | Relationship | |----------|-----|-------------| | Cybersecurity Policy | CERG-POL-001 | Parent policy — Principle 5 | | Grid and Control System Standard | CERG-STD-OT-001 | OT overlays | | IT/Cloud/SaaS Security Standard | CERG-STD-IT-001 | IT/Cloud/SaaS scope | | CUI Handling Standard | CERG-STD-CUI-001 | CUI environment overlays | | Access Management Standard | CERG-STD-AC-001 | Identity-related exposures | | Secure Configuration Baseline | CERG-STD-CFG-001 | DISH baseline drift | | Risk Register and Exception Process | CERG-PRC-RM-001 | Risk acceptance workflow | | Third-Party and Supply Chain Risk | CERG-PRC-TPRM-001 | Vendor/supply-chain observations | | Threat Intelligence | CERG-PRC-TI-001 | Threat intel feed into observations | | CERG Operating Model | CERG-GOV-OM-001 | Pillar structure | | Metrics Dashboard | CERG-GOV-MTR-001 | EM and PH metrics | --- > > _A scanner report is inventory data. Confirmed exposure is what matters._ --- _CERG-PRC-VM-001 · Version 2.02 · PUBLIC_ --- ## INCIDENT RESPONSE PLAYBOOK SET ### CERG Inputs · IR Team Handoff · Scenario Checklists · Evidence and Recovery Support --- | | | |---|---| | **Document ID** | CERG-PRC-IR-002 | | **Version** | 1.2 | | **Status** | External Interface | | **Classification** | External Interface | | **Owner** | Standing IR Team / Incident Commander | | **Parent Policy** | Not applicable; adjacent-function artifact cross-referenced by CERG for integration | | **Supporting Documents** | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) · [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [`CERG-STD-MSG-001`](../standards/CERG-STD-MSG-001_Email_and_Messaging_Security_Standard.md) · [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / After significant incident or IR plan change | | **Frameworks** | [NIST 800-61r2](https://csrc.nist.gov/pubs/sp/800/61/r2/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (IR, AU, SI, CP) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (RESPOND, RECOVER) | | **Regulations** | CMMC L2 / 800-171r3 · NERC-CIP · SOX ITGC · breach notification and contractual obligations where applicable | | **Environments** | CERG-facing support to incidents affecting CERG-managed systems, controls, data, and evidence | --- > **ADJACENT FUNCTION — NOT A CERG-OWNED DOCUMENT** > > This artifact belongs to the standing Incident Response team, not to CERG. Per [OM-001 §3.4](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md), CERG is not responsible for Incident Response operations, the IR plan itself, regulatory notification clocks, or exercise management. CERG provides a liaison to the IR team and maintains this document in the repository for cross-functional integration only. > > **During an incident:** the standing IR team's procedures and the Incident Commander's authority take precedence over any CERG workflow. CERG's role during incidents is supporting (evidence, reporting, lessons-learned feedback per FLOW-001 F-06), not directing. > > **Ownership:** This document is maintained by the standing IR team. CERG Governance reviews it for cross-reference accuracy only. Changes to IR procedures, notification timelines, or exercise schedules are the IR team's responsibility. > --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Ownership Boundary](#2-ownership-boundary) 3. [Common Playbook Structure](#3-common-playbook-structure) 4. [Playbook 1: Ransomware](#4-playbook-1-ransomware) 5. [Playbook 2: Business Email Compromise](#5-playbook-2-business-email-compromise) 6. [Playbook 3: Data Breach or Exfiltration](#6-playbook-3-data-breach-or-exfiltration) 7. [Playbook 4: Phishing Campaign](#7-playbook-4-phishing-campaign) 8. [Playbook 5: Distributed Denial of Service](#8-playbook-5-distributed-denial-of-service) 9. [Playbook 6: Insider Threat](#9-playbook-6-insider-threat) 10. [Playbook 7: Cloud Account Compromise](#10-playbook-7-cloud-account-compromise) 11. [Playbook 8: Supply Chain Compromise](#11-playbook-8-supply-chain-compromise) 12. [Playbook 9: Web Application Attack](#12-playbook-9-web-application-attack) 13. [Playbook 10: Malware Outbreak](#13-playbook-10-malware-outbreak-non-ransomware) 14. [Playbook 11: Zero-Day Exploitation](#14-playbook-11-zero-day-exploitation) 15. [Playbook 12: Cryptographic Compromise](#15-playbook-12-cryptographic-compromise) 16. [Playbook 13: Social Engineering](#16-playbook-13-social-engineering-vishing--smishing) 17. [Post-Incident CERG Actions](#17-post-incident-cerg-actions) 18. [Roles and Responsibilities](#18-roles-and-responsibilities) 19. [Regulatory and Framework Alignment Summary](#19-regulatory-and-framework-alignment-summary) 20. [Document Control](#20-document-control) --- ## 1. Purpose and Scope [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) establishes the Incident Response Plan. [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4 states that incident response is owned by a standing Incident Response team, not by CERG. That boundary is correct and must remain. At the same time, CERG owns many controls, records, and technical inputs the Incident Response team needs during an incident. This document provides CERG-facing incident playbooks: what CERG prepares, what CERG hands to the Incident Response team, what CERG supports during containment, eradication, recovery, communications, and evidence preservation, and what CERG does after the incident to turn lessons into risks, controls, and evidence. This is not a SOC procedure, forensics manual, or replacement Incident Response Plan. It is a support and handoff playbook set for CERG-managed systems and controls. > **CERG Does Not Command the Incident. CERG Makes the Incident Runnable.** > > During an active incident, the Incident Commander commands. CERG does not create a parallel command structure. CERG brings the material the Incident Response team needs: asset context, data classification, control evidence, logging posture, recovery dependencies, risk history, vendor context, and the owners who can change the environment safely. The boundary is simple: the IR team runs the incident; CERG makes sure the IR team is not guessing. --- ## 2. Ownership Boundary | **Area** | **Owner** | **CERG Role** | |---|---|---| | Incident declaration and severity | Incident Commander | Informed and consulted. | | Tactical containment, eradication, and recovery direction | Incident Commander | Supports with Engineering and Risk expertise. | | Forensic investigation | Lead Investigator | Supports with logs, asset data, and control context. | | Legal, privacy, customer, and regulator notification decisions | Incident Commander with legal and executive process | Governance supplies data classification, scope, evidence, and regulatory mapping. | | Detection content and telemetry readiness | Detection Engineer under CERG standards | Supplies and improves signals before and after incident. | | Post-incident risk and control remediation | CERG | Records risks, updates controls, tracks remediation. | The standing IR team owns and maintains this playbook set. CERG Governance provides repository, cross-reference, and evidence-integration support only. Scenario execution during an active incident is under the Incident Commander. ### 2.1 Integration with the Incident Response Plan This playbook set operates under [CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) (the IR Plan), which is owned by the standing Incident Response team. The following defines how the two documents connect operationally. #### Activation Flow | **IR Plan Stage** | **CERG Playbook Activation** | **CERG Action** | |---|---|---| | Incident declared | Incident Commander notifies CERG on-call per Section 18.1 | CERG acknowledges and stands by | | Severity determined (P1 / Sev 1 through P4 / Sev 4) | Playbook selected per Section 3.1 | CERG activates at the level defined in Section 3.2 | | Triage | Playbook Triage phase | CERG supplies asset context, data classification, control evidence, logging posture | | Containment | Playbook Containment phase | CERG supports with Engineering and Risk expertise | | Eradication | Playbook Eradication phase | CERG identifies control gaps and remediation paths | | Recovery | Playbook Recovery phase | CERG validates control posture before restoration | | Post-incident | Section 17 (Post-Incident CERG Actions) | CERG records residual risk, updates controls, updates evidence library | | Incident closed | CERG stands down | CERG returns to normal operations | #### Information Flow - The Incident Commander provides CERG with: incident declaration, severity, affected scope, and status updates - CERG provides the Incident Commander with: asset inventory, data classification, control evidence, risk history, vendor context, and recovery dependencies - CERG actions taken during the incident are documented in the IR record by the Evidence Librarian --- ### 2.2 Playbook Testing and Exercise Program Playbooks are tested to validate that they work as intended and that CERG personnel can execute them under pressure. #### Testing Cadence | **Activity** | **Frequency** | **Scope** | |---|---|---| | Tabletop exercise | Annually per playbook | Walk through each playbook with CERG roles; at least 2 playbooks exercised per year | | Functional exercise | Annually (at least one) | Simulated incident with CERG activation; test communication, evidence, and handoff procedures | | Full-scale exercise | Every 2 years or per regulatory requirement | Organization-wide exercise including IR team, CERG, and executive leadership | #### Exercise Design - Exercises are designed and owned by the Incident Commander / standing IR team; Governance and Risk provide CERG support scenarios and evidence objectives - Each exercise has defined objectives, success criteria, and an after-action review - Exercises test the playbook, not the individuals; the goal is to find gaps, not to evaluate performance #### Success Criteria | **Criterion** | **Measure** | |---|---| | Activation time | CERG on-call acknowledged within SLA per Section 18.1 | | Playbook selection | Correct playbook selected per Section 3.5 | | Evidence delivery | Requested evidence delivered to Incident Commander within expected timeframe | | Communication | Notifications and updates sent per templates in Section 19.1 | | Post-incident actions | Post-incident actions initiated per Section 17 | #### Exercise Findings Exercise findings feed into [CERG-PRC-LL-001](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) as lesson artifacts when they affect CERG controls, evidence, risk, or support procedures. The standing IR team approves playbook updates based on exercise findings; CERG Governance updates repository links and CERG-facing support language within 30 days of the after-action review. --- ## 3. Common Playbook Structure Each scenario uses the same structure so teams can move quickly. | **Phase** | **CERG Support Question** | |---|---| | Triage | What do we know, what systems and data are involved, and what evidence must be preserved now? | | Containment | What control changes, access restrictions, network actions, or vendor actions can safely limit spread? | | Eradication | What root cause, vulnerability, misconfiguration, credential, or malicious artifact must be removed? | | Recovery | What dependencies, backups, baselines, and validation are required before restoring service? | | Communications | What technical, regulatory, customer, and executive facts can CERG supply? | | Evidence | What logs, approvals, configurations, decisions, and artifacts must be preserved? | --- ### 3.1 Playbook Selection Guide When an incident is reported, use the following decision tree to select the appropriate playbook. For multi-vector incidents, activate the highest-severity playbook first, then supplement with relevant sections from other playbooks as the incident scope clarifies. | **Question** | **If Yes** | **If No** | |---|---|---| | Is there evidence of ransomware (encrypted files, ransom note, TOR link)? | → Playbook 1 (Ransomware) | Continue | | Is there evidence of compromised business email (unusual rules, forwarding, executive impersonation)? | → Playbook 2 (BEC) | Continue | | Is there confirmed or suspected data exfiltration or breach of regulated data? | → Playbook 3 (Data Breach) | Continue | | Is the primary indicator a phishing email campaign (multiple users targeted, no confirmed compromise yet)? | → Playbook 4 (Phishing) | Continue | | Is the service degradation or outage consistent with a denial-of-service attack? | → Playbook 5 (DDoS) | Continue | | Is the threat actor believed to be an internal employee or contractor? | → Playbook 6 (Insider Threat) | Continue | | Is there evidence of cloud account or tenant compromise (unusual control-plane activity, new resources)? | → Playbook 7 (Cloud Account) | Continue | If none of the above match, or if the incident type is unclear, activate the playbook that most closely matches the observed indicators and consult the Incident Commander for direction. The Incident Commander may override playbook selection at any time. ### 3.2 Incident Severity Classification All incidents are classified by severity to determine response priority, escalation requirements, and notification obligations. This playbook set uses the P1–P4 severity scale aligned with the Incident Response Plan ([CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) §5, which defines the authoritative Sev 1–4 classification). The mapping is: P1 = Sev 1 (Critical), P2 = Sev 2 (Significant), P3 = Sev 3 (Moderate), P4 = Sev 4 (Minor). | **Severity** | **Label** | **Criteria** | **CERG Activation** | |---|---|---|---| | **P1 / Sev 1** | Critical | Active data breach of Restricted/CUI data; ransomware in production with confirmed encryption of critical systems; BES Cyber System compromise; confirmed compromise of a Crown Jewel asset; incident with safety or operational reliability impact | Full CERG activation; all pillar leaders engaged; CISO notified immediately | | **P2 / Sev 2** | High | Confirmed compromise of a privileged account; CUI exposure without confirmed exfiltration; malware on systems handling regulated data; material vendor breach with downstream impact; DDoS affecting customer-facing services | CERG Engineering + Risk pillars activated; Governance engaged for regulatory scoping; CISO notified within 1 hour | | **P3 / Sev 3** | Medium | Confirmed compromise of a standard user account; phishing campaign with credential submission but no confirmed account access; malware on non-regulated endpoint; policy violation with security implications | CERG supporting role; relevant pillar(s) engaged as needed; CISO notified in standing briefing | | **P4 / Sev 4** | Low | Isolated security event with no confirmed compromise; failed attack attempt; routine alert requiring investigation but no incident declaration | CERG monitoring only; no activation required unless escalated by the Incident Commander | #### Escalation Thresholds - Any P1 / Sev 1 or P2 / Sev 2 incident: CISO is notified immediately. The Incident Commander and Legal determine regulatory notification obligations; Governance supplies evidence and obligation-mapping support. - Any incident involving PII, CUI, or BCSI: The relevant compliance manager (CMMC / NERC-CIP) is engaged within the first hour. - Any incident with potential customer impact: Account Management and Legal are engaged per the Incident Response Plan. - Any incident lasting > 24 hours: Severity is re-evaluated; a P2 / Sev 2 that persists > 24 hours may be elevated to P1 / Sev 1 at the Incident Commander's discretion. --- ## 4. Playbook 1: Ransomware ### 4.1 Triage CERG supports the Incident Response team by rapidly identifying: - affected assets and asset owners from the inventory; - criticality and recovery priority from [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md); - data classification and regulated data exposure from [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md); - backup status and last known good recovery point from [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md); - identity paths and privileged sessions that may be involved; - relevant vulnerabilities, open risks, or exceptions. ### 4.2 Containment CERG-supported containment may include: disabling compromised identities, isolating affected network segments or endpoints, blocking command-and-control indicators, freezing risky privileged access, pausing affected automation, and preserving backup systems from contamination. ### 4.3 Eradication and Recovery CERG supports eradication by identifying the likely control failure: exposed remote access, missing MFA, vulnerable service, endpoint control gap, credential theft, misconfiguration, or vendor path. Recovery support includes baseline validation, restore validation, vulnerability remediation, and logging confirmation before production return. ### 4.4 Evidence and Communications Inputs CERG preserves asset inventory snapshots, backup evidence, affected-data classification, security-control status, risk-register history, exception history, and relevant logs. Governance supplies regulatory mapping and evidence for customer, regulator, or executive communication. --- ## 5. Playbook 2: Business Email Compromise ### 5.1 Triage CERG identifies the compromised mailbox or identity, MFA status, sign-in history, mailbox rules, forwarding rules, suspicious OAuth grants, sent mail volume, external recipients, and whether payments, regulated data, or executive impersonation are involved. ### 5.2 Containment CERG support may include: disabling the account, revoking sessions and tokens, removing malicious mailbox rules, disabling external forwarding, resetting credentials, blocking indicators, quarantining related messages, and identifying other recipients or compromised accounts. ### 5.3 Eradication and Recovery CERG validates that the mailbox, identity, OAuth grants, rules, and recovery methods are clean before returning access. Email and messaging control gaps are tracked under [`CERG-STD-MSG-001`](../standards/CERG-STD-MSG-001_Email_and_Messaging_Security_Standard.md). ### 5.4 Evidence and Communications Inputs CERG preserves sign-in logs, mailbox audit logs, message traces, rule changes, MFA status, external forwarding evidence, DLP alerts, and related risk or exception records. Governance supplies SOX, privacy, and customer-scope implications where relevant. --- ## 6. Playbook 3: Data Breach or Exfiltration ### 6.1 Triage CERG determines what data may be involved, its classification, the affected systems, the likely exfiltration path, volume, time window, data owner, and regulated or contractual obligations. Restricted data, CUI, BES Cyber System Information, personal data, and financial reporting data receive immediate Governance involvement. ### 6.2 Containment Containment may include blocking exfiltration paths, disabling identities, revoking vendor access, suspending risky integrations, enforcing DLP blocks, rotating exposed secrets, and isolating affected repositories or storage locations. ### 6.3 Eradication and Recovery CERG identifies and remediates the control gap: access failure, DLP failure, storage exposure, vendor path, compromised credential, misconfiguration, or logging gap. Recovery includes validating access, storage, DLP, and monitoring controls before normal operations resume. ### 6.4 Evidence and Communications Inputs CERG preserves data classification records, data-owner confirmation, access logs, DLP events, storage configuration, vendor access logs, risk-register entries, and evidence of containment actions. --- ## 7. Playbook 4: Phishing Campaign ### 7.1 Triage CERG identifies reported messages, sender infrastructure, subject and lure, affected users, clicked users, credential submissions, malicious links or attachments, and whether the campaign targets executives, privileged users, finance, or regulated environments. ### 7.2 Containment Containment may include message purge, URL or attachment blocking, credential resets, session revocation, OAuth grant removal, mailbox rule review, and user notification. Employee reporting remains blame-free under [`CERG-STD-MSG-001`](../standards/CERG-STD-MSG-001_Email_and_Messaging_Security_Standard.md). ### 7.3 Eradication and Recovery CERG supports control tuning: email filtering, DMARC/SPF/DKIM review, user-reporting workflow, DLP, mailbox auditing, and detection content. If the phish leads to account compromise, Playbook 2 also applies. ### 7.4 Evidence and Communications Inputs CERG preserves reported messages, message trace, user-report timestamps, click and submission evidence, containment actions, and affected-account actions. --- ## 8. Playbook 5: Distributed Denial of Service ### 8.1 Triage CERG identifies affected services, customer or operational impact, upstream providers, DDoS protection status, network paths, service dependencies, and whether the incident masks another attack. ### 8.2 Containment Containment support may include activating DDoS protection, coordinating with providers, changing routing or filtering, scaling resilient services, protecting management interfaces, and preserving logs showing attack characteristics. ### 8.3 Eradication and Recovery DDoS is rarely eradicated in the traditional sense. CERG supports service restoration, resilience validation, provider review, and permanent control improvements after the attack subsides. ### 8.4 Evidence and Communications Inputs CERG preserves traffic metrics, provider tickets, protection activation evidence, affected-service timelines, customer-impact timeline, and recovery evidence. --- ## 9. Playbook 6: Insider Threat ### 9.1 Triage CERG supports the Incident Response team carefully and discreetly. Triage identifies affected systems, data classification, access history, anomalous behavior, DLP events, privileged activity, and risk to investigation integrity. Access to information is strictly need-to-know. ### 9.2 Containment Containment may include access suspension, privilege reduction, session revocation, monitoring preservation, device preservation, and targeted control changes. Actions are coordinated with the Incident Commander and appropriate legal, HR, or executive process outside CERG. ### 9.3 Eradication and Recovery CERG identifies control improvements: access review gaps, segregation-of-duties gaps, logging gaps, DLP gaps, privileged access gaps, or data governance failures. Recovery may include access recertification and control strengthening. ### 9.4 Evidence and Communications Inputs CERG preserves access logs, DLP events, privileged activity, data classification, asset ownership, risk records, and evidence-chain notes as directed by the Incident Commander and Lead Investigator. --- ## 10. Playbook 7: Cloud Account Compromise ### 10.1 Triage CERG identifies the affected tenant, account, subscription, project, workload, identity, access keys, service principals, secrets, exposed data, privilege level, and recent control-plane activity. Cloud account compromise is treated as both identity and platform compromise. ### 10.2 Containment Containment may include disabling or isolating identities, revoking sessions, rotating keys and secrets, blocking suspicious IPs, quarantining workloads, snapshotting evidence, disabling risky automation, and preserving control-plane logs. ### 10.3 Eradication and Recovery CERG identifies the root path: credential theft, exposed secret, misconfigured federation, over-privileged role, vulnerable workload, or malicious OAuth or service principal. Recovery requires validation of IAM, logging, network controls, baseline conformance, and secrets rotation. ### 10.4 Evidence and Communications Inputs CERG preserves cloud audit logs, IAM history, key and secret rotation records, workload inventory, network flows, storage access logs, risk-register records, and affected-data classification. --- ## 11. Playbook 8: Supply Chain Compromise ### 11.1 Triage CERG supports the Incident Response team by rapidly identifying: - affected vendor, service, or software component from the TPRM records and asset inventory; - data classifications and regulated data potentially exposed through the vendor; - vendor tier and criticality from [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md); - the organization's usage of the affected service (direct, embedded, transitive); - any IOCs or threat intelligence from [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md); - affected systems, identities, or data paths that integrate with the compromised vendor. ### 11.2 Containment CERG-supported containment may include: disabling vendor access and integrations, revoking vendor API keys and service accounts, blocking vendor IP ranges, isolating systems that consume the affected service, suspending data flows to/from the vendor, and preserving evidence of the vendor relationship for investigation. If the vendor compromise is confirmed, the SCCT is activated per [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Section 15. ### 11.3 Eradication and Recovery CERG identifies the vendor dependency path: direct integration, embedded library, transitive dependency, or shared infrastructure. Recovery may require vendor remediation, service replacement, or architectural decoupling. CERG validates that replacement or remediated services meet control requirements before restoration. Vendor risk records are updated to reflect the incident and any tier, evidence, or monitoring changes. ### 11.4 Evidence and Communications Inputs CERG preserves: vendor contract and security obligations, TPRM assessment records, vendor access logs, data flow documentation, integration architecture, and evidence of containment and recovery actions. Governance supplies regulatory mapping for any regulated data exposed through the vendor. --- ## 12. Playbook 9: Web Application Attack ### 12.1 Triage CERG identifies: the affected application, its data classification, authentication mechanism, hosting environment (cloud, on-prem, SaaS), whether it processes regulated data (CUI, SOX, PII), the likely attack vector (SQLi, XSS, CSRF, SSRF, IDOR, auth bypass, API abuse), and whether WAF or other protective controls were in place and functioning per [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md). ### 12.2 Containment Containment may include: taking the affected application or endpoint offline, blocking the attack source IPs, enabling WAF blocking rules, disabling the vulnerable function, revoking compromised sessions and tokens, rotating application secrets, and quarantining affected application servers for forensic imaging. ### 12.3 Eradication and Recovery CERG supports the application team in identifying and fixing the vulnerability: code fix, configuration change, WAF rule, or architectural change. Recovery includes validating the fix, re-scanning per the application penetration test checklist in [CERG-PRC-AV-001](CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) Section 8, and confirming detection rules are updated for the observed attack pattern. ### 12.4 Evidence and Communications Inputs CERG preserves: application logs, WAF logs, authentication logs, database audit logs, attack payloads, vulnerability scan results, fix evidence, and retest results. If the application handles regulated data, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support. --- ## 13. Playbook 10: Malware Outbreak (Non-Ransomware) ### 13.1 Triage CERG identifies: affected endpoints and servers, malware type (infostealer, RAT, botnet, cryptominer, wiper - differentiated from ransomware per Playbook 1), command-and-control infrastructure, initial infection vector, scope of compromise (which systems, what data accessed), and whether the malware has credential-theft or lateral-movement capability. ### 13.2 Containment Containment may include: isolating affected systems, blocking C2 indicators at the network edge, disabling compromised accounts, forcing credential resets, quarantining affected mailboxes or file shares, and suspending automation or scheduled tasks that could propagate the malware. ### 13.3 Eradication and Recovery CERG supports eradication by identifying the infection vector: email attachment, drive-by download, removable media, software supply chain, or exploited vulnerability. Recovery includes: re-imaging affected systems from known-good baselines, restoring data from clean backups, validating EDR coverage, and confirming that C2 indicators are blocked and detection rules are active. ### 13.4 Evidence and Communications Inputs CERG preserves: malware samples, C2 logs, affected system inventory, infection timeline, containment actions, and recovery evidence. If the malware accessed regulated data, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support. --- ## 14. Playbook 11: Zero-Day Exploitation ### 14.1 Triage CERG identifies: the affected software, version, vendor, and patch status; whether the vulnerability is publicly disclosed or actively exploited in the wild; which organizational assets are vulnerable; the exploit vector (remote, local, authenticated); and whether the vulnerability affects regulated systems (SOX, CUI, NERC-CIP). Threat intelligence from [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) is consulted for IOCs and TTPs. ### 14.2 Containment Containment may include: disabling the affected service or feature, applying vendor-provided mitigation (if available before a patch), implementing network-level blocking rules, isolating vulnerable systems, increasing monitoring on vulnerable but not-yet-compromised systems, and communicating the threat to system owners per the exposure management procedure. ### 14.3 Eradication and Recovery CERG tracks the vendor patch release and coordinates with Engineering for emergency patch deployment per [CERG-PRC-VM-001](CERG-PRC-VM-001_Exposure_Management_Procedure.md) §5.2. If compromise is confirmed, eradication follows the relevant playbook for the post-exploitation activity (Data Breach, Cloud Compromise, etc.). Recovery validates that the patch is applied, the vulnerability is remediated, and compensating controls are in place for any systems that cannot be immediately patched. ### 14.4 Evidence and Communications Inputs CERG preserves: vulnerability advisory or CVE, affected asset inventory, patch deployment evidence, containment actions, and any compromise evidence. For vulnerabilities affecting regulated systems, the Incident Commander and Legal determine regulatory notification obligations; Governance supplies evidence and obligation-mapping support. --- ## 15. Playbook 12: Cryptographic Compromise ### 15.1 Triage CERG identifies: the compromised cryptographic material (certificate, private key, signing key, API key, secret), its scope of use (which systems, services, or identities depend on it), whether it protects regulated data or authentication, the likely compromise vector (exposed secret, insider, CA compromise, weak algorithm, side-channel), and the blast radius if the key is actively exploited. ### 15.2 Containment Containment may include: revoking the compromised certificate or key, rotating all secrets in the same scope, invalidating sessions and tokens signed with the compromised key, blocking authentication paths that relied on the compromised material, and preserving forensic evidence of the compromise for root cause analysis. Emergency rotation follows [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) Section 8. ### 15.3 Eradication and Recovery CERG coordinates with the Cryptography Engineer to: identify how the material was compromised (exposed in repository, weak generation, insider action, CA breach), remediate the root cause, issue replacement material through the approved PKI or secrets management process, deploy replacement material to all dependent systems, and validate that no system continues to trust the compromised material. ### 15.4 Evidence and Communications Inputs CERG preserves: certificate or key metadata, revocation records, rotation evidence, affected system inventory, and timeline of compromise and recovery. If the compromised material protected regulated data or authentication to regulated systems, the Incident Commander and Legal determine notification obligations; Governance supplies evidence and obligation-mapping support. Certificate Transparency logs are monitored for 30 days post-incident for anomalous issuance. --- ## 16. Playbook 13: Social Engineering (Vishing / Smishing) ### 16.1 Triage CERG identifies: the social engineering vector (phone call, SMS, messaging app), the pretext used, targeted individuals and their roles (executive, finance, IT admin, privileged user), what information or access was obtained, whether credentials were disclosed or MFA was bypassed, and whether the attack led to account compromise, financial transfer, or data disclosure. ### 16.2 Containment Containment may include: disabling affected accounts, revoking sessions, resetting credentials, blocking the attacker's phone number or messaging account, quarantining related messages, identifying and protecting other potential targets briefed on the pretext, and notifying the telecom provider or messaging platform if account takeover is suspected. ### 16.3 Eradication and Recovery CERG supports eradication by identifying the control gap: lack of verification procedure for sensitive requests, MFA bypass, absence of out-of-band confirmation for financial transfers, or training gap. Recovery includes: updating awareness content, implementing verification procedures for high-risk requests (financial, credential, data), and confirming that affected individuals receive targeted follow-up training. ### 16.4 Evidence and Communications Inputs CERG preserves: call or message records, pretext details (sanitized for distribution), affected account logs, containment actions, and awareness recommendations. Social engineering findings are reported separately from technical findings. No disciplinary action shall result from an employee falling for a social engineering attack; the incident informs program improvement, not individual performance management. ## 17. Post-Incident CERG Actions After the Incident Commander closes active response, CERG completes its own post-incident work. | **Action** | **Owner** | **Purpose** | |---|---|---| | Record residual risk | Risk Register Owner | Ensure unresolved exposure is tracked. | | Update controls or standards | Policy & Standards Manager with relevant owner | Close program gaps revealed by the incident. | | Update baselines | Relevant Engineering role | Prevent recurrence through configuration or architecture change. | | Update detection and logging requirements | Detection Engineer | Improve observability and alerting where in scope. | | Update evidence library | Evidence Librarian | Preserve incident-relevant control and response evidence. | | Review vendor or third-party implications | Vendor Risk Analyst | Reassess suppliers or integrations involved. | | Report material lessons | Governance Pillar Leader | Feed metrics, CISO reporting, and oversight. | --- ## 18. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Playbook Responsibility** | |---|---| | **Incident Commander** | Commands the active incident. Owns tactical incident decisions. | | **Lead Investigator** | Leads investigation and evidence direction during active response. | | **Governance Pillar Leader** | Provides repository, cross-reference, regulatory-mapping, evidence, and reporting support; does not own incident command, notification clocks, exercises, or this adjacent-function artifact. | | **Risk Pillar Leader** | Coordinates Cyber Risk support and post-incident risk capture. | | **Engineering Pillar Leader** | Coordinates Cyber Engineering support and technical control changes. | | **Detection Engineer** | Supplies telemetry context and post-incident detection improvements where in scope. | | **Risk Register Owner** | Records residual risks and post-incident risk entries. | | **Evidence Librarian** | Preserves CERG evidence and submitted incident support material. | | **Cloud Security Engineer** | Supports cloud, SaaS, email, and platform incidents. | | **Identity Engineer** | Supports identity, privilege, token, session, and account-containment actions. | | **Endpoint Engineer** | Supports endpoint isolation and recovery where needed. | | **Cryptography Engineer** | Supports key, certificate, token, and secret rotation. | | **Vendor Risk Analyst** | Supports vendor and third-party implications. | | **CMMC / Federal Compliance Manager** | Supports CUI and federal implications. | | **NERC-CIP Compliance Manager** | Supports NERC-CIP implications. | | **SOX ITGC Lead** | Supports SOX ITGC implications. | | **Chief Information Security Officer (CISO)** | Receives material incident briefings and risk escalations. | --- ### 18.1 CERG On-Call and Activation CERG maintains an on-call rotation for incident support. The rotation schedule is maintained in the incident response tooling and is not duplicated here to avoid staleness. The following defines the activation procedure and escalation contacts. #### Activation Procedure 1. **Declaration**: The Incident Commander (or delegate) declares an incident and determines severity per Section 3.2. 2. **CERG Notification**: The Incident Commander or SOC notifies the CERG on-call contact through the designated channel (secure messaging, phone). 3. **Pillar Activation**: - P1 / Sev 1 and P2 / Sev 2: Engineering Pillar Leader and Risk Pillar Leader are activated immediately. Governance Pillar Leader is activated for evidence support and regulatory mapping at IC / Legal direction. - P3 / Sev 3: Relevant pillar leader(s) activated as needed. - P4 / Sev 4: CERG monitors; no activation unless escalated. 4. **Acknowledgment**: Activated CERG roles acknowledge within 30 minutes (P1 / Sev 1), 1 hour (P2 / Sev 2), or 4 hours (P3 / Sev 3). 5. **Stand-down**: The Incident Commander declares stand-down; CERG returns to normal operations and begins post-incident actions per Section 17. #### Escalation Contacts | **Role** | **Escalation Contact** | **When to Escalate** | |---|---|---| | On-call CERG responder | Engineering Pillar Leader or Risk Pillar Leader | Unable to resolve within capability; incident severity escalates | | Engineering Pillar Leader | CISO | P1 / Sev 1 incident; urgent technical containment or recovery decision needed; executive decision needed | | Risk Pillar Leader | CISO | P1 / Sev 1 incident; risk acceptance required during active response | | Governance Pillar Leader | Incident Commander / Legal; CISO if unresolved | Evidence preservation, regulatory mapping, or repository-support dispute | | CISO | Executive Sponsor / Board | Material business impact; SEC disclosure consideration; safety consequence | --- ## 19. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Playbook Set** | |---|---|---| | NIST 800-61r2 | Preparation, detection and analysis, containment, eradication, recovery, post-incident activity | Sections 3 through 11 | | NIST 800-53r5 | IR, AU, SI, CP families | Sections 3 through 11 | | NIST CSF 2.0 | RESPOND and RECOVER | Sections 4 through 11 | | CMMC L2 / NIST 800-171r3 | Incident response and CUI handling implications | Sections 6, 11, 12 | | NERC-CIP | Incident and BES Cyber System implications | Sections 6, 11, 12 | | SOX ITGC | Evidence, access, and change implications for financial systems | Sections 5, 11, 12 | --- ### 19.1 Communication Templates The following templates support incident communications. Templates are populated during the Communications phase of each playbook. All templates are marked with the incident's classification level. #### Initial Incident Notification (Internal) ``` INCIDENT NOTIFICATION - IR-YYYY-NNNN Classification: [per incident classification] Date/Time: [declaration timestamp] Severity: [P1 / Sev 1 / P2 / Sev 2 / P3 / Sev 3 / P4 / Sev 4] Incident Commander: [name] CERG Lead: [name] Incident Type: [Ransomware / BEC / Data Breach / etc.] Affected Systems: [list] Affected Data: [classifications, if known] Current Status: [Triage / Containment / Eradication / Recovery] Next Update Expected: [time] Actions Requested: - [Any specific actions needed from recipients] - [Do not take independent action without Incident Commander approval] Contact: [Incident Commander contact] ``` #### Status Update Template ``` INCIDENT STATUS UPDATE - IR-YYYY-NNNN Update #: [N] Date/Time: [timestamp] Classification: [per incident classification] Status Change Since Last Update: - [What changed] - [New findings] - [Containment actions completed] - [Recovery progress] Current Assessment: - [Current state of the incident] - [Remaining actions] Estimated Time to Resolution: [estimate] Next Update Expected: [time] ``` #### Regulatory Breach Notification Template ``` REGULATORY NOTIFICATION - IR-YYYY-NNNN Classification: CONFIDENTIAL - REGULATORY Date/Time: [timestamp] To: [Regulatory body / contact] From: [Organization representative] Incident Type: [description] Date of Discovery: [date] Affected Data Subjects: [count and jurisdictions] Data Types Affected: [PII / CUI / BCSI / etc.] Description of Incident: [factual, concise] Measures Taken: [containment, investigation, remediation] Measures Planned: [next steps] Contact for Follow-up: [name, role, contact] Attachments: [list] ``` #### Customer / Partner Communication Template ``` INCIDENT NOTICE - IR-YYYY-NNNN Classification: [as approved by Legal and Incident Commander] Date: [date] To: [Customer / Partner contact] [Organization] is writing to inform you of a security incident that may affect [the service / data / system] we provide to you. What Happened: [factual description, approved by Legal] What Data Was Affected: [if applicable, approved by Legal] What We Have Done: [containment and remediation actions] What We Are Doing: [ongoing actions] What You Should Do: [any recommended customer actions] We will provide additional information as it becomes available. If you have questions, please contact [name / role / contact]. [Signature block] ``` #### Post-Incident Summary Template ``` POST-INCIDENT SUMMARY - IR-YYYY-NNNN Classification: [per incident classification] Date Closed: [date] Incident Overview: [type, severity, timeline] Root Cause: [determined or suspected] Affected Systems and Data: [list] Containment and Eradication Actions: [summary] Recovery Actions: [summary] Evidence Preserved: [list of evidence artifacts] Residual Risk: [risk register entries created] Lessons Learned: [key findings for program improvement per CERG-PRC-LL-001] Action Items: [owner, action, due date] Prepared by: [Standing IR Team / CERG support contributor] Reviewed by: [Incident Commander, CISO] ``` --- ## 20. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-IR-002 | | **Version** | 1.2 | | **Status** | External Interface | | **Effective Date** | 2026-05-22 | | **Classification** | External Interface | | **Owner** | Standing IR Team / Incident Commander | | **Approved By** | CISO | | **Parent Policy** | Not applicable; adjacent-function artifact cross-referenced by CERG for integration | | **Review Cycle** | Annual; and after significant incident or IR plan change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-61r2; NIST 800-53r5 (IR, AU, SI, CP); NIST CSF 2.0 (RESPOND, RECOVER) | | **Regulations** | CMMC L2 / 800-171r3; NERC-CIP; SOX ITGC; breach notification and contractual obligations where applicable | | **Environments** | CERG-facing support to incidents affecting CERG-managed systems, controls, data, and evidence | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-18 | Standing IR Team / Incident Commander | Standardized core playbook severity labels to paired P / Sev notation. | | 1.1 | 2026-06-18 | Standing IR Team / Incident Commander | Clarified that the standing IR team owns this playbook set, exercises, notification-clock process, and scenario execution; CERG Governance provides repository, evidence, regulatory-mapping, and post-incident improvement support only. | | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes CERG-facing incident playbooks for ransomware, business email compromise, data breach or exfiltration, phishing campaign, distributed denial of service, insider threat, and cloud account compromise. Preserves the Operating Model boundary that the standing Incident Response team owns active incident command while CERG supplies control, evidence, risk, and recovery support. | ### Review Triggers - Significant incident or exercise finding - Change to [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) - Material change to logging, resilience, data governance, email, or cloud security standards - Change to legal, regulatory, or contractual incident-notification obligations - Direction from the CISO or Incident Commander The standing IR team owns and maintains this playbook set. CERG Governance reviews repository links, metadata, cross-references, and CERG-facing evidence/support language only. Changes to incident procedures, notification timelines, exercise cadence, or scenario execution require Incident Commander / CISO approval and IRT acknowledgment. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines IR ownership boundary and adjacent roles | | Incident Response Plan | [`CERG-PLN-IR-001`](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | Active incident response plan owned by the IR team | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Telemetry and detection support | | Email and Messaging Security Standard | [`CERG-STD-MSG-001`](../standards/CERG-STD-MSG-001_Email_and_Messaging_Security_Standard.md) | Email, phishing, BEC, and messaging controls | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Recovery and backup support | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Data classification and handling support | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Post-incident residual risk tracking | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence preservation and audit support | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact | --- ## LESSONS LEARNED AND PROGRAM IMPROVEMENT PROCEDURE ### After-Action Intake · Quarterly Aggregation · Improvement Pipeline · Verification · Improvement Register --- | | | |---|---| | **Document ID** | CERG-PRC-LL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-PRC-IR-002`](CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) · [`CERG-PRC-AV-001`](CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) · [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [`CERG-PLN-BC-001`](../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) · [`CERG-PRC-TI-001`](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) · [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) · [`CERG-GOV-IMPREG-001`](../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | | **Review Cycle** | Annual / After each quarterly lessons-aggregation cycle | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.IM, GOVERN) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CA, PM) · ISO/IEC 27001 A.10 | | **Regulations** | Cross-cutting : applies to all CERG-supported frameworks | | **Environments** | All CERG-managed processes, controls, and program functions | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Intake Sources and Triggers](#3-intake-sources-and-triggers) 4. [Lesson Triage and Classification](#4-lesson-triage-and-classification) 5. [Quarterly Lessons Aggregation](#5-quarterly-lessons-aggregation) 6. [Improvement Action Pipeline](#6-improvement-action-pipeline) 7. [Improvement Register Integration](#7-improvement-register-integration) 8. [Verification and Closure](#8-verification-and-closure) 9. [Roles and Responsibilities](#9-roles-and-responsibilities) 10. [Metrics](#10-metrics) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope The CERG Framework (CERG-GOV-FRM-001 Section 6.2) states that "Lessons learned drive improvement" and that "Post-incident reviews, penetration test retrospectives, and audit findings are tracked in the Governance risk register with assigned owners and improvement actions." The risk register (PRC-RM-001) is designed for risks: threats, vulnerabilities, likelihoods, treatments. It is not designed to track program-level improvements, aggregate cross-cutting patterns, or verify that lessons were absorbed into the program. This procedure closes that gap. It defines how CERG collects, analyzes, and converts after-action findings into permanent program improvements. It applies to every CERG process, engagement, and control that generates a post-event review: incidents, penetration tests, red team exercises, audit findings, DR and BC exercises, tabletop exercises, near-miss events, metrics threshold breaches, and external intelligence shifts. > **The Assessor Test** > > An assessor asks "How did last year's pen test change your program?" An organization that answers "We fixed the findings" with no evidence of structural change is operating at Repeatable maturity. An organization that answers "We fixed the findings, identified two systemic weaknesses, amended three standards, and verified the changes worked in this year's test" is operating at Adaptive maturity. This procedure is the machinery that produces the second answer. --- ## 2. Principles 1. **Every significant event produces a lesson.** After every incident, pen test, red team engagement, audit, exercise, and near-miss, a structured after-action artifact is produced. The default is to produce one; omitting one requires a documented rationale. 2. **Lessons are aggregated, not siloed.** A single incident review that stays in the IR team's folder is wasted. Lessons from all sources are collected into a single aggregation point for cross-cutting analysis. 3. **Lessons produce program changes, not just fixes.** The standard pattern : find a vulnerability, fix it, close the ticket : is operational hygiene, not program improvement. Program improvement is: "Why did four of six DMZ servers share the same misconfiguration, and what standard or procedure must change so the next six servers do not repeat it?" 4. **Every improvement is verified.** A change that is not verified to have worked is not complete. The next review cycle checks whether prior improvements had their intended effect. 5. **Improvements are tracked separately from risks.** The risk register tracks risks. The improvement register (CERG-GOV-IMPREG-001) tracks program changes. Conflating them creates noise in both. --- ### 2.1 Definition of a Significant Event Principle 1 states "Every significant event produces a lesson." A "significant event" is defined as any event that meets one or more of the following criteria: - Triggers a P1 or P2 incident response per [CERG-PRC-IR-002](CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) Section 3.6 - Results in a Critical or High finding from adversarial validation per [CERG-PRC-AV-001](CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) - Produces a "Deficient" control rating from an audit or control test per [CERG-PRC-AUD-001](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) - Involves a near-miss that could have resulted in any of the above (e.g., a control that failed silently but was caught before impact) - Is directed by the CISO to produce a lesson regardless of the above criteria #### Events Explicitly NOT Significant The following do not require a lesson artifact unless they reveal systemic findings: - Routine P3 or P4 incidents with no systemic findings and no new control gap identified - Standard operational changes with no security impact - Routine vulnerability remediation within SLA with no program implication - Standard access reviews, recertifications, or metric reports that pass without exception --- ## 3. Intake Sources and Triggers The following events trigger a lessons-learned artifact. Each source names the accountable role for producing the artifact and the target SLA for completion. | Source | Trigger Event | Accountable Role | SLA (from event close) | |---|---|---|---| | Post-incident review | Incident closed per PRC-IR-002 | Incident Commander (IR team) or Governance Pillar Leader | 14 calendar days | | Adversarial validation engagement | Pen test, red-team, cloud, application, OT-safe, or comparable engagement report delivered per PRC-AV-001 | Adversarial Testing Lead | 14 calendar days | | Purple team exercise | Exercise completed per LM-001 or PRC-AV-001 | Detection Engineer | 14 calendar days | | Audit finding (internal) | Audit report issued per PRC-AUD-001 | Governance Pillar Leader | 21 calendar days | | Audit finding (external / regulator) | Final report received | Governance Pillar Leader | 21 calendar days | | DR / BC exercise | Exercise AAR completed per PLN-BC-001 | Governance Pillar Leader | 14 calendar days | | Tabletop exercise | Exercise AAR completed per PRC-IR-002 | Governance Pillar Leader | 14 calendar days | | Near-miss event | Event contained before impact; documented | Risk Pillar Leader | 7 calendar days | | Metrics threshold breach | Any metric in MTR-001 Section 3 exceeds red threshold for 2 consecutive periods | Metric owner | 7 calendar days | | External intelligence shift | Threat landscape assessment identifies a material change per PRC-TI-001 | Threat Intelligence Analyst | 7 calendar days | | CISO-directed review | CISO requests a lessons review | Assigned pillar leader | As directed | > **Near-Miss Definition** > > A near-miss is an event that met detection thresholds but was contained before operational impact. Examples: a phishing campaign that reached user inboxes but was reported before any credential was harvested; an unauthorized lateral movement attempt that was blocked by network segmentation; a configuration change that would have created an exposure window but was caught by pre-production review before reaching production. Near-misses are the cheapest lessons the organization will ever get : the cost of analysis is orders of magnitude below the cost of the incident that did not happen. ### 3.1 Lesson Artifact Format Every lesson artifact contains, at minimum: - **Event summary:** what happened, when, scope, severity - **Root cause:** what allowed the event to occur or nearly occur - **What worked:** controls or processes that functioned as intended - **What did not work:** controls or processes that failed, were bypassed, or were absent - **Systemic assessment:** does this finding indicate a weakness that exists elsewhere? (yes / maybe / no, with rationale) - **Improvement candidates:** specific, actionable program changes proposed - **Immediate fixes taken:** what was fixed at the operational level --- ## 4. Lesson Triage and Classification Each lesson artifact is triaged within 7 days of receipt by the Governance Pillar Leader, who assigns a severity classification. | Severity | Criteria | Escalation | |---|---|---| | **Critical** | Threatens program effectiveness; indicates a control-family-wide weakness; or a finding that, if unaddressed, would cause an assessor to downgrade maturity. | Immediately briefed to CISO. Improvement action approved within 14 days. | | **High** | A repeated pattern across multiple sources (same root cause found in a pen test, an audit, and an incident); a single-source finding with broad systemic implications. | Routed to quarterly aggregation with CISO visibility. | | **Medium** | A single-source finding with improvement potential but no immediate cross-pillar impact. | Routed to quarterly aggregation. | | **Low** | A minor process tweak or documentation clarification. | Owner implements directly; recorded in the improvement register for completeness but not tracked through full aggregation. | > **Severity Is Not the Same as Incident Severity** > > An incident can be Low severity (single user, contained in minutes) but produce a Critical lesson (the root cause reveals a systemic weakness across an entire control family). Conversely, a Critical incident can produce a Low lesson (the controls worked; the root cause was a one-off human error with no systemic implications). Classify the lesson, not the event. --- ### 4.1 Escalation for Overdue Artifacts SLAs for lesson artifact production and triage are defined in Section 3.1 (artifact production within 7-21 days of event closure) and Section 4 (triage within 7 days of receipt). When these SLAs are missed, the following escalation applies. #### Escalation Triggers | **Trigger** | **Action** | |---|---| | Lesson artifact not produced within SLA + 3 business days | Governance Pillar Leader notifies the event owner and requests status | | Lesson artifact not produced within SLA + 10 business days | Governance Pillar Leader escalates to the responsible pillar leader | | Lesson artifact not produced within SLA + 20 business days | Pillar leader escalates to CISO | | Triage not completed within SLA + 3 business days | Governance Pillar Leader escalates internally; covered in monthly curation pass | #### Escalation Ladder Event Owner → Governance Pillar Leader → Responsible Pillar Leader → CISO At each level, the responsible party must either (a) produce the artifact, (b) provide a documented rationale for why the event does not require an artifact (per Section 2.1), or (c) commit to a revised production date. Overdue artifacts are reported in the quarterly lessons aggregation summary and tracked as a metric. #### Tracking The Governance Pillar Leader maintains a register of overdue artifacts. The count and age of overdue artifacts is reported in the monthly CERG leadership review. More than 3 artifacts overdue at any time triggers a process review. ## 5. Quarterly Lessons Aggregation Once per quarter, aligned with the CERG leadership review cadence (GOV-CAL-001 Section 5), the Governance Pillar Leader convenes a cross-pillar Lessons Aggregation Review. ### 5.1 Participants - Governance Pillar Leader (convener, chair) - Risk Pillar Leader (intelligence, vulnerability, adversarial inputs) - Engineering Pillar Leader (design, architecture, configuration inputs) - CISO (for Critical lesson dispositions) ### 5.2 Agenda 1. **Roll call of open lessons:** all lessons from the trailing quarter, grouped by severity 2. **Cross-source pattern analysis:** are the same root causes appearing across incident reviews, pen tests, and audits? This is the primary value of aggregation : patterns invisible to any single source become visible when all sources are analyzed together 3. **Root cause clustering:** group lessons by common root cause. Name the systemic weakness each cluster represents 4. **Improvement backlog ranking:** produce a ranked list of proposed program improvements. Ranking factors: number of source types that produced the pattern, potential impact if unaddressed, effort to implement, alignment with current CISO priorities 5. **Prior-quarter verification:** review improvements that were closed in the prior quarter's aggregation. For each: did the intended effect materialize? (See Section 8) 6. **Output:** a Lessons Aggregation Summary, published within 5 business days, containing: the ranked improvement backlog, prior-quarter verification results, and any Critical lessons that require immediate CISO action ### 5.3 Summary Format The Lessons Aggregation Summary is a structured document, not meeting minutes. It contains: - **Period:** QN YYYY - **Total lessons intake:** count by source, count by severity - **Pattern clusters identified:** named clusters with the source count and lesson IDs contributing to each - **Ranked improvement backlog:** top 5-10 proposed improvements with: improvement ID (from IMPREG-001), description, accountable role, target quarter - **Prior-quarter verification:** for each previously closed improvement: verified effective / partially effective / ineffective, with rationale - **Escalations:** any Critical lessons not yet dispositioned --- ## 6. Improvement Action Pipeline A lesson that produces an improvement action follows this pipeline from identification to program integration. ### 6.1 Improvement Action Types | Type | Description | Example | |---|---|---| | Control baseline amendment | A new or modified control in CB-001 | Add a control requiring credential rotation enforcement at provisioning | | Standard revision | A change to a CERG standard | Amend STD-CFG-001 to specify DMZ TLS configuration requirements | | Procedure update | A change to an existing procedure | Add a pre-production checklist item to PRC-AR-001 | | New capability | A new tool, platform, or process that does not currently exist | Deploy secrets scanning in CI/CD pipelines | | Training gap flag | A knowledge or awareness gap that contributed to the finding | "Engineers were unaware of the new segmentation standard" : routed to Security Awareness team | | Staffing or budget recommendation | A resource gap identified | "Current VM staffing cannot sustain the SLA with the expanded asset base" | | Metric or threshold change | A change to MTR-001 metrics or thresholds | Tighten the drift-rate threshold after observing 6 consecutive green months | | Retirement | Removal of a control, process, or tool that is no longer effective or relevant | Retire a legacy WAF rule set that no longer matches the threat landscape | ### 6.2 Routing | Improvement Type | Routed To | Approval Authority | |---|---|---| | Control baseline amendment | Governance Pillar Leader | CISO | | Standard revision | Governance Pillar Leader (Policy & Standards Manager) | Governance Pillar Leader | | Procedure update | Procedure owner (per RAC-001) | Pillar owner | | New capability | Relevant pillar leader | CISO (if budget required) | | Training gap flag | Security Awareness team (adjacent program; CERG does not own) | Awareness program lead | | Staffing or budget recommendation | CISO | CISO / Executive Sponsor | | Metric or threshold change | Metric owner | Governance Pillar Leader | | Retirement | Artifact owner | Per catalog authority (CAT-001 Section 4) | ### 6.3 Integration Points Improvements that affect the control baseline or standards feed into the annual review cycle documented in GOV-CAL-001. Improvements that affect metrics feed into the threshold calibration procedure (MTR-001 Section 3.X). Improvements that require new tooling or staffing are routed to the CISO for the next budget cycle. --- ## 7. Improvement Register Integration Every improvement action that reaches the "Approved" state in this procedure is recorded in the Program Improvement Register (CERG-GOV-IMPREG-001). The improvement register is the authoritative record of what changed, why, when, by whom, and with what result. The relationship between this procedure and the improvement register is: - This procedure defines the intake, triage, aggregation, and pipeline - The improvement register is the durable record that tracks each improvement through its lifecycle to verified closure - The risk register (PRC-RM-001) is NOT used for program improvements. When a risk treatment plan requires a program-level change (not just a control implementation or risk acceptance), the change is recorded in the improvement register, not the risk register > **Risk vs. Improvement: A Bright Line** > > A risk register entry: "Vulnerability in SCADA firmware version 4.2 : CVSS 9.1 : treatment: patch within 90 days." This is a risk. It goes in the risk register. > > An improvement register entry: "Three of the last four critical vulnerabilities shared the same root cause: firmware versions were not tracked in the CMDB. Proposed improvement: add automated firmware-version discovery to the asset management platform, amend STD-AM-001 to require firmware version as a tracked attribute, and add firmware-age SLA to PRC-VM-001." This is a program improvement. It goes in the improvement register. > > The distinguishing question: "Is this a specific risk to a specific asset, or is it a change to how the program operates?" If the latter, it belongs in the improvement register. --- ## 8. Verification and Closure No improvement is closed without verification. The verification step is not optional and is not deferred. ### 8.1 Verification Methods | Improvement Type | Verification Method | |---|---| | Control baseline amendment | New or modified control is Implemented in CB-001 and evidence exists for one full review cycle | | Standard revision | Revised standard is published; related procedures updated; compliance check confirms adoption | | Procedure update | Procedure is executed under the new version at least once; operator confirms it works as intended | | New capability | Tool deployed, configured, and producing output; operators trained | | Training gap flag | Confirmation from Awareness team that content was delivered (CERG does not verify training effectiveness : that is the Awareness program's remit) | | Metric or threshold change | New threshold produces actionable signals for one full reporting quarter | ### 8.2 Verification Cadence Verification occurs at the quarterly Lessons Aggregation Review (Section 5). Improvements that were marked "Complete" in the prior quarter are verified. The output is one of three dispositions: - **Effective:** the improvement produced the intended effect. Improvement is closed. - **Partially effective:** the improvement helped but did not fully resolve the root cause. Improvement remains open with an amended approach. - **Ineffective:** the improvement did not produce the intended effect. Improvement is re-opened with additional root cause analysis. The original approach is documented as "attempted and ineffective" : the lesson from the failed improvement is itself a lesson. > **The Verification Honesty Rule** > > The program that marks every improvement "Effective" without evidence is performing, not improving. An ineffective improvement is not a failure : it is a data point that sharpens the next attempt. The scar tissue from a failed improvement is worth more than a dozen unverified claims of success. Record the failure honestly and move to the next approach. ### 8.3 Re-Opened Improvements An improvement marked "Ineffective" or "Partially effective" is re-opened in the improvement register. A new analysis entry is added describing why the original approach failed and what the revised approach will be. The re-opened improvement follows the same pipeline: approval, implementation, verification. --- ## 9. Roles and Responsibilities | Role | Responsibility | |---|---| | **Governance Pillar Leader** | Owns this procedure. Convenes and chairs the quarterly Lessons Aggregation Review. Triage authority for all incoming lesson artifacts. Maintains the improvement register (IMPREG-001). Reports aggregation results to the CISO. | | **CISO** | Approval authority for Critical lessons and any improvement that requires budget, staffing, or control baseline amendment. Attends quarterly aggregation reviews. | | **Risk Pillar Leader** | Produces lesson artifacts for vulnerability, adversarial, intelligence, and near-miss sources. Participates in quarterly aggregation. Accountable for improvement actions in the Risk pillar. | | **Engineering Pillar Leader** | Produces lesson artifacts for architecture, configuration, and design-review sources. Participates in quarterly aggregation. Accountable for improvement actions in the Engineering pillar. | | **Adversarial Testing Lead** | Produces the post-engagement systemic analysis per PRC-AV-001. Ensures pen test findings are analyzed for root cause patterns, not just remediated individually. | | **Incident Commander (IR team)** | Produces post-incident lesson artifacts per PRC-IR-002. Governance Pillar Leader coordinates if the standing IR team does not produce them. | | **Threat Intelligence Analyst** | Produces lesson artifacts for external intelligence shifts. Presents threat landscape changes at quarterly aggregation. | | **Exposure Management Lead** | Produces lesson artifacts when VM metrics signal a systemic weakness. | | **Evidence Librarian** | Archives all lesson artifacts, aggregation summaries, and verification records. Ensures auditability of the lessons-learned pipeline. | | **Policy & Standards Manager** | Receives standard revision actions from the improvement pipeline. Manages the amendment process per the catalog (CAT-001). | --- ## 10. Metrics The effectiveness of this procedure itself is measured. These metrics are reported to the CISO quarterly alongside the aggregation summary. | ID | Name | Formula | Source | Refresh | G / A / R | |---|---|---|---|---|---| | LL-001 | Lesson Artifact Completeness | % of trigger events that produced a lesson artifact within SLA | Lesson intake log | Quarterly | >= 90% / 75-90% / < 75% | | LL-002 | Improvement Closure Rate | % of improvements closed (Effective) within 2 quarters of approval | IMPREG-001 | Quarterly | >= 70% / 50-70% / < 50% | | LL-003 | Verification Pass Rate | % of verified improvements rated Effective | IMPREG-001 | Quarterly | >= 80% / 60-80% / < 60% | | LL-004 | Cross-Source Pattern Rate | Number of pattern clusters identified in quarterly aggregation that drew from 2+ distinct source types | Aggregation summary | Quarterly | n/a: informational; higher is better | | LL-005 | Improvement Aging | % of open improvements older than 2 quarters | IMPREG-001 | Quarterly | <= 20% / 21-40% / > 40% | --- --- ## Appendix A: Lesson Artifact Template The following template captures the 7 required fields for every lesson artifact. ``` LESSON ARTIFACT - LL-YYYY-NNNN 1. SOURCE EVENT Event Type: [Incident / Pen Test / Red Team / Audit / Exercise / Near-Miss / Metric Breach / CISO Directed] Event ID: [IR-YYYY-NNNN / AV-YYYY-NNNN / AUD-YYYY-NNNN / etc.] Event Date: [date event occurred or closed] Event Summary: [one paragraph describing what happened] 2. DATE Artifact Production Date: [date] Produced By: [name, role] 3. SUMMARY What Happened: [factual, concise - what was observed, what the finding was, what failed or succeeded] 4. ROOT CAUSE Direct Cause: [the immediate technical, procedural, or human factor] Systemic Cause: [the underlying standard, process, or control gap that allowed the direct cause] Was This Preventable? [Yes / Partially / No - with rationale] 5. IMPROVEMENT RECOMMENDATION What Should Change: [specific, actionable recommendation] What Standard, Procedure, or Control Is Affected: [document ID(s)] Expected Impact: [how the change prevents recurrence] 6. PRIORITY Severity: [Critical / High / Medium / Low - per Section 4] Urgency: [Immediate / This Quarter / This Year / Opportunistic] 7. OWNER Improvement Owner: [name, role - who will drive the change] Approver: [name, role - who approves the change] Target Completion Date: [date] ``` ## Appendix B: Lessons Aggregation Summary Template ``` LESSONS AGGREGATION SUMMARY - LAS-YYYY-QN PERIOD COVERED Quarter: [Q1 / Q2 / Q3 / Q4] [YYYY] Date Range: [start] to [end] SOURCES REVIEWED | Source Type | Count Reviewed | Count with Artifacts | |---|---|---| | Incidents (P1/P2) | | | | Pen Tests / Red Teams | | | | Audits / Control Tests | | | | Exercises (TTX, DR, BC) | | | | Near-Miss Events | | | | Metric Breaches | | | | CISO-Directed | | | Total Artifacts Produced This Quarter: [N] Overdue Artifacts (from prior periods): [N] KEY THEMES 1. [Theme]: [description, frequency, affected controls/standards] 2. [Theme]: [description, frequency, affected controls/standards] ... IMPROVEMENT ACTIONS RECOMMENDED | Action ID | Description | Priority | Owner | Target Date | |---|---|---|---|---| | | | | | | ACTIONS APPROVED | Action ID | Description | Approved By | Approved Date | |---|---|---|---| | | | | | ACTIONS DEFERRED | Action ID | Description | Reason for Deferral | Next Review Date | |---|---|---|---| | | | | | TREND ANALYSIS (if 4+ quarters available) - Artifact production trend: [increasing / stable / decreasing] - Top recurring theme: [theme] - appeared in [N] of last [M] quarters - Improvement closure rate: [X%] of actions from prior quarter(s) verified closed Prepared by: [Governance Pillar Leader] Date: [date] Reviewed by: [CISO] ``` ## 11. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-LL-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual / After each quarterly lessons-aggregation cycle | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST CSF 2.0 (ID.IM, GOVERN); NIST 800-53r5 (CA, PM); ISO/IEC 27001 A.10 | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed processes, controls, and program functions | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-05-26 | Cyber Governance | Initial draft. Established the lessons-learned intake, triage, quarterly aggregation, improvement pipeline, verification, and improvement register integration procedure. Addresses NIST CSF Adaptive gap: closing the loop from after-action findings to verified program improvements. | --- ## RISK REGISTER AND EXCEPTION PROCESS ### Identification · Treatment · Acceptance · Review --- | | | |---|---| | **Document ID** | CERG-PRC-RM-001 | | **Version** | 1.04 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | | **Review Cycle** | Annual / Upon Significant Change / Major Tooling Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final) · [NIST 800-30r1](https://csrc.nist.gov/pubs/sp/800/30/r1/final) · [NIST 800-39](https://csrc.nist.gov/pubs/sp/800/39/final) · NIST RMF · ISO 31000 | | **Regulations** | NERC-CIP · [CMMC L2](https://dodcio.defense.gov/CMMC/) · [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC · | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Roles and Responsibilities](#2-roles-and-responsibilities) 3. [Risk Identification](#3-risk-identification) 4. [Risk Assessment and Scoring](#4-risk-assessment-and-scoring) 5. [Risk Treatment](#5-risk-treatment) 6. [The Risk Register](#6-the-risk-register) 7. [Exception Process](#7-exception-process) 8. [Approval Authority](#8-approval-authority) 9. [Review, Escalation, and Reporting](#9-review-escalation-and-reporting) 10. [Integration With Other Programs](#10-integration-with-other-programs) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Procedure Control](#12-procedure-control) --- ## 1. Purpose and Scope This procedure operationalizes the risk management principle established in **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Principle 9**. It defines how the organization identifies, documents, scores, treats, reviews, and reports cybersecurity risks, and how exceptions to established controls are requested, approved, tracked, and reviewed. The risk register is the single, authoritative record of organizational cybersecurity risk. The exception process is the single, authoritative record of intentional deviations from established controls. The two are coupled: every approved exception is itself a risk-register entry. ### 1.1 Scope This procedure applies to: - All cybersecurity risks affecting in-scope assets, data, or operations - All deviations from controls established in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) and its subordinate standards and procedures - All risk-related decisions requiring documentation: acceptance, transfer, avoidance, and reduction - All organizational personnel, every CERG team member, every asset owner, every business sponsor of a system or process that holds cybersecurity risk ### 1.2 The Operating Premise > **Undocumented Risk Is Accepted Risk Without an Owner** > > Every organization has more risk than it has time to remediate. The question is not whether risk exists, it is whether the organization has a documented, owned, and reviewed posture toward each one. An undocumented risk that materializes into an incident leaves no audit trail of what was known, who knew it, or why nothing was done. CERG treats the risk register as evidence of program maturity, not as a chore. --- ### 1.3 Risk Appetite and Tolerance The organization's risk appetite defines the amount and type of risk the organization is willing to accept in pursuit of its objectives. Without a stated appetite, "accept" decisions lack an objective anchor, and scoring discussions drift toward personal calibration. #### Appetite Statement The organization accepts residual risk only where (a) the cost or operational impact of further treatment demonstrably exceeds the residual risk, (b) compensating controls are in place and operating effectively, and (c) the risk does not threaten regulatory standing, customer trust, or safety. Risk that cannot satisfy all three conditions must be treated. #### Quantitative Tolerance Thresholds The durations below are scope-specific treatment horizons. They do not extend risk-acceptance authority or duration beyond the canonical limits in [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7; when more than one rule applies, the shortest applicable duration wins. | **Tier / Scope** | **Maximum Acceptable Residual Risk Score** | **Maximum Acceptable Treatment Horizon** | **Notes** | |---|---|---|---| | BES Cyber Systems (NERC-CIP) | 6 (Medium-Low) | 90 days | Aligned to CIP mitigation plan timelines | | CUI Environments (CMMC) | 6 (Medium-Low) | 90 days | Aligned to POA&M timelines; Critical not acceptable | | SOX-Relevant Systems | 8 (Medium) | 180 days | ITGC compensating controls required | | Production Tier 1 (Customer-Facing) | 8 (Medium) | 180 days | Critical not acceptable without CISO + Executive Sponsor | | Production Tier 2 (Internal Business) | 10 (Medium-High) | 365 days | | | Production Tier 3+ / Non-Production | 12 (High-Low) | 365 days | | | SaaS / Third-Party | 10 (Medium-High) | Contract cycle | Driven by vendor tier per [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | #### Tolerance by Business Unit Tolerance thresholds may vary by business unit where the business unit operates under materially different regulatory, contractual, or operational risk profiles. Business unit tolerance adjustments are proposed by the Risk Owner in that unit, reviewed by the Governance Pillar Leader, and approved by the CISO. Adjustments are recorded in the risk register as a standing annotation on the business unit's scope. #### Board and Leadership Engagement The board or an authorized board committee reviews and affirms the organization's risk appetite annually. Material changes to risk appetite - including adjustments to quantitative thresholds or tolerance by business unit - are submitted to the CISO for recommendation and board approval. The CISO owns the annual appetite affirmation cycle and reports the organization's actual risk posture against appetite at each quarterly CISO-level review. --- ## 2. Roles and Responsibilities | **Role** | **Risk Management Responsibility** | |---|---| | **Risk Register Owner** | Owns this procedure and the risk register tool. Maintains the data model, taxonomy, dashboards, and reporting. Coordinates the risk review cadence. Curates the register for quality and completeness. | | **Risk Pillar Leader** | Identifies risks through exposure management, threat intelligence, vendor assessment, adversarial testing, and continuous monitoring. Records risks in the register and recommends scoring and treatment. | | **Engineering Pillar Leader** | Identifies risks through architecture review and pre-production assessment. Recommends compensating controls. Implements risk-reduction treatments on assets it supports. | | **Business / Asset Owners (Risk Owners)** | Accountable for the risks associated with the systems and processes they own. Authorize treatment decisions for their scope. Sign on risk acceptances. | | **Approvers (Engineering Pillar Leader → CISO → Executive Sponsor)** | Apply the approval matrix in Section 8. Approvers do not own risks; they authorize the treatment decision against organizational policy. | | **CISO** | Approves High and Critical risk acceptances and material exceptions. Owns escalation to executive leadership and the board. Owns the overall organizational risk posture. | | **Internal Audit and Compliance Partners** | Consume the register as evidence of risk management activity. Verify integrity of the process through periodic audit. | --- ## 3. Risk Identification A risk is a potential event that could adversely affect organizational assets, operations, or obligations. Risks may be technical (a vulnerability, a misconfiguration, a control gap), programmatic (a process gap, a staffing gap), or external (a regulatory change, a vendor failure, a threat actor's interest). ### 3.1 Sources of Risk Risks are identified continuously from the following sources, each of which feeds the register: | **Source** | **Examples** | |---|---| | Exposure management | Out-of-SLA findings, KEV exposures, structural patching limitations. | | Engineering review | Architectural gaps identified in pre-production review, IT/OT convergence findings, technical debt with security implications. | | Adversarial validation | Pen-test findings, red-team paths to crown-jewel assets, control-bypass discoveries. | | Third-party / vendor risk | SOC 2 / ISO 27001 / FedRAMP exceptions, vendor incidents, supply-chain advisories. | | Threat intelligence | Threats specifically targeting the organization's industry, technology, or geography. | | Compliance monitoring | Findings from internal compliance reviews, regulator examination, external audit. | | Incident review | Root causes from post-incident reviews. | | Exception requests | Approved exceptions, which become risk-register entries. | | Strategic / programmatic | Staffing shortfalls, tooling gaps, sunset of unsupported platforms. | | Self-reporting | Risk submissions by any personnel through the documented intake. | ### 3.2 Intake Any personnel may submit a candidate risk through the centralized intake. Submissions include the proposed risk statement, affected assets, observed or estimated impact, and supporting context. Governance triages submissions within 5 business days into one of: accept as new register entry, merge with existing entry, escalate to active investigation, or return with explanation. --- ## 4. Risk Assessment and Scoring ### 4.1 Risk Statement Each risk is expressed in a consistent, declarative form: > "**[Event / condition]** affecting **[asset class / scope]** could result in **[impact]** within **[likelihood window]** unless **[control / treatment]**." Risk statements are specific enough to support scoring. "We need better cloud security" is not a risk statement; "Unauthorized changes to production cloud IAM roles could result in privilege escalation enabling exfiltration of customer data within the current control period unless drift detection and JIT elevation are enforced" is. ### 4.2 Scoring Framework Risks are scored using the canonical 5×5 **Likelihood × Impact** model in [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.5. This procedure operationalizes that model; it does not define a separate scoring scale. If this procedure and RMF-001 differ, RMF-001 governs. The matrix produces a residual risk rating after considering controls in place. Inherent risk (controls hypothetically absent) is recorded but not the primary driver of treatment decisions. #### Likelihood Summary | **Score** | **RMF Label** | **Operational Meaning** | |---|---|---| | 1 | Very Low | No specific indicator; outside common attack or failure patterns for the organization. | | 2 | Low | Occurs in the industry occasionally; no current indicator at the organization. | | 3 | Medium | Realistic given the threat landscape; mitigating controls reduce likelihood. | | 4 | High | Frequent in the industry; conditions present at the organization with limited mitigation. | | 5 | Very High | Active or imminent; observed indicators, active exploitation, or minimal current mitigation. | #### Impact Summary | **Score** | **RMF Label** | **Operational Meaning** | |---|---|---| | 1 | Negligible | No regulatory, customer, financial, or operational impact beyond routine response. | | 2 | Minor | Limited operational disruption or remediation cost; no regulatory or customer-visible impact. | | 3 | Medium | Material remediation effort, leadership-reportable loss, or limited reputation impact. | | 4 | Major | Significant regulatory exposure, material customer impact, Tier 1 disruption, or significant reputation damage. | | 5 | Catastrophic | Material business / financial impact, broad customer harm, regulatory enforcement, safety or reliability consequence, or SEC-disclosable impact. | #### Rating Bands | **Score Product** | **Rating** | **Default Treatment Expectation** | |---|---|---| | 1 | **Informational** | Track for trend analysis; no formal acceptance required unless another obligation requires it. | | 2–5 | **Low** | Track; treat as resources allow; acceptance follows RMF-001 §9.7. | | 6–11 | **Medium** | Treat within a defined plan; review at standing cadence; acceptance follows RMF-001 §9.7. | | 12–19 | **High** | Treat with priority; acceptance follows RMF-001 §9.7 and requires CISO + Business Owner approval. | | 20–25 | **Critical** | Immediate treatment required; acceptance follows RMF-001 §9.7 and requires CISO + Executive Sponsor approval plus board notification. | ### 4.3 Quantitative Calibration Guide Quantitative calibration is maintained in [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.5 and §12. Local revenue, insurance, downtime, regulatory, and safety thresholds may be calibrated there, but calibrated thresholds do not override the acceptance authority in RMF-001 §9.7. #### Using Calibration in Scoring Discussions The calibration table is a coordination tool, not a precise calculator. When two analysts reach different scores: 1. Each states their rationale in terms of likelihood (what is the annualized frequency?) and impact (what is the estimated financial, operational, regulatory, safety, or customer consequence?). 2. The Governance Lead facilitates the discussion toward the better-supported score using RMF-001 §9.5. 3. If disagreement persists, the higher score is used and the rationale for both scores is recorded. The goal is not perfect precision - it is consistent conversation that produces comparable risk rankings across the register. ### 4.4 Scoring Discipline > **The 5×5 Trap** > > The 5×5 matrix is a coordination tool, not an oracle. Two analysts will reach different scores for the same risk; the value of the matrix is consistency of conversation, not precision of measurement. The Governance Lead enforces consistency within the register and reconciles outliers, but does not fight every score. The goal is comparable risks ranked comparably, not perfect calibration. Re-score upon: material change in observed threat activity, completion of treatment work, new compensating controls, new exploitation indicators, or regulator / customer engagement that materially changes impact. --- ## 5. Risk Treatment Each risk has one of four treatment decisions. Treatment is decided by the risk owner with input from CERG and approved per Section 8. | **Treatment** | **Description** | **When Appropriate** | |---|---|---| | **Reduce (Mitigate)** | Implement or strengthen controls to reduce likelihood, impact, or both. The default treatment for most risks. | Almost always preferred where feasible and timely. | | **Transfer** | Shift the financial or operational consequence to a third party (insurance, contractual indemnity, managed service). | When transfer is economically and operationally rational; not a substitute for treatment of the underlying technical risk. | | **Avoid** | Cease or decline the activity producing the risk. | When the activity is not essential or when residual risk is unacceptable under any treatment. | | **Accept** | Acknowledge the residual risk under documented conditions, owner accountability, expiration/review cadence, and monitoring. | When the cost or operational impact of treatment exceeds the residual risk, the residual is within the organization's tolerance, and the Business Owner or Executive Sponsor accepts the consequence under RMF-001 §9.7. | ### 5.1 Treatment Plan Elements Every treatment decision records: - The selected treatment. - The plan, for Reduce: target end-state controls and the steps to get there; for Transfer: the instrument and counter-party; for Avoid: the cessation steps; for Accept: the rationale and conditions of acceptance. - Owner, accountable for the plan's execution. - Target dates, milestone and final. - Compensating controls, in place now and required for the duration of the plan. - Trigger conditions for re-evaluation, what would invalidate the current decision. ### 5.2 Funding or Capacity Decision Brief When a treatment cannot proceed because funding, staffing, change-window capacity, vendor spend, or business prioritization is unavailable, the Risk Register Owner attaches a Control Funding Decision Brief using [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) §6.1. The brief records the decision needed, control/risk link, business capability affected, options, deadline, and consequence of deferral. A funding or capacity deferral does not by itself accept residual risk. If residual risk remains after the decision, the Business Owner or required RMF-001 authority must complete [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md), and the risk register records the acceptance, expiration, treatment owner, and next review date. ### 5.3 Risk Acceptance Has Two Forms | **Form** | **Description** | |---|---| | **Standing acceptance** | The residual risk is within tolerance for an ongoing activity. Standing acceptance still requires a named Business Owner, periodic re-review, and a register entry; it is not irrevocable or ownerless. | | **Time-bound acceptance** | The risk is accepted for a defined window during which compensating controls operate; treatment is expected to occur within the window. This is the predominant form of acceptance for control deficiencies awaiting remediation. Duration cannot exceed RMF-001 §9.7 or any shorter applicable regulatory/procedure limit. | --- ## 6. The Risk Register ### 6.1 Required Fields | **Field** | **Description** | |---|---| | Risk ID | Unique identifier assigned at intake. | | Risk Statement | The standardized risk statement (Section 4.1). | | Risk Owner | Business or asset owner accountable for the risk. | | Risk Category | Taxonomy classification (e.g., Identity & Access, OT / NERC-CIP, Cloud / SaaS, Third-Party / Supply Chain, CUI / Federal, Application Security, Data Protection, Insider, Resilience). | | Affected Assets / Scope | Systems, data classes, environments. | | Source | Where the risk was identified (Section 3.1). | | Likelihood / Impact / Rating | Current scores and band. | | Inherent Rating | Hypothetical rating absent controls (recorded once at intake; not re-scored each cycle). | | Controls in Place | Existing controls reducing the risk. | | Treatment Decision | Reduce / Transfer / Avoid / Accept. | | Treatment Plan | Plan summary. | | Target Dates | Milestone and final. | | Approver | Approver name and approval date per Section 8. | | Compliance Linkage | Associated regulation, framework, or contract (e.g., 800-171 control reference, CIP standard, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC). | | Linked Exceptions | Exception IDs created under this risk, if any. | | Linked Incidents | Incident IDs that derived from or contributed to the risk, if any. | | Status | Open / In Treatment / Accepted / Closed. | | Review Date | Next scheduled review. | | Audit Trail | History of changes - every score change, treatment change, approver change, status change. | ### 6.2 Quality and Integrity The Governance Lead curates the register for quality. Specifically: - Risks shall not be duplicated; new submissions are merged with existing entries when appropriate. - Risk statements that are vague or unscope-able are returned for clarification. - Risks that are no longer relevant (e.g., the underlying system has been decommissioned) are closed with rationale. - Closed risks remain queryable; the register is append-only at the audit-trail level. ### 6.3 Risk Taxonomy The following taxonomy is the controlled vocabulary for risk categorization. Every risk entry must be assigned exactly one category from this taxonomy. Consistent categorization enables trend analysis, ownership clarity, and regulatory mapping. | **Category** | **Definition** | **Examples** | |---|---|---| | **Identity & Access** | Risks related to identity lifecycle, authentication, authorization, privilege management, and access control failures. | Standing privileged access, MFA gaps, orphaned accounts, over-privileged service principals, credential theft. | | **OT / NERC-CIP** | Risks affecting Operational Technology, BES Cyber Systems, or NERC-CIP compliance posture. | Unpatched OT assets, IT/OT boundary weaknesses, CIP-007 deviation, BCSI exposure. | | **Cloud / SaaS** | Risks arising from cloud platform misconfiguration, SaaS security posture, or cloud-native service exposure. | Open S3 bucket, excessive IAM roles, SaaS OAuth grant abuse, tenant isolation failure. | | **CUI / Data Protection** | Risks to the confidentiality, integrity, or availability of Controlled Unclassified Information or other regulated data. | CUI stored outside authorized boundary, FIPS non-compliance, data spillage, missing encryption at rest. | | **Third-Party / Vendor** | Risks introduced through vendor relationships, supply chain dependencies, or subcontractor access. | Vendor SOC 2 exception, subprocessor concentration, vendor breach with downstream impact. | | **Endpoint** | Risks related to endpoint security, including workstations, servers, and mobile devices. | Missing EDR coverage, unpatched endpoint, local admin abuse, removable media exposure. | | **Network** | Risks to network segmentation, perimeter controls, traffic inspection, or remote access. | Flat network, exposed management interface, missing segmentation between regulatory zones. | | **Application Security** | Risks in custom or third-party application code, APIs, or application architecture. | SQL injection, broken authentication in custom app, API key exposure, SSRF vulnerability. | | **Cryptography** | Risks related to cryptographic key management, algorithm selection, certificate lifecycle, or secrets handling. | Expired certificate, weak cipher suite, hard-coded secret, missing HSM for CA key. | | **Governance / Compliance** | Risks from gaps in policy, process, regulatory alignment, or program maturity. | Missing policy review cycle, undocumented exception process, audit finding without remediation plan. | | **Resilience** | Risks to business continuity, disaster recovery, backup integrity, or service restoration capability. | Untested backups, single-region dependency, RTO/RPO gap for Tier 1 system. | | **Insider** | Risks from intentional or unintentional actions by authorized personnel. | Data exfiltration by departing employee, accidental PII exposure, privilege misuse. | | **Physical / Environmental** | Risks from physical access, environmental controls, or facility security. | Unsecured data center access, missing CCTV coverage, inadequate fire suppression. | Access and Confidentiality Risk register access is role-based. Business owners see their scope by default; CERG personnel see organization-wide. Specific risk entries may be marked Restricted (e.g., active high-sensitivity exposure, insider matters) with limited visibility. The CISO has full visibility at all times. --- ## 7. Exception Process ### 7.1 Exception vs. Risk Acceptance — Which Path to Use Per [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7a, CERG distinguishes two distinct decision paths. Using the wrong path bypasses the required approval authority. | **Path** | **Description** | **Form** | **Approval** | **Register** | |---|---|---|---|---| | **Security Exception** (Governance-tracked) | A specific control or standard cannot be met as written. The deviation is temporary, with compensating controls, expiration, and a remediation plan. | [`CERG-TMPL-RM-002`](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) — Security Exception Request Form | Governance approves within authority per §8. Assessment by Risk and Engineering. | Exception register; linked to risk register entry | | **Risk Acceptance** (Business Owner + RMF-001 §9.7) | The residual risk after controls is within appetite. No further treatment is planned beyond monitoring. The Business Owner explicitly accepts the business consequence. | [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) — Risk Acceptance Request Form | Per RMF-001 §9.7 authority table: Business Owner at all levels; CISO for High; CISO + Executive Sponsor for Critical. | Risk register (accepted status) | **Routing rule:** If the trigger is a control or standard that cannot be met → Security Exception (TMPL-RM-002). If the trigger is residual risk the organization chooses to live with → Risk Acceptance (TMPL-RM-004). When in doubt, route as Security Exception; the Risk Register Owner may reclassify during triage. ### 7.2 What Requires an Exception An exception is required whenever a system, person, or process intentionally deviates from a control established in [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) or its subordinate standards. Examples include: - A system that cannot meet a hardening baseline due to a vendor or operational constraint - A user role that requires standing privileged access despite the JIT requirement - A SaaS application not behind SSO due to a technical limitation - A vulnerability remediation that cannot meet the SLA - A vendor account configuration not meeting the access management standard - An OT system that cannot satisfy a CIP-007 requirement on schedule (in addition to the CIP deviation process) ### 7.3 Exception Workflow | **Step** | **Action** | **Owner** | |---|---|---| | 1 | Requester submits exception with: control reference, business / operational justification, affected systems, proposed compensating controls, risk owner, and proposed duration. | Requester | | 2 | Engineering reviews proposed compensating controls. | Engineering | | 3 | Risk assesses likelihood and impact of the residual risk; provides a written risk finding. | Risk | | 4 | Governance applies the approval matrix (Section 8); routes for approval. Business owner approval is required for any exception carrying residual risk above Low. | Governance | | 5 | Approver decides: approve, approve with conditions, deny, or return for additional information. | Approver | | 6 | Approved exception is entered into the exception register and linked to the risk register when residual exposure exists; compensating controls are tracked. | Governance | | 7 | At expiration, the exception is re-evaluated. Renewal requires a new approval cycle. Renewals shall not be granted by default. | Governance | ### 7.4 Exception Discipline > **Renewals Are Where Programs Decay** > > The most common failure mode of an exception program is the silent renewal. An exception is approved with a six-month duration; six months later it is renewed with a single email; six months after that the original reviewers have left the organization, the compensating controls have drifted, and the underlying control gap has become permanent. Governance enforces re-evaluation at every renewal: confirm the compensating controls are still in place, confirm the business justification is still valid, confirm the requested duration is still reasonable. ### 7.4.1 Exception Expiration Warning Chain Every exception carries an expiration date. The following warning chain ensures no exception expires silently: | Timing | Action | Actor | |--------|--------|-------| | **30 days before expiration** | Automated notification to Exception Owner and Risk Register Owner | Governance (Evidence Librarian or automated calendar) | | **14 days before expiration** | Escalation notification to Pillar Leader; Exception Owner must confirm renewal request submitted or closure planned | Risk Register Owner | | **7 days before expiration** | Final escalation to Governance Pillar Leader; Exception Owner must have a disposition (renew, close, or convert to finding) | Governance Pillar Leader | | **Post-expiration (Day 0)** | Auto-create Finding Record (severity: High); flag affected control as "gap open"; the exception is no longer valid | Risk Register Owner | | **Post-expiration (Day 5)** | If no disposition: escalate to CISO | Governance Pillar Leader | An exception renewed more than twice without material progress toward remediation escalates one approval tier above the original approver. If the renewal also accepts residual risk, the approval path follows RMF-001 §9.7. The renewal justification must document what has changed since the previous approval and what prevents closure. ### 7.5 Regulatory Overlays For exceptions affecting regulated assets: - **NERC-CIP (BES Cyber Systems):** A CIP deviation and mitigation plan is initiated in addition to this exception. Governance coordinates per [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) §11. - **[CMMC](https://dodcio.defense.gov/CMMC/) / 800-171 (CUI environments):** A POA&M entry is opened in addition to this exception, per [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) §11. - **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems:** Internal Audit and CFO designee are notified for ITGC control gaps. Compensating ITGC controls are documented for audit. - **Customer / contractual:** Where the affected control supports a customer contractual commitment, Account Management and Legal are notified for customer-notification decisions. --- ### 7.6 Exception Request Form and Risk Acceptance Form Templates The following templates shall be used for all exception and acceptance requests. Use the correct form per the routing rule in §7.1. Completed forms are submitted through the centralized risk intake and referenced in the risk register. **For Security Exceptions** (policy/standard deviation, Governance-tracked): use [`CERG-TMPL-RM-002`](../templates/CERG-TMPL-RM-002_Security_Exception_Request_Form.md) — Security Exception Request Form. **For Risk Acceptances** (Business Owner accepts residual risk, per-RMF-001 authority): use [`CERG-TMPL-RM-004`](../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) — Risk Acceptance Request Form. The Security Exception Request Form (TMPL-RM-002) template is reproduced below for reference. The Risk Acceptance Request Form (TMPL-RM-004) is a separate artifact. [`CERG-TMPL-RM-003`](../templates/CERG-TMPL-RM-003_Risk_Acceptance_Memo_Template.md) may be attached as a lightweight memo, but it does not replace TMPL-RM-004 or RMF-001 §9.7 approval authority. ``` EXCEPTION REQUEST FORM - EXC-YYYY-NNNN 1. REQUESTOR Name: Role / Title: Department / Business Unit: Date of Request: 2. CONTROL(S) TO BE EXCEPTED Control ID (from CERG-GOV-CB-001 or applicable standard): Control Description: Standard / Policy Reference: 3. AFFECTED SCOPE System(s) / Asset(s): Environment (IT / Cloud / SaaS / OT): Data Classification(s): Regulatory Scope (NERC-CIP / CUI / SOX / Other): Number of Users Impacted: 4. BUSINESS JUSTIFICATION Why is the exception necessary? What business outcome depends on it? What alternatives were considered and why were they rejected? 5. RISK ASSESSMENT OF THE EXCEPTION Inherent Risk (Likelihood × Impact): Description of the risk created by this exception: Existing Compensating Controls: Residual Risk after Compensating Controls (Likelihood × Impact): Residual Risk Rating (Low / Medium / High / Critical): 6. COMPENSATING CONTROLS (detailed) | Control | Description | Owner | Implementation Date | Validation Method | |---|---|---|---|---| | | | | | | 7. DURATION Proposed Start Date: Proposed End Date: Renewal Expected? (Yes / No): If yes, what conditions must be met for renewal? 8. APPROVAL | Role | Name | Decision | Date | |---|---|---|---| | Business Owner (Risk Owner) | | Approve / Deny / Conditional | | | Engineering Pillar Leader | | Approve / Deny / Conditional | | | Governance Pillar Leader | | Approve / Deny / Conditional | | | CISO (if High or Critical) | | Approve / Deny / Conditional | | | Executive Sponsor (if Critical) | | Approve / Deny / Conditional | | 9. RISK REGISTER LINKAGE Risk Register Entry ID: Exception ID cross-reference: 10. CLOSURE Actual End Date: Closure Rationale: Closure Approver: ``` --- ## 8. Approval Authority Risk treatment decisions require documented approval from the authority matching the risk's severity. The canonical approval authority table — including the Business role at every level — is maintained in [CERG-GOV-RMF-001](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. The table below summarizes approval authority for convenience; the RMF table is authoritative. Security assesses, recommends, and validates. The business owner owns the consequence. | **Risk Rating / Treatment** | **Security Role** | **Business Role** | **Approval** | |---|---|---|---| | Low risk – Accept or exception | Governance: confirms procedural exception; Risk: confirms low residual risk if needed | Business Owner: owns local consequence | Business Owner + Risk Register Owner | | Medium risk – Reduce / Transfer / Avoid | Risk: performs risk assessment; Engineering: validates treatment plan | Business Owner: signs off on treatment | Risk or Engineering Pillar Leader | | Medium risk – Accept | Risk: performs risk assessment; Governance: documents conditions | Business Owner: accepts residual risk | Business Owner + Pillar Leader or Governance Pillar Leader | | High risk – Accept | Risk: signs finding; Governance: structures package | Business Owner: accepts business consequence | CISO + Business Owner | | Critical risk – Accept | Risk: signs finding; Governance: structures package | Executive Sponsor: accepts business consequence | CISO + Executive Sponsor; Board notified | | Any exception affecting BES Cyber Systems | As above per severity | As above | As above + NERC-CIP deviation process | | Any exception affecting CUI environment posture | As above per severity | As above | As above + POA&M entry | | Any exception affecting [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC | As above per severity | As above | As above + CFO designee notification or approval where required by SOX governance | | Emergency exception (operational necessity) | Risk Pillar Leader or Engineering Pillar Leader may authorize immediately to protect operations | Business Owner notified within 24 hours and required for any continuing residual-risk acceptance | CISO must approve or deny post-hoc within 24 hours. If denied, the action must be reversed or mitigated, and the residual risk is logged to the risk register with the denial rationale. Continuing acceptance follows RMF-001 §9.7. | Approvers may delegate within their authority but shall document the delegation. The CISO retains final authority for any risk-related decision. Acceptance of residual risk at any tier follows the canonical authority table in [CERG-GOV-RMF-001](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. The business owner accepts the business risk — security does not accept business risk. No acceptance expires automatically; every acceptance at every tier requires a fresh approval cycle at expiration. --- ## 9. Review, Escalation, and Reporting ### 9.1 Review Cadence | **Item** | **Cadence** | **Owner** | |---|---|---| | Risk owner self-review of open risks in their scope | Quarterly | Risk Owner | | Governance curation pass (quality, duplicates, status) | Monthly | Governance | | CERG leadership review (Engineering + Risk + Governance) | Monthly | Governance | | CISO-level risk review with material movement and overdue items | Quarterly | CISO + Governance | | Executive / board risk briefing | Quarterly (or per board protocol) | CISO | | Standing exception re-review | At exception expiration; no automatic renewal | Governance | ### 9.2 Escalation Triggers The following trigger escalation to the CISO outside the standing cadence: - A new High or Critical risk - A material score increase on any existing risk - A risk acceptance approaching expiration without a credible treatment plan - A material deterioration in compensating control performance - Realization of a risk into an incident - A regulator or auditor inquiry referencing a register entry - A renewal request for an exception in its second consecutive cycle ### 9.3 Reporting Standing reports (consumed by Governance dashboards): | **Report** | **Audience** | **Cadence** | |---|---|---| | Top risks (by rating and by trend) | CISO | Monthly | | Open exceptions by environment | CERG Leadership | Monthly | | Overdue treatments / expired exceptions | Governance | Weekly | | Risks by category trend (Identity, Cloud, OT, CUI, Third-Party, etc.) | CISO + executive | Quarterly | | Risks linked to active incidents | IC + CISO | Continuous during active response | | Regulatory-specific posture (CIP, [CMMC](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)) | Governance + Regulatory partners | Per regulator cycle | ### 9.4 Quality Indicators The Governance Lead monitors the register itself for health: - Median age of open High and Critical risks - % of treatment plans on schedule - Exception re-evaluation rate (declined vs. renewed) - % of risks with a documented owner - % of risks reviewed within their scheduled review date --- ## 10. Integration With Other Programs The risk register is the integration point for several other programs. Risk-register entries derive from and feed back into: | **Program** | **Integration** | |---|---| | Exposure Management ([CERG-PRC-VM-001](CERG-PRC-VM-001_Exposure_Management_Procedure.md)) | Out-of-SLA findings and aggregate exposure feed risk entries; large remediation campaigns are tracked as treatments. | | Incident Response ([CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md)) | Post-incident corrective actions are recorded as risks or risk-acceptance closures. | | Vendor / Third-Party Risk | Vendor assessment findings open risks; vendor reassessment cadence reviews them. | | Compliance - NERC-CIP, [CMMC](https://dodcio.defense.gov/CMMC/), [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) | Open compliance gaps map to risk entries; POA&M and CIP deviations link to register entries. | | Architecture / Engineering Review | Pre-production review findings open risks where acceptance is sought to deploy. | | Awareness & Insider Programs | Concentrated insider-risk indicators are recorded (with appropriate restricted visibility). | | Audit | Internal Audit and external audit observations open or update risk entries. | The register is not a parallel system to these programs. It is the connective tissue that lets each program point to the same set of facts. --- ## 11. Regulatory and Framework Alignment Summary | **Process Area** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | **[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)** | **NIST RMF** | **NERC-CIP** | **[CMMC L2](https://dodcio.defense.gov/CMMC/)** | **[SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) ITGC** | |---|---|---|---|---|---|---|---| | Risk Strategy & Governance | GV.RM | PM-9 | 3.11.1 | Steps 1–2 | CIP-003 | RM.L2-3.11.1 | ERM interface | | Risk Assessment / Scoring | ID.RA | RA-3 | 3.11.1 | Step 3 | CIP-002 / 007 | RM.L2-3.11.1 | - | | Risk Treatment | GV.RM | PM-4, CA-5 | 3.11.3 | Steps 3–5 | CIP-003 | RM.L2-3.11.3 | - | | Risk Acceptance | GV.RM | CA-6 | 3.12.2 | Step 5 | CIP-003 | CA.L2-3.12.2 | - | | Exception / POA&M | GV.RR | CA-5 | 3.12.2 | Step 5 | CIP Mitigation Plans | CA.L2-3.12.2 | - | | Continuous Monitoring of Risk | DE.CM, ID.IM | CA-7 | 3.12.3 | Step 6 | CIP-007 | CA.L2-3.12.3 | Monitoring | | Reporting & Communication | GV.RR | PM-9, PM-31 | 3.12.3 | Step 6 | CIP-003 | CA.L2-3.12.3 | Reporting | --- ## 12. Procedure Control | | | |---|---| | **Document ID** | CERG-PRC-RM-001 | | **Version** | 1.04 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Approved By** | CISO | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-14 | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 · NIST RMF | | **Regulations** | NERC-CIP · CMMC L2 · SOX ITGC | | **Environments** | All in-scope environments | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.04 | 2026-06-18 | Governance Pillar Leader | Added funding/capacity decision brief routing and clarified that funding deferral does not itself accept residual risk. | | 1.03 | 2026-06-18 | Governance Pillar Leader | Made RMF-001 the explicit source of truth for scoring and acceptance authority, removed competing local calibration thresholds, clarified Business Owner consequence acceptance, and constrained TMPL-RM-003 to a supporting memo role. | | 1.02 | 2026-06-18 | Governance Pillar Leader | Added §7.1 Exception vs. Risk Acceptance routing table distinguishing Security Exception (→TMPL-RM-002, Governance-tracked) from Risk Acceptance (→TMPL-RM-004, Business Owner + RMF-001 authority). Renumbered subsequent subsections. Updated §7.6 template references. | | 1.01 | 2026-06-14 | Governance Pillar Leader | Aligned scoring bands, approval summaries, and duration guidance to the canonical RMF authority table. | | 1.0 | 2026-05-01 | CERG Governance | Initial release | ### Review Triggers This procedure shall be reviewed annually and upon any of the following: - Material change to risk taxonomy or scoring scheme - Material change to risk-management tooling - Material change to regulatory expectations affecting risk acceptance, POA&M, or CIP deviation processes - A significant incident or audit finding affecting the program - Direction from the CISO Governance owns this procedure. The Risk Register Owner is responsible for revisions, ongoing maintenance, and obtaining CISO approval for material updates. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - Principle 9 | | Grid and Control System Standard | [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT risk and CIP deviation overlay | | IT / Cloud / SaaS Security Standard | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | IT/Cloud/SaaS risk scope, tier-based control expectations | | CUI Handling Standard | [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | CUI risk scope, POA&M tracking | | Access Management Standard | [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Identity-related risk and access exception handling | | Unified Control Baseline | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control framework that risk entries reference | | Exposure Management Procedure | [CERG-PRC-VM-001](CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Vulnerability risk acceptance path | | Adversarial Validation Procedure | [CERG-PRC-AV-001](CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | Adversarial testing finding risk acceptance | | Third Party and Supply Chain Risk Procedure | [CERG-PRC-TPRM-001](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor risk register entries and tier-based acceptance authority | | Architecture Review and Project Intake Procedure | [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Project review findings flow to risk register | | CERG Operating Model | [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Pillar structure and risk governance | --- > > _Identify it. Score it. Record it. Own it._ --- _CERG-PRC-RM-001 · Version 1.01 · Public_ --- ## SECURITY CHANGE MANAGEMENT PROCEDURE ### Change Security Review · Emergency Changes · Control Impact · SOX ITGC Linkage --- | | | |---|---| | **Document ID** | CERG-PRC-CHG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) · [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | | **Review Cycle** | Annual / On material change to enterprise change management or SOX scope | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CM, SA, CA) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GOVERN, PROTECT) · ISO/IEC 27001 A.8.32 · CIS Controls v8 | | **Regulations** | SOX ITGC · CMMC L2 / 800-171r3 · NERC-CIP where changes affect scoped systems | | **Environments** | All security-relevant changes to CERG-managed systems, platforms, controls, and regulated environments | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [What Is a Security-Relevant Change](#3-what-is-a-security-relevant-change) 4. [Change Categories](#4-change-categories) 5. [Security Review Requirements](#5-security-review-requirements) 6. [Emergency Changes](#6-emergency-changes) 7. [SOX and Regulated-Scope Changes](#7-sox-and-regulated-scope-changes) 8. [Evidence and Records](#8-evidence-and-records) 9. [Metrics](#9-metrics) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Regulatory and Framework Alignment Summary](#11-regulatory-and-framework-alignment-summary) 12. [Document Control](#12-document-control) --- ## 1. Purpose and Scope CERG does not replace the enterprise change management process. It supplies the security review discipline that process needs. A change can be operationally approved and still be a bad security change if it weakens a baseline, creates a new trust boundary, bypasses logging, changes privileged access, affects SOX scope, or pushes unresolved risk into production. This procedure defines how security-relevant changes are identified, reviewed, evidenced, escalated, and linked to risk acceptance or architecture review. It also defines the minimum security handling for emergency changes and for changes affecting SOX ITGC, CUI, NERC-CIP, and other regulated scope. > **Change Management Is Where Controls Stay True** > > A baseline is not defeated all at once. It erodes one exception, one rushed firewall rule, one emergency admin grant, one disabled log source at a time. Security change management is the discipline that catches that erosion while it is still a change request, not a finding six months later. --- ## 2. Principles 1. **CERG reviews security impact, not business priority.** The business decides whether a change is important. CERG decides whether the change weakens, bypasses, or requires controls. 2. **Security review is proportional.** A minor baseline-preserving change does not need a full architecture review. A material change to identity, network, data, cloud, OT, or regulated scope does. 3. **Emergency does not mean undocumented.** Emergency changes may move faster, but they still record what changed, why, who approved it, and how it was reviewed afterward. 4. **Changes with residual risk use the risk process.** A change that introduces unresolved security risk is not waved through informally. It is remediated or accepted through [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). 5. **SOX scope gets evidence discipline.** Financially relevant systems require stronger change evidence: request, approval, testing, implementation, and segregation of duties. --- ## 3. What Is a Security-Relevant Change A change is security-relevant if it creates, removes, weakens, bypasses, or materially alters a security control, trust boundary, privileged access path, sensitive data path, or regulated system. Security-relevant changes include: - network segmentation, firewall, routing, remote access, VPN, or proxy changes; - identity provider, MFA, SSO, privileged access, service account, or federation changes; - cloud landing zone, account, subscription, tenant, storage, or policy changes; - endpoint, EDR, MDM, logging, backup, or cryptography control changes; - changes to applications that process Confidential or Restricted data; - changes to SOX, CUI, NERC-CIP, OT, or safety-impacting environments; - new third-party data exchange or vendor integration; - emergency control bypasses; - new AI capability or AI-enabled feature touching business data; - changes that resolve or introduce a risk-register item. A change not on this list may still be security-relevant if the Engineering Pillar Leader, Risk Pillar Leader, or Governance Pillar Leader determines that it affects control posture. ### 3.1 Materiality The term "material" is used throughout this procedure and related CERG documents to distinguish changes that fundamentally alter security posture from those that are routine. A change is "material" if it meets any of the following criteria: - Affects systems in SOX, CUI, or NERC-CIP regulated scope - Modifies trust boundaries or network segmentation between environments - Introduces new external connectivity (internet-facing services, vendor interconnects, API gateways) - Changes identity or privilege models (federation, PAM topology, role-based access architecture) - Introduces a new data classification into an environment - Impacts more than 100 users or a customer-facing production service - Introduces a new SaaS platform, cloud account, or cloud service A change is explicitly NOT material if it: - Is a routine patch or version upgrade within the same product line - Reuses a pre-approved architecture pattern without modification - Adds capacity to an already-reviewed system without changing its architecture - Is a configuration change within the DISH-conformant baseline - Is a standard user provisioning or de-provisioning action When classification is ambiguous, the Engineering Pillar Leader determines materiality in consultation with the relevant pillar leader for the affected scope. --- ## 4. Change Categories | **Category** | **Definition** | **Security Handling** | |---|---|---| | Standard security-preserving change | Pre-approved, low-risk, repeatable, and does not weaken a control. | Evidence retained; no separate CERG review unless sampled. | | Normal security-relevant change | Planned change with security impact. | CERG review before implementation. | | Material architecture change | Creates new trust boundary, data path, identity pattern, internet exposure, vendor integration, AI capability, or regulated scope. | Architecture review under [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | | Emergency change | Must be implemented before normal review to restore service, contain risk, or meet urgent operational need. | Emergency approval plus post-implementation security review. | | Control bypass or exception | Temporarily or permanently weakens an approved control. | Risk acceptance or exception under [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | ### 4.1 Security Review Workflow The following workflow defines the step-by-step process from change submission through security review to closure. | **Step** | **Action** | **Owner** | **Decision Point** | |---|---|---|---| | 1 | Change submitted through the enterprise change management system | Requester | - | | 2 | Security relevance determination: is the change security-relevant per Section 3? | Engineering Pillar Leader or delegate | If No: no CERG review required. If Yes: proceed to Step 3 | | 3 | Categorization: classify the change per Section 4 (Standard / Normal / Material / Emergency / Control Bypass) | Engineering Pillar Leader or delegate | - | | 4 | Route to appropriate reviewer based on change type and affected scope | Engineering Pillar Leader | Cloud, Identity, OT, AppSec, or Endpoint Engineer as appropriate | | 5 | Security review: evaluate against minimum review questions (Section 5.1) | Designated reviewer | - | | 6 | Decision: determine review outcome | Designated reviewer | **Approved** → proceed to Step 8. **Approved with Conditions** → proceed to Step 7. **Requires Architecture Review** → enter PRC-AR-001. **Requires Risk Acceptance** → enter PRC-RM-001. **Rejected** → return to requester with rationale | | 7 | Conditions met: requester satisfies conditions; reviewer verifies | Requester + Reviewer | Conditions verified → proceed to Step 8 | | 8 | Evidence recorded: change record captures review decision, approver, date, conditions (if any), and linked risk/architecture actions | Reviewer | - | | 9 | Implementation: change is executed per the enterprise change management process | Implementer | - | | 10 | Closure: post-implementation validation confirms the change achieved its objective without unintended security impact | Reviewer or delegate | Closed | #### Decision Points Summary ``` Change Submitted │ ├── Not security-relevant ──► No CERG review │ └── Security-relevant │ ├── Standard (sampled) ──► Sample review or no review ├── Emergency ──► Emergency approval + post-review └── Normal / Material / Control Bypass │ ├── Approved ──► Implement + Evidence ├── Approved with Conditions ──► Conditions met → Implement + Evidence ├── Requires Architecture Review ──► PRC-AR-001 ├── Requires Risk Acceptance ──► PRC-RM-001 └── Rejected ──► Return to requester ``` ### 4.2 Sampling Methodology for Standard Changes Standard security-preserving changes do not require individual CERG review, but a sample is reviewed each month to verify that the "standard" classification is accurate and that security posture is not degrading through accumulated small changes. | **Parameter** | **Value** | |---|---| | Sampling rate | 10% of standard changes per month (minimum 5, maximum 50) | | Selection method | Random selection with risk-based oversampling | | Risk-based oversampling criteria | Changes affecting regulated scope (SOX, CUI, NERC-CIP); changes by team members with < 6 months tenure; changes outside business hours; changes to systems with Critical or High open risk-register entries | | Documentation | Sampling results recorded monthly; any standard change found to be misclassified is re-categorized and reviewed retroactively | | Trend monitoring | If > 5% of sampled standard changes are found to be misclassified (should have been Normal or Material), the sampling rate increases to 20% until the trend resolves | --- ## 5. Security Review Requirements ### 5.1 Minimum Review Questions Every normal security-relevant change answers these questions before implementation: 1. What system, control, data path, or trust boundary changes? 2. What data classification is affected? 3. Does the change affect identity, privilege, logging, encryption, backup, segmentation, endpoint posture, or vendor access? 4. Does the change affect SOX, CUI, NERC-CIP, OT, or other regulated scope? 5. Does the change create a new threat model trigger under [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md)? 6. Does the change create residual risk, and if so, is that risk recorded and approved? 7. What evidence will prove the change was approved, tested, implemented, and verified? 8. What rollback or recovery plan exists? ### 5.2 Review Outcomes | **Outcome** | **Meaning** | |---|---| | Approved | Security review finds no unresolved issue blocking implementation. | | Approved with conditions | Change may proceed only if named conditions are met. | | Requires architecture review | Change exceeds normal change review and enters [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | | Requires risk acceptance | Change introduces residual risk requiring [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | | Rejected | Change weakens control posture without sufficient mitigation or acceptance. | A change cannot be closed as security-approved until conditions, risk acceptances, or architecture-review actions are linked. ### 5.3 Security Review SLAs Security reviews are time-bound to prevent the review process from becoming a bottleneck. The following SLAs apply from the time a complete change request is received. | **Change Category** | **SLA** | **Notes** | |---|---|---| | Emergency security review | 4 hours | Reviewer must respond within 4 hours; post-implementation review within the next business review cycle | | Material architecture change | 5 business days | Review may extend if the change enters the full architecture review process per [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | | Normal security-relevant change | 3 business days | Reviewer must provide outcome (Approved / Approved with Conditions / Rejected / Requires AR / Requires RA) within this window | | Standard security-preserving change | Sampled (no individual SLA) | Sampled per Section 4.6; no individual review timeline applies | | Control bypass or exception | 3 business days for initial assessment; full exception processing per [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk acceptance timeline governed by PRC-RM-001 | #### SLA Escalation | **Condition** | **Action** | |---|---| | Review not completed within SLA | Reviewer escalates to Engineering Pillar Leader with reason for delay | | Review not completed within SLA + 2 business days | Engineering Pillar Leader escalates to CISO | | SLA consistently missed (> 20% of reviews in a calendar month) | Engineering Pillar Leader reviews resourcing, process, or tooling; CISO notified | --- ### 5.4 Integration with Enterprise Change Management CERG does not replace the enterprise change management process. This section defines how the two processes interface. #### Interface Workflow | **Step** | **Action** | **System** | **Owner** | |---|---|---|---| | 1 | Change request is created in the enterprise change management system (e.g., ServiceNow, Jira) | Enterprise CM | Requester | | 2 | If the change is security-relevant per Section 3, the change ticket is flagged for CERG review | Enterprise CM → CERG | Enterprise CM workflow automation or Engineering Pillar Leader | | 3 | CERG reviews the change per Section 5 and records the security review outcome | CERG review tracker | Designated CERG reviewer | | 4 | CERG review outcome is communicated back to the enterprise change ticket (Approved / Approved with Conditions / Requires AR / Requires RA / Rejected) | CERG → Enterprise CM | CERG reviewer | | 5 | Enterprise change proceeds or is blocked based on CERG outcome | Enterprise CM | Change Manager | #### Handoff Responsibility - The Engineering Pillar Leader is responsible for ensuring CERG review outcomes are communicated back to the enterprise change management system. - The Change Manager in the enterprise CM process is responsible for enforcing CERG outcomes: a change rejected by CERG must not proceed through the enterprise change process unless the rejection is overturned or the change is modified and re-reviewed. #### Conflict Resolution If the enterprise change management process and CERG disagree on a change's security disposition: | **Scenario** | **Resolution** | |---|---| | Enterprise CM approves a change CERG rejected | CERG rejection stands; change does not proceed until CERG concern is resolved. Escalate to CISO if bypass is attempted. | | CERG review delays enterprise CM SLA | Engineering Pillar Leader notifies Change Manager of delay with rationale and estimated completion. | | Ambiguity over whether a change is security-relevant | Engineering Pillar Leader determines; if disputed, CISO decides. | --- ## 6. Emergency Changes Emergency changes are allowed, but they are not a loophole. ### 6.1 Emergency Criteria A change may be treated as emergency only when delay creates unacceptable operational, security, safety, or compliance impact. Convenience is not an emergency. ### 6.2 Minimum Emergency Record The emergency change record contains: - business or operational reason for emergency treatment; - systems and controls affected; - approver; - implementer; - start and completion time; - change performed; - testing or validation performed; - rollback result or reason rollback was not needed; - post-implementation security review outcome. ### 6.3 Post-Implementation Review Emergency changes receive post-implementation security review within the organization's defined emergency-change window, and no later than the next business review cycle. The review confirms that: 1. the emergency criteria were valid; 2. the change is documented; 3. no unintended control bypass remains; 4. required evidence is retained; 5. any residual risk is recorded; 6. any temporary access, firewall rule, control disablement, or exception is removed or formally accepted. > **Emergency Is a Speed, Not a Standard** > > An emergency change moves faster because the situation requires speed. It does not get a lower evidence bar, a lower approval bar, or a free pass on residual risk. The evidence may be completed after implementation, but it still exists. The review may occur after the change, but it still occurs. Emergency is the route, not the destination. --- ## 7. SOX and Regulated-Scope Changes Changes affecting SOX ITGC, CUI, NERC-CIP, OT, or other regulated environments require additional evidence and review. ### 7.1 SOX ITGC For SOX-scope systems, the change record must show: - request and business justification; - approval before implementation, except valid emergency changes; - evidence of testing; - implementer and approver; - segregation of duties or compensating control where the same person requests, approves, tests, or implements; - implementation evidence; - post-implementation validation; - link to the relevant SOX ITGC control in [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md). ### 7.2 CUI, NERC-CIP, and OT For CUI, NERC-CIP, and OT-scope systems, the change record must show the regulatory scope considered, the relevant compliance manager consulted, and any required evidence retained in the evidence library under [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). --- ## 8. Evidence and Records Security change records are evidence. They are retained under [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) and include, at minimum: | **Evidence Item** | **Required For** | |---|---| | Change request and scope | Every security-relevant change. | | Security review decision | Normal, material, emergency post-review, and control-bypass changes. | | Approval record | Every change requiring approval. | | Test or validation result | Normal, material, SOX, CUI, NERC-CIP, and emergency changes. | | Implementation record | Every implemented change. | | Rollback plan or recovery note | Normal, material, and emergency changes. | | Risk acceptance or exception | Any unresolved residual risk or control bypass. | | Architecture review link | Any material architecture change. | --- ## 9. Metrics | **Metric** | **Purpose** | |---|---| | Security-relevant changes reviewed | Measures volume of security change engagement. | | Percent of reviewed changes approved with conditions | Shows how often review changes the outcome. | | Changes requiring architecture review | Shows material design-change volume. | | Changes requiring risk acceptance | Shows how often changes introduce residual risk. | | Emergency changes by system and owner | Shows emergency-change pattern and possible process weakness. | | Emergency changes reviewed within required window | Measures emergency discipline. | | SOX-scope changes with complete evidence | Measures audit readiness. | | Repeat change findings | Shows whether the process is improving. | --- ## 10. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Security Change Responsibility** | |---|---| | **Engineering Pillar Leader** | Accountable for this procedure and for security review of changes. Determines when a change requires architecture review. | | **Cloud Security Engineer** | Reviews cloud, SaaS, network, and platform changes. | | **Identity Engineer** | Reviews identity, MFA, privileged access, service account, federation, and secrets-related changes. | | **OT Security Engineer** | Reviews OT, BES Cyber System, and IT/OT boundary changes. | | **Application Security Engineer** | Reviews application, SDLC, API, and AI-related changes. | | **Endpoint Engineer** | Reviews endpoint, MDM, EDR, and device posture changes. | | **Cryptography Engineer** | Reviews key, certificate, TLS, and cryptographic control changes. | | **Risk Pillar Leader** | Consulted on residual risk and risk treatment for changes. | | **Risk Register Owner** | Records accepted residual risk and control exceptions arising from changes. | | **SOX ITGC Lead** | Reviews and validates SOX-scope change evidence. | | **CMMC / Federal Compliance Manager** | Reviews CUI-scope change implications. | | **NERC-CIP Compliance Manager** | Reviews NERC-CIP-scope change implications. | | **Evidence Librarian** | Retains change evidence for audits and control testing. | | **Chief Information Security Officer (CISO)** | Approves High and Critical residual risk acceptance where required. | --- ## 11. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Procedure** | |---|---|---| | NIST 800-53r5 | CM-3, CM-4, CM-5, SA-10, CA-7 | Sections 3, 5, 6, 8 | | NIST CSF 2.0 | GOVERN and PROTECT | Sections 5, 7, 9 | | ISO/IEC 27001 | A.8.32 change management | Sections 4, 5, 6 | | CIS Controls v8 | Secure configuration and change-related safeguards | Sections 5, 8 | | SOX ITGC | Change approval, testing, implementation evidence, segregation of duties | Section 7 | | CMMC L2 / NIST 800-171r3 | Configuration management and security assessment | Sections 5, 7 | | NERC-CIP | Change and configuration controls for BES Cyber Systems | Sections 6, 7 | --- ## 12. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-CHG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to enterprise change management or SOX scope | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-53r5 (CM, SA, CA); NIST CSF 2.0 (GOVERN, PROTECT); ISO/IEC 27001 A.8.32; CIS Controls v8 | | **Regulations** | SOX ITGC; CMMC L2 / 800-171r3; NERC-CIP where changes affect scoped systems | | **Environments** | All security-relevant changes to CERG-managed systems, platforms, controls, and regulated environments | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Engineering | Initial release. Establishes security-relevant change criteria, change categories, minimum security review questions, review outcomes, emergency-change handling, SOX and regulated-scope evidence requirements, retained evidence, metrics, and canonical role responsibilities. | ### Review Triggers - Material change to enterprise change management - Material change to SOX scope or ITGC expectations - Repeated emergency-change findings - Significant incident or audit finding caused by a change - Direction from the CISO Cyber Engineering owns this document. The Engineering Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Material changes enter architecture review | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Residual risk and exceptions from changes | | SOX ITGC Operational Package | [`CERG-PLN-SOX-001`](../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) | SOX change-control evidence linkage | | Secure Configuration Baseline Standard | [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) | Baseline-impacting changes | | Access Management Standard | [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | Identity and access changes | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Logging and monitoring changes | | Secure Software Development and Application Security Standard | [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Application and SDLC changes | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Change evidence retention | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `CHG` domain | --- ## THIRD-PARTY AND SUPPLY CHAIN RISK PROCEDURE ### Vendor Tiering · Evidence by Tier · Contract Clauses · SBOM · International Access · Supply Chain Compromise Team (SCCT) --- | | | |---|---| | **Document ID** | CERG-PRC-TPRM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Vendor Risk Analyst | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PLN-IR-001](../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) | | **Review Cycle** | Annual / On major TPRM platform change | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (SR) · NIST 800-161r1 · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GV.SC) · ISO 27036 · CSA STAR · NTIA SBOM minimum elements | | **Regulations** | NERC-CIP CIP-013 · DFARS / [CMMC L2](https://dodcio.defense.gov/CMMC/) · SOX ITGC · FedRAMP equivalency | | **Environments** | All third-party-touched scopes - SaaS · IaaS/PaaS · OT vendors · CUI subcontractors · MSPs · software suppliers · hardware suppliers | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Roles and Interface to Procurement / ERM / BR](#2-roles-and-interface-to-procurement--erm--br) 3. [Vendor Tiering](#3-vendor-tiering) 4. [Cyber-Specific Score Adjustment](#4-cyber-specific-score-adjustment) 5. [Evidence by Tier](#5-evidence-by-tier) 6. [Differences by Vendor Type](#6-differences-by-vendor-type) 7. [Approved Provider and SaaS Catalog](#7-approved-provider-and-saas-catalog) 8. [Contract Security Clause Library](#8-contract-security-clause-library) 9. [Shared Responsibility Matrix](#9-shared-responsibility-matrix) 10. [International Access, Denied by Default](#10-international-access--denied-by-default) 11. [SBOM and Software Integrity](#11-sbom-and-software-integrity) 12. [CIP-013 Supply Chain Plan](#12-cip-013-supply-chain-plan) 13. [CUI Subcontractor Flow-Down](#13-cui-subcontractor-flow-down) 14. [FedRAMP Equivalency Evidence](#14-fedramp-equivalency-evidence) 15. [Supply Chain Compromise Team (SCCT)](#15-supply-chain-compromise-team-scct) 16. [Continuous Monitoring and Re-Assessment](#16-continuous-monitoring-and-re-assessment) 17. [Regulatory and Framework Alignment Summary](#17-regulatory-and-framework-alignment-summary) 18. [Document Control](#18-document-control) --- ## 1. Purpose and Scope The policy makes third-party and supply-chain security Principle 8. Subordinate standards each impose specific requirements: IT/cloud/SaaS approval and attestation tracking, OT vendor assessment and CIP-013, CUI flow-down and FedRAMP equivalency, SBOM and software integrity. Until this procedure, those obligations had no shared operating model. This procedure defines how CERG engages with the broader enterprise vendor program, where CERG's cyber-specific work begins and ends, what evidence is collected at each tier, and how the program responds when a vendor is compromised. It operationalizes the edge types defined in the [Edge Register](../governance/CERG-GOV-EDG-001_Edge_Register.md) — specifically the Vendor, SaaS, and Software Supply edges. > **CERG Doesn't Own Vendor Management, It Owns the Cyber Slice** > > Procurement, Enterprise Risk Management, and Business Resiliency typically own vendor tiering, contract lifecycle, and business continuity. CERG accepts the business tier as the starting point and adjusts only where cyber-specific concerns are material enough to alter it. This boundary is the difference between a TPRM program that ships and one that drowns in vendors. --- ## 2. Roles and Interface to Procurement / ERM / BR | **Function** | **Owns** | **CERG Interface** | |---|---|---| | **Procurement** | Vendor onboarding, contracts, master vendor record. | CERG reviews proposed contracts for security clauses; SCCT escalation routes through Procurement for contractual remedies. | | **Enterprise Risk Management (ERM)** | Enterprise vendor tier, criticality, business-impact rating. | CERG accepts the business tier as input; adjusts only per Section 4. | | **Business Resiliency** | Vendor continuity, exit plans. | CERG cyber-recovery expectations feed BR vendor recovery plans. | | **Legal (external)** | Contract negotiation, regulatory flow-down, privacy notices. | CERG provides cyber clauses (Section 8); Legal owns negotiation. | | **Vendor Risk Analyst** | This procedure. Vendor cyber assessments, SCCT, evidence-by-tier, continuous monitoring. | - | | **Governance Pillar Leader** | Cyber audit interface; regulator-facing artifacts ([CMMC](https://dodcio.defense.gov/CMMC/) SSP, CIP-013 plan). | - | | **Business / Asset Owners** | Vendor relationship; business-side acceptance of vendor-related risk. | Sign off on residual cyber risk per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | --- ## 3. Vendor Tiering CERG uses a 5-tier vendor model that maps to the typical enterprise model. Business rating sets the baseline; CERG adjusts only via Section 4. | **Tier** | **Description** | **Examples** | |---|---|---| | **T1 - Critical** | Failure or compromise has material business, safety, regulatory, or financial impact. | Core ERP SaaS, primary cloud provider, OT vendor with operator presence, IDP, EDR. | | **T2 - Significant** | Failure or compromise materially disrupts operations or exposes Restricted/CUI data. | CRM SaaS, Tier 1 SaaS holding sensitive data, financial-system MSP. | | **T3 - Standard** | Failure or compromise is operationally inconvenient but recoverable in days. | Productivity SaaS, secondary tooling. | | **T4 - Limited** | Minor business impact; no Restricted data; bounded blast radius. | Marketing tools, training providers. | | **T5 - Transactional** | One-off purchase, commodity goods, no system access, no data access. | Office supplies, conference services. | ### 3.1 Tiering Inputs CERG accepts the **business tier** from ERM / Procurement as the starting point. Inputs include data classification handled, system access granted, regulatory scope, blast radius, and operational dependency. --- ## 4. Cyber-Specific Score Adjustment CERG adjusts the vendor tier *up* only when one or more cyber-specific concerns are material. Adjustments down (vendor "isn't as critical as Business says") are not permitted, Business owns criticality. ### 4.1 Adjustment Triggers | **Cyber Concern** | **Adjustment** | |---|---| | Vendor has privileged access to in-scope systems | +1 tier | | Vendor processes / stores Restricted, CUI, or BCSI data | +1 tier (to T1 if CUI/BCSI) | | Vendor handles OT integration or BES Cyber System interaction | +1 tier (to T1 if BCS) | | Vendor has a recent (≤ 12 months) material breach affecting its customers | +1 tier with case-by-case review | | Vendor is operating below the evidence floor for its proposed tier | hold at lower tier until evidence is current | | Vendor's product / service supports a SOX-relevant business process | +1 tier if not already T2+ | | Vendor product is software shipped to be deployed in our environment with elevated privileges | +1 tier | | Vendor relationship requires non-US access to in-scope systems / data | +1 tier (and see Section 10) | > **Adjustments Are Documented, Not Negotiated** > > Every cyber-driven tier adjustment is recorded in the TPRM tool with the trigger, evidence, and reviewer. If a Business Owner disagrees, the resolution path is [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) Section 8, never an off-record handshake. --- ## 5. Evidence by Tier Evidence requirements grow with tier. The table below names the cyber evidence required *at minimum*; specific subordinate standards may require more (e.g., FedRAMP for CUI scope). | **Evidence** | **T5** | **T4** | **T3** | **T2** | **T1** | |---|---|---|---|---|---| | SOC 2 Type II (or ISO 27001) attestation, current | - | optional | required | required | required | | SOC 2 carve-outs and CUECs reviewed | - | - | - | required | required | | ISO 27001 certificate (where SOC 2 not applicable) | - | optional | required | required | required | | FedRAMP authorization (Moderate or High) for CUI / federal scope | - | - | - | required (CUI) | required (CUI) | | FedRAMP equivalency documentation per Section 14 | - | - | - | required (CUI, where applicable) | required (CUI, where applicable) | | [CMMC](https://dodcio.defense.gov/CMMC/) Level (1 or 2) status for CUI subcontractor | - | - | - | required (CUI) | required (CUI) | | Penetration test summary (sanitized) | - | - | - | required | required | | SIG / CAIQ questionnaire (or CERG equivalent) | - | - | optional | required | required | | SBOM for software products in use | - | - | required (software) | required | required | | Hardware Bill of Materials (HBOM) | - | - | - | optional | required (OT / hardware in BES scope) | | Subprocessor list and CUEC review | - | - | required (SaaS) | required | required | | Right-to-audit clause | - | - | optional | required | required | | Breach / incident notification commitment (timing, scope) | - | required | required | required | required | | Insurance: cyber liability, E&O, where contract-appropriate | - | optional | required | required | required | | OT vendor: NERC-CIP CIP-013 plan participation | - | - | - | required (OT) | required (OT / BES) | | Inheritance Evidence Package (per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 5) for inherited controls | - | - | - | required | required | | Country-of-access disclosure and country-risk rating | - | - | required | required | required | ### 5.1 Evidence Currency - T1 evidence is reviewed annually, no later than 30 days before attestation expiry. - T2 evidence is reviewed annually. - T3 evidence is reviewed every 24 months unless conditions change. - T4/T5 evidence is reviewed on contract renewal. Material vendor events (breach, ownership change, regulator action) trigger an out-of-cycle review regardless of tier. --- ## 6. Differences by Vendor Type Requirements differ by what the vendor *is*. The table below summarizes the most-different requirements; subordinate standards govern detail. | **Vendor Type** | **Distinctive Requirements** | |---|---| | **SaaS provider** | Approved Provider Catalog (Section 7); shared responsibility matrix (Section 9); CSPM/SSPM coverage on the consumer side; tenant configuration baseline per [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md). | | **IaaS / PaaS provider** | Landing zone baseline; CMK or BYOK per [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md); provider attestation including service-in-scope reconciliation; sub-service organization carve-outs. | | **OT vendor** | CIP-013 plan participation; SBOM; firmware integrity verification; 24-hour incident notification commitment; engineering-controlled remote access; on-site presence vetting. | | **CUI subcontractor** | DFARS / 252.204-7012 flow-down; [CMMC L2](https://dodcio.defense.gov/CMMC/) status; incident notification cooperation (DC3); CUI handling commitment with same controls as us. | | **Managed Service Provider (MSP)** | Privileged access via PAM ([`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md)); session recording; named-individual accounts; geographic-access controls; tenant separation evidence. | | **Software supplier (commercial / open source)** | SBOM (NTIA minimum elements); CVE / advisory subscription; software integrity (signed releases); patch / EOL commitments. | | **Hardware supplier (esp. OT)** | HBOM where in BES scope; chain-of-custody; firmware integrity; tamper-evidence; secure delivery. | ### 6.1 Low-Control / High-Dependency Operating Model Not every provider relationship allows the organization to configure, monitor, patch, or test. CERG recognizes four control levels that determine what can be required of a provider and how residual risk is managed. | Control Level | What the Org Can Do | Examples | CERG Approach | |---------------|---------------------|----------|---------------| | **Direct Control** | Configure, monitor, patch, test | Owned servers, self-managed cloud workloads, on-premise network | Standard CERG controls: baselines, scanning, change management, evidence collection | | **Shared Control** | Configure tenant, require evidence, validate logs | SaaS tenants (M365, Salesforce), IaaS/PaaS (AWS, Azure) | Customer-side evidence: IdP exports, KMS inventory, SIEM source inventory, backup config, tenant configuration scans | | **Contractual Control** | Negotiate clauses, notification, audit rights | MSPs, managed security providers, subprocessors | Contract language, annual evidence collection (SOC 2, ISO 27001), incident notification commitments, tested kill-switch | | **Opaque Dependency** | Track residual risk, exit plan, kill switch, compensating monitoring | SaaS vendor's underlying infrastructure, open-source library maintainers, upstream cloud provider outages | Documented residual risk acceptance, exit/migration plan, compensating monitoring (CSPM/SSPM for visible surface), documented assumption register | The control level is recorded per provider in the Approved Provider Catalog and re-assessed at each annual review. A provider at Contractual or Opaque levels must have a documented kill-switch procedure tested at least annually. > **CERG does not pretend to control what it cannot control.** The distinction between "we require this" and "we hope this" is not a compliance failure — it is operational honesty. Document the gap, monitor what is visible, plan the exit. ### 6.2 MSP and MSSP Hard Requirements Managed Service Providers and Managed Security Service Providers operate inside the organization's trust boundary with elevated access. The following requirements apply to every MSP/MSSP relationship, regardless of tier: | Requirement | Description | Verification | |-------------|-------------|-------------| | **Named accounts only** | Every provider user accessing organizational systems operates under a uniquely identifiable, named account. Shared, generic, or role-based accounts are prohibited. | Quarterly access review; IdP audit log | | **PAM or brokered access** | Provider access is brokered through a Privileged Access Management (PAM) solution per [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md). Direct RDP, SSH, or VPN with standing credentials is prohibited. | PAM session logs; monthly access review | | **No standing global admin** | No provider account holds standing global administrator, domain admin, or equivalent superuser privilege. Privilege is elevated per-session, per-task, with justification logged. | PAM elevation log; quarterly privileged group audit | | **Customer-owned logs** | All provider activity logs are owned by the customer organization and stored in customer-controlled infrastructure. The provider shall not delete, modify, or restrict access to logs of their own activity. | SIEM source verification; quarterly log completeness check | | **Break-glass process** | A documented break-glass procedure exists for emergency provider access that cannot follow the normal PAM path. Break-glass use triggers immediate notification to the CISO and is reviewed within 24 hours. | Break-glass event log; quarterly review of all break-glass activations | | **Kill-switch procedure tested quarterly** | A documented procedure exists to revoke all provider access within 60 minutes of activation. The procedure is tested at least quarterly and test results are logged. The machine-readable kill-switch schema in [`machine-readable/`](../machine-readable/) provides the artifact format. | Quarterly test log; time-to-revoke measurement | | **Provider access reviewed like privileged internal access** | Provider access is subject to the same access review cadence, recertification requirements, and anomalous-access detection as internal privileged users per [CERG-PRC-AC-002](CERG-PRC-AC-002_Access_Management_Runbook.md). | Access review records; recertification status | | **Separate incident path for provider compromise** | A documented incident response path exists for "provider compromise with uncertain blast radius." This path is distinct from standard incident response — it assumes the attacker may have visibility into the organization's incident coordination channels if the provider's systems are compromised. | SCCT activation records; annual tabletop exercise | **MSP/MSSP onboarding requires:** contract language covering all eight requirements, evidence of the provider's own security posture (SOC 2 Type II or equivalent), a completed shared responsibility matrix, and a successful kill-switch test before production access is granted. **MSP/MSSP offboarding requires:** revocation of all access within 24 hours of contract termination, confirmation that provider-owned artifacts (logs, configurations, credentials) have been returned or destroyed, and a final access review confirming no residual access paths remain. --- ## 7. Approved Provider and SaaS Catalog CERG maintains an Approved Provider and SaaS Catalog as the system-of-record for which third-party services may be procured for which scope. | **Field** | **Definition** | |---|---| | Provider Name / Service | - | | Vendor Tier | Per Section 3 + Section 4 adjustments | | Approved Scopes | None / Public / Internal / Restricted / CUI / BCSI / SOX-relevant / BES-relevant | | Data Residency Constraints | Approved regions / regions explicitly prohibited | | Last Evidence Review | Date and reviewer | | Next Required Review | - | | Outstanding Risks | Risk register IDs | | Inheritance Evidence | Y/N - link | | Status | Approved · Approved-with-Conditions · Conditional Use Only · Sunset · Prohibited | Procurement consults the catalog at intake; CERG updates it at each evidence cycle and after each SCCT closure. --- ## 8. Contract Security Clause Library CERG provides Legal with a clause library; Legal owns negotiation. Clauses below are the minimums to seek; alternative language with equivalent intent is acceptable. | **Clause** | **Required For** | **Substantive Content** | |---|---|---| | Security controls baseline | T2+ | Vendor commits to maintain controls aligned to a named standard ([NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), [NIST CSF 2.0](https://www.nist.gov/cyberframework), ISO 27001) for the data and access in scope. | | Incident notification | All accessing data/systems | Notification within 24 hours (T1/OT/BES) or 72 hours (T2) of confirmed incident affecting customer data or services. | | Right to audit | T2+ | Documented audit rights, including evidence on request, with reasonable notice; alternatives include current SOC 2/ISO/FedRAMP report. | | Subprocessor consent | SaaS T2+ | Customer-facing list of sub-processors; notification on change. | | Data location | All processing Restricted/CUI/BCSI | Defined regions; no data movement to non-approved regions without consent. | | Encryption | All processing Restricted/CUI | TLS in transit; FIPS-validated where required; CMK / BYOK rights documented per [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md). | | Return / destruction of data | All processing customer data | On termination; documented method and timeline; certification. | | Vulnerability and patch | Software / hardware suppliers | Vendor commits to remediation SLAs aligned to severity; advisory publication. | | SBOM | Software suppliers (T1/T2) | SBOM at NTIA minimum elements at delivery and at material update. | | Background checks | MSPs / vendors with privileged access | Background screening; named-individual access; geographic-access controls. | | Insurance | T2+ | Cyber liability and E&O at industry-appropriate levels. | | Cooperation | All accessing data/systems | Cooperation in incident investigations and regulator inquiries. | | Flow-down | CUI subcontractors | DFARS 252.204-7012 / [CMMC](https://dodcio.defense.gov/CMMC/) requirements flowed to sub-tier. | | CIP-013 | OT vendors in BES scope | Participation in supply chain security plan including software integrity, incident notification, coordination of access controls. | | International access | T2+ where international access proposed | Country-of-access disclosure; right to refuse non-approved geographies. | --- ## 9. Shared Responsibility Matrix Every T2+ cloud / SaaS provider has a Shared Responsibility Matrix on file. Where the vendor publishes one, CERG annotates it; where they don't, CERG produces it and seeks vendor confirmation. | **Control Area** | **Provider Owns** | **Customer Owns** | **Customer-Side Evidence Reference** | |---|---|---|---| | Physical security | Provider | - | - | | Hypervisor / base platform | Provider | - | - | | Tenant isolation | Provider | Configuration | DISH scan / SSPM | | Identity / authentication | Provider provides; Customer configures | Customer configures | IdP policy export | | Encryption (rest / transit) | Provider provides; Customer chooses CMK/BYOK | Customer configures | KMS inventory | | Logging | Provider provides; Customer routes | Customer routes | SIEM source inventory | | Detection | Provider provides limited; Customer extends | Customer extends | Detection coverage | | Recovery / backup | Provider depending on service | Customer-driven for CUI / SOX / Tier 1 | Backup config | | Configuration management | Provider for service; Customer for tenant | Customer | DISH scan | | Subprocessor management | Provider | Customer accepts / refuses | Sub-processor list | The matrix is the single source of truth for cross-team conversations about "who handles X." --- ## 10. International Access: Denied by Default International access to in-scope systems and data is **denied by default**. Where business need requires it, access is treated as a documented exception with conditions. ### 10.1 Operating Model - A **Country Risk Register** classifies each country into tiers: Permitted · Restricted · Conditional · Prohibited. - Permitted countries are those with established trust relationships, low geopolitical risk, and acceptable law-enforcement / data-protection regimes; access is allowed without exception (logged, monitored). - Restricted countries require an exception per [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md), with named controls (managed-device-only, session recording, enhanced detection routing). - Conditional countries require additional senior exec / CISO approval, time-boxed access windows, and possible per-session approval. - Prohibited countries do not get access; business need is resolved by alternative means (US-based delivery, alternate vendor). - The Country Risk Register is reviewed at least quarterly; geopolitical events can trigger reclassification at any time. - All international access is logged to SIEM with country-of-access metadata; the SOC routing pack includes country-tier as a fast-triage field. ### 10.2 Vendor Implications - Vendors must disclose all proposed countries of access at onboarding and at any change. - Vendor international-access tier above the country's permitted level triggers a contract addendum and exception. - Vendor non-disclosure of country-of-access discovered post-onboarding is a material event triggering SCCT. --- ## 11. SBOM and Software Integrity ### 11.1 SBOM Collection — Tiered Requirements | **Requirement** | **T1 Vendor** | **T2 Vendor** | **T3 Vendor (Software)** | **T3 Vendor (Non-Software)** | **Internal Builds** | |---|---|---|---|---|---| | SBOM at delivery (NTIA minimum elements) | Required | Required | Required | N/A | Required (CI-generated) | | SBOM at material update | Required | Required | Required | N/A | Required (CI-generated) | | SBOM format | CycloneDX or SPDX | CycloneDX or SPDX | CycloneDX or SPDX | N/A | CycloneDX (preferred) | | SBOM scan for known vulnerabilities | Required (on receipt + quarterly) | Required (on receipt + semi-annual) | Required (on receipt) | N/A | Required (pipeline gate) | | VEX for findings | Required for Critical/High | Required for Critical/High | Recommended | N/A | Required for Critical/High | | License risk review | Required | Required | Recommended | N/A | Required (policy gate) | | Embedded secrets scan | Required | Required | Recommended | N/A | Required (pipeline gate) | | SBOM recorded in CERG registry (machine-readable/cerg-sbom-schema.yaml) | Required | Required | Required | N/A | Required | | Evidence link in TPRM tool | Required | Required | Required | N/A | Required | **Material update** = new minor/major version, security patch release, or dependency change affecting >10% of components. **SBOM delivery method:** Vendor provides via secure channel (TPRM portal, signed email, or API). Internal builds generate in CI/CD per Section 11.3. ### 11.2 SBOM Processing Pipeline 1. **Ingest:** SBOM received → validate format (CycloneDX/SPDX) → parse components 2. **Scan:** Cross-reference components against NVD, GHSA, vendor advisories → findings → PRC-VM-001 pipeline 3. **Enrich:** Map to `machine-readable/cerg-sbom-schema.yaml` fields → store in SBOM registry 4. **VEX:** Request/validate VEX from vendor for Critical/High findings → record `vex_status` 5. **Approve:** Governance reviews → `approval_status` set → evidence linked in TPRM tool 6. **Monitor:** Quarterly re-scan for T1/T2; pipeline scan on every build for internal ### 11.3 Internal SBOM Generation (CI/CD Integration) All internal production builds shall generate an SBOM as a pipeline artifact: - **Build-time:** Generate CycloneDX SBOM from lockfiles / dependency graph (Syft, Trivy, or language-native tool) - **Scan:** Immediate vulnerability scan against generated SBOM — fail build on Critical/High without VEX - **Sign:** Cosign/Sigstore sign the SBOM artifact - **Publish:** Push SBOM to artifact registry and CERG SBOM registry (machine-readable consumer) - **Gate:** Production promotion requires `approval_status = approved` for the build's SBOM Pipeline snippet reference: `tools/sbom-generate.sh` (see below). ### 11.4 Software Integrity - Releases signed by the vendor; signatures verified before deployment. - Container images signed (cosign / sigstore); admission gate per [`CERG-STD-CFG-001`](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) Section 7. - Firmware (OT) verified per [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md); firmware updates follow CIP-010 process per [`CERG-PLN-CIP-001`](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md). --- ## 12. CIP-013 Supply Chain Plan For BES Cyber Systems, CERG maintains a CIP-013 Supply Chain Risk Management Plan as a [CERG-PLN-CIP-001](../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) component, satisfying CIP-013-2 R1. The plan includes: - Identification of supply chain risks across procurement and installation. - Vendor security controls expectations (incident notification, coordination of access controls, software integrity, vendor remote access management, disclosure of known vulnerabilities). - Procurement controls, clauses, evaluation, approvals. - Implementation and verification, how controls are verified at installation and over time. - Coordination with this procedure: vendor records here are CIP-013 records. --- ## 13. CUI Subcontractor Flow-Down | **Requirement** | **Source** | |---|---| | DFARS 252.204-7012 flow-down to subcontractors handling CUI | DFARS | | [CMMC](https://dodcio.defense.gov/CMMC/) Level 2 third-party assessment status verification | DoD / [CMMC](https://dodcio.defense.gov/CMMC/) | | Incident notification cooperation, including DC3 reporting | DFARS | | Same encryption / handling requirements as the prime | [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) + [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) | | CUI Subcontractor Register maintained | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) | --- ## 14. FedRAMP Equivalency Evidence Where a CUI-relevant SaaS / cloud service is not FedRAMP-authorized but is proposed for use, CERG requires a documented FedRAMP-equivalency package: - SOC 2 Type II with [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Moderate baseline mapping. - 3PAO-equivalent assessment letter or independent assessor attestation. - Customer-side configuration commitments (CUI label, region, key control). - Sub-service organization carve-outs reconciled. - Re-papering trigger documented (FedRAMP authorization issued, attestation lapses, scope change). The package is recorded in the TPRM tool as the vendor's Inheritance Evidence Package for the CUI overlay. --- ## 15. Supply Chain Compromise Team (SCCT) When a vendor reports, or is publicly disclosed as having, a material cybersecurity incident affecting their service or product, CERG activates the **Supply Chain Compromise Team (SCCT)**. ### 15.1 SCCT Membership At minimum: - **SOC / Incident Response lead**: coordinates investigation and customer-side detection / containment. - **CERG, Risk (TPRM)**: vendor liaison; assembles vendor-supplied facts; updates TPRM record. - **CERG, Governance**: regulator notification path; CUI / NERC-CIP / SOX reporting if applicable. - **Legal**: contractual remedies, regulator interface, communications review. - **Procurement**: vendor relationship; commercial leverage. - **Business Owner of the affected service**: operational decision authority; user / customer communications. Other invitees as needed: CISO (declared briefing), Privacy (PII implications), Engineering, OT operations (OT vendors), Communications. ### 15.2 SCCT Activation Triggers - Confirmed vendor breach affecting our data, systems, or service. - Material vulnerability in a deployed vendor product (e.g., critical CVE, supply-chain implant). - Vendor's regulator action affecting our reliance on their service. - Public reporting of a vendor compromise where our exposure is plausible. - Vendor non-disclosure of country-of-access discovered. - Discovery of unauthorized vendor sub-processor handling our data. ### 15.3 SCCT Workflow 1. **Activate.** TPRM declares SCCT, notifies membership within 4 business hours of trigger (1 business hour for T1 vendors). 2. **Assemble facts.** Vendor advisory, public reporting, internal exposure analysis (which systems, which data, which scopes). 3. **Contain.** Coordinate with SOC / IR on containment, credentials rotation, vendor session termination, IOC sweep, detection tuning. 4. **Decide.** Disposition: continue use with conditions / suspend use / terminate. Documented and owned by Business + CISO. 5. **Communicate.** Internal user / customer notification per Legal; regulator notification where required (CUI DC3, NERC-CIP O&P, SOX disclosure committee). 6. **Remediate.** Risk register entries, exception updates, contract addenda, monitoring uplift. 7. **Close.** SCCT after-action with lessons learned; feeds threat intelligence and detection. ### 15.4 SCCT Evidence Every SCCT activation produces an SCCT record with: trigger, membership, timeline, decisions, notifications, risk register updates, vendor-side commitments. Records are retained for the longer of the vendor relationship + 3 years or the regulatory retention requirement. > **Why a Named Team Instead of "We'll Pull People In"** > > Naming the team in advance, with a roster, a trigger, and a 4-hour clock, converts vendor compromise from a panicked phone-tree exercise into a procedure. The first SolarWinds-class event tests every assumption about your TPRM program; SCCT is how that test doesn't surprise you. --- ## 16. Continuous Monitoring and Re-Assessment ### 16.1 Automated Monitoring Signals CERG continuously monitors the vendor landscape using automated signals. The following sources are integrated into the TPRM monitoring pipeline: | **Signal Type** | **Source** | **Frequency** | **Action on Alert** | |---|---|---|---| | Security ratings service | Third-party security ratings provider | Continuous | Alert Vendor Risk Analyst for any score drop > 50 points or below tier threshold | | Dark web monitoring | Threat intelligence platform | Continuous | Alert if organization credentials, source code, or PII attributed to a vendor appear on dark web sources | | Certificate transparency logs | CT log monitors | Daily | Alert on anomalous certificate issuance for vendor domains | | Vendor breach notifications | Direct notification, media monitoring, ISAC feeds | Continuous | Trigger SCCT activation per Section 15 if the breach affects services consumed by the organization | | Sanctions and adverse media | Sanctions list providers, news monitoring | Weekly | Alert Vendor Risk Analyst; trigger Country Risk Register review if jurisdiction-related | | Financial health indicators | Business credit monitoring | Quarterly | Alert for vendors with deteriorating financial posture (downgrade, bankruptcy filing, going concern opinion) | ### 16.2 Periodic Re-Assessment Triggers Vendors are re-assessed on the following cadence based on tier: | **Tier** | **Re-Assessment Cadence** | **Trigger Events (override cadence)** | |---|---|---| | T1 (Critical) | Annual | Vendor breach, material change in service, M&A activity, regulatory action against vendor | | T2 (High) | Annual | Vendor breach, material change in service, M&A activity | | T3 (Moderate) | 24 months | Vendor breach affecting the service consumed | | T4 (Low) | Renewal-driven | Re-assess at contract renewal; trigger if service scope expands | | T5 (Business Default) | Renewal-driven | Re-assess if usage crosses into T4 territory | ### 16.3 Vendor Performance Metrics The Vendor Risk Analyst tracks the following metrics for each T1 and T2 vendor: | **Metric** | **Description** | **Review Cadence** | |---|---|---| | Evidence currency | % of required evidence artifacts that are current (within validity period) | Quarterly | | Assessment completion timeliness | Whether re-assessments complete within the scheduled window | Quarterly | | Finding remediation velocity | Mean time from finding issuance to closure, by severity | Quarterly | | SCCT activation frequency | Number of SCCT activations involving the vendor | Quarterly | | Contractual compliance | Adherence to security obligations, RTO/RPO commitments, and notification SLAs | Annual | ### 16.4 Escalation Paths for Deteriorating Vendor Posture | **Condition** | **Escalation** | **Action** | |---|---|---| | Security rating drops below tier threshold | Vendor Risk Analyst | Immediate review; request remediation plan from vendor within 10 business days | | Vendor breach with potential organizational impact | SCCT Lead per Section 15 | Activate SCCT; assess containment and exposure | | Critical finding open > 90 days without remediation plan | Vendor Risk Analyst → Governance Pillar Leader | Escalate to vendor executive; consider contract remedies | | Vendor refuses to provide required evidence | Vendor Risk Analyst → Engineering Pillar Leader → CISO | Risk acceptance required; if unacceptable, initiate vendor transition planning | | Financial distress indicators | Vendor Risk Analyst → Governance Pillar Leader | Develop contingency plan; identify alternative vendors | ### 16.5 Integration with Approved Provider Catalog Continuous monitoring results directly affect the Approved Provider Catalog (APC) status values: - **Green (Approved)**: All monitoring signals within acceptable thresholds; evidence current. - **Amber (Conditional)**: One or more signals outside Green threshold; remediation plan accepted. Automatic review at 90 days. - **Red (Restricted)**: Critical finding or breach unresolved; new engagements restricted until status returns to Amber or Green. - **Black (Prohibited)**: Vendor determined to pose unacceptable risk; existing services transitioned off per the offboarding procedure. ### 16.6 Integration with Threat Intelligence Vendor monitoring is integrated with [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) for threat intelligence specific to vendors: - The Threat Intelligence Analyst produces a **Vendor Risk Note** (per PRC-TI-001 §6.5) when threat intelligence reveals TTPs, CVEs, or campaign activity relevant to a vendor in the APC. - Vendor-specific IOCs from threat intelligence are deployed to detection tooling per PRC-TI-001 §4.6. - Quarterly threat briefings to the Vendor Risk Analyst summarize the threat landscape affecting the vendor portfolio. ### 16.7 Vendor Offboarding When a vendor relationship ends, a structured offboarding process ensures access is revoked, data is retrieved or destroyed, and residual obligations are met. #### Offboarding Triggers | **Trigger** | **Description** | |---|---| | Contract expiration | Normal end of contract term; vendor not renewed | | Termination for cause | Vendor breach of contract, security incident, or performance failure | | Vendor bankruptcy / dissolution | Vendor ceases operations | | Strategic replacement | Organization transitions to an alternative vendor | #### Offboarding Checklist | **Step** | **Action** | **Owner** | **Timing** | |---|---|---|---| | 1 | Notify vendor; confirm effective date | Business Sponsor | Immediately | | 2 | Disable all vendor user accounts | Identity Engineer | Effective date or within 24 hours | | 3 | Revoke vendor API keys, OAuth grants, service principals | Identity Engineer / Cloud Security Engineer | Effective date | | 4 | Rotate shared secrets vendor had access to | Cryptography Engineer | Within 5 business days | | 5 | Deauthorize SSO / federation | Identity Engineer | Effective date | | 6 | Remove vendor from Approved Provider Catalog (status = Offboarded) | Vendor Risk Analyst | Within 5 business days | | 7 | Confirm data retrieval or destruction per contract | Business Sponsor + Legal | Per contract | | 8 | Update TPRM record | Vendor Risk Analyst | Within 10 business days | #### Post-Termination Surviving contractual clauses (confidentiality, data handling, audit rights) remain in effect. Evidence is retained per [CERG-PRC-AUD-001](CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). Offboarding completion is signed off by the Vendor Risk Analyst and Business Sponsor. ### 16.8 Fourth-Party Risk Management Fourth-party risk arises when a critical vendor relies on subcontractors (sub-processors) the organization does not have a direct relationship with. #### Disclosure Requirements - T1 and T2 vendors must disclose all critical sub-processors - Vendors must notify the organization of sub-processor changes at least 30 days before the change - The organization reserves the right to object; the vendor must provide an alternative or allow contract termination without penalty #### Evidence for Critical Sub-Processors | **Evidence** | **When Required** | |---|---| | SOC 2 Type II report | Sub-processors hosting or processing the organization's data | | ISO 27001 certification | Acceptable alternative for international sub-processors | | Inheritance evidence | Vendor's own assessment, if methodology is reviewed and approved | #### Concentration Risk The Vendor Risk Analyst monitors for multiple vendors relying on the same sub-processor. If a single sub-processor supports ≥ 3 T1/T2 vendors, a formal concentration risk assessment is conducted. --- ### 16.9 Business Continuity and Disaster Recovery (BCDR) for Vendors Critical and high-tier vendors must demonstrate BCDR capability proportional to the criticality of the service they provide. #### BCDR Requirements by Tier | **Tier** | **BCDR Requirement** | **Evidence** | |---|---|---| | T1 (Critical) | Documented BCDR plan; RTO ≤ 4 hours; RPO ≤ 1 hour; annual functional BCDR test | BCDR plan summary; test results | | T2 (High) | Documented BCDR plan; RTO ≤ 24 hours; RPO ≤ 4 hours; annual tabletop or functional test | BCDR plan summary; test results | | T3 (Moderate) | BCDR plan or equivalent; RTO/RPO appropriate to service | BCDR plan acknowledgment | | T4 (Low) | BCDR capability acknowledged in contract | Contractual commitment | | T5 (Business Default) | None required beyond standard terms | - | #### RTO/RPO Expectations RTO (Recovery Time Objective) and RPO (Recovery Point Objective) expectations are set based on the organization's dependency on the vendor: - If the organization's own Tier 1 service depends on the vendor, the vendor's RTO must be ≤ the organization's RTO for that service. - If the vendor processes regulated data (CUI, SOX), RPO must be ≤ 1 hour. - RTO/RPO commitments are documented in the contract and reviewed at each vendor re-assessment. #### BCDR Assessment During vendor assessment, the Vendor Risk Analyst evaluates: - Does the vendor have a documented BCDR plan? - Has the plan been tested? When? What was the outcome? - Are RTO/RPO commitments compatible with the organization's requirements? - Does the vendor's BCDR plan account for dependencies on its own critical sub-processors? Assessment results are recorded in the TPRM tool and reviewed at each re-assessment cycle. ### 16.10 Metrics | **KPI** | **Formula** | **Source** | **Refresh** | **Green** | **Amber** | **Red** | |---|---|---|---|---|---|---| | Vendors assessed on time | % of vendors with assessment completed within scheduled window | TPRM tool | Quarterly | ≥ 95% | 85–94% | < 85% | | Average assessment time | Mean calendar days from assessment start to completion | TPRM tool | Quarterly | ≤ 30 days | 31–45 days | > 45 days | | Vendors by tier | Count of active vendors per tier (T1–T5) | TPRM tool | Monthly | - | - | - | | Active exceptions | Count of open vendor-related risk exceptions | Risk register | Monthly | 0 | 1–5 | > 5 | | Vendor risk trend | % of vendors with improving / stable / declining risk posture | TPRM tool | Quarterly | ≥ 80% stable or improving | 60–79% | < 60% | | Evidence currency | % of T1/T2 vendors with all required evidence current | TPRM tool | Monthly | ≥ 95% | 85–94% | < 85% | | SCCT activation frequency | Count of SCCT activations | SCCT log | Quarterly | 0 | 1 | ≥ 2 | | Fourth-party concentration | Count of sub-processors supporting ≥ 3 T1/T2 vendors | TPRM tool | Quarterly | 0 | 1 | ≥ 2 | ## 17. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Procedure** | |---|---| | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) SR family | All sections | | NIST 800-161r1 | All sections; especially 11–15 | | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (GV.SC) | Sections 2–6, 15 | | ISO 27036 | Sections 5, 8, 9 | | DFARS 252.204-7012 / [CMMC L2](https://dodcio.defense.gov/CMMC/) | Sections 13, 14 | | NERC-CIP CIP-013 | Section 12 | | FedRAMP / FedRAMP equivalency | Section 14 | | NTIA SBOM minimum elements | Section11 | | SOX ITGC | Cross-cutting; vendor SOC 1 reuse where applicable | --- ## 18. Document Control | | | |---|---| | **Document ID** | CERG-PRC-TPRM-001 | | **Version** | 1.0 | | **Approved By** | CISO | | **Next Review** | Annual / TPRM platform change | | **Change Log** | 1.0 - Initial publication. Tiering, evidence by tier, shared responsibility, international access denial-by-default, SBOM, CIP-013, CUI flow-down, FedRAMP equivalency, SCCT. | --- ## THREAT INTELLIGENCE PROCEDURE ### Sources · Intake · Relevance · Dissemination · Action Tracking · Program Reprioritization · External Collaboration --- | | | |---|---| | **Document ID** | CERG-PRC-TI-001 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md) · [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [`CERG-PRC-LL-001`](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) · [`CERG-GOV-IMPREG-001`](../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) · [`CERG-GOV-CAL-001`](../governance/CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | | **Review Cycle** | Annual / On material change to threat landscape or intelligence sources | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (RA-3, RA-5, SI-5, PM-16) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (ID.RA, DE.CM, ID.IM, GOVERN) · [MITRE ATT&CK](https://attack.mitre.org/) · [MITRE ATT&CK for ICS](https://attack.mitre.org/matrices/ics/) | | **Regulations** | CMMC L2 / 800-171r3 · NERC-CIP · SOX ITGC where threat intelligence affects scoped systems | | **Environments** | All CERG-managed environments and risk decisions informed by threat intelligence | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [Intelligence Sources](#3-intelligence-sources) 4. [Intake and Triage](#4-intake-and-triage) 5. [Relevance and Priority](#5-relevance-and-priority) 6. [Products and Dissemination](#6-products-and-dissemination) 7. [Action Tracking](#7-action-tracking) 8. [Integration With CERG Processes](#8-integration-with-cerg-processes) 9. [Intelligence-Driven Program Reprioritization](#9-intelligence-driven-program-reprioritization) 10. [External Collaboration and Information Sharing](#10-external-collaboration-and-information-sharing) 11. [Metrics](#11-metrics) 12. [Roles and Responsibilities](#12-roles-and-responsibilities) 13. [Regulatory and Framework Alignment Summary](#13-regulatory-and-framework-alignment-summary) 14. [Document Control](#14-document-control) --- ## 1. Purpose and Scope The README names threat intelligence as a Cyber Risk function. The Operating Model names the Threat Intelligence Analyst as the role that tracks threat actors, advisories, and intelligence-to-detection translation. Existing procedures consume threat intelligence, but no procedure defined how intelligence is sourced, triaged, prioritized, disseminated, or tracked to action. This procedure closes that gap. Threat intelligence in CERG is operational. Its purpose is not to publish interesting reports. Its purpose is to help the organization make better decisions sooner: patch the right thing faster, change a design before it ships, warn the right owner, tune a detection, reassess a vendor, or record a risk. This procedure applies to all threat intelligence used by CERG to inform exposure management, threat modeling, architecture review, third-party risk, OT risk, detection priorities, and risk-register decisions. > **Intelligence That Does Not Change Action Is Trivia** > > A threat feed can produce thousands of indicators and still produce no security outcome. CERG does not measure intelligence by volume. It measures whether intelligence reached the right owner in time to change a decision: patch this, block that, model this abuse case, watch this vendor, raise this risk. If a piece of intelligence has no decision path, it is context, not work. --- ## 2. Principles 1. **Relevance beats volume.** Intelligence is judged by its relationship to the organization's assets, technologies, vendors, data, and threat exposure. 2. **Timeliness matters.** A perfect advisory delivered after exploitation is history, not intelligence. 3. **Every actionable item has an owner.** If an intelligence item requires action, the action is assigned to a canonical role and tracked to disposition. 4. **Use multiple source types.** No single feed or vendor provides the full threat picture. CERG uses government, commercial, open-source, sector, vendor, and internal sources. 5. **Internal telemetry is intelligence.** Vulnerability trends, incidents, phishing reports, and adversarial testing findings are intelligence inputs, not just local events. 6. **Dissemination is tailored.** The CISO needs posture and decision impact. Engineering needs concrete action. Governance needs evidence and regulatory implication. Risk needs exposure and priority. --- ## 3. Intelligence Sources The Threat Intelligence Analyst maintains a source register. Sources are reviewed at least annually for relevance, reliability, and usefulness. | **Source Type** | **Examples** | **Primary Use** | |---|---|---| | Government and sector advisories | CISA, FBI, MS-ISAC, ES-ISAC, NCSC, sector regulators | High-confidence alerts, exploited vulnerabilities, sector campaigns. | | Vendor advisories | Cloud, SaaS, endpoint, identity, OT, and security vendors | Product-specific vulnerabilities and mitigations. | | Commercial intelligence | Paid intelligence platforms or managed-intelligence feeds | Actor tracking, campaign context, enriched indicators. | | Open-source intelligence | Public research, blogs, GitHub advisories, abuse reports | Fast context, exploit availability, community findings. | | Internal telemetry | Vulnerability data, phishing reports, incident lessons, adversarial testing findings | Organization-specific exposure and observed behavior. | | Peer and trust groups | ISACs, industry groups, trusted peer exchanges | Sector targeting, early warning, practical mitigations. | | Regulatory and legal updates | Regulator alerts, new requirements, enforcement activity | Governance and compliance implications. | Restricted-source or sensitive intelligence is handled according to its classification under [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md). --- ## 4. Intake and Triage ### 4.1 Intake Channels Threat intelligence enters through approved channels: source registers, email subscriptions, vendor portals, ISAC channels, internal reports, incident lessons, adversarial validation reports, and vulnerability advisories. Informal inputs are allowed, but once an item is actionable it is recorded in the intelligence intake log. ### 4.2 Minimum Intake Fields Every actionable item records: | **Field** | **Purpose** | |---|---| | Source | Where the item came from. | | Date received | Timeliness and review tracking. | | Summary | Plain-language statement of what changed. | | Affected technologies, vendors, or sectors | Relevance check. | | Associated vulnerabilities, techniques, or indicators | Links to CVEs, ATT&CK techniques, IOCs, or behaviors. | | Known exploitation | Whether exploitation is observed, likely, or theoretical. | | Initial priority | Critical, High, Medium, Low. | | Action owner | Canonical role responsible for next step. | | Disposition | Monitor, disseminate, create action, create risk, close. | ### 4.3 Triage Outcomes | **Outcome** | **Meaning** | |---|---| | **Close as not relevant** | No affected asset, vendor, technology, sector, or plausible exposure. | | **Monitor** | Relevant but no immediate action. Review when conditions change. | | **Disseminate** | Useful context for one or more owners, but no tracked action required. | | **Create action** | Requires patching, configuration, detection, review, vendor follow-up, or project change. | | **Create risk** | Residual exposure requires tracking through [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | --- ### 4.4 Analysis Methodology Raw intelligence is analyzed before dissemination. The following frameworks and standards ensure consistent, defensible analysis. #### Analysis Frameworks | **Framework** | **Application** | **Description** | |---|---|---| | Diamond Model | Intrusion analysis | Maps adversary, capability, infrastructure, and victim for each intrusion event. Used to identify adversary campaigns and infrastructure patterns. | | Intelligence Cycle | Production workflow | Planning → Collection → Processing → Analysis → Dissemination → Feedback. Each intelligence product follows this cycle. | | Kill Chain Analysis | Attack reconstruction | Maps observed activity to Recon → Weaponization → Delivery → Exploitation → Installation → C2 → Actions. Used to identify where defenses failed or succeeded. | #### Confidence Levels Every intelligence product includes a confidence assessment: | **Confidence** | **Definition** | **Criteria** | |---|---|---| | Confirmed | Independently corroborated by multiple reliable sources | ≥ 3 corroborating sources; no conflicting information | | Probable | Supported by reliable sources with minor gaps | 2 corroborating sources or 1 highly reliable source | | Possible | Plausible but single source or limited corroboration | 1 source of moderate reliability; limited supporting evidence | | Unlikely | Contradicted by more reliable information | Primary source contradicted; low reliability | | Doubtful | Highly improbable based on available information | Single low-reliability source; significant contradicting evidence | #### Source Reliability Assessment | **Rating** | **Definition** | |---|---| | A - Completely Reliable | History of complete reliability; no doubt of authenticity | | B - Usually Reliable | Minor doubts; history of valid information with occasional errors | | C - Fairly Reliable | Some doubts; information used but not confirmed through other sources | | D - Not Usually Reliable | Significant doubts; information used only when corroborated | | E - Unreliable | History of invalid information; not used | | F - Cannot Be Judged | No basis for reliability assessment | The Threat Intelligence Analyst assesses both confidence in the analyzed intelligence and reliability of the source. Products clearly state the confidence level and source reliability rating. --- ### 4.5 IOC Lifecycle Management Indicators of Compromise (IOCs) have a lifecycle from ingestion through deployment to retirement. #### IOC Confidence Scoring | **Score** | **Criteria** | |---|---| | High | Confirmed malicious by ≥ 2 independent sources; observed in production attacks | | Medium | Reported by a trusted source; limited independent confirmation | | Low | Single report; unverified; or context-dependent (e.g., IP that is also used legitimately) | #### IOC Expiration IOCs auto-expire after 90 days unless refreshed. The Threat Intelligence Analyst reviews expiring IOCs and either: - Refreshes: IOC is still active and confirmed; expiration clock resets - Retires: IOC is no longer active, has been remediated, or is no longer relevant Expired IOCs are removed from active detection tooling but retained in the intelligence archive for historical analysis. #### False Positive Management | **Step** | **Action** | |---|---| | 1 | Detection Engineer identifies a false positive IOC (alert fires on benign activity) | | 2 | IOC is suppressed in detection tooling with a note and timestamp | | 3 | Threat Intelligence Analyst reviews within 5 business days | | 4 | If confirmed false positive: IOC is retired with rationale. If disputed: IOC remains active; detection rule is tuned instead | False positive rate is tracked as a metric. A sustained false positive rate > 20% on any IOC source triggers a source quality review. #### Integration with Detection Tooling IOCs are deployed to detection tooling (SIEM, EDR, NGFW) through an automated or semi-automated pipeline. IOC retirement is synchronized: when an IOC is retired in the intelligence platform, it is automatically removed from detection tooling within 24 hours. --- ## 5. Relevance and Priority Priority is based on relevance, exposure, exploitation, and potential impact. A dramatic threat report with no relationship to the environment is lower priority than a quiet advisory for a product the organization runs on the internet. | **Priority** | **Criteria** | **Expected Handling** | |---|---|---| | **Critical** | Active exploitation against technology the organization uses, especially internet-facing, identity, OT, or Restricted-data systems. | Same-day owner notification; action or risk entry opened immediately. | | **High** | Likely exploitation or high-impact technique affecting used technology, a key vendor, or a regulated environment. | Owner notification within one business day; tracked action opened. | | **Medium** | Plausible relevance, limited exposure, or no known exploitation. | Disseminate to relevant owner; monitor or schedule action. | | **Low** | General context, weak relevance, or awareness-only item. | Record if useful; no action required. | Priority does not replace vulnerability severity or risk scoring. It informs them. Vulnerability remediation still follows [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md), and residual risk still follows [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). --- ## 6. Products and Dissemination The Threat Intelligence Analyst produces only products with a clear audience and decision purpose. | **Product** | **Audience** | **Purpose** | |---|---|---| | Flash advisory | Engineering, Risk, Governance, CISO as needed | Time-sensitive item requiring immediate awareness or action. | | Weekly intelligence digest | Risk and Engineering owners | Relevant trends, exploited vulnerabilities, sector activity, and follow-up reminders. | | Threat-model input brief | Threat modeling participants | Actor, technique, and abuse-case context for design review. | | Vulnerability context note | Exposure Management Lead | Exploitation status, weaponization, and prioritization context. | | Vendor risk note | Vendor Risk Analyst | Supplier compromise, product vulnerability, or service-risk context. | | Executive threat brief | CISO and Executive Sponsor | Material changes to threat exposure and decisions needed. | Dissemination is targeted. Sending every item to everyone trains everyone to ignore the channel. > **Broadcast Is Not Dissemination** > > Dumping every advisory into a shared chat is not a threat intelligence program. It is noise with timestamps. CERG dissemination names the audience, the decision, and the requested action. If the recipient cannot tell what to do with the intelligence, the message failed. --- ## 7. Action Tracking Actionable intelligence is tracked to disposition. The Threat Intelligence Analyst does not necessarily do the remediation, but owns the intelligence-to-action handoff until the receiving owner accepts it. | **Action Type** | **Receiving Owner** | **Tracking Path** | |---|---|---| | Patch or mitigate vulnerability | Exposure Management Lead | [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md). | | Change design or control requirement | Engineering Pillar Leader or relevant Engineering role | [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) or relevant standard. | | Add threat-model abuse case | Threat Intelligence Analyst | [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md). | | Reassess supplier | Vendor Risk Analyst | [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). | | Create or tune detection | Detection Engineer | Detection backlog governed by [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md). | | Record residual exposure | Risk Register Owner | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | | Brief leadership | Risk Pillar Leader | CISO dashboard or executive threat brief. | An item is closed only when the receiving owner records disposition: completed, accepted risk, not applicable with reason, or superseded. --- ## 8. Integration With CERG Processes Threat intelligence feeds the program through defined channels. | **CERG Process** | **How Intelligence Feeds It** | |---|---| | Architecture review | Supplies threat context and abuse cases for design decisions. | | Threat modeling | Supplies actor, technique, and campaign context. | | Exposure management | Adds exploitation, weaponization, and environmental relevance to remediation priority. | | Third-party risk | Identifies supplier compromise, vendor product vulnerabilities, and sector vendor campaigns. | | Asset management | Helps identify crown-jewel systems and technologies under active targeting. | | AI security | Tracks prompt-injection, model supply chain, and AI-service data-risk developments. | | OT risk | Uses ICS-specific intelligence and ATT&CK for ICS where OT is in scope. | | Risk register | Converts sustained exposure into tracked risk. | | Metrics and reporting | Provides threat-context narrative for posture reporting. | --- ## 9. Intelligence-Driven Program Reprioritization Threat intelligence that is collected, triaged, and disseminated but never changes the program is a reporting exercise, not an Adaptive capability. The CERG Framework (FRM-001 Section 6.2) states that "Threat intelligence actively shapes Engineering design decisions and Governance policy priorities." An Adaptive assessor expects to see evidence that intelligence has actually changed the program, not just informed it. This section defines the quarterly cadence and decision framework by which intelligence drives program-level reprioritization. ### 9.1 Quarterly Threat Landscape Assessment Once per quarter, aligned with the CERG leadership review cadence (GOV-CAL-001 Section 5), the Risk Pillar Leader presents a Threat Landscape Assessment to the CISO and pillar leaders. The assessment is a structured briefing, not a raw intelligence dump. The assessment covers: - **Top 3 threat actors** targeting the organization's sector, with observed TTPs and campaign context - **TTP changes** observed in the last quarter that differ from the prior assessment - **Changes in targeting patterns:** are new sectors, technologies, or organization types being targeted? - **Vulnerabilities actively exploited in the wild** (CISA KEV or vendor-confirmed exploitation), with mapping to CERG assets - **Intelligence gaps identified:** what should CERG know about the threat landscape that it does not currently know? - **External incident impact assessment:** any major breach at a peer or in-sector organization, with implications for CERG ### 9.2 Reprioritization Decision Framework The assessment MUST produce at least one of the following reprioritization decisions, each recorded with rationale in the improvement register (IMPREG-001): | Decision | Trigger Condition | Example | |---|---|---| | **No program change** | Current posture is adequate for the assessed threat landscape. | Must state specifically why : not "we are fine" but "our current network segmentation (STD-NET-001 Section 5) blocks the lateral movement technique observed in the campaign." | | **Control baseline adjustment** | A new TTP or exploitation pattern is not addressed by the current control baseline. | "Ransomware groups are now exploiting RMM tools for initial access. Proposed: add a CB-001 control requiring RMM tool inventory and approved-tool policy." | | **Project intake priority shift** | A class of project or technology now carries elevated risk. | "API-first architectures are being targeted. Proposed: elevate API gateway projects to mandatory architecture review." | | **Detection rule update** | Observed TTPs are not covered by current detection rules. | "The campaign uses a specific LOLBin chain not in our detection set. Proposed: add detection rules for the observed chain." | | **Tooling or capability gap** | The threat landscape requires a capability CERG does not currently have. | "Adversaries are abusing OAuth token attacks at scale. Proposed: evaluate OAuth threat detection tooling." | | **Staffing or training recommendation** | A sustained threat pattern requires specialized expertise. | "ICS-targeting activity has increased 300% year-over-year. Proposed: add an OT Threat Analyst position." | | **External sharing action** | Intelligence is relevant to an ISAC, peer group, or regulator. | "Observed novel ICS technique. Proposed: share sanitized TTP with E-ISAC." | > **The "No Change" Decision Requires Proof** > > "No program change" is a valid output of the quarterly assessment, but it must be a deliberate conclusion with specific rationale, not a default. An assessor reviewing two years of quarterly assessments where every single one concluded "no change needed" will correctly conclude either that the intelligence program is not producing actionable intelligence or that the program is not listening to it. Both conclusions are Adaptive-fatal. ### 9.3 Decision Record Each reprioritization decision is recorded in the improvement register (IMPREG-001) with: - Source: "Intelligence-Driven Reprioritization, QN YYYY" - The intelligence trigger (specific threat actor, TTP, campaign, or vulnerability) - The decision and accountable role - A verification checkpoint (reviewed at the next quarterly assessment) ### 9.4 Verification At each quarterly assessment, the prior quarter's reprioritization decisions are verified: - Was the control adjusted? Is the new or modified control in CB-001? - Was the detection rule deployed? Is it producing alerts? - Was the capability gap funded? Is the tool procured or the hire in progress? - Incomplete actions are escalated to the CISO. Verification outcomes (Effective, Partially Effective, Ineffective) are recorded in IMPREG-001 per the improvement lifecycle. ### 9.5 Integration with Lessons Learned The quarterly Threat Landscape Assessment is an intake source for the Lessons Learned procedure (PRC-LL-001). Intelligence-driven patterns that persist across multiple quarters are analyzed alongside incident, audit, and adversarial validation patterns at the quarterly Lessons Aggregation Review. --- ## 10. External Collaboration and Information Sharing Adaptive maturity expects bidirectional information sharing : not just consuming threat intelligence, but contributing back, participating in communities, and learning from peers' incidents. This section defines the external collaboration requirements for CERG. ### 10.1 ISAC / ISAO Membership CERG must maintain membership in at least one sector-appropriate Information Sharing and Analysis Center (ISAC) or Information Sharing and Analysis Organization (ISAO). For organizations with IT and OT footprints, dual membership in the sector IT ISAC and E-ISAC (electricity) or equivalent OT ISAC is recommended. | Requirement | Detail | |---|---| | Minimum participation | Attend quarterly member calls and respond to Requests for Information (RFIs) within the ISAC's published SLA | | Designated liaison | Threat Intelligence Analyst or Risk Pillar Leader | | Escalation | Material intelligence received through ISAC channels follows the same triage and prioritization as Section 4-5 | ### 10.2 Peer Benchmarking At least annually, the Threat Intelligence Analyst collects and analyzes peer benchmarking data where available. Sources include: - ISAC member threat reports and statistics - Industry surveys (DBIR, SANS, sector-specific reports) - Regulatory aggregate data where published - Trusted peer exchanges The benchmarking analysis compares CERG's posture against peer norms: - Vulnerability closure rates compared to sector peers - Incident frequency and type compared to sector peers - Control coverage compared to recommended sector baselines Significant deviations from peer norms trigger a program review. Example: if peer organizations close Critical vulnerabilities in a mean of 30 days and CERG's mean is 90 days, the gap must be explained and either accepted with rationale or converted to an improvement action. ### 10.3 External Incident Learning When a major breach at a peer or in-sector organization is publicly reported, CERG conducts a structured External Incident Review within 14 calendar days. The review is led by the Threat Intelligence Analyst with participation from the affected pillar. The review answers four questions: 1. **Could this happen here?** Does the affected technology, configuration, vendor, or process exist in CERG's environment? 2. **Are the relevant controls present and effective?** Map the attack chain to CERG's control baseline (CB-001). Are all relevant controls Implemented? Have their effectiveness metrics (CEF-001) been measured? 3. **What would our detection and response look like?** If the same attack chain were executed against CERG, would it be detected? Would the response be effective? 4. **What changes, if any, are warranted?** The output is either: - "No change needed" with specific rationale (e.g., "the affected technology is not deployed; the attack vector is blocked by STD-NET-001 Section 5") - An improvement register entry (IMPREG-001) for each warranted change ### 10.4 Community Contribution At least annually, CERG contributes back to the ISAC or security community. Minimum contribution: sanitized lessons learned, threat observations, or control effectiveness data. This is both an Adaptive indicator in NIST CSF assessments and a professional obligation. Acceptable contributions include: - Sanitized incident lessons (what happened, what worked, what did not : without attribution or sensitive detail) - Novel threat observations or TTPs - Control effectiveness insights ("we found that control X was consistently ineffective in Y scenario") - Tool or technique evaluations ### 10.5 Information Sharing Boundaries Not everything can be shared. Before any external contribution, the following classification rules apply: | Classification | Sharing Rule | |---|---| | Sanitized, non-attributable observations | Share freely with ISAC / peer groups | | Specific vulnerabilities before remediation | Do not share externally until remediated | | Customer, patient, or citizen data | Never share; regulated | | Attorney-client privileged material | Never share without legal review | | Competitive or business-strategy information | Never share | | Incident details during active incident | Share only with official response partners (ISAC, CISA, law enforcement as appropriate) | When in doubt, the CISO and legal counsel review before sharing. --- ### 10.6 Traffic Light Protocol (TLP) Handling CERG uses the Traffic Light Protocol (TLP) for all intelligence sharing with external partners, ISACs, and industry groups. | **TLP Level** | **Definition** | **Handling Requirement** | |---|---|---| | TLP:RED | For the eyes and ears of named recipients only; no further distribution | Not shared beyond named recipients. Stored with access restricted to the Threat Intelligence Analyst and named recipients. Not included in any wider-distribution product. | | TLP:AMBER | Limited distribution within the organization and named partners | May be shared within CERG and with named partner organizations on a need-to-know basis. Not posted on publicly accessible platforms. Products containing TLP:AMBER information are clearly marked. | | TLP:GREEN | Distribution within the community | May be shared with peer organizations, ISAC members, and trusted partners within the same sector or community. Not released publicly. | | TLP:CLEAR | Unlimited distribution | May be shared freely. No restrictions on distribution. | #### TLP Marking Every intelligence product that contains TLP-classified information is marked with the highest applicable TLP level. The marking appears in the product header. When a product combines intelligence from multiple TLP sources, the most restrictive level applies. #### Source TLP Compliance The Threat Intelligence Analyst ensures that intelligence received under a TLP designation is handled per that designation. Intelligence received as TLP:RED is never sourced in a TLP:AMBER or lower product. Intelligence received under Chatham House Rule is paraphrased and not attributed to a specific organization or individual. --- ### 10.7 Consumer Feedback Loop Intelligence products are assessed by the consumers who use them. This feedback loop drives continuous improvement in intelligence production. #### Feedback Mechanism | **Mechanism** | **Description** | |---|---| | Product rating | Recipients of intelligence products are invited to rate each product on usefulness (1–5) and accuracy (1–5) | | Structured feedback | Quarterly, the Threat Intelligence Analyst solicits feedback from the top 5 consumers of intelligence products (e.g., Exposure Management Lead, Vendor Risk Analyst, Detection Engineer, CISO) | | Ad-hoc feedback | Any consumer may provide feedback at any time through the intelligence intake channel | #### Feedback Review Process The Threat Intelligence Analyst reviews all feedback quarterly: - Products rated < 3 on usefulness are analyzed: was the wrong audience targeted? Was the analysis insufficient? Was the timing poor? - Products rated < 3 on accuracy are re-examined; if confirmed inaccurate, a correction is issued and the source reliability rating is adjusted - Patterns in feedback inform source selection, product format changes, and dissemination list adjustments #### Program Improvements from Feedback Feedback that identifies a systematic gap in intelligence production (e.g., "we consistently lack context on vulnerabilities affecting our tech stack" or "the weekly digest is too long to read") is routed to the improvement register per [CERG-PRC-LL-001](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md). --- ## 11. Metrics Threat intelligence metrics measure relevance and action, not raw feed volume. | **Metric** | **Why It Matters** | |---|---| | Actionable intelligence items received | Measures useful signal, not total noise. | | Items closed as not relevant | Shows filtering discipline and source quality. | | Time from receipt to owner notification for Critical and High items | Measures timeliness. | | Percent of actionable items with assigned owner | Measures handoff quality. | | Percent of actions closed by disposition | Measures follow-through. | | Intelligence items feeding vulnerability priority | Shows connection to exposure reduction. | | Intelligence items feeding threat models | Shows design-stage use. | | Intelligence items resulting in risk-register entries | Shows residual exposure capture. | --- ## 12. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Threat Intelligence Responsibility** | |---|---| | **Risk Pillar Leader** | Accountable for this procedure and for intelligence quality, prioritization, and escalation. | | **Threat Intelligence Analyst** | Operates the procedure; maintains sources; triages intelligence; produces intelligence products; tracks intelligence-to-action handoffs. | | **Exposure Management Lead** | Consumes intelligence for vulnerability prioritization and remediation decisions. | | **Adversarial Testing Lead** | Uses intelligence to shape adversarial validation scope and scenarios. | | **Vendor Risk Analyst** | Consumes supplier and vendor intelligence; performs reassessment where needed. | | **OT Risk Analyst** | Supplies and consumes OT and ICS threat intelligence. | | **Detection Engineer** | Receives detection leads and maps intelligence to detection backlog where in scope. | | **Engineering Pillar Leader** | Receives design and architecture-impacting intelligence and assigns relevant Engineering owners. | | **Governance Pillar Leader** | Receives intelligence with compliance, audit, or executive reporting implications. | | **Risk Register Owner** | Records sustained exposure or accepted residual risk from intelligence-driven findings. | | **Chief Information Security Officer (CISO)** | Receives material threat briefings and makes program-level decisions based on intelligence. | --- ## 13. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Procedure** | |---|---|---| | NIST 800-53r5 | RA-3, RA-5, SI-5, PM-16 | Sections 3, 4, 5, 7, 8 | | NIST CSF 2.0 | ID.RA, DE.CM | Sections 5, 7, 8 | | MITRE ATT&CK | Adversary technique mapping | Sections 5, 6, 8 | | MITRE ATT&CK for ICS | OT and ICS threat context | Sections 3, 8, 10 | | CMMC L2 / NIST 800-171r3 | Risk assessment and flaw remediation support | Sections 5, 7, 8 | | NERC-CIP | OT threat awareness and BES Cyber System implications | Sections 3, 8, 10 | | SOX ITGC | Threat context for financially relevant systems | Sections 7, 8 | --- --- ## Appendix A: Intelligence Product Templates ### A.1 Flash Advisory ``` FLASH ADVISORY - TI-YYYY-NNNN TLP: [AMBER / GREEN] Date: [date] Priority: [CRITICAL / HIGH / MEDIUM] Title: Summary: [one paragraph - what happened, what to do] Affected Technology: [vendor, product, version] Recommended Actions: 1. [action] 2. [action] IOCs (Confidence: [High/Medium/Low]): - [type]: [value] ATT&CK Mapping: [technique IDs] Source: [source type, reliability rating] Analyst: [name] ``` ### A.2 Weekly Digest ``` WEEKLY THREAT DIGEST - TI-WD-YYYY-WNN TLP: GREEN Period: [start] to [end] Key Developments: 1. [development] 2. [development] New IOCs: [count] - [summary of types] Upcoming Threats: [what to watch for in the next 7 days] Recommended Reading: [links to relevant advisories, reports] Analyst: [name] ``` ### A.3 Threat Model Input Brief ``` THREAT MODEL INPUT BRIEF - TI-TM-YYYY-NNNN TLP: AMBER System: [system name] Architecture Review: [AR-YYYY-NNNN] Threat Actors in Scope: | Actor | Capability | Relevance | |---|---|---| | | | | Relevant TTPs: | TTP | Description | Relevance to System | |---|---|---| | | | | Relevant CVEs (last 90 days): | CVE | CVSS | Affected Product | Exploit Available? | |---|---|---|---| | | | | | Recommended Abuse Cases: 1. [abuse case] 2. [abuse case] Analyst: [name] ``` ### A.4 Vulnerability Context Note ``` VULNERABILITY CONTEXT NOTE - TI-VC-YYYY-NNNN TLP: GREEN Date: [date] CVE: [CVE-ID] CVSS: [score] Exploit Status: [ ] Not observed in wild [ ] PoC available [ ] Actively exploited Affected Assets (from CMDB): [list or "None identified"] Recommended Priority: [Immediate / 72hr / 30-day / Patch-cycle] Context: [why this matters to the organization] Analyst: [name] ``` ### A.5 Vendor Risk Note ``` VENDOR RISK NOTE - TI-VR-YYYY-NNNN TLP: AMBER Date: [date] Vendor: [name] Vendor Tier: [T1/T2/T3] Finding: [description of threat intelligence] Risk Implication: [what this means for the organization's use of this vendor] Recommended Action: [specific action for Vendor Risk Analyst] Related: [CERG-PRC-TPRM-001 reference] Analyst: [name] ``` ### A.6 Executive Threat Brief ``` EXECUTIVE THREAT BRIEF - TI-EX-YYYY-QN TLP: AMBER Period: [quarter] [year] Top Threats: 1. [threat] - [impact to organization] - [likelihood] 2. [threat] - [impact] - [likelihood] 3. [threat] - [impact] - [likelihood] Program Impact: [how the threat landscape affects CERG program priorities] Recommended Decisions: [specific decisions for CISO/executive consideration] Analyst: [name] Reviewer: [CISO] ``` ## 14. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-TI-001 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-05-26 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to threat landscape or intelligence sources | | **Next Scheduled Review** | 2027-05-26 | | **Frameworks** | NIST 800-53r5 (RA-3, RA-5, SI-5, PM-16); NIST CSF 2.0 (ID.RA, DE.CM, ID.IM, GOVERN); MITRE ATT&CK; MITRE ATT&CK for ICS | | **Regulations** | CMMC L2 / 800-171r3; NERC-CIP; SOX ITGC where applicable | | **Environments** | All CERG-managed environments and risk decisions informed by threat intelligence | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Risk | Initial release. Establishes source management, intake fields, triage outcomes, relevance-based prioritization, tailored intelligence products, action tracking, integration with CERG processes, metrics, and canonical role responsibilities for threat intelligence. | | 1.1 Draft | 2026-05-26 | Cyber Risk | Added Section 9 (Intelligence-Driven Program Reprioritization): quarterly threat landscape assessment, reprioritization decision framework, decision record, verification, and integration with lessons learned. Added Section 10 (External Collaboration and Information Sharing): ISAC/ISAO membership requirements, peer benchmarking, external incident learning, community contribution, and information sharing boundaries. Renumbered subsequent sections. Updated supporting documents to include PRC-LL-001, IMPREG-001, and GOV-CAL-001. Addresses NIST CSF Adaptive gaps in intelligence-driven program change and bidirectional information sharing. | ### Review Triggers - Material change to the organization's threat landscape - Significant change to threat intelligence sources - Significant incident showing an intelligence gap - Change to exposure management, threat modeling, third-party risk, or risk-register processes - Direction from the CISO Cyber Risk owns this document. The Risk Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines Threat Intelligence Analyst role | | Exposure Management Procedure | [`CERG-PRC-VM-001`](CERG-PRC-VM-001_Exposure_Management_Procedure.md) | Consumes vulnerability intelligence | | Threat Modeling Procedure | [`CERG-PRC-TM-001`](CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Consumes threat actor and abuse-case context | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Consumes supplier and vendor intelligence | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Tracks residual risk from intelligence-driven findings | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Receives detection leads from intelligence | | Lessons Learned and Program Improvement Procedure | [`CERG-PRC-LL-001`](CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) | Intelligence assessments feed the quarterly aggregation | | Program Improvement Register | [`CERG-GOV-IMPREG-001`](../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) | Records intelligence-driven program changes | | Annual Security and Governance Calendar | [`CERG-GOV-CAL-001`](../governance/CERG-GOV-CAL-001_Annual_Security_and_Governance_Calendar.md) | Aligns quarterly assessment cadence | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `TI` domain | --- ## THREAT MODELING PROCEDURE ### Design Review · ATT&CK Mapping · Abuse Cases · Control Decisions · Architecture Review Input --- | | | |---|---| | **Document ID** | CERG-PRC-TM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Documents** | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) · [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) · [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / On material change to architecture review or threat modeling methods | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (RA, SA, PL, SC) · [NIST 800-160](https://csrc.nist.gov/pubs/sp/800/160/v1/final) · [NIST SSDF](https://csrc.nist.gov/pubs/sp/800/218/final) · [MITRE ATT&CK](https://attack.mitre.org/) · [MITRE ATT&CK for ICS](https://attack.mitre.org/matrices/ics/) · [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) | | **Regulations** | CMMC L2 / 800-171r3 · NERC-CIP · SOX ITGC where applicable | | **Environments** | All projects subject to CERG architecture review and all material changes to in-scope systems | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Principles](#2-principles) 3. [When Threat Modeling Is Required](#3-when-threat-modeling-is-required) 4. [Inputs](#4-inputs) 5. [Method](#5-method) 6. [Outputs](#6-outputs) 7. [Integration With Architecture Review](#7-integration-with-architecture-review) 8. [Finding Severity and Treatment](#8-finding-severity-and-treatment) 9. [Scaling the Procedure](#9-scaling-the-procedure) 10. [Roles and Responsibilities](#10-roles-and-responsibilities) 11. [Metrics](#11-metrics) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope The CERG README states that during architecture and design review, Engineering leads and Risk performs threat modeling. [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) makes threat modeling part of Phase 2. Until this procedure, the method, triggers, inputs, outputs, and handoff rules were implicit. This procedure makes them executable. Threat modeling is the design-time discipline of asking how a system can be abused before it is built or changed. It is not a paperwork exercise. It is how CERG turns threat knowledge into architecture decisions, control requirements, and risk register entries early enough that the project can still change cheaply. This procedure applies to every project subject to CERG architecture review, every material change to an in-scope system, and every new or materially changed use of AI, cloud, SaaS, OT, identity, regulated data, or internet exposure. > **Threat Modeling Is Risk's Design Contribution** > > Engineering reviews whether the design can be built and operated securely. Risk asks how an adversary will try to break it. Those are different questions, and a serious project needs both. Threat modeling is where Cyber Risk earns its seat in the design conversation: not by saying no, but by naming the attack paths early enough that Engineering can design them out. --- ## 2. Principles 1. **Model early.** The threat model happens while design decisions are still changeable. A threat model performed after go-live is a postmortem with nicer formatting. 2. **Model the system, not the diagram.** Diagrams are inputs. The model is about how data, identities, trust boundaries, and attackers move through the real system. 3. **Use threat intelligence, but do not wait for perfect intelligence.** Known threat actors, MITRE ATT&CK techniques, and recent incidents improve the model. Absence of a named actor is not absence of threat. 4. **Produce decisions.** A threat model that does not change a design, add a control, create a finding, or record an accepted risk did not do its job. 5. **Keep it proportional.** A low-risk SaaS configuration change does not need a three-hour workshop. A new internet-facing application touching Restricted data does. 6. **No orphan findings.** Every threat-model output has a disposition: designed out, mitigated by a control, accepted through the risk process, or tracked to remediation. --- ## 3. When Threat Modeling Is Required Threat modeling is required when a project meets any of the mandatory architecture review triggers in [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) §4.1 and also meets any of the following threat-modeling triggers. | **Trigger** | **Why It Matters** | |---|---| | New internet-facing service or external API | Expands attacker-reachable surface. | | Processing or storing Confidential or Restricted data | Raises impact of disclosure, alteration, and loss. | | New identity, access, privilege, or federation pattern | Changes who can reach what and how compromise propagates. | | New third-party integration or data exchange | Adds supply chain and trust-boundary risk. | | New cloud, SaaS, or multi-tenant architecture | Changes control responsibility and isolation assumptions. | | OT, BES Cyber System, or safety-impacting environment | Changes consequence and tolerance for active testing. | | New AI system or AI feature | Introduces prompt injection, data leakage, excessive agency, and model supply chain risks. | | Material change to an existing high-value system | Existing controls may no longer match the design. | | Significant incident, finding, or threat intelligence affecting the design | New information changes the threat picture. | A project below these thresholds may still receive a lightweight threat model at the discretion of the Risk Pillar Leader. --- ### 3.1 Legacy and Brownfield Systems The triggers in Section 3.1 focus on new systems and material changes. For existing (brownfield) systems that have never been threat-modeled, the following prioritization framework applies. #### Prioritization for Retroactive Threat Modeling | **Priority** | **Criteria** | **Target Completion** | |---|---|---| | Priority 1 | Systems handling CUI, BCSI, or SOX-relevant data; BES Cyber Systems; systems with Critical or High open risk register entries; internet-facing Tier 1 systems | Within 6 months | | Priority 2 | Internal Tier 1 or Tier 2 systems with Medium risk entries; systems supporting customer-facing services | Within 12 months | | Priority 3 | Tier 2 or Tier 3 systems with Low risk entries; internal-only non-production systems | Within 24 months | | Out of Scope | Tier 4+ systems; systems scheduled for decommissioning within 12 months; pure SaaS services where the vendor provides an equivalent threat model | - | #### Lightweight Threat Model for Legacy Systems For legacy systems where full threat modeling is infeasible (e.g., undocumented architecture, no original design artifacts), a lightweight approach is acceptable: - **Scope**: Document known boundaries, data flows, and integrations rather than attempting to reconstruct the entire architecture. - **Focus**: Concentrate on trust boundaries, external interfaces, and data classification paths rather than internal component detail. - **Output**: A reduced threat model covering abuse cases for the top 5 risks identified from the risk register, exposure backlog, and incident history. - **Acceptance**: The lightweight model is accepted as "sufficient for current risk posture" with a note that a full model will be produced at the next material change or system redesign. --- ## 4. Inputs The Threat Intelligence Analyst and the project team provide inputs before the session. Missing inputs do not automatically stop the model, but missing critical inputs are recorded as assumptions. | **Input** | **Source** | **Required For** | |---|---|---| | Business purpose and scope | Project sponsor or technical lead | Every model | | Architecture diagram | Project technical lead | Every model | | Data flow diagram | Project technical lead | Any system moving data across trust boundaries | | Data classification | Asset Owners, per [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Any system processing data | | Identity and access model | Identity Engineer | Any system with user, service, or privileged access | | External dependencies and vendors | Vendor Risk Analyst | Any third-party integration | | Deployment model and network paths | Cloud Security Engineer, OT Security Engineer, Endpoint Engineer as applicable | Cloud, OT, endpoint, and networked systems | | Known vulnerabilities and prior findings | Exposure Management Lead, Adversarial Testing Lead | Existing systems and material changes | | Relevant threat intelligence | Threat Intelligence Analyst, OT Risk Analyst where OT is in scope | Every model | | Applicable control requirements | Governance Pillar Leader, compliance manager as applicable | Regulated or audited systems | --- ### 4.1 Threat Actor Identification The abuse-case format includes a threat actor field. The following framework guides consistent actor identification. | **Actor Category** | **Description** | **Capability** | **Motivation** | |---|---|---|---| | Nation-state | State-sponsored actors with advanced capabilities | Advanced (custom tools, zero-days) | Espionage, disruption, strategic advantage | | Cybercriminal | Financially motivated organized groups | Intermediate to Advanced | Financial gain, data theft | | Hacktivist | Ideologically motivated individuals or groups | Low to Intermediate | Publicity, political statement | | Insider - Disgruntled | Employee/contractor with authorized access, malicious intent | Variable (access-dependent) | Revenge, financial gain | | Insider - Negligent | Employee/contractor who unintentionally causes harm | Low (accidental) | None (error, negligence) | | Competitor | Business competitor seeking advantage | Low to Intermediate | IP theft, market advantage | | Script Kiddie | Low-skill actor using publicly available tools | Low | Curiosity, notoriety | #### Actor Scoping Actors are scoped based on data classification, industry sector, system exposure, and threat intelligence from [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md). Nation-state and competitor actors are in scope for CUI, BCSI, and strategic IP. Internet-facing systems include cybercriminal and hacktivist actors. Internal-only systems emphasize insider actors. #### Actor-to-ATT&CK Mapping | **Actor** | **Typical ATT&CK Techniques** | |---|---| | Nation-state | T1190, T1078, T1021, T1003, T1041 | | Cybercriminal | T1566, T1203, T1486, T1048 | | Insider | T1078, T1530, T1048, T1485 | | Hacktivist | T1498, T1499, T1485, T1491 | --- ## 5. Method CERG uses a practical hybrid method. It combines asset and data-flow review, trust-boundary analysis, abuse-case generation, and MITRE ATT&CK mapping. The method is intentionally simple enough to run in a one-hour working session but complete enough to produce durable findings. ### 5.1 Step 1: Define What Is Being Protected The facilitator identifies the system's valuable assets and outcomes: - data and its classification; - identities and privileges; - service availability and recovery expectations; - financial, operational, safety, and regulatory impact; - business process the system enables. The goal is to state plainly what harm matters. A system cannot be threat-modeled well until the team knows what it is trying to protect. ### 5.2 Step 2: Draw Trust Boundaries The facilitator marks trust boundaries on the architecture and data-flow diagrams. A trust boundary exists wherever control assumptions change: internet to internal, user to service, tenant to tenant, corporate to vendor, IT to OT, identity provider to application, or AI model to tool execution. Every trust-boundary crossing is reviewed for authentication, authorization, encryption, logging, and validation. ### 5.3 Step 3: Generate Abuse Cases The group asks how a motivated attacker, malicious insider, compromised vendor, or mistaken user could abuse the system. The facilitator records abuse cases in the form: ```text As a [threat actor], I can [action] so that [impact]. ``` Examples: - As a phisher, I can steal a user's token and use it to call the application API so that I can export customer data. - As a compromised vendor integration, I can send malformed payloads so that I can trigger unauthorized actions. - As an attacker controlling prompt input, I can override the AI system's instructions so that it leaks restricted context. ### 5.4 Step 4: Map to ATT&CK The Threat Intelligence Analyst maps plausible abuse cases to MITRE ATT&CK techniques. For OT systems, the OT Risk Analyst uses MITRE ATT&CK for ICS. Mapping is not done to decorate the document; it is done to check whether the model reflects real adversary behavior and to feed detection and control decisions. ### 5.5 Step 5: Decide the Control Response For each abuse case, the team decides one of four dispositions: | **Disposition** | **Meaning** | |---|---| | **Design out** | Change the architecture so the abuse case is no longer plausible. | | **Mitigate** | Add or strengthen a preventive, detective, or recovery control. | | **Accept** | Record and approve residual risk through [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | | **Defer with owner and date** | Temporarily defer action, with an owner, due date, and review point. Deferment is not a parking lot. | ### 5.6 Step 6: Record Findings Findings are written as control-relevant statements, not vague concerns. A good finding names the attack path, the affected asset, the missing or weak control, the likely impact, and the recommended treatment. --- ### 5.7 Structured Threat Classification (STRIDE) STRIDE is the default threat classification framework for all CERG threat models. During abuse-case brainstorming (Section 5.3), the facilitator uses STRIDE categories as prompts to ensure comprehensive coverage. | **STRIDE** | **Question** | **Example** | |---|---|---| | **S**poofing | Can an actor impersonate an identity? | Attacker authenticates as admin using stolen credentials | | **T**ampering | Can an actor modify data? | Attacker modifies API payload to change authorization scope | | **R**epudiation | Can an actor deny an action without proof? | User deletes sensitive record; audit log insufficient | | **I**nformation Disclosure | Can an actor access data they should not see? | Attacker enumerates S3 bucket and downloads data | | **D**enial of Service | Can an actor degrade or deny service? | Attacker exhausts API rate limits | | **E**levation of Privilege | Can an actor gain unauthorized permissions? | Attacker exploits misconfigured IAM role to escalate | #### STRIDE-to-ATT&CK Mapping | **STRIDE** | **ATT&CK Tactics** | **Example Techniques** | |---|---|---| | Spoofing | Credential Access | T1078, T1550 | | Tampering | Impact | T1565, T1485 | | Repudiation | Defense Evasion | T1070, T1562 | | Information Disclosure | Collection, Exfiltration | T1530, T1048 | | Denial of Service | Impact | T1498, T1499 | | Elevation of Privilege | Privilege Escalation | T1068, T1078 | For OT systems, add **L**ateral Movement as a seventh category (STRIDE-LM). ### 5.6.1 AI-Specific Abuse Case Categories When threat modeling systems that incorporate AI or ML capabilities, the following abuse case categories supplement the standard STRIDE framework. Detailed controls are defined in CERG-STD-AI-001. | **Category** | **Description** | **Example Abuse Case** | |---|---|---| | Prompt Injection | Attacker crafts input that overrides system instructions or safety constraints | User injects "ignore previous instructions" to bypass content filtering | | Model Poisoning | Attacker contaminates training data to influence model behavior | Attacker submits poisoned data to a model that learns from user feedback | | Data Leakage | Model reveals training data, sensitive prompts, or system configuration | Attacker uses prompt engineering to extract PII from model responses | | Excessive Agency | Model performs actions beyond its authorized scope due to plugin or tool access | Model autonomously executes a DELETE operation on a production database | | Supply Chain for AI Models | Compromised pre-trained model, dataset, or dependency introduces backdoor or vulnerability | Attacker publishes a malicious model on a public hub that includes a backdoor trigger | | Adversarial Input | Input designed to cause misclassification or unexpected behavior | Slightly perturbed image that causes a classifier to misidentify a stop sign | | Model Inversion / Extraction | Attacker queries the model to reconstruct training data or replicate the model | Attacker makes thousands of API calls to extract model weights or training distribution | #### AI Threat Model Checklist When an AI component is in scope, the threat model additionally: - Identifies the model's data sources (training, fine-tuning, RAG, user input) and their trust levels - Maps the model's agency boundary: what can the model do without human approval? - Assesses the model supply chain: pre-trained weights, fine-tuning datasets, model-serving infrastructure - References [CERG-STD-AI-001] for detailed control requirements for each abuse case category ### 5.8 Facilitation Guide #### Pre-Session Preparation | **Activity** | **Timing** | |---|---| | Distribute inputs (diagrams, data classification, asset inventory, threat intelligence) | 5 business days before | | Confirm participants (system owner, architect, security engineer) | 5 business days before | | Pre-read threat intelligence per [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) | 2 business days before | #### Session Time-Boxing | **Step** | **Activity** | **Time** | |---|---|---| | 1 | Define assets, data, scope | 30 min | | 2 | Identify actors and entry points | 30 min | | 3 | Generate abuse cases using STRIDE prompts | 60 min | | 4 | Map existing controls | 30 min | | 5 | Assess residual risk, assign severity | 30 min | | 6 | Document findings, dispositions, control updates | 15 min | #### Handling Disagreements Disagreements during threat modeling indicate that a trust assumption or design decision needs clarification. The facilitator records disputed items, defaults to the higher severity when severity is disputed, and escalates to the Risk Pillar Leader for resolution if disagreements block session progress. Items are not allowed to derail the session; unresolved items are captured for follow-up. #### Brainstorming Techniques - **STRIDE prompts**: Use each category as a prompt per trust boundary - **Attack trees**: Start with the attacker's goal and work backward - **Kill chain mapping**: Map abuse cases to Recon → Weaponization → Delivery → Exploitation → Installation → C2 → Actions - **"What if" scenarios**: "What if this API key is leaked? What if this admin account is compromised?" #### Post-Session Activities | **Activity** | **Timing** | |---|---| | Distribute draft threat model | 2 business days after session | | Participants review | 5 business days | | Finalize threat model | 10 business days | | Enter findings in risk register per [CERG-PRC-RM-001](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | 3 business days after finalization | | Archive with review record per [CERG-PRC-AR-001](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | At finalization | --- ## 6. Outputs Every completed threat model produces the following outputs. | **Output** | **Description** | **Destination** | |---|---|---| | Threat model summary | Scope, date, participants, assumptions, diagrams reviewed, and high-level conclusion. | Project review record in [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). | | Abuse-case table | Abuse cases, ATT&CK mappings, impacted assets, and disposition. | Project review record; reused in secure development. | | Findings list | Specific design, control, or risk findings with owner and due date. | Architecture review action log. | | Risk entries | Residual risks that are not remediated before go-live. | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). | | Control updates | Needed changes to standards, baselines, detection, or evidence requirements. | Relevant document owner or control owner. | | Detection leads | ATT&CK-informed detection ideas arising from the model. | Detection Engineer. | > **The Output Is Not the Workshop Notes** > > Workshop notes are raw material. The output is the decision record. A project team should be able to read the final threat model and know exactly what must change, what risk remains, who owns each action, and what must be true before go-live. If the notes are interesting but the decisions are unclear, the model is unfinished. --- ## 7. Integration With Architecture Review Threat modeling is embedded in Phase 2 of [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md), not run as an unrelated side process. | **Architecture Review Phase** | **Threat Modeling Role** | |---|---| | Phase 1, Intake | Determine whether threat modeling is required and set expected depth. | | Phase 2, Architecture Review and Threat Model | Run this procedure; produce abuse cases and findings. | | Phase 3, Build-Time Engagement | Validate that design-out and mitigation actions are implemented. | | Phase 4, Pre-Production Security Review | Confirm unresolved threat-model findings are remediated or risk-accepted. | | Phase 5, Production Handoff and Go-Live | Include residual threat-model findings in the handoff package and risk register. | A go-live recommendation is not complete if required threat-model findings are unresolved and have no approved risk disposition. --- ## 8. Finding Severity and Treatment Threat-model findings are scored using the risk and exception process in [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). Severity considers both likelihood and impact, including the data classification from [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md), the asset criticality from [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md), and the system's regulatory scope. A finding may be closed only when one of the following is true: 1. the design changed and the abuse case no longer applies; 2. a control was implemented and verified; 3. the finding was recorded as residual risk and accepted by the correct authority; 4. the finding was proven invalid by new evidence and the Threat Intelligence Analyst or Risk Pillar Leader agrees. --- ## 9. Scaling the Procedure Threat modeling scales by depth, not by skipping accountability. | **Project Type** | **Threat Model Depth** | **Minimum Participants** | |---|---|---| | Low-risk change with no new trust boundary | Lightweight review, checklist plus assumptions. | Threat Intelligence Analyst or Risk Pillar Leader, project technical lead. | | Normal application or SaaS integration | Standard session, 60 to 90 minutes. | Threat Intelligence Analyst, Application Security Engineer or Cloud Security Engineer, project technical lead. | | High-value, regulated, internet-facing, AI, or OT system | Full session, may require multiple workshops. | Risk Pillar Leader, Threat Intelligence Analyst, relevant Engineering role, relevant compliance manager, project technical lead. | | Material post-incident redesign | Full session focused on the failed control path. | Risk Pillar Leader, Lead Investigator, relevant Engineering role, Risk Register Owner. | A five-person team still performs all four depths. One person may hold multiple roles under [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md), but the record still names the canonical role responsible for each decision. --- ### 9.1 Quality Assurance The Risk Pillar Leader is accountable for threat model quality. The following process ensures consistency and completeness. #### Peer Review All threat models receive a peer review by a second qualified analyst before finalization. The peer reviewer validates: - All trust boundaries are identified and documented - All data flows are mapped - All STRIDE categories are considered per trust boundary - All abuse cases have severity ratings and dispositions - All deferred or accepted items have named owners and target dates - The threat model references current threat intelligence from [CERG-PRC-TI-001](CERG-PRC-TI-001_Threat_Intelligence_Procedure.md) #### Calibration Sessions Quarterly calibration sessions are conducted using a sample threat model reviewed by all analysts. The purpose is to align severity ratings, ensure consistent abuse-case generation across analysts, and identify systematic gaps in the threat modeling process. The Risk Pillar Leader facilitates calibration and documents outcomes. #### Quality Checklist | **Check** | **Criteria** | |---|---| | Scope | System boundaries are clearly defined; out-of-scope items are documented with rationale | | Assets | All data classifications and critical assets are identified | | Diagrams | Context, data flow, network, identity, trust boundary diagrams are complete | | Threats | All STRIDE categories are considered; abuse cases are specific and testable | | Controls | Existing controls are mapped to each threat; control gaps are identified | | Findings | All findings have severity, disposition, owner, and due date | | Residual risk | Residual risk is assessed and documented; accepted risk has approval | #### Escalation Quality disputes that cannot be resolved between the analyst and peer reviewer are escalated to the Risk Pillar Leader for final determination. --- ## 10. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Threat Modeling Responsibility** | |---|---| | **Risk Pillar Leader** | Accountable for this procedure and for the quality of threat-model outputs. Determines required depth for high-risk projects. | | **Threat Intelligence Analyst** | Facilitates most threat models; supplies threat actor, campaign, and ATT&CK context; records abuse cases and ATT&CK mappings. | | **Application Security Engineer** | Supplies application security context; ensures findings feed secure development gates. | | **Cloud Security Engineer** | Supplies cloud, SaaS, network, and platform context for cloud-based systems. | | **Identity Engineer** | Supplies identity, privilege, federation, token, and access-path context. | | **OT Risk Analyst** | Supplies OT threat context and ATT&CK for ICS mapping where OT is in scope. | | **OT Security Engineer** | Supplies OT architecture and boundary-control context where OT is in scope. | | **Vendor Risk Analyst** | Supplies third-party and supply chain context for vendor integrations. | | **Detection Engineer** | Receives detection leads arising from threat models and translates them into detection backlog items where in scope. | | **Risk Register Owner** | Ensures residual risk from threat-model findings is recorded and tracked. | | **Governance Pillar Leader** | Ensures regulated-scope implications are captured and evidence requirements are identified. | | **Pre-production Reviewer** | Confirms threat-model findings are remediated or risk-accepted before go-live. | --- ## 11. Metrics | **KPI** | **Formula** | **Source** | **Refresh** | **Green** | **Amber** | **Red** | |---|---|---|---|---|---|---| | Threat models completed | Count of threat models finalized | Threat model repository | Quarterly | Baseline Y1 | | | | Average time per threat model | Mean calendar days from session to finalization | Threat model tracker | Quarterly | ≤ 15 days | 16–20 days | > 20 days | | Findings designed out | % of findings with disposition "Designed Out" vs. "Accepted" | Threat model repository | Quarterly | ≥ 40% | 20–39% | < 20% | | Deferred findings past due | Count of deferred findings with past-due target dates | Risk register | Monthly | 0 | 1–3 | > 3 | | Recurrence rate | % of findings that recur in subsequent threat models for the same system | Threat model repository | Annually | ≤ 10% | 11–25% | > 25% | | Threat model coverage rate | % of in-scope systems (per PRC-AR-001 Section 4.1) with current threat models | Asset inventory + TM repo | Quarterly | ≥ 90% | 75–89% | < 75% | > Baseline: "Baseline Y1" indicates the metric is collected for 12 months before Green/Amber/Red thresholds are established. --- ## 12. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Procedure** | |---|---|---| | NIST 800-53r5 | RA-3, RA-5, SA-8, SA-11, PL-8, SC family | Sections 3, 5, 6, 8 | | NIST 800-160 | Systems security engineering and design-time risk analysis | Sections 5, 7 | | NIST SSDF | PW.1, PW.2, RV.1, RV.2 | Sections 5, 7, 8 | | MITRE ATT&CK | Technique-informed adversary behavior | Sections 5, 6 | | MITRE ATT&CK for ICS | OT and ICS threat behavior | Sections 5, 10 | | OWASP ASVS | Application security verification context | Sections 5, 8 | | CMMC L2 / NIST 800-171r3 | Security assessment and risk assessment practices | Sections 3, 8 | | NERC-CIP | Design implications for BES Cyber System scope and boundary controls | Sections 3, 5, 10 | | SOX ITGC | Change-risk analysis for financially relevant systems | Sections 7, 8 | --- --- ## Appendix A: Threat Model Template ``` THREAT MODEL - TM-YYYY-NNNN 1. SYSTEM OVERVIEW System Name: System Owner: Data Classification(s): Regulatory Scope (CUI / SOX / NERC-CIP / None): Environment (IT / Cloud / SaaS / OT): Architecture Review Reference (AR-YYYY-NNNN): 2. SCOPE AND BOUNDARIES In Scope: Out of Scope (with rationale): Trust Boundaries: - [Boundary Name]: [between X and Y] 3. DATA FLOW DIAGRAM [Pending — create a data flow diagram (DFD) for the system under review. The diagram should identify all system components, external entities, data stores, and data flows with direction labels. Store in the `threat-model-diagrams/` directory alongside this threat model document. Recommended formats: Draw.io (.drawio), Excalidraw (.excalidraw), or Lucidchart exported as PDF. See CERG PRC-TM-001 §3.1 for minimum diagram requirements.] 4. TRUST BOUNDARY DIAGRAM [Pending — create a trust boundary diagram identifying all trust boundaries between system components, processes, and external entities. Highlight boundaries where data crosses between different trust levels (e.g., Internet ↔ DMZ, DMZ ↔ Internal, Internal ↔ OT, SaaS provider ↔ On-prem). Store in the `threat-model-diagrams/` directory. See CERG PRC-TM-001 §3.2 for minimum diagram requirements.] 5. ASSET INVENTORY | Asset | Classification | Owner | Environment | |---|---|---|---| | | | | | 6. ABUSE CASES | ID | Threat Actor | Abuse Case | STRIDE | ATT&CK | Severity | Disposition | |---|---|---|---|---|---|---| | TM-001 | | | | | | | Disposition values: Designed Out / Mitigated / Transferred / Accepted / Deferred 7. FINDINGS | ID | Description | Severity | Disposition | Owner | Due Date | |---|---|---|---|---|---| | | | | | | | 8. CONTROL UPDATES REQUIRED | Control ID (CB-001) | Current State | Required State | Owner | Due Date | |---|---|---|---|---| | | | | | | 9. RESIDUAL RISK [Summary of residual risk after controls; link to risk register entries] 10. SIGN-OFF Threat Modeling Facilitator: [name, date] Peer Reviewer: [name, date] Risk Pillar Leader: [name, date] ``` ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PRC-TM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material change to architecture review or threat modeling methods | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-53r5 (RA, SA, PL, SC); NIST 800-160; NIST SSDF; MITRE ATT&CK; MITRE ATT&CK for ICS; OWASP ASVS | | **Regulations** | CMMC L2 / 800-171r3; NERC-CIP; SOX ITGC where applicable | | **Environments** | All projects subject to CERG architecture review and material changes to in-scope systems | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Risk | Initial release. Establishes the procedure for threat modeling during architecture review, including triggers, inputs, a practical hybrid method using abuse cases and MITRE ATT&CK mapping, required outputs, integration with CERG-PRC-AR-001, finding treatment, scaling guidance, and canonical role responsibilities. | ### Review Triggers - Change to [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - Change to the CERG secure development or AI security standards - Revision to MITRE ATT&CK, MITRE ATT&CK for ICS, NIST SSDF, or relevant NIST 800-53 controls - Significant incident showing threat-modeling gaps - Direction from the CISO Cyber Risk owns this document. The Risk Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Establishes the pillar handoff and canonical roles | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Threat modeling is Phase 2 input and output | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control requirements considered during modeling | | Secure Software Development and Application Security Standard | [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Threat-model findings feed secure development gates | | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | AI-specific threat classes and required modeling | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Residual threat-model findings are recorded and treated | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Data classification input | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Asset criticality input | | Consolidated Roles, Responsibilities, and RACI Instrument | [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Scaling and role accountability reference | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `TM` domain | --- ## BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN ### Business Impact Analysis · Recovery Sequencing · Crisis Roles · DR Exercises · Cyber Recovery Interface --- | | | |---|---| | **Document ID** | CERG-PLN-BC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Documents** | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | | **Supporting Documents** | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-PLN-IR-001`](CERG-PLN-IR-001_Incident_Response_Plan.md) · [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) · [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / After major outage, DR exercise, or business-process change | | **Frameworks** | [NIST 800-34r1](https://csrc.nist.gov/pubs/sp/800/34/r1/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (CP, IR) · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (RECOVER) · ISO 22301 · ISO/IEC 27031 | | **Regulations** | SOX ITGC · CMMC L2 / 800-171r3 · NERC-CIP CIP-009 where applicable | | **Environments** | Business-critical processes, supporting systems, regulated environments, and CERG-managed recovery controls | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [BCP and Cyber Recovery Boundary](#2-bcp-and-cyber-recovery-boundary) 3. [Business Impact Analysis](#3-business-impact-analysis) 4. [Recovery Tier Model](#4-recovery-tier-model) 5. [Recovery Sequencing](#5-recovery-sequencing) 6. [Crisis Roles and Governance](#6-crisis-roles-and-governance) 7. [Plan Activation and Communications](#7-plan-activation-and-communications) 8. [Disaster Recovery Exercise Program](#8-disaster-recovery-exercise-program) 9. [Evidence and Records](#9-evidence-and-records) 10. [Metrics](#10-metrics) 11. [Roles and Responsibilities](#11-roles-and-responsibilities) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) defines the technical recovery bar: backup protection, immutable copies, restoration testing, and cyber recovery tiers. This plan defines the operational wrapper around that bar: business impact analysis, recovery sequencing, crisis roles, recovery decisioning, exercise cadence, and evidence. This plan applies to business processes and systems whose interruption could cause material operational, regulatory, customer, safety, financial, or reputational impact. It is written as a CERG-operable plan, not a full enterprise business-continuity program charter. It gives the program-in-a-box enough structure to survive an outage and to prove the recovery discipline existed before the outage. > **A Backup Is Not a Continuity Plan** > > A clean restore is necessary, but it is not sufficient. The business still has to know which process comes back first, which degraded process is acceptable, who declares the crisis, who talks to customers, who approves operating below normal control posture, and what evidence proves the recovery was controlled. Disaster recovery restores technology. Business continuity restores the business. --- ## 2. BCP and Cyber Recovery Boundary | **Question** | **Primary Owner** | **CERG Contribution** | |---|---|---| | Which business processes are most critical? | Business owner / Enterprise BCP | Uses the BIA output to align recovery tiers. | | Can backups be restored cleanly? | Engineering Pillar Leader | Owns technical restoration validation under `CERG-STD-RES-001`. | | Which systems support the process? | Business owner with Asset Management | Uses the asset inventory and dependency records. | | Who declares a crisis? | Enterprise crisis process / CISO when cyber-led | Provides security impact, risk, and control-state facts. | | Can the business operate manually or degraded? | Business owner / Enterprise BCP | Identifies cyber control implications of degraded operation. | | What residual risk exists during recovery? | Risk Pillar Leader | Records and routes risk acceptance under `CERG-PRC-RM-001`. | | What evidence proves recovery readiness? | Governance Pillar Leader | Maintains evidence package and audit trail. | CERG does not replace Enterprise BCP. CERG supplies the cyber, risk, evidence, and control integrity layer that BCP needs. --- ## 3. Business Impact Analysis The Business Impact Analysis (BIA) is the source record for recovery priority. Each in-scope business process has a BIA record with the fields below. | **Field** | **Purpose** | |---|---| | Business Process | Named process or service being protected. | | Business Owner | Accountable owner for recovery priority and acceptable degradation. | | Supporting Systems / Assets | Asset IDs from `CERG-STD-AM-001`. | | Data Classification | Highest data classification processed. | | Regulated Scope | SOX, CUI, NERC-CIP, privacy, contractual, or other obligations. | | Maximum Tolerable Downtime | Business tolerance for interruption. | | Target RTO | Required recovery time objective. | | Target RPO | Required recovery point objective. | | Manual Workaround | Whether degraded manual operation exists and for how long. | | Upstream Dependencies | Vendors, networks, identity, facilities, data feeds. | | Downstream Dependencies | Processes or customers that rely on this process. | | Recovery Priority | Sequencing tier for restoration. | | Minimum Control Posture | Security controls required before operation resumes. | BIA records are reviewed at least annually and whenever a critical process, system dependency, regulated scope, or business owner changes. --- ## 4. Recovery Tier Model The plan uses the recovery tiers defined in [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md). The BIA may assign a stricter business requirement than the technical recovery tier, but it may not silently assign a weaker one for a regulated or mission-critical process. | **Tier** | **Business Meaning** | **Minimum Planning Requirement** | |---|---|---| | T1 - Mission-Critical | Outage creates safety, regulatory, material financial, or severe customer impact within hours. | Documented recovery runbook, quarterly restore evidence, annual full DR exercise, named crisis owner. | | T2 - Business-Critical | Outage materially impairs operations within one business day. | Documented recovery runbook, semi-annual restore evidence, annual tabletop or technical exercise. | | T3 - Important | Outage degrades operations but is tolerable for several days. | Documented recovery steps, annual restore evidence, annual review. | | T4 - Standard | Outage is inconvenient but manageable through ordinary support. | Backup and rebuild path documented. | | T5 - Non-Production | Recovery is rebuild from code, infrastructure-as-code, or golden image. | Rebuild method documented where needed. | > **RTO and RPO Are Claims Until Tested** > > A stated RTO or RPO does not become a planning fact until it has been demonstrated. Until then, the recovery tier is aspirational and the gap is tracked as a resilience risk. The plan may still operate, but leadership must know which recovery promises are proven and which are hoped for. --- ## 5. Recovery Sequencing Recovery sequencing is decided before an outage, not during the worst hour of one. Each T1 and T2 process has a sequencing record: 1. Confirm safety, legal, and regulatory constraints. 2. Confirm identity, network, logging, and backup platform availability. 3. Restore or fail over platform dependencies. 4. Restore core data stores and integrity checks. 5. Restore application or operational service. 6. Validate security controls: access, logging, encryption, endpoint posture, segmentation, backup protection. 7. Validate business function with the business owner. 8. Approve return to production or degraded operation. 9. Record residual risk and exceptions. 10. Preserve recovery evidence. A process may resume in degraded mode only when the business owner, Engineering Pillar Leader, Risk Pillar Leader, and CISO or delegate understand the missing controls and approve the risk path. --- ## 6. Crisis Roles and Governance | **Role** | **Continuity Responsibility** | |---|---| | Chief Information Security Officer (CISO) | Receives crisis briefings, approves material cyber risk during recovery, escalates to executive leadership. | | Governance Pillar Leader | Owns this plan, evidence discipline, and continuity governance reporting. | | Engineering Pillar Leader | Owns cyber recovery execution, restoration validation, and technical sequencing. | | Risk Pillar Leader | Owns residual-risk assessment and risk-register entries arising from recovery decisions. | | Evidence Librarian | Maintains exercise and outage evidence. | | Risk Register Owner | Records resilience risks, accepted degraded operations, and post-event remediation. | | Cloud Security Engineer | Supports cloud, SaaS, platform, and tenant recovery. | | Identity Engineer | Restores and validates identity, MFA, privilege, service accounts, and federation. | | OT Security Engineer | Supports OT recovery and NERC-CIP implications where applicable. | | SOX ITGC Lead | Ensures SOX-relevant recovery evidence is retained. | | CMMC / Federal Compliance Manager | Ensures CUI recovery obligations are addressed. | | NERC-CIP Compliance Manager | Ensures CIP recovery obligations and evidence are addressed. | Where an enterprise BCP or crisis-management program names additional roles, those roles remain outside CERG. CERG coordinates through its canonical roles. --- ## 7. Plan Activation and Communications This plan is activated when an outage, incident, disaster, supplier failure, cyber event, facility issue, or platform failure threatens a T1 or T2 process, or when the CISO, Governance Pillar Leader, Engineering Pillar Leader, or enterprise crisis process requests activation. Activation record: - date and time activated; - activating role and reason; - affected business process and systems; - current impact and expected trajectory; - recovery tier and sequencing priority; - cyber control state; - communication cadence; - recovery decision log; - risk acceptances or exceptions; - closure criteria. Communications use the enterprise crisis communications process where one exists. CERG supplies technical facts, control posture, data classification, regulated-scope facts, recovery evidence, and residual-risk statements. --- ## 8. Disaster Recovery Exercise Program | **Exercise Type** | **Minimum Cadence** | **Required For** | **Evidence** | |---|---|---|---| | Tabletop | Annual | T1 and T2 processes | Scenario, participants, decisions, gaps, actions. | | Technical restore test | Per `CERG-STD-RES-001` tier | Systems with recoverable state | Restore time, data currency, validation result. | | Full DR exercise | Annual for T1; at least every two years for T2 where feasible | Mission-critical process chains | End-to-end recovery evidence and lessons learned. | | Regulated-scope exercise | Per regulator or audit cycle | SOX, CUI, NERC-CIP, and contractual scopes | Control-specific evidence package. | Exercise findings become risk-register entries or tracked remediation actions. A passed exercise with missing evidence is not a passed exercise for audit purposes. --- ## 9. Evidence and Records Continuity records are retained under [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). | **Evidence Item** | **Required When** | |---|---| | BIA record | Every in-scope T1 through T3 business process. | | Recovery runbook | Every T1 and T2 process. | | Restore test evidence | Per recovery tier. | | DR exercise package | Every tabletop, technical exercise, and full DR exercise. | | Activation record | Every plan activation. | | Recovery decision log | Every active continuity event. | | Risk acceptance or exception | Any degraded operation or missing control. | | Post-event report | Every material outage or exercise. | --- ## 10. Metrics | **Metric** | **Purpose** | |---|---| | T1/T2 processes with current BIA | Measures planning coverage. | | T1/T2 processes with current recovery runbook | Measures executable readiness. | | Restore tests completed on schedule | Measures technical recovery discipline. | | RTO achieved in tests | Measures recovery realism. | | RPO achieved in tests | Measures data-loss realism. | | Open recovery gaps by age and severity | Measures remediation backlog. | | Exercises completed on schedule | Measures governance cadence. | | Degraded-operation risk acceptances | Measures how often recovery requires control compromise. | --- ## 11. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Plan Responsibility** | |---|---| | **Governance Pillar Leader** | Accountable owner for this plan and continuity governance evidence. | | **Engineering Pillar Leader** | Accountable for cyber recovery execution and restoration validation. | | **Risk Pillar Leader** | Accountable for residual-risk assessment during recovery. | | **Evidence Librarian** | Maintains BIA, exercise, activation, and recovery evidence. | | **Risk Register Owner** | Records recovery gaps, resilience risks, and accepted degraded operations. | | **Cloud Security Engineer** | Supports platform and SaaS recovery. | | **Identity Engineer** | Supports identity restoration and access validation. | | **Endpoint Engineer** | Supports endpoint recovery and device posture validation. | | **OT Security Engineer** | Supports OT continuity and CIP-009 interfaces. | | **SOX ITGC Lead** | Ensures financially relevant recovery evidence is audit-ready. | | **CMMC / Federal Compliance Manager** | Ensures CUI recovery obligations are addressed. | | **NERC-CIP Compliance Manager** | Ensures NERC-CIP recovery obligations are addressed. | | **Chief Information Security Officer (CISO)** | Approves material recovery risk acceptance and executive escalation. | --- ## 12. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Plan** | |---|---|---| | NIST 800-34r1 | Contingency planning guide | Sections 3 through 9 | | NIST 800-53r5 | CP, IR, CA | Sections 4, 5, 8, 9 | | NIST CSF 2.0 | RECOVER | Sections 5, 7, 8 | | ISO 22301 | Business continuity management | Sections 3, 6, 7, 8 | | ISO/IEC 27031 | ICT readiness for business continuity | Sections 4, 5, 8 | | SOX ITGC | Backup, operations, change, evidence | Sections 4, 8, 9 | | CMMC L2 / 800-171r3 | Contingency and incident response support | Sections 5, 8, 9 | | NERC-CIP CIP-009 | Recovery plans for BES Cyber Systems | Sections 4, 8, 11 | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PLN-BC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and after major outage, DR exercise, or business-process change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-34r1; NIST 800-53r5 (CP, IR); NIST CSF 2.0 (RECOVER); ISO 22301; ISO/IEC 27031 | | **Regulations** | SOX ITGC; CMMC L2 / 800-171r3; NERC-CIP CIP-009 where applicable | | **Environments** | Business-critical processes, supporting systems, regulated environments, and CERG-managed recovery controls | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes BIA requirements, recovery tiers, recovery sequencing, crisis roles, activation records, DR exercise cadence, continuity evidence, metrics, and the boundary between Enterprise BCP and CERG cyber recovery. | ### Review Triggers - Major outage or disaster-recovery event - Material change to business-process criticality - Material change to recovery tiering or backup architecture - Failed DR exercise or missed RTO/RPO target - New regulated-scope recovery requirement - Direction from the CISO Cyber Governance owns this plan. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval and Enterprise BCP owner concurrence where applicable. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines canonical roles and CERG boundaries | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control source for continuity and recovery obligations | | Cyber Resilience and Backup Standard | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Technical recovery and backup standard | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Asset and dependency source | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Data classification and regulated data support | | Incident Response Plan | [`CERG-PLN-IR-001`](CERG-PLN-IR-001_Incident_Response_Plan.md) | Incident-driven activation interface | | Incident Response Playbook Set | [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | CERG incident support playbooks | | Security Change Management Procedure | [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) | Recovery changes and emergency changes | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Residual risk and degraded-operation acceptance | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence retention | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `BC` domain | --- ## CUI / [CMMC](https://dodcio.defense.gov/CMMC/) OPERATIONAL PACKAGE ### SSP · POA&M · SPRS · Boundary · 800-171 Practice Evidence · [CMMC L2](https://dodcio.defense.gov/CMMC/) Readiness · Subcontractor Register --- | | | |---|---| | **Document ID** | CERG-PLN-CUI-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Standard** | [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) - CUI Handling Standard | | **Supporting Documents** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) · [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [CERG-PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) | | **Review Cycle** | Annual / Continuous - POA&M monthly, SSP on material change | | **Frameworks** | [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) · [NIST 800-172](https://csrc.nist.gov/pubs/sp/800/172/final) (selected) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) mappings · [CMMC L2](https://dodcio.defense.gov/CMMC/) | | **Regulations** | DFARS 252.204-7012 · DFARS 252.204-7019/7020/7021 · [CMMC L2](https://dodcio.defense.gov/CMMC/) | | **Environments** | All systems within the CUI boundary | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Assumed Scrutiny Level, CMMC L2 Third-Party Assessment](#2-assumed-scrutiny-level--cmmc-l2-third-party-assessment) 3. [CUI Boundary, Finding It and Drawing It](#3-cui-boundary--finding-it-and-drawing-it) 4. [SSP Template](#4-ssp-template) 5. [POA&M Template](#5-poam-template) 6. [SPRS Score Worksheet](#6-sprs-score-worksheet) 7. [CUI Boundary Diagram Template](#7-cui-boundary-diagram-template) 8. [CUI Data Flow Map Template](#8-cui-data-flow-map-template) 9. [CUI Category Register](#9-cui-category-register) 10. [800-171 Practice Evidence Matrix](#10-800-171-practice-evidence-matrix) 11. [CMMC L2 Readiness Checklist](#11-cmmc-l2-readiness-checklist) 12. [C3PAO Assessment Logistics](#12-c3pao-assessment-logistics) 13. [CUI Subcontractor Register](#13-cui-subcontractor-register) 14. [FedRAMP Equivalency Evidence Checklist](#14-fedramp-equivalency-evidence-checklist) 15. [Regulatory and Framework Alignment Summary](#15-regulatory-and-framework-alignment-summary) 16. [Document Control](#16-document-control) --- ## 1. Purpose and Scope The CUI Handling Standard names what is required; this package makes the standard executable. It assembles the SSP, POA&M, SPRS worksheet, boundary diagrams, data flow maps, category register, 800-171 evidence matrix, [CMMC L2](https://dodcio.defense.gov/CMMC/) readiness checklist, C3PAO logistics, subcontractor register, and FedRAMP equivalency evidence into a single operational binder. It applies to every system, person, and process within the CUI boundary, and to every CUI subcontractor receiving CUI from the organization. --- ## 2. Assumed Scrutiny Level: [CMMC L2](https://dodcio.defense.gov/CMMC/) Third-Party Assessment CERG operates the CUI program at the level required to pass a **[CMMC](https://dodcio.defense.gov/CMMC/) Level 2 third-party assessment** by an authorized C3PAO. [CMMC L1](https://dodcio.defense.gov/CMMC/) is treated as a strict subset that is automatically met when L2 is met. > **Why Plan for L2 Third-Party as the Baseline** > > [CMMC L2](https://dodcio.defense.gov/CMMC/) with C3PAO assessment is the highest practical scrutiny most CUI primes face on a routine cadence. If the program is ready for that scrutiny, it is ready for the lesser ones. Designing to a lower level and hoping to "lift later" produces a program that drifts under audit pressure. --- ## 3. CUI Boundary: Finding It and Drawing It The CUI boundary is the set of systems, people, processes, and physical spaces that store, process, or transmit CUI. Defining it is the first executable step; it drives everything else. ### 3.1 Discovery Method 1. **Start from contracts.** DFARS-flowed contracts identify CUI obligations and (often) the categories. 2. **Add data discovery.** Use DLP, data discovery tools, and labelled storage signals to locate CUI in environments that may have it. 3. **Add process discovery.** Interview business units that interact with contracts; identify where CUI enters the environment. 4. **Validate via Architecture Review records.** [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) should have intaken any system handling CUI; any CUI-handling system not in the AR record is a finding. 5. **Reconcile against the CUI Category Register** (Section 9). ### 3.2 Categories of CUI Currently In Scope The CUI Category Register (Section 9) lists categories actually handled (e.g., Controlled Technical Information, Export Control, Procurement Sensitive). Categories not handled are explicitly noted as Not-In-Scope so future inquiries are unambiguous. ### 3.3 Boundary Statement (Example Skeleton) ``` The CUI boundary comprises: - in (FedRAMP Moderate / equivalent) - in - assigned to - with their associated identity, logging, and backup systems Excludes: - General corporate IT - OT environments (separately governed by [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) / [CERG-PLN-CIP-001](CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md)) - SOX-relevant systems that do not also handle CUI ``` --- ## 4. SSP Template The System Security Plan is the assessor-facing description of the CUI environment and how each 800-171 practice is implemented. ``` SYSTEM SECURITY PLAN - SSP-CUI-NNN 1. SYSTEM IDENTIFICATION System Name(s) / Aliases System Type (enclave / app / hybrid) Operational Status Executive Sponsor / System Representative Authorizing Official (CISO) Information System Security Point of Contact (CMMC / Federal Compliance Manager or delegate) System Boundary Description (Section 3.3 instance) 2. SYSTEM ENVIRONMENT Architecture and components (reference Section 7 diagram) Hardware and software inventory Network topology (reference Section 7 diagram) Hosting / cloud / SaaS providers and FedRAMP / equivalency status (Section 14) Interconnections and authorized data flows (reference Section 8 map) 3. CUI CATEGORIES PROCESSED List of categories per Section 9 register Sensitivity considerations (export control, etc.) 4. SECURITY REQUIREMENT IMPLEMENTATION For each 800-171r3 practice (3.1.1 … 3.14.x): - Practice statement - Implementation status (Implemented / Partially / Inherited / Planned / N/A) per [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 4 - Implementation description (specific, system-specific text) - Inheritance source (if inherited; references Section 14) - Evidence pointer (system / artifact / location) - Cross-reference to CERG control / standard / procedure 5. ROLES AND RESPONSIBILITIES Named roles for system operations and security 6. CONTINUOUS MONITORING STRATEGY Detection coverage; vulnerability scanning; recertification; control test cadence 7. INCIDENT RESPONSE Reference to [CERG-PLN-IR-001](CERG-PLN-IR-001_Incident_Response_Plan.md) with CUI-specific notes (DC3 reporting, 72-hour notification) 8. APPROVALS Information System Security Point of Contact, Executive Sponsor / System Representative, CISO Appendices: A. CUI Boundary Diagram (Section 7) B. CUI Data Flow Map (Section 8) C. 800-171 Practice Evidence Matrix (Section 10) D. POA&M (Section 5) E. Inheritance Evidence Packages (Section 14) ``` > **The SSP Is Specific, Not Aspirational** > > "Multi-factor authentication is implemented" is not implementation language. "Phishing-resistant MFA via Entra ID enforced by Conditional Access policy 'CUI-Enclave-Privileged-MFA' for all privileged role holders, with break-glass exception per [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §7" is. C3PAO assessors read implementation language for specificity; vague text invites probing questions and findings. --- ## 5. POA&M Template The Plan of Action and Milestones tracks Partially Implemented and Planned items toward closure. | **Field** | **Description** | |---|---| | POAM ID | `POAM-CUI-YYYY-NNNN` | | 800-171 Practice | e.g., 3.13.11 | | Weakness | Specific, not vague | | Affected Systems | Reference SSP boundary | | Source | Self-assessed · Internal audit · C3PAO · Pen test · Vuln scan | | Severity | Per [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) scoring | | Owner | Named role | | Resources Required | People / budget / vendor | | Original Identification Date | - | | Target Milestones | Step-level with dates | | Completion Date | Target | | Status | Open · In Progress · Completed · Risk Accepted | | Linked Risk Register ID | If risk-accepted or material | | Evidence on Closure | Artifact required at close | POA&M is updated **monthly** at minimum; closures must include evidence acceptable at C3PAO assessment. --- ## 6. SPRS Score Worksheet The Supplier Performance Risk System score is the self-reported [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) maturity number reported under DFARS 252.204-7019. The worksheet: | **Field** | **Description** | |---|---| | Assessment Date | - | | Assessment Scope | SSP-CUI-NNN reference | | Methodology | [NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final) DoD Assessment Methodology v1.2.1 | | Starting Score | 110 | | Weighted Deductions Applied | Per DoD scoring template - list each practice missed and its deduction | | Final Score | Calculated | | POA&M Items at Time of Score | Count + IDs | | Expected Closure Schedule | Per POA&M | | Reporter | Named role | | Submitted to SPRS Date | - | The worksheet is reproduced from the public DoD methodology; CERG does not invent its own scoring weights. --- ## 7. CUI Boundary Diagram Template The diagram is produced in the architecture tool used by [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). The required elements: - The **trust boundary** of the CUI environment, clearly drawn. - All **CUI-processing systems** inside the boundary. - All **entry / exit points** with named identity, network, and encryption controls. - **External services** that touch the boundary (FedRAMP / equivalency status annotated). - **Subcontractor connections** (Section 13). - **Out-of-scope adjacent systems** distinguished with shading or annotation. A diagram is required at SSP submission and refreshed on any material change. --- ## 8. CUI Data Flow Map Template The data flow map shows how CUI moves from contract intake → processing → archival, including: - Each **transit hop** annotated with protocol and [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) encryption details. - Each **transformation** (where CUI is combined, derived, or labeled). - Each **storage location** with classification label, retention, and access pattern. - Each **export** (to a customer, a subcontractor, or a contracting officer) with delivery method. The map is referenced from the SSP and from the boundary diagram. --- ## 9. CUI Category Register | **Field** | **Description** | |---|---| | Category | e.g., Controlled Technical Information, Export Control, Procurement Sensitive | | Source Authority | E.g., 32 CFR § 2002, DFARS 252.204-7012 | | First Seen | When CUI of this category entered scope | | Currently In Scope | Y/N | | Receiving Systems | SSP references | | Special Handling | Export control, FedRAMP requirement, etc. | | Disposition on Contract End | Return / Destroy / Retain per contract | Categories never handled are explicitly listed as Not-In-Scope so future inquiries are unambiguous. --- ## 10. 800-171 Practice Evidence Matrix The matrix is the row-per-practice spine. It is the principal artifact a C3PAO uses to navigate the SSP. | **Field** | **Description** | |---|---| | Practice ID | e.g., 3.13.11 | | Practice Statement | [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) language | | Implementation Status | Per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 4 | | CERG Control(s) | From [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | | Subordinate Standard / Procedure | E.g., [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) §9 | | System(s) Implementing | Per SSP | | Evidence Artifact | Specific document / report / configuration export | | Evidence Location | URI / system / binder reference | | Last Verified | Date | | Next Verification | Date | | Open POA&M | POAM ID if applicable | | Notes | Special handling, exceptions | The matrix is the artifact CERG ships with the SSP. It is updated whenever an evidence artifact is refreshed. --- ## 11. [CMMC L2](https://dodcio.defense.gov/CMMC/) Readiness Checklist A pre-assessment self-check, repeated quarterly and aggressively in the 90 days before an assessment. | **Area** | **Check** | **Pass** | |---|---|---| | Scope | CUI boundary documented and currently accurate | Y / N | | Scope | All CUI-handling systems intaken via [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Y / N | | SSP | SSP current; specific implementation language; appendices complete | Y / N | | Evidence | Evidence Matrix has artifact for every practice | Y / N | | Evidence | Every evidence artifact dates within the assessor's expected window | Y / N | | POA&M | All Partially Implemented items have current POA&M | Y / N | | Inheritance | Every Inherited practice has Inheritance Evidence Package per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 5 | Y / N | | Crypto | FIPS profile per [`CERG-STD-CR-001`](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) Section 9 satisfied | Y / N | | Logging | Mandatory log sources onboarded per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Y / N | | Detection | Day-one detection set in CUI environment | Y / N | | Access | Phishing-resistant MFA on CUI access paths | Y / N | | Backup | Recovery plan exists; recent restoration test for CUI tier | Y / N | | Vendor / Sub | Subcontractor register current; flow-down validated | Y / N | | Incident Response | DC3 reporting path tested or rehearsed | Y / N | | People | Awareness training current for CUI handlers | Y / N | | Physical | CUI work areas conform to physical control requirements | Y / N | | **Sampled Walkthroughs** | At least one walkthrough per CUI system in the 90-day window | Y / N | ### 11.2 Mock CMMC Assessment Procedure The Mock Assessment Procedure is scheduled 6 months before the target C3PAO assessment date. It simulates the full CMMC Level 2 assessment process using internal or partner assessors to identify gaps before the real assessment. #### Scope Definition | **Scope Element** | **Description** | |---|---| | Assessment Boundary | All systems, people, processes, and facilities within the CUI boundary (Section 3) | | Framework | CMMC Level 2 practices and processes (ALL 110+ practices across 14 domains) | | Assessment Type | Full mock (practice-by-practice evidence review + interview simulation) | | Exclusions | Explicitly documented; any exclusion must be approved by CMMC / Federal Compliance Manager | | Evidence Window | Evidence from prior 12 months minimum; assessors may request specific periods | #### Assessor Assignment | **Assessor Role** | **Source** | **Responsibilities** | |---|---|---| | Lead Assessor | Internal (Governance Pillar Leader or qualified senior CERG member) OR external partner (e.g., consulting firm, C3PAO-in-training) | Overall assessment coordination, final findings report, exit briefing | | Practice Reviewer | Internal (Engineering, Risk, Governance pillar members NOT responsible for the systems under assessment) | Practice-by-practice evidence review per Practice Evidence Matrix | | Interviewer | Internal (trained assessor or HR-partnered facilitator) | Conduct leadership, system owner, and operator interviews | | Scribe | Internal (Evidence Librarian or designee) | Document findings, observations, and notes during all sessions | | Observer | CMMC / Federal Compliance Manager | Observe process; no scoring authority during mock | #### Independence Requirement - No assessor may evaluate practices they personally own or operate. - If the organization has only 2–3 CERG team members, use an external partner for at least the Lead Assessor role. - Independence declarations are signed by each assessor before the mock begins. #### Practice-by-Practice Evidence Review The core of the mock assessment. Each CMMC Level 2 practice (ALL 110+) is reviewed against the Practice Evidence Matrix (Section 10). | **Review Step** | **Details** | |---|---| | Pre-populate | Evidence Matrix is pre-populated with current evidence artifacts, status, and last-verified dates | | Reviewer assignment | Each practice assigned to a Practice Reviewer; 20–30 practices per reviewer typical | | Evidence inspection | Reviewer inspects each evidence artifact for: completeness (per Section 10 matrix), freshness (within expected window), traceability (artifact maps to the practice claim), and quality (per [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md)) | | Scoring | Per CMMC scoring: MET / NOT MET / NOT APPLICABLE | | Observation notes | Reviewer records observations, concerns, and clarifying questions per practice | | Gap flagging | Any practice scored NOT MET is flagged with the specific deficiency, root cause, and recommended remediation | | Re-review | Remediated practices are re-reviewed within 2 weeks of closure evidence | #### Interview Simulation Interviews simulate C3PAO assessor interaction with key personnel. | **Interview Session** | **Participants** | **Duration** | **Topics** | |---|---|---|---| | Leadership | CISO, Governance Pillar Leader, CMMC / Federal Compliance Manager | 60 min | Program governance, risk posture, resource adequacy, CISO awareness | | System Owners | Named system owners for each CUI system | 45 min per system | System architecture, boundary, data flows, SSP accuracy, evidence accessibility | | Operators | Engineering and IT staff operating CUI systems | 30 min per group | Day-to-day operations, control execution, evidence production, training awareness | | Policy & Process | Policy & Standards Manager, relevant process owners | 45 min | Policy awareness, process adherence, document currency, exception handling | | Incident Response | Incident Commander, IR team members | 30 min | IR plan awareness, DC3 reporting path, tabletop exercise experience | #### Findings Report | **Report Section** | **Content** | |---|---| | Executive Summary | Overall mock assessment result, total practices scored NOT MET, top 5 risks | | Scope and Methodology | Assessment boundary, assessor roles, evidence window, interview participants | | Practice-by-Practice Results | Full matrix: practice ID, scoring, observations, evidence state | | Findings Detail | Each NOT MET practice: deficiency description, root cause, evidence gap analysis, risk impact | | Strengths | Practices where evidence is exemplary — maintain as-is | | Interview Observations | Notable themes, awareness gaps, procedural inconsistencies | | Recommendations | Prioritised remediation actions with owners and target dates | #### Remediation Timeline | **Phase** | **Activities** | **Duration** | **Owner** | |---|---|---|---| | Findings Review | CMMC / Federal Compliance Manager reviews findings; categorises by severity and effort | 1 week | CMMC / Federal Compliance Manager | | Remediation Planning | Owner assigned per finding; remediation plan with milestones | 2 weeks | Practice owners | | Quick Wins | Fixes requiring <2 hours effort: missing evidence labels, stale dates, documentation corrections | 2 weeks | Practice owners | | Medium Remediation | Fixes requiring 2–40 hours: new evidence collection, SOP updates, control implementation | 6 weeks | Practice owners | | Major Remediation | Fixes requiring >40 hours: new tooling, architecture changes, policy creation | 8–12 weeks | Governance Pillar Leader + pillar owners | | Milestone Review | Biweekly check-ins on remediation progress | Until closed | CMMC / Federal Compliance Manager | #### Re-Test | **Re-Test Element** | **Detail** | |---|---| | Timing | 30 days before target C3PAO assessment date | | Scope | Only previously scored NOT MET practices + any practice affected by remediation | | Assessor | Same Lead Assessor (or equivalent independence) | | Method | Full evidence re-inspection + targeted interviews on changed practices | | Outcome | Updated findings report; remaining NOT MET practices are either remediated with evidence or escalated to CISO for risk acceptance decision | | Go/No-Go Decision | CISO, Governance Pillar Leader, and CMMC / Federal Compliance Manager decide based on re-test results: proceed to C3PAO assessment, delay (with contract impact assessment), or proceed with known gaps documented | --- ## 12. C3PAO Assessment Logistics Logistics that consistently surprise organizations on assessment day; CERG handles them ahead of time. | **Item** | **Owner** | **Pre-Assessment Action** | |---|---|---| | Authorized C3PAO selected and scheduled | Governance - CUI | 90+ days out | | Assessment scope confirmed in writing | C3PAO + Governance - CUI | 60 days out | | Pre-assessment evidence package shipped | Governance - CUI | 30 days out | | On-site / remote logistics arranged | Governance - CUI | 30 days out | | Named interviewees prepared (system owners, ISSO, leadership) | Governance - CUI | 30 days out | | Workspace / shared evidence repo configured for assessor access | Governance - CUI | 30 days out | | Daily out-brief cadence agreed | C3PAO + Governance - CUI | At kickoff | | Finding response process agreed | C3PAO + Governance - CUI | At kickoff | | Final report receipt and POA&M response window | Governance - CUI | At report | | CISO and executive comms prepared | CISO + Governance | Pre-final | --- ## 13. CUI Subcontractor Register | **Field** | **Description** | |---|---| | Subcontractor Name | - | | Contract ID(s) | - | | CUI Category Received | Per Section 9 | | Flow-Down Verified | Y/N + verification date | | [CMMC L2](https://dodcio.defense.gov/CMMC/) Status | Status + assessment expiry | | FedRAMP Equivalency | If subcontractor hosts in cloud | | Cyber POC | Named contact | | Incident Notification Path | Reference; tested? | | Last Review | Date | | Next Review | Date | | Status | Active · Inactive · Suspended | The register is maintained jointly by Governance, CUI and TPRM; the TPRM record is canonical for vendor data with this register adding CUI-specific fields. --- ## 14. FedRAMP Equivalency Evidence Checklist For cloud / SaaS providers handling CUI that are not FedRAMP-authorized, the equivalency package required by [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Section 14. Repeated here as a CUI-program reference. | **Element** | **Required** | |---|---| | SOC 2 Type II with [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Moderate baseline mapping | ✓ | | 3PAO-equivalent assessment letter / independent assessor attestation | ✓ | | Customer-side configuration commitments (CUI label, region, key control) | ✓ | | Sub-service organization carve-outs reconciled | ✓ | | Re-papering trigger documented | ✓ | | Inheritance Evidence Package per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 5 on file | ✓ | --- ## 15. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Package** | |---|---| | [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) | All sections; Section 10 is the principal evidence artifact | | [NIST 800-172](https://csrc.nist.gov/pubs/sp/800/172/final) (selected enhancements) | Where contract requires | | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (Moderate baseline mapping) | Sections 4, 14 | | [CMMC L2](https://dodcio.defense.gov/CMMC/) | All sections; Section 11 is the readiness check | | DFARS 252.204-7012 | Sections 4, 13 (flow-down) | | DFARS 252.204-7019 / 7020 / 7021 | Section 6 (SPRS) | --- ## 16. Document Control | | | |---|---| | **Document ID** | CERG-PLN-CUI-001 | | **Version** | 1.22 | | **Approved By** | CISO | | **Next Review** | Annual / on regulatory change | | **Change Log** | 1.0 - Initial publication. SSP, POA&M, SPRS, boundary, flow map, category register, evidence matrix, readiness, C3PAO logistics, subcontractor register, FedRAMP equivalency. 1.22 - Added Mock CMMC Assessment Procedure (§11.2) with scope, assessor assignment, practice-by-practice evidence review, interview simulation, findings report, remediation timeline, and re-test. | --- ## INCIDENT RESPONSE PLAN ### Detection · Containment · Investigation · Notification · Recovery · Lessons Learned --- | | | |---|---| | **Document ID** | CERG-PLN-IR-001 | | **Version** | 1.23 | | **Status** | External Interface | | **Classification** | External Interface | | **Owner** | Standing IR Team / Incident Commander | | **Parent Policy** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Supporting Standards** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) · [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | | **Review Cycle** | Annual / After Any Significant Incident / Regulatory Change | | **Frameworks** | [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) (RS, RC) · [NIST 800-61r2](https://csrc.nist.gov/pubs/sp/800/61/r2/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) · [NIST 800-171r3](https://csrc.nist.gov/pubs/sp/800/171/r2/final) · NIST RMF | | **Regulations** | NERC-CIP CIP-008 · [CMMC](https://dodcio.defense.gov/CMMC/) IR.L2 · DFARS 252.204-7012 · SEC 8-K Item 1.05 (where applicable) · State breach laws · GDPR (where applicable) | | **Environments** | All in-scope assets - owned, hybrid, cloud, SaaS, OT | --- > **ADJACENT FUNCTION — NOT A CERG-OWNED DOCUMENT** > > This artifact belongs to the standing Incident Response team, not to CERG. Per [OM-001 §3.4](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md), CERG is not responsible for Incident Response operations, the IR plan itself, regulatory notification clocks, or exercise management. CERG provides a liaison to the IR team and maintains this document in the repository for cross-functional integration only. > > **During an incident:** the standing IR team's procedures and the Incident Commander's authority take precedence over any CERG workflow. CERG's role during incidents is supporting (evidence, reporting, lessons-learned feedback per FLOW-001 F-06), not directing. > > **Ownership:** This document is maintained by the standing IR team. CERG Governance reviews it for cross-reference accuracy only. Changes to IR procedures, notification timelines, or exercise schedules are the IR team's responsibility. > --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Authority and Activation](#2-authority-and-activation) 3. [Roles and the Incident Response Team](#3-roles-and-the-incident-response-team) 4. [Incident Lifecycle](#4-incident-lifecycle) 5. [Severity Classification](#5-severity-classification) 6. [Notification Obligations](#6-notification-obligations) 7. [Environment-Specific Considerations](#7-environment-specific-considerations) 8. [Playbooks](#8-playbooks) 9. [Communications](#9-communications) 10. [Evidence, Forensics, and Legal Privilege](#10-evidence-forensics-and-legal-privilege) 11. [Exercises and Plan Maintenance](#11-exercises-and-plan-maintenance) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Plan Control](#13-plan-control) --- ## 1. Purpose and Scope This plan operationalizes the incident response principle established in **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) Principle 10**. It defines how the organization detects, contains, investigates, notifies, recovers from, and learns from cybersecurity events across all in-scope environments. The plan is intentionally cross-environment. A single incident may span enterprise IT, cloud, SaaS, OT, and CUI environments simultaneously. The plan provides one structure of authority, classification, and notification, with environment-specific overlays that reflect the operational and regulatory reality of each domain. ### 1.1 Scope This plan applies to: - All confirmed and suspected cybersecurity events affecting organizational assets, data, or personnel - All in-scope environments, owned data center, hybrid, cloud, SaaS, OT, BES Cyber Systems, CUI environments - All third-party incidents that materially affect the organization (vendor compromises, software supply-chain compromises, shared-tenant impacts) - All personnel involved in detection, response, decision-making, communication, and recovery ### 1.2 Definitions | **Term** | **Definition** | |---|---| | **Event** | Any observable occurrence in a system or network. Not all events are incidents. | | **Incident** | An event that violates security policy, threatens confidentiality, integrity, or availability, or has the realistic potential to do so. | | **Significant Cyber Incident** | An incident classified P1 / Sev 1 or P2 / Sev 2 under Section 5, or any incident triggering an external notification obligation. | | **Reportable Cyber Incident (DFARS)** | A cyber incident that affects covered defense information or the contractor's ability to perform operationally critical support - triggers 72-hour DC3 reporting. | | **Reportable Cyber Security Incident (NERC-CIP)** | An incident as defined in NERC Glossary that compromises or attempts to compromise an ESP, PSP, or BES Cyber System, or disrupts BES operations. | | **Material Cybersecurity Incident (SEC)** | An incident determined material under SEC Item 1.05 (Form 8-K), based on reasonable-investor materiality - triggers a 4-business-day disclosure clock. | | **Incident Commander (IC)** | The CISO or designated deputy with single-decision authority for an active incident. | | **Lead Investigator** | Risk-side technical lead for the investigation. Reports to the IC. | ### 1.3 Relationship to Parent Policy and Standards This plan is subordinate to **[CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md)** and implements the response and recovery obligations of the peer standards. Where a peer standard imposes additional or more stringent notification, evidence, or recovery requirements, the more stringent requirement controls. --- ## 2. Authority and Activation ### 2.1 Authority > **Single Decision Authority During Active Response** > > Incident response is not a consensus activity. The Incident Commander has single decision authority during active response. Containment and notification decisions are made by the IC after consultation with the appropriate Subject Matter Experts; they are not voted on. The IC remains accountable to the CISO and executive leadership and is briefed continuously. The CISO is the standing Incident Commander. The CISO may delegate IC authority to a named deputy for a specific incident, with notification to executive leadership. Authority transitions are explicit and logged. ### 2.2 Activation Triggers Activate this plan upon any of the following: - Confirmed compromise of credentials with privileged access, or of a privileged identity platform - Confirmed or strongly suspected unauthorized access to organizational systems or data - Confirmed presence of ransomware, destructive malware, or unauthorized cryptographic activity on organizational systems - Confirmed exfiltration or unauthorized disclosure of Confidential or Restricted-tier data - Significant denial of service, integrity, or availability event affecting Tier 1 systems - Any cyber event affecting BES Cyber Systems, CUI environments, [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems, or other regulated assets, where regulatory notification timelines may apply - Vendor or supply-chain notification indicating the organization may be affected - External notification (law enforcement, regulator, partner, customer) of a credible threat or breach ### 2.3 Activation Process 1. **Triage.** SOC / on-call analyst confirms the event meets activation criteria using documented triage criteria. When in doubt, activate. 2. **Notify.** Page the on-call IC and Lead Investigator. The IC confirms activation and assigns an incident identifier. 3. **Establish.** Open the incident channel (defined out-of-band communication path), open the incident record (ticketing system), and begin the timeline log. 4. **Brief.** Initial brief to the IC within 30 minutes of activation. The IC determines initial severity classification. 5. **Mobilize.** IC convenes the Incident Response Team appropriate to severity (Section 3). --- ## 3. Roles and the Incident Response Team ### 3.1 Standing Roles | **Role** | **Standing Responsibility** | |---|---| | **Incident Commander (CISO / designated deputy)** | Single-decision authority; convenes and directs the IRT; owns external notification decisions; briefs executive leadership. | | **Lead Investigator** | Owns technical investigation; coordinates evidence collection and forensic analysis; produces the incident technical timeline. | | **Engineering Pillar Leader** | Executes containment and recovery technical actions; coordinates with platform teams; advises on architectural impact. | | **Governance Pillar Leader** | Supports regulatory mapping and evidence preservation at IC / Legal direction; maintains SSP / POA&M impact tracking; assembles CERG-owned post-incident evidence and improvement artifacts. | | **Legal (external function)** | Advises on privilege, notification obligations, regulator engagement, customer / partner contractual notifications, law enforcement engagement. | | **Communications (external function)** | Coordinates internal, customer, partner, and external public communications under IC direction. | | **Executive Sponsor (CEO / COO / CIO / CFO as appropriate)** | Provides executive decision support for material business, regulatory, or financial determinations. | | **Operations Representative (external function)** | Coordinates operational impact assessment and recovery sequencing. For OT events, the operations liaison is the on-shift operations supervisor or designee. | ### 3.2 Tier of Engagement | **Severity** | **Engaged at Activation** | **Engaged on Escalation** | |---|---|---| | P4 / Sev 4 | SOC / Lead Investigator | - | | P3 / Sev 3 | Lead Investigator + Engineering Lead | IC (notified) | | P2 / Sev 2 | IC + Lead Investigator + Engineering Lead + Governance | Legal + Communications + Executive Sponsor | | P1 / Sev 1 | Full IRT incl. Legal + Communications + Executive Sponsor + Board notification | External support (forensics retainer, law enforcement liaison, breach coach) | ### 3.3 Third-Party Engagement The CISO maintains the following pre-arranged external retainers, activated by the IC as needed: - **External forensics / digital investigation retainer**: for surge capacity, specialized expertise, or independent investigation - **Breach coach / outside counsel**: for privilege, multi-jurisdictional notification, and external communication - **Public relations / crisis communications partner**: engaged at IC direction for material incidents - **Law enforcement / federal liaison contacts**: FBI, CISA, sector ISAC, and DC3 (for CUI incidents) Retainer contacts and activation procedures are maintained in the IRT contact roster, reviewed quarterly and distributed only to the standing IRT. --- ## 4. Incident Lifecycle The lifecycle follows [NIST 800-61r2](https://csrc.nist.gov/pubs/sp/800/61/r2/final) phases adapted for cross-environment operations. ### 4.1 Preparation (Continuous) Preparation is the work performed before any specific incident. It includes maintaining this plan, training the IRT, exercising playbooks, validating tooling, maintaining external retainers, and ensuring detection telemetry is functioning. Preparation is not optional and is not "off the clock." ### 4.2 Detection and Analysis | **Step** | **Action** | **Owner** | |---|---|---| | 1 | Detection signal arrives (SIEM, EDR, CSPM/SSPM, partner / vendor notification, user report, external alert). | SOC / Risk | | 2 | Initial triage applies documented criteria to determine whether the event warrants activation. | SOC / Risk | | 3 | Activation triggers the procedure in Section 2.3. The incident timeline log begins. | IC | | 4 | Lead Investigator builds a working hypothesis: scope, affected systems, suspected technique, blast radius. Re-evaluates continuously. | Lead Investigator | | 5 | IC sets initial severity (Section 5). Severity is re-evaluated at each major learning. | IC | ### 4.3 Containment Containment objectives: stop ongoing harm, prevent lateral movement, preserve evidence, maintain operational integrity. | **Containment Type** | **Use** | **Considerations** | |---|---|---| | **Short-term** | Immediate isolation actions to stop ongoing impact (disable account, revoke session, isolate host, block IOC at firewall / EDR). | Designed to be reversible and to preserve forensic data. | | **Long-term** | Architectural changes that prevent the same path being used during recovery (e.g., new IAM policies, network segmentation, rebuilt systems). | Implemented before declaring eradication complete. | | **Operational hold** | Pause of non-essential activity to focus response (e.g., temporary block on outbound SaaS connections, suspension of non-essential remote access). | Approved by IC with operations input. | > **The "Don't Tip Your Hand" Reminder** > > Premature containment can warn an adversary and accelerate destructive action, particularly in ransomware or supply-chain scenarios where the attacker may be actively monitoring response. Pace containment to scope, prefer reversible isolation, and coordinate with the Lead Investigator on telemetry implications before each major action. ### 4.4 Eradication Eradication removes the adversary's access and the means by which it was obtained. Eradication is declared complete only when: - All identified persistence mechanisms (accounts, scheduled tasks, services, OAuth grants, IaC backdoors, malicious code) have been removed. - Underlying vulnerabilities or misconfigurations have been remediated. - Compensating controls are in place for issues that cannot be fully remediated immediately. - Independent verification confirms the eradication actions. ### 4.5 Recovery Recovery restores affected systems to operational service. Recovery is coordinated with operations, sequenced by business priority, and monitored for indications of recurrence. | **Step** | **Action** | **Owner** | |---|---|---| | 1 | Identify systems for restoration and the sequence. Critical operations restored first with elevated monitoring. | Engineering / Operations | | 2 | Restore from verified-clean baselines or trusted backups. Validate integrity before bringing systems online. | Engineering | | 3 | Validate that restored systems are not reinfected; monitor with enhanced detection. | Risk / Engineering | | 4 | Phased return-to-service with documented validation gates. | IC / Operations | | 5 | Operations confirms business resumption; IC closes the operational response phase. | IC | ### 4.6 Post-Incident Activity (Lessons Learned) A post-incident review is mandatory for every P1 / Sev 1 and P2 / Sev 2 incident, and recommended for Sev 3. P1 / Sev 1 reviews occur within 14 calendar days of recovery; P2 / Sev 2 within 30 days. The review produces: - A factual timeline (detection, containment, eradication, recovery, notification milestones) - A root-cause analysis (technical and process) - A list of corrective actions categorized as Engineering, Risk, or Governance backlog items - Updates to playbooks, detection rules, and this plan - Lessons-learned briefing to leadership and to the IRT Corrective actions are tracked to closure in the risk register with assigned owners and due dates. --- ## 5. Severity Classification Severity drives engagement, communication cadence, and notification scrutiny. Severity may be revised at any time during response. | **Severity** | **Indicative Criteria (any of)** | **Engagement** | **Reporting** | |---|---|---|---| | **P1 / Sev 1 - Critical** | Confirmed material data loss or destruction; ransomware encrypting Tier 1 or regulated systems; confirmed compromise affecting BES Cyber System operations; broad customer / partner impact; meets reasonable-investor materiality threshold for SEC disclosure. | Full IRT, executive sponsor, board notification, external partners as needed. | Hourly IC briefing to executive leadership during active response. | | **P2 / Sev 2 - Significant** | Confirmed unauthorized access to Tier 1 systems or Confidential/Restricted data; ransomware contained to non-critical scope; confirmed cyber incident triggering DFARS / NERC-CIP / breach-law notification. | IC + full IRT + Legal + Communications. | At least twice-daily IC briefing during active response. | | **P3 / Sev 3 - Moderate** | Localized compromise (single endpoint, scoped credential), with no confirmed sensitive-data impact; significant phishing wave with successful but contained credential theft. | IC notified; Lead Investigator + Engineering active. | Daily IC update until closure. | | **P4 / Sev 4 - Minor** | Failed attack with no impact; isolated malware blocked by EDR; SOC-triaged anomaly with no escalation criteria met. | SOC / Risk only. | Routine SOC reporting. | The IC may up- or down-grade severity at any time based on emerging information. Severity changes are logged on the incident timeline. --- ## 6. Notification Obligations Notification is one of the highest-risk areas of incident response. Many obligations operate on clocks that begin at discovery, not at confirmation. The Incident Commander owns the notification-clock process for each in-flight incident, with Legal determining applicable obligations and Governance maintaining the supporting evidence and notification register at IC / Legal direction. ### 6.1 Internal Notification | **Audience** | **Trigger** | **Owner** | **Timing** | |---|---|---|---| | CISO / IC | Plan activation | SOC / on-call | Immediate | | Executive leadership (CEO/CIO/CFO/COO) | P1 / Sev 1 or P2 / Sev 2 activation | IC | Within 1 hour of activation | | Board (Audit / Risk Committee) | P1 / Sev 1; or P2 / Sev 2 with regulatory / financial implications | CISO via CEO | Within 24 hours of confirmation per board protocol | | Workforce communications | P1 / Sev 1; or any incident requiring workforce action | Communications + IC | As approved by IC | | Internal Audit | P1 / Sev 1; [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant incidents | Governance | Per [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204) protocol | ### 6.2 External Notification (Regulator and Statutory) | **Authority / Obligation** | **Trigger** | **Clock** | **Decision Owner / Support** | **Reference** | |---|---|---|---|---| | **DoD DC3 / DIBNet** | Reportable cyber incident affecting CUI or operationally critical support | **72 hours** from discovery | IC + Legal; Governance evidence support | DFARS 252.204-7012(c) | | **NERC E-ISAC and Regional Entity** | Reportable Cyber Security Incident or attempt against BES Cyber Systems | Per CIP-008 timelines (1 hour for compromise of BCS; 24 hours for attempts) | IC + Legal + OT Operations; Governance evidence support | NERC-CIP CIP-008-6 R1.4 | | **SEC (Form 8-K Item 1.05)** | Material cybersecurity incident at a public-company registrant | **4 business days** from materiality determination | CISO + Legal + CFO | SEC Reg S-K Item 106(b); Form 8-K Item 1.05 | | **State breach notification laws** | Unauthorized acquisition of state-defined personal information | Per state - often "without unreasonable delay"; specific deadlines vary (e.g., 30/45/60 days) | Legal + IC; Governance evidence support | State statutes | | **GDPR Supervisory Authority** (where applicable) | Personal data breach with risk to data subjects | **72 hours** from awareness | Legal / DPO | GDPR Art 33 | | **HIPAA Breach Notification** (where applicable) | Breach of unsecured PHI | Per HIPAA timelines | Legal / Privacy | HIPAA 164.400 series | | **Sector / customer contractual notification** | Per contract terms (often 24–72 hours) | Per contract | IC + Legal + Account Management; Governance evidence support | Contractual | | **Law enforcement (FBI / Secret Service / local)** | P1 / Sev 1 events at IC / Legal discretion; mandated reporting in some jurisdictions | At IC discretion unless mandated | IC + Legal | Jurisdiction-specific | | **CISA voluntary reporting (and CIRCIA when in force)** | Significant cyber incidents at critical infrastructure entities | Per CIRCIA rule (72 hours for incidents; 24 hours for ransom payments) once effective | IC + Legal; Governance evidence support | CIRCIA (when final rule effective) | ### 6.3 Notification Decision Discipline > **Two Failure Modes** > > The two notification failure modes are: notifying too early on incomplete information, or notifying too late after the regulatory clock has run. Both are damaging. The discipline is: (a) start the regulatory clock log at the moment of discovery, not at the moment of confirmation; (b) make notification decisions through the IC + Legal process, using Governance for evidence and regulatory-mapping support; (c) document the rationale at each decision point. If you would not be willing to defend the rationale to a regulator after the fact, do not adopt it during the incident. --- ## 7. Environment-Specific Considerations ### 7.1 Enterprise IT / Cloud / SaaS Containment leverages cloud-native isolation (quarantine IAM, account suspension, security-group changes), conditional-access lockdowns, and SaaS admin-controlled session revocation. Forensic acquisition depends on provider-exposed artifacts; pre-staged acquisition procedures are maintained per **[CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) §7**. ### 7.2 OT / BES Cyber Systems > **Operational Priority Rule** > > Response in OT environments evaluates every containment action for operational impact before execution. Isolation that would be routine in IT can produce a grid disturbance in OT. OT response actions require operations-team participation in the decision, not just notification. OT incidents engage the operations liaison as a peer decision-maker on containment options. Containment defaults to least-disruptive options first (passive monitoring intensification, network-edge controls) before in-band actions. NERC-CIP CIP-008 reporting timelines run regardless of operational readiness; the IC owns the notification-clock process with Legal and OT Operations, while Governance supplies evidence and regulatory mapping support. ### 7.3 CUI Environments CUI incidents trigger DFARS 252.204-7012 reporting via DC3 / DIBNet within 72 hours of discovery (Section 6.2). Evidence preservation requirements (90-day retention of images and malware) apply per **[CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) §7**. The IC and Legal coordinate required contracting-officer engagement, with Governance providing evidence and contract-mapping support. ### 7.4 [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-Relevant Systems Incidents affecting [SOX](https://www.govinfo.gov/app/details/PLAW-107publ204)-relevant systems require Internal Audit and CFO designee engagement to assess ITGC control implications. Material control gaps may require disclosure considerations under SEC Item 1.05. ### 7.5 Third-Party / Supply-Chain Incidents When the originating compromise is a third party (vendor, SaaS provider, software supplier), the IC owns the determination of whether the organization is itself affected, what containment actions are appropriate, and what onward notification is required. Vendor incident notifications are not a substitute for the organization's own investigation. --- ## 8. Playbooks The plan is supported by detailed playbooks maintained by the standing IR team as living artifacts in this repository for cross-functional integration. Each playbook follows a consistent structure: trigger criteria, immediate actions, investigation steps, containment options, recovery steps, evidence checklist, and notification triggers. Currently maintained playbooks: | **Playbook** | **Scenario** | |---|---| | PB-01 | Ransomware / Destructive Malware | | PB-02 | Privileged Credential Compromise (IT) | | PB-03 | Privileged Credential Compromise (Cloud / SaaS) | | PB-04 | OAuth / Third-Party App Abuse (SaaS) | | PB-05 | Compromised Cloud Workload (IaaS) | | PB-06 | Cloud Control-Plane Compromise | | PB-07 | Public Exposure of Sensitive Data (cloud storage / database) | | PB-08 | Data Exfiltration Confirmed or Suspected | | PB-09 | Supply Chain / Vendor Compromise | | PB-10 | Phishing Wave with Successful Credential Theft | | PB-11 | Insider Threat - Authorized User Misuse | | PB-12 | DDoS / Availability Attack | | PB-13 | BES Cyber System Compromise (CIP-008) | | PB-14 | OT - Loss of SCADA Visibility / Control | | PB-15 | CUI Cyber Incident (DFARS 7012 reporting) | | PB-16 | Lost / Stolen Endpoint with Sensitive Data | | PB-17 | Business Email Compromise (BEC) | | PB-18 | Web Application Compromise | Playbooks are reviewed annually and updated upon material change to environment, tooling, or regulation. Playbook updates derived from post-incident reviews are tracked as Engineering / Risk / Governance backlog items. --- ## 9. Communications ### 9.1 Internal Communications Internal communications channels for active response are pre-established and exercised. The plan assumes the possibility that organizational productivity systems (email, chat, ticketing) are compromised or unavailable. | **Channel** | **Use** | |---|---| | Primary incident channel | Coordination among IRT; updated by IC and Lead Investigator. | | Out-of-band channel | Used when primary collaboration tooling is potentially compromised or unavailable. Defined and tested in advance. | | Executive briefing channel | IC → executive sponsors and CEO. | | Workforce broadcast | Used for actions required of the broader workforce (e.g., reset credentials, do not click links). Approved by IC. | ### 9.2 External Communications External communications during an active incident are owned by the IC, with content prepared by Communications and reviewed by Legal. The principles are: - Say only what is established as fact. If a claim is not supported by current evidence, do not make it. - Lead with the actions being taken and the protections in place for affected parties. - Coordinate timing of public statements with regulatory and contractual notifications. - Refer technical questions to the appropriate IRT spokesperson; refer regulatory questions to Legal, with Governance available for evidence and obligation-mapping support. - Document every external statement in the incident timeline. --- ## 10. Evidence, Forensics, and Legal Privilege ### 10.1 Evidence Handling Principles | **Principle** | **Description** | |---|---| | Preserve before you contain | Where feasible, capture volatile state (memory, network captures, ephemeral cloud telemetry) before destructive containment. | | Chain of custody | Every evidence artifact is logged: source system, time captured, method, custodian, hash. | | Original integrity | Work from images and copies. Do not modify original artifacts. | | Provider-side evidence | For cloud and SaaS, identify which artifacts are obtainable from the provider and what the retention window is - request promptly. | | Retention | Evidence is retained per the most stringent applicable obligation. DFARS requires 90-day minimum for CUI incidents. | ### 10.2 Privilege The Legal Lead is involved at activation for all P1 / Sev 1 and P2 / Sev 2 events. Privileged work product is created under counsel direction and labeled accordingly. Whether and how privilege applies to forensic findings is a judgment of counsel; the IRT operates with privilege awareness from the outset. ### 10.3 Law Enforcement Engagement Engagement with law enforcement is at the IC's discretion in consultation with Legal, except where reporting is mandated. Law enforcement engagement may affect notification timing and content; the standing IR team maintains contact procedures for FBI Cyber, Secret Service, CISA, and DC3, with Governance repository support. --- ## 11. Exercises and Plan Maintenance | **Activity** | **Cadence** | **Owner** | |---|---|---| | Tabletop exercise - P1 / Sev 1 scenario (cross-environment) | Annual | Incident Commander / Standing IR Team; Governance + Risk support | | Tabletop exercise - OT (CIP-008) | Annual | Incident Commander / Standing IR Team + OT Ops; Governance + Risk support | | Tabletop exercise - CUI (DFARS 7012 reporting) | Annual | Incident Commander / Standing IR Team; Governance evidence support | | Functional exercise / detection validation (purple-team) | Quarterly | Incident Commander / Standing IR Team; Risk support | | IRT contact roster validation | Quarterly | Incident Commander / Standing IR Team; Governance repository support | | External retainer activation test | Annual | Incident Commander / Standing IR Team; Legal / Procurement support | | Playbook review | Annual; after each use | Incident Commander / Standing IR Team; Governance / Risk support | | This plan review | Annual; after any P1 / Sev 1 or P2 / Sev 2 incident; upon regulatory change | Incident Commander / Standing IR Team; Governance cross-reference support | Exercise results, including identified gaps and corrective actions, are recorded in the risk register and tracked to closure. --- ## 12. Regulatory and Framework Alignment Summary | **Process Area** | **[NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)** | **[NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** | **[NIST 800-171](https://csrc.nist.gov/pubs/sp/800/171/r3/final)** | **NERC-CIP** | **[CMMC L2](https://dodcio.defense.gov/CMMC/)** | **Other** | |---|---|---|---|---|---|---| | IR Capability / Plan | RS / RC | IR-2, IR-4, IR-8 | 3.6.1 | CIP-008 R1 | IR.L2-3.6.1 | DFARS 252.204-7012 | | Detection & Analysis | DE.AE, RS.AN | IR-4, AU-6, SI-4 | 3.6.1 | CIP-007 R4 | IR.L2-3.6.1 | - | | Containment / Eradication | RS.MI | IR-4, IR-4(1)(2) | 3.6.2 | CIP-008 | IR.L2-3.6.2 | - | | Notification (regulator / law enforce.) | RS.CO | IR-6 | 3.6.2 | CIP-008 R1.4 | IR.L2-3.6.2 | DFARS · GDPR · State | | Recovery | RC.RP | CP-2, CP-10, IR-4 | 3.6.3 | CIP-009 | RE.L2-3.6.3 | - | | Lessons Learned | ID.IM, RC.IM | IR-4(4), CA-7 | 3.6.3 | CIP-008 R3 | IR.L2-3.6.3 | - | | Exercises & Testing | ID.IM | IR-3, IR-3(2) | 3.6.3 | CIP-008 R3 | IR.L2-3.6.3 | - | | Disclosure (public registrant) | GV.RR | - | - | - | - | SEC 8-K Item 1.05 | --- ## 13. Plan Control ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.23 | 2026-06-18 | Standing IR Team / Incident Commander | Standardized core incident severity labels to paired P / Sev notation. | | 1.22 | 2026-06-18 | Standing IR Team / Incident Commander | Clarified that the standing IR team owns notification-clock process, playbook maintenance, exercises, and plan maintenance; CERG Governance provides evidence, regulatory-mapping, repository, and improvement-routing support only. | | 1.0 DRAFT | 2026 | CERG Governance | Initial release | ### Review Triggers This plan shall be reviewed annually and upon any of the following: - Any P1 / Sev 1 or P2 / Sev 2 incident affecting the organization - Material change to applicable regulation (DFARS, CIP, SEC, breach laws, CIRCIA) - Material change to the organization's environments or tooling - IRT structural change (CISO transition, new external retainer) - Direction from the CISO, internal audit, or external examination The standing IR team owns and maintains this plan. CERG Governance reviews repository links, metadata, and cross-references only. Updates to incident procedures, notification timelines, or exercise cadence require Incident Commander / CISO approval and IRT acknowledgment. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy - Principle 10 | | Grid and Control System Standard | [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) | OT IR overlay, CIP-008 obligations | | IT (Hosted/Cloud/SaaS) Security Standard | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | Cloud / SaaS IR overlay | | CUI Handling Standard | [CERG-STD-CUI-001](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) | CUI-specific incident handling and DFARS notification interface | | Logging, Monitoring, and Detection Standard | [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Detection, telemetry, and evidence support | | Cyber Resilience and Backup Standard | [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) | Recovery and restoration interface | | Incident Response Playbook Set | [CERG-PRC-IR-002](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | Scenario playbooks and CERG handoff checklists | --- ## ISO/IEC 27001 OPERATIONAL PACKAGE ### ISMS Scope · Statement of Applicability · Annex A Mapping · Internal Audit · Management Review --- | | | |---|---| | **Document ID** | CERG-PLN-ISO-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Documents** | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-GOV-CMX-001`](../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) · [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | | **Supporting Documents** | [`CERG-GOV-MAT-001`](../governance/CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) · [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | | **Review Cycle** | Annual / Per ISO audit cycle / On material ISMS scope change | | **Frameworks** | ISO/IEC 27001:2022 · ISO/IEC 27002:2022 · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) · [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) | | **Regulations** | Cross-cutting; supports customer assurance and certification readiness | | **Environments** | ISMS scope selected by the organization; CERG-managed controls and evidence supporting that scope | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [ISMS Boundary](#2-isms-boundary) 3. [ISO 27001 Operating Model](#3-iso-27001-operating-model) 4. [Statement of Applicability](#4-statement-of-applicability) 5. [Annex A Mapping](#5-annex-a-mapping) 6. [Risk Assessment and Treatment Interface](#6-risk-assessment-and-treatment-interface) 7. [Internal Audit Program](#7-internal-audit-program) 8. [Management Review Package](#8-management-review-package) 9. [Certification and External Audit Interface](#9-certification-and-external-audit-interface) 10. [Evidence Library](#10-evidence-library) 11. [Metrics](#11-metrics) 12. [Roles and Responsibilities](#12-roles-and-responsibilities) 13. [Regulatory and Framework Alignment Summary](#13-regulatory-and-framework-alignment-summary) 14. [Document Control](#14-document-control) --- ## 1. Purpose and Scope CERG already aligns many artifacts to ISO/IEC 27001 and ISO/IEC 27002. Alignment is not the same thing as operating an Information Security Management System. An ISO-ready program needs an ISMS scope, a Statement of Applicability, risk treatment linkage, internal audit, management review, corrective actions, and evidence organized for assessors. This operational package turns the CERG library into an ISO-operable system. It is designed for organizations seeking formal certification, customer-assurance readiness, or disciplined internal operation against ISO/IEC 27001 without immediate certification. > **ISO Is a Management System, Not a Control Checklist** > > Annex A matters, but certification succeeds or fails on the management system: scope, risk treatment, evidence, internal audit, corrective action, and management review. A control may be technically strong and still fail ISO if the organization cannot show why it is in scope, who owns it, how it is reviewed, and what happens when it fails. --- ## 2. ISMS Boundary The ISMS scope statement defines what the ISO program covers. It is approved by the CISO and reviewed at least annually. Minimum scope fields: | **Field** | **Description** | |---|---| | Scope Name | Name of the ISMS scope. | | Business Processes | Processes included in the ISMS. | | Locations | Physical and logical locations included. | | Systems and Assets | Asset classes and key systems included. | | Data Classes | Highest data classification processed. | | Exclusions | Areas not in scope and rationale. | | Interfaces | Dependencies on third parties, shared services, and adjacent programs. | | Regulatory Drivers | Customer, contractual, or regulatory reasons for the scope. | | Scope Owner | Accountable owner. | | Approval Date | Date approved by the CISO or delegated authority. | A scope exclusion is valid only when it is truthful, documented, and does not hide a control failure. Exclusions are reviewed during internal audit and management review. --- ## 3. ISO 27001 Operating Model | **ISO Function** | **CERG Mechanism** | |---|---| | Context and scope | ISMS scope record in this package. | | Leadership and policy | `CERG-POL-001` and CISO governance. | | Risk assessment | `CERG-PRC-RM-001` scoring and risk register. | | Risk treatment | Risk treatment plans, exceptions, and control ownership. | | Controls | `CERG-GOV-CB-001` and subordinate standards. | | Competence and awareness evidence | Evidence from the enterprise awareness program where applicable, not owned by CERG. | | Communication | Governance reporting and management review package. | | Documented information | `CERG-GOV-CAT-001` and evidence library. | | Performance evaluation | `CERG-GOV-MTR-001`, `CERG-GOV-MAT-001`, and internal audit. | | Internal audit | `CERG-PRC-AUD-001` plus the ISO internal audit schedule. | | Management review | Section 8 of this package. | | Nonconformity and corrective action | Audit finding workflow and risk register linkage. | --- ## 4. Statement of Applicability The Statement of Applicability (SoA) is the authoritative ISO control decision record. It states which Annex A controls apply, why they apply, which CERG artifacts implement them, and whether any control is excluded. Minimum SoA fields: | **Field** | **Description** | |---|---| | Annex A Control ID | ISO/IEC 27001:2022 Annex A control reference. | | Control Title | Official or shortened control name. | | Applicability | Applicable / Not Applicable. | | Applicability Rationale | Why the control applies or does not apply. | | Implementation Status | Implemented / Partially Implemented / Planned / Not Implemented. | | CERG Control Source | CERG artifact and section implementing the control. | | Evidence Source | Evidence library folder, report, or record. | | Control Owner | Canonical CERG role or business owner. | | Risks Linked | Risk-register IDs, if applicable. | | Last Reviewed | Review date. | > **A Bad SoA Is Worse Than No SoA** > > A copied SoA that says every control applies and everything is implemented tells the auditor the program has not done real scoping. A useful SoA makes decisions visible: what applies, what does not, why, who owns it, and what evidence proves the claim. --- ## 5. Annex A Mapping The mapping below is the starting spine. The maintained SoA provides row-level detail. | **Annex A Theme** | **CERG Implementation Sources** | |---|---| | Organizational controls | `CERG-POL-001`, `CERG-GOV-OM-001`, `CERG-GOV-CB-001`, `CERG-GOV-RAC-001`, `CERG-PRC-RM-001`, `CERG-PRC-AUD-001`, `CERG-PRC-TPRM-001` | | People controls | Enterprise HR and awareness programs supply evidence; CERG records interfaces where controls affect privileged access, exceptions, and training-dependent control claims. | | Physical controls | Enterprise physical security supplies evidence; CERG records physical dependencies for data centers, OT, and backup media where applicable. | | Technological controls | `CERG-STD-IT-001`, `CERG-STD-OT-001`, `CERG-STD-AC-001`, `CERG-STD-CFG-001`, `CERG-STD-LM-001`, `CERG-STD-RES-001`, `CERG-STD-CR-001`, `CERG-STD-SDL-001`, `CERG-STD-DG-001`, `CERG-STD-MSG-001`, `CERG-STD-AI-001` | Controls owned outside CERG are not ignored. They are listed in the SoA with the external evidence owner and the CERG dependency clearly stated. --- ## 6. Risk Assessment and Treatment Interface ISO risk treatment uses the CERG risk register rather than a parallel ISO-only risk log. ISO-specific risk requirements are met by ensuring each ISMS-scope risk includes: - risk statement; - asset or process scope; - likelihood, impact, and rating; - selected treatment; - treatment owner; - target date; - linked Annex A controls; - linked SoA row; - residual risk decision; - approver; - review date. Risk treatment decisions that leave a control gap use `CERG-PRC-RM-001` exception or acceptance workflow. --- ## 7. Internal Audit Program The ISO internal audit program uses `CERG-PRC-AUD-001` and adds ISO-specific scope and independence rules. Minimum audit schedule: | **Audit Area** | **Minimum Cadence** | |---|---| | ISMS scope and context | Annual | | SoA accuracy | Annual | | Risk assessment and treatment | Annual | | Evidence library and documented information | Annual | | Selected Annex A controls | Risk-based rotation; all applicable themes covered over the certification cycle | | Corrective action closure | Quarterly until closed | Internal auditors must be independent of the control operation being audited. In small organizations, independence may mean cross-pillar review, external reviewer support, or documented CISO-approved independence constraints. --- ## 8. Management Review Package Management review is held at least annually and before certification or surveillance audits. Management review package contents: 1. ISMS scope changes. 2. Internal audit results. 3. External audit findings. 4. Risk posture and material risk changes. 5. SoA changes and exclusions. 6. Control performance metrics. 7. Corrective action status. 8. Supplier and third-party security issues. 9. Incident and continuity lessons. 10. Resource constraints and improvement needs. 11. Decisions and assigned actions. Management review minutes are retained as evidence. Decisions that create work become tracked actions, risk-register entries, or cataloged document updates. --- ## 9. Certification and External Audit Interface For certification readiness, Governance maintains an audit pack: - ISMS scope statement; - information security policy; - SoA; - risk assessment and treatment records; - internal audit schedule and results; - management review records; - corrective action register; - evidence index mapped to Annex A; - document catalog and version record; - list of exclusions and interfaces owned outside CERG. External auditor requests are handled through `CERG-PRC-AUD-001`. Auditor observations that indicate control weakness become findings or risks, not side emails. --- ## 10. Evidence Library Evidence is organized by ISO requirement and by CERG control source. | **Folder / Index** | **Contents** | |---|---| | 01 Scope and Context | Scope statement, boundaries, exclusions, interested parties. | | 02 Policy and Governance | Policy, operating model, RACI, catalog. | | 03 Risk Assessment and Treatment | Risk methodology, register extracts, treatment plans, acceptances. | | 04 Statement of Applicability | SoA, change history, rationale records. | | 05 Annex A Evidence | Control evidence indexed by Annex A control. | | 06 Internal Audit | Audit plans, test sheets, findings, corrective actions. | | 07 Management Review | Agendas, decks, minutes, decisions, action register. | | 08 External Audit | Auditor requests, evidence provided, findings, responses. | | 09 Corrective Actions | Nonconformities, root cause, action plans, closure evidence. | --- ## 11. Metrics | **Metric** | **Purpose** | |---|---| | Applicable Annex A controls with current owner | Measures SoA ownership quality. | | Applicable Annex A controls with current evidence | Measures audit readiness. | | SoA rows reviewed on schedule | Measures SoA hygiene. | | Open ISO nonconformities by age | Measures corrective-action performance. | | Internal audits completed on schedule | Measures audit program execution. | | Risk treatments overdue in ISMS scope | Measures risk-treatment discipline. | | Management review actions overdue | Measures leadership follow-through. | | External audit repeat findings | Measures systemic weakness. | --- ## 12. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **ISO Responsibility** | |---|---| | **Governance Pillar Leader** | Accountable owner for this package, ISMS governance, SoA maintenance, internal audit coordination, and management review package. | | **Policy & Standards Manager** | Maintains documented information and updates CERG artifacts that implement ISO controls. | | **Evidence Librarian** | Maintains ISO evidence library and audit pack. | | **Risk Pillar Leader** | Ensures ISO risk assessment and treatment use the CERG risk process. | | **Risk Register Owner** | Maintains risk-register entries, treatments, acceptances, and review dates for ISMS-scope risks. | | **Engineering Pillar Leader** | Owns implementation evidence for technical controls. | | **Vendor Risk Analyst** | Supplies third-party evidence and supplier-risk inputs. | | **SOX ITGC Lead** | Coordinates reusable evidence where ISO and SOX overlap. | | **CMMC / Federal Compliance Manager** | Coordinates reusable evidence where ISO and CUI/CMMC overlap. | | **NERC-CIP Compliance Manager** | Coordinates reusable evidence where ISO and CIP overlap. | | **Chief Information Security Officer (CISO)** | Approves ISMS scope, accepts material residual risk, and chairs or delegates management review. | --- ## 13. Regulatory and Framework Alignment Summary | **Framework** | **Reference** | **Where in This Package** | |---|---|---| | ISO/IEC 27001:2022 | Clauses 4 through 10 | Sections 2 through 10 | | ISO/IEC 27001:2022 | Annex A | Sections 4, 5, 10 | | ISO/IEC 27002:2022 | Control implementation guidance | Sections 4, 5, 10 | | NIST CSF 2.0 | GOVERN | Sections 2, 3, 8, 11 | | NIST 800-53r5 | Crosswalk source for controls | Sections 5, 10 | | Customer assurance | ISO evidence pack | Sections 9, 10 | --- ## 14. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PLN-ISO-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; per ISO audit cycle; and on material ISMS scope change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | ISO/IEC 27001:2022; ISO/IEC 27002:2022; NIST CSF 2.0; NIST 800-53r5 | | **Regulations** | Cross-cutting; supports customer assurance and certification readiness | | **Environments** | ISMS scope selected by the organization; CERG-managed controls and evidence supporting that scope | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes ISMS scope requirements, ISO operating model, Statement of Applicability structure, Annex A mapping, risk-treatment interface, internal audit program, management review package, certification audit interface, evidence library, metrics, and canonical role responsibilities. | ### Review Triggers - Material ISMS scope change - ISO certification, surveillance, or recertification audit - Material SoA change or control exclusion - Major internal audit finding or external nonconformity - Management review direction - Direction from the CISO Cyber Governance owns this package. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control source for ISO mapping | | Compliance Matrix | [`CERG-GOV-CMX-001`](../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) | Framework crosswalk source | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `ISO` domain | | Maturity Self-Assessment and Scorecard | [`CERG-GOV-MAT-001`](../governance/CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Maturity evidence and measurement | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence and audit process | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Risk treatment and acceptance process | | Security Change Management Procedure | [`CERG-PRC-CHG-001`](../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) | Change-control evidence and corrective action support | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Asset and scope evidence | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Information classification and handling evidence | --- ## NERC-CIP OPERATIONAL PACKAGE ### Evidence Library · OT VM · BES Access · Deviations · IT/OT Convergence · BES Categorization · ESP/EAP · CIP-013 · CIP-009 · CIP-015 (Forward-Looking) --- | | | |---|---| | **Document ID** | CERG-PLN-CIP-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | NERC-CIP Compliance Manager | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Standard** | [CERG-STD-OT-001](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) - Grid Control Systems Security Standard | | **Supporting Documents** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) · [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [CERG-PRC-AV-001](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) · [CERG-PLN-IR-001](CERG-PLN-IR-001_Incident_Response_Plan.md) | | **Review Cycle** | Annual / Continuous tracking - evidence currency monthly | | **Frameworks** | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) · IEC 62443-3-3 / 4-2 | | **Regulations** | NERC-CIP v7 (CIP-002 through CIP-014) · CIP-015 (draft, forward-looking) · CIP-013-2 | | **Environments** | BES Cyber Systems (Low / Medium / High Impact) + associated EACMS / PACS / PCAs | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Three-Lines-of-Defense Model](#2-three-lines-of-defense-model) 3. [CIP Version Strategy](#3-cip-version-strategy) 4. [BES Cyber System Categorization Procedure](#4-bes-cyber-system-categorization-procedure) 5. [ESP / EAP Topology Documentation](#5-esp--eap-topology-documentation) 6. [NERC-CIP Evidence Library Procedure (`CERG-GOV-CIP-001`)](#6-nerc-cip-evidence-library-procedure-cerg-gov-cip-001) 7. [OT Exposure Management Procedure (`CERG-PRC-VM-001`)](#7-ot-exposure-management-procedure-cerg-prc-vm-001) 8. [BES Cyber System Access Management Overlay](#8-bes-cyber-system-access-management-overlay) 9. [CIP Deviation and Mitigation Plan Template (`CERG-TMPL-CIP-001`)](#9-cip-deviation-and-mitigation-plan-template-cerg-tmpl-cip-001) 10. [IT/OT Convergence Security Architecture Guideline](#10-itot-convergence-security-architecture-guideline) 11. [CIP-013 Supply Chain Risk Management Plan](#11-cip-013-supply-chain-risk-management-plan) 12. [CIP-009 Recovery Plan Package](#12-cip-009-recovery-plan-package) 13. [CIP-015 INSM Implementation Annex](#13-cip-015-insm-implementation-annex) 14. [Operating Cadence and Reporting](#14-operating-cadence-and-reporting) 15. [Regulatory and Framework Alignment Summary](#15-regulatory-and-framework-alignment-summary) 16. [Document Control](#16-document-control) --- ## 1. Purpose and Scope The OT Standard names several subordinate artifacts and obliges CERG to maintain a full NERC-CIP evidence library separately. Until this package, those named subordinates did not exist. This package assembles them: an evidence library procedure, an OT VM procedure, a BES access management procedure, a CIP deviation template, an IT/OT convergence guideline, BES categorization and ESP/EAP topology procedures, the CIP-013 supply chain plan, the CIP-009 recovery plan package, and a forward-looking treatment of CIP-015 INSM. It applies to every BES Cyber System (Low / Medium / High Impact) and the associated Electronic Access Control / Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs). > **Operate the Compliance, Don't Just Document It** > > A binder of CIP requirements is not compliance. Compliance is the continuous evidence that the controls are operating, RTO measured, configurations baselined, access reviewed, deviations tracked, lessons learned actioned. This package is the operating manual for producing that evidence on a schedule the regulator can audit. --- ## 2. Three-Lines-of-Defense Model CERG operates as the **second line of defense** for CIP controls. | **Line** | **Role** | **Who** | |---|---|---| | **First** | Implementation of controls in the field. | OT Operators (substation engineering, control center operations, OT IT support). | | **Second** | Review, track implementation, evidence, and deviation; coordinate with Operators on control design and remediation. | CERG (NERC-CIP Compliance Manager, OT Risk Analyst, OT Security Engineer). | | **Third** | Dispassionate assurance independent of both. | Internal Audit and/or external firms. | The model is intentionally explicit so audit trails are clean: Operators do; CERG reviews and tracks; Audit independently assures. CERG never grades its own homework on first-line activities, and Operators are not asked to be their own auditors. --- ## 3. CIP Version Strategy CERG operates against the **latest approved** version of each CIP Standard, with a documented adoption window for newly approved versions and a draft-tracking posture for proposed standards. Specifically: - Active version baseline reviewed at every CIP filing-effective-date change. - Migration period for newly approved CIP versions tracked as risk register entries until cutover is complete. - Draft / proposed standards (presently including CIP-015 INSM) tracked per Section 13. --- ## 4. BES Cyber System Categorization Procedure CIP-002 requires identification and categorization of BES Cyber Systems. CERG categorizes following Attachment 1 criteria; the procedure: 1. **Inventory all BES Cyber Assets** in the enterprise inventory with required metadata (function, location, criticality input from Operations). 2. **Apply Attachment 1 criteria** (Section 1, High Impact criteria; Section 2, Medium Impact; everything else Low). 3. **Group BCAs into BES Cyber Systems** along functional / physical lines per operator input. 4. **Identify associated systems**: EACMS, PACS, PCAs, BCSI repositories. 5. **Document the rationale** for each categorization, the assessor will want to see it. 6. **Review annually** and on material grid configuration / asset changes. The categorization is reflected in the asset inventory and drives every subsequent CIP obligation. --- ## 5. ESP / EAP Topology Documentation CIP-005 requires Electronic Security Perimeters (ESPs) and Electronic Access Points (EAPs). CERG maintains: - A network diagram set showing every Medium and High Impact ESP, the EAPs defining it, and the connections crossing each EAP. - Per-EAP documentation: device, firmware version, rule set, last reviewed, owner, evidence of inbound/outbound deny-by-default, and authentication for interactive remote access. - Per-ESP documentation: enclosed BCS, EACMS, PACS, PCAs; supported categorization (Medium/High); evidence of monitoring (CIP-007 R4, and forthcoming CIP-015 INSM). - Annual review (or sooner on architecture change) with evidence routed into the library (Section 6). --- ## 6. NERC-CIP Evidence Library Procedure (`CERG-GOV-CIP-001`) The Evidence Library is the single, authoritative repository of CIP compliance evidence, what the auditor opens first. ### 6.1 Library Structure The library is organized by CIP Standard, then by Requirement, then by Sub-requirement. Each leaf has: | **Field** | **Description** | |---|---| | Standard / Requirement / Sub-Req | E.g., CIP-007-6 R2.2 | | Applicability | Low / Medium / High | | Owner | CERG role + Operator role | | Evidence Artifact(s) | Specific document / report / configuration / log | | Evidence System of Record | Where the live artifact lives | | Refresh Cadence | Monthly / Quarterly / Annual / 15-month / 36-month | | Last Refresh | Date | | Next Refresh | Date | | Status | Current · Approaching Expiry · Expired | | Deviation in Place? | Per Section 9 | | Notes | - | ### 6.2 Evidence Discipline - Every CIP Requirement applicable to in-scope assets has at least one Evidence Artifact named in the library. - Evidence is gathered through normal operations (CERG-managed scans, configuration capture, access reviews), not assembled at audit time. - Refresh cadences are driven from this library to the operating cadence (Section 14). ### 6.3 Reused Evidence CIP evidence reuses the broader CERG evidence catalog wherever possible (per [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) Section 8). The library cites where it lives rather than duplicating the artifact. --- ## 7. OT Exposure Management Procedure (`CERG-PRC-VM-001`) The enterprise exposure management procedure ([`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)) governs IT scopes; this OT-specific procedure overlays it with OT-safe practices. ### 7.1 Identification - **Passive scanning** is the default for live OT surfaces. - **Authenticated checks** under engineering supervision in defined windows. - **Vendor advisories** subscribed; advisories triaged against in-service firmware / software inventories. - **NVD / CISA ICS Advisories** subscribed. - Active scanning is permitted only under an approved scope and time window per [`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md) Section 9. ### 7.2 Risk Assessment and Treatment - Vulnerabilities mapped against CIP-007 R2 patch evaluation cycle (35 calendar days from release for Medium/High Impact to evaluate; per the standard's specifics). - Treatment options: apply patch in next maintenance window · implement compensating control · accept via Risk Register and CIP deviation if a deviation is required (Section 9). ### 7.3 Patching - Patch evaluation cadence per CIP-007 R2. - Patch deployment per CIP-010 R1, configuration changes require baseline update, security impact analysis, and authorization. - Patch evidence retained in the Evidence Library per CIP-007 R2.4. ### 7.4 Documentation - Per the procedure in [`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) Section 6 with OT-specific fields: applicability to BES, CIP-007 R2 timing, CIP-010 R1 change record. --- ## 8. BES Cyber System Access Management Overlay CIP-004 R4 / R5 obligations are operationalized as an embedded BES overlay on [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md). ### 8.1 Authorization - Access to BES Cyber Systems is authorized only after the individual has met CIP-004 personnel risk assessment requirements (background check, training). - Authorization is documented with a named approver per role. - Reviews per CIP-004 cadence (every 15 months, plus on role change). ### 8.2 Provisioning and Revocation - Provisioning of unescorted physical access to ESPs and electronic access to BCS goes through PAM-mediated workflows where supported. - Revocation within 24 hours of termination (CIP-004 R5.1), CERG operates against 1 hour for involuntary terminations. - BCSI access is governed under CIP-011 (information protection). ### 8.3 Vendor Remote Access - Brokered through approved gateways with session recording. - Authenticated per CIP-005 R2; monitored per CIP-005 R2.5 (interactive remote access via intermediate system). - Vendor identities enrolled via [`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) Section 10 and [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). --- ## 9. CIP Deviation and Mitigation Plan Template (`CERG-TMPL-CIP-001`) When a CIP requirement cannot be met as written (or cannot be met for a defined window), CERG documents a deviation and mitigation plan. This is in addition to the risk register entry in [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md). ``` CIP DEVIATION AND MITIGATION PLAN - DEV-CIP-YYYY-NNNN A. DEVIATION IDENTIFICATION Standard / Requirement : (e.g., CIP-007-6 R2.2) Applicability : Low / Medium / High Affected BCS / EACMS / PACS / PCAs Discovered By : Discovery Date : Description : Specific, requirement-citing language B. CAUSE Why the requirement is not met as written C. RISK Risk Register ID (per [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md)) Residual Risk Score Operator Sign-Off D. MITIGATION Compensating control(s) - specific, in-place, named, evidenced Detection coverage uplift (if applicable) E. PLAN TO ELIMINATE THE DEVIATION Steps : Owner : Target Closure : F. APPROVAL CERG NERC-CIP Compliance Manager : CISO : Operations : G. RECORD Library Reference : (where deviation lives in Section 6 library) Self-Report Required? : Y/N Self-Report Submitted : Date if applicable ``` > **Deviations Get Self-Reported When Self-Reporting Is the Right Call** > > CERG works with Operations and Legal to determine when a deviation is a self-reportable noncompliance under the regional entity's self-reporting program. The deviation record above always exists; whether to self-report is a deliberate Legal / Compliance / CISO decision, not a default. --- ## 10. IT/OT Convergence Security Architecture Guideline This embedded convergence guideline informs architecture decisions where IT systems touch OT systems. It is the V1 authoritative location for the planned standalone `CERG-GL-OT-001` guideline until that reserved artifact is promoted in a future catalog amendment. It is referenced by [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) for any project crossing the IT/OT boundary. ### 10.1 Foundational Patterns - **No flat IT/OT networks.** Convergence happens at named, documented EAPs. - **One-way logging out of OT, brokered control into OT.** Data flows out of OT to SIEM are one-way; control / management flows into OT traverse identity, authorization, and recording controls. - **Identity-first segmentation.** IT identity does not auto-translate to OT identity; OT identities are separate and governed by Section 8. - **DMZ / industrial DMZ.** Where IT systems consume OT data, an industrial DMZ holds data brokers, historians, and integration services. - **Engineering-tool isolation.** Engineering tools live on managed engineering workstations only; not on general-purpose corporate endpoints. ### 10.2 Pattern Reviews The guideline catalogs approved IT/OT integration patterns: - Historian-as-publisher (read-only, broker-mediated). - Operator workstation reading OT data via DMZ. - Vendor remote access via brokered jump. - Cloud-hosted analytics consuming OT data via one-way export. - IT identity using OT data in business analytics platforms. Each pattern lists the controls, the diagrams required, and the architecture review depth. ### 10.3 Anti-Patterns - Direct IT→OT VPN without brokering. - OT-side credentials used by IT business processes. - IT-side patching tools reaching into OT. - Cloud agents installed directly on OT endpoints. - File shares straddling IT and OT trust boundaries. --- ## 11. CIP-013 Supply Chain Risk Management Plan Operationalized in coordination with [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md). The CIP-013 Plan satisfies CIP-013-2 R1 and is reviewed annually (R3). ### 11.1 Scope Vendor relationships involving Medium or High Impact BCS planning, design, installation, deployment, software/firmware/services, vendor remote access. ### 11.2 Components | **R1 Risk Area** | **CERG Implementation** | |---|---| | Notification of vendor incidents | Contract clause + SCCT activation per [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Section 15 | | Coordination of incident response | SCCT + [`CERG-PLN-IR-001`](CERG-PLN-IR-001_Incident_Response_Plan.md) interface | | Notification of vendor personnel changes affecting access | Contract clause + CIP-004 access revocation per Section 8 | | Disclosure of known vulnerabilities | Subscription to vendor advisories + Section 7 OT VM | | Software / firmware integrity verification | [`CERG-STD-OT-001`](../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) + [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) Section 11 | | Vendor remote access - coordination of session controls | Section 8 + [`CERG-STD-AC-001`](../standards/CERG-STD-AC-001_Access_Management_Standard.md) | ### 11.3 Evidence CIP-013 evidence flows from this section into the Evidence Library (Section 6). --- ## 12. CIP-009 Recovery Plan Package Operationalized in coordination with [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md). The CIP-009 obligations: | **CIP-009 Requirement** | **CERG Implementation** | |---|---| | R1.1 Plan specifications | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 11 Recovery Plan template + Section 7 OT artifacts | | R1.2 Roles and responsibilities | Documented per plan | | R1.3 Process for backup management | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 4 | | R1.4 Method for preserving recovery data | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 7.1 | | R1.5 Operator-led recovery | Plan names operator with substation engineering authority | | R2.1 Testing | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 5 - at least every 15 months | | R2.2 Operational exercise | Every 36 months - full operational exercise | | R3 Lessons learned and plan update within 90 days | [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 5.2 step 8 | --- ## 13. CIP-015 INSM Implementation Annex CIP-015 (Internal Network Security Monitoring) is tracked as a forward-looking obligation for Medium and High Impact BES Cyber Systems. This annex operationalizes the CIP-015 readiness overlay referenced in CB-001 §8 BES Overlay. Until CIP-015 becomes enforceable for the organization, CERG treats this annex as a readiness investment; upon applicability, it becomes an audit-asserted operational procedure. > **INSM Is Not Optional for Medium/High Impact BCS** > > Once CIP-015 becomes enforceable, operators of Medium and High Impact BES Cyber Systems must demonstrate continuous internal network security monitoring. This annex ensures CERG is not scrambling on day one. ### 13.1 Scope and Applicability | **Scope Element** | **Coverage** | |---|---| | BES Impact Levels | Medium and High Impact BES Cyber Systems | | Associated Systems | EACMS, PACS, PCAs within the ESP boundary | | INSM Objective | Detect anomalous or malicious activity on internal OT networks at the ESP/EAP boundary and within the BES Cyber System interior | | Regulatory Driver | CIP-015 (draft, forward-looking); CB-001 §8 BES Overlay | | CERG Readiness Obligation | Produce evidence of readiness decisions, sensor coverage maps, and gap analysis until applicability | ### 13.2 Network Sensor Placement Sensor placement follows the ESP/EAP topology documented in Section 5 and the IT/OT convergence architecture in Section 10. | **Sensor Location** | **Placement Requirement** | **Monitoring Purpose** | |---|---|---| | EAP ingress/egress (IT side) | One sensor per EAP monitoring all inbound and outbound traffic crossing the ESP boundary | Detect unauthorized traversal, protocol anomalies, command-and-control patterns, data exfiltration attempts | | EAP interior (OT side) | One sensor within each ESP monitoring east-west traffic between BCS inside the same ESP | Detect lateral movement, insider-threat activity, protocol violations, unauthorized device-to-device communication | | IT/OT DMZ | Sensor at each industrial DMZ monitoring historian and data-broker flows | Detect data exfiltration, unauthorized data access, corrupted historian feeds | | Vendor remote-access gateway | Sensor at the vendor VPN/concentrator egress monitoring all remote sessions | Detect unauthorized vendor activity, session hijacking, credential misuse | | Field-location aggregation point | Where substations or remote sites aggregate, a sensor at the aggregation uplink | Detect compromised field devices communicating anomalously | #### Sensor Density Guidelines - Each Medium Impact ESP: Minimum 1 sensor covering EAP ingress/egress. - Each High Impact ESP: Minimum 2 sensors — one at EAP boundary, one for interior east-west monitoring. - Any ESP with >50 BCA devices: Add 1 sensor per additional 50 BCAs or fraction thereof, distributed across logical segments. - Sensor coverage evidence: Documented in the ESP/EAP topology diagram (Section 5) with sensor locations annotated. ### 13.3 Data Collection Requirements | **Data Type** | **Source** | **Collection Method** | **Retention** | **CIP-015 Relevance** | |---|---|---|---|---| | NetFlow / IPFIX | Network switches and routers at EAPs and interior segments | Flow export to collector; minimum 1:4096 sampling for high-throughput links | 90 days (CIP-006 minimum); 365 days for High Impact | Network baseline, anomaly detection | | Full packet capture | EAP ingress/egress for High Impact ESPs | 10% sampled PCAP at EAP; 100% on High Impact EAPs for control-session traffic | 30 days rolling; 90 days for security events | Forensic analysis, threat-hunting | | DNS query logs | Authoritative DNS resolvers serving OT zones | Syslog to SIEM | 365 days | C2 detection, beacon identification | | Authentication events | Active Directory / LDAP, PAM, RADIUS servers | Syslog / Windows Event Forwarding to SIEM | 365 days | Unauthorized access detection | | OT protocol logs | Protocol-aware monitoring (DNP3, Modbus, IEC 61850, IEC 104 pass-through) | Deep packet inspection via OT-IDPS or protocol-aware sensor | 90 days; 365 days for security events | Protocol anomaly detection, control-command validation | | Firewall / ACL logs | ESP boundary firewalls, EAP devices | Syslog to SIEM | 90 days; 365 days for High Impact | Policy violation detection | | Endpoint detection logs | OT endpoints with approved host-based monitoring | Agent-based (where available and OT-safe) or log export | 90 days | Host compromise detection | | Vendor remote-access logs | PAM gateway, VPN concentrator | Session recording + metadata to SIEM | 365 days; indefinite for security incidents | Vendor anomaly detection | #### Collection Integration - All INSM data sources feed into the enterprise SIEM per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) Section 4. - Where SIEM ingestion is not feasible (e.g., air-gapped OT environments), a local log collector forwards to SIEM via one-way data diode. ### 13.4 Alerting Rules and Detection Baseline The following alert categories are the minimum detection baseline for Medium and High Impact BES Cyber Systems. Rules are implemented in the SIEM and maintained by the Detection Engineer per [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) Section 6. | **Alert Category** | **Rule Description** | **Severity** | **Response SLA** | |---|---|---|---| | Unauthorized EAP traversal | Device not on authorized BCA list communicating across EAP | Critical | 1 hour | | Protocol anomaly | DNP3/Modbus/IEC 61850 message outside allowed function codes or address range | High | 2 hours | | Beaconing / C2 | Outbound connection to untrusted destination with periodic patterns | Critical | 1 hour | | New device on OT segment | MAC or IP not in asset inventory detected on OT LAN | High | 4 hours | | Authentication spike | >10 failed authentication attempts on any OT system in 5 minutes | Medium | 4 hours | | Vendor session anomaly | Vendor remote access outside approved schedule or from unexpected location | Medium | 2 hours | | Configuration drift | Baseline comparison of ESP/ EAP rule set differs from authorised baseline | High | 4 hours | | Data volume anomaly | Outbound data transfer from OT DMZ exceeding 3x rolling 30-day average | High | 2 hours | | Controller firmware change | Firmware hash change on BES Cyber System controller | Critical | 1 hour | | Rogue DHCP / ARP spoof | DHCP server or unexpected ARP announcement within ESP | High | 2 hours | #### Alert Tuning and False-Positive Management - All alerting rules start in test mode for 30 days post-deployment. - After 30 days, rules are moved to active monitoring with a 14-day tuning window. - False-positive rate >5% per rule triggers re-evaluation and rule revision. - Tuning documentation is retained in the evidence library. ### 13.5 Evidence Package CIP-015 evidence is collected and stored in the NERC-CIP Evidence Library (Section 6) under CIP-015 requirements. | **Evidence Item** | **Source** | **Cadence** | **CIP-015 Requirement** | |---|---|---|---| | Sensor inventory and placement diagram | Section 13.2 sensor tables + ESP/EAP diagrams | Annual + on change | R1 (monitoring coverage) | | Data collection configuration | SIEM data source inventory | Quarterly | R2 (data collection) | | Alerting rule inventory | SIEM rule registry | Quarterly | R3 (analysis) | | Sample alert records | SIEM alert history (10 per category per quarter) | Quarterly | R3 (analysis) | | False-positive tuning log | SIEM tuning tickets | Quarterly | R3 (analysis) | | Sensor health check | Sensor uptime report | Monthly | R1 (monitoring coverage) | | Coverage gap analysis | Section 13.6 | Quarterly | R1, R2 | | Response time measurement | Alert-to-investigation timestamp logs | Quarterly | R4 (response) | | INSM governance record | Risk-register entries, readiness decisions | Annual | Cross-cutting | ### 13.6 Coverage Gap Analysis A formal gap analysis is performed quarterly, comparing current INSM coverage against the CIP-015 draft requirements and CB-001 §8 BES Overlay expectations. | **Gap Category** | **Assessment Question** | **Acceptable State** | **Escalation Path** | |---|---|---|---| | Sensor coverage | Does every Medium/High ESP have at least one sensor? | Yes for Medium; minimum 2 for High | Gap >30 days → CISO escalation | | Data source coverage | Are all data types in Section 13.3 being collected? | ≥80% of required data types collected | Gap >90 days → Risk Register entry | | Alert coverage | Are all alert categories in Section 13.4 active? | 100% of Critical/High alert categories active | Gap >14 days → Risk Register entry | | Retention compliance | Are data retention periods meeting Section 13.3 minimums? | 100% of data types at min retention | Gap → Deviation record per Section 9 | | Response time adherence | Are alert response SLAs being met? | ≥90% within SLA | Gap → Corrective action per Section 8 | Gaps are documented in the risk register and tracked as deviation items per Section 9 until closure. ### 13.7 Integration with Existing CERG Capabilities | **CERG Capability** | **Integration Point** | **INSM Dependency** | |---|---|---| | Exposure Management ([`CERG-PRC-VM-001`](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md)) | Vulnerability scan findings correlated with INSM alert data to identify actively exploited vulnerabilities | INSM provides active-threat context for vulnerability prioritisation | | Logging and Detection ([`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md)) | OT telemetry added to SIEM as mandatory log source per LM-001 §4; alert rules follow LM-001 §6 | LM-001 is the procedural owner of SIEM ingestion and rule management | | Threat Intelligence ([`CERG-PRC-TI-001`](../procedures/CERG-PRC-TI-001_Threat_Intelligence_Procedure.md)) | OT-specific threat intel feeds enrich INSM alerts (e.g., ICS-CERT advisories, sector-specific IOCs) | INSM alerting rules consume threat intel for contextual alerting | | Incident Response ([`CERG-PLN-IR-001`](CERG-PLN-IR-001_Incident_Response_Plan.md)) | INSM alerts feed incident triage; playbooks incorporate OT-specific containment | IR team requires INSM evidence for OT incident scoping | | Architecture Review ([`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md)) | New OT projects include INSM sensor placement review in architecture intake | INSM coverage is a gate criterion for OT project production handoff | | Adversarial Validation ([`CERG-PRC-AV-001`](../procedures/CERG-PRC-AV-001_Adversarial_Validation_Procedure.md)) | Penetration test scope includes INSM alert evasions to test detection coverage | AV tests validate INSM effectiveness | | Risk Register ([`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md)) | INSM coverage gaps recorded as risk items with compensating controls | Risk register tracks residual detection risk | ### 13.8 Readiness Activities (Pre-Applicability) Until CIP-015 is enforceable, CERG performs the following readiness activities: 1. **Map existing OT telemetry sources** to expected INSM coverage objectives (Section 13.3). 2. **Identify ESP / EAP monitoring gaps** that would affect Medium or High Impact BES Cyber Systems. 3. **Deploy minimum viable sensors** at EAP ingress/egress for High Impact ESPs. 4. **Implement baseline alerting rules** for Critical and High alert categories (Section 13.4). 5. **Route monitoring backlog items** through [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) and the risk register when coverage cannot be implemented immediately. 6. **Preserve evidence of readiness decisions** in the Evidence Library (Section 6). ### 13.9 Cutover Trigger When CIP-015 becomes applicable, Governance: 1. Updates this annex from "readiness" to "enforceable" status. 2. Sets evidence collection cadences from "on readiness" to Section 13.5 table frequencies. 3. Activates all alerting rules from test mode to active monitoring. 4. Updates compliance calendar with enforceable evidence requirements. 5. Notifies all NERC-CIP Compliance Manager, OT Security Engineer, and Detection Engineer roles. 6. Creates CIP-015-specific evidence library entries per Section 6. --- ## 14. Operating Cadence and Reporting | **Activity** | **Cadence** | |---|---| | Evidence library refresh sweep | Continuous; full review monthly | | BES categorization review | Annual + on material change | | ESP/EAP topology review | Annual + on architecture change | | CIP-004 access reviews | Per CIP cadence (≤ 15 months); CERG operates quarterly | | CIP-007 R2 patch evaluation | Per CIP cadence | | CIP-009 recovery testing | Every 15 months minimum; full exercise every 36 months; CERG operates annually | | CIP-010 baseline review | Per CIP cadence | | CIP-013 plan review | Annual (R3) | | Deviation register review | Monthly | | Reg posture report | Quarterly per `CERG-GOV-MTR-001` | | Internal CIP walkthrough | Quarterly (sampling) | | Independent (third-line) review | Annual minimum | --- ## 15. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Package** | |---|---| | CIP-002 | Section 4 | | CIP-003 | Cross-cutting (policy + program); Section 2 | | CIP-004 | Section 8 | | CIP-005 | Section 5 | | CIP-006 | Interface to Facilities (out of CERG scope; coordinated) | | CIP-007 | Sections 5–7, evidence library | | CIP-008 | Interface to `CERG-PLN-IR-001` | | CIP-009 | Section 12 + `CERG-STD-RES-001` | | CIP-010 | Sections 5, 7 + `CERG-STD-CFG-001` | | CIP-011 | Section 8 + `CERG-STD-CR-001` | | CIP-013 | Section 11 + `CERG-PRC-TPRM-001` | | CIP-014 | Interface to Facilities | | CIP-015 (draft) | Section 13 + `CERG-STD-LM-001` | | [NIST 800-82r3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) | Sections 7, 10 + `CERG-STD-OT-001` / `CERG-STD-CFG-001` | | IEC 62443-3-3 / 4-2 | Sections 7, 10 | --- ## 16. Document Control | | | |---|---| | **Document ID** | CERG-PLN-CIP-001 | | **Version** | 1.22 | | **Approved By** | CISO | | **Next Review** | Annual / on CIP version or filing change | | **Change Log** | 1.0 - Initial publication. Evidence library, OT VM, BES access, deviation template, IT/OT convergence guideline, categorization, ESP/EAP, CIP-013, CIP-009, CIP-015 forward-looking. 1.22 - Expanded CIP-015 §13 from preliminary section to full INSM Implementation Annex with sensor placement, data collection, alerting rules, evidence package, gap analysis, and integration map. | --- ## PRIVACY AND DATA PROTECTION OPERATIONAL PACKAGE ### Privacy Scope · DPIA · Data Subject Requests · Breach Clocks · Evidence Interface --- | | | |---|---| | **Document ID** | CERG-PLN-PRIV-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Documents** | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) · [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | | **Supporting Documents** | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / On material privacy-law, data-processing, or vendor-scope change | | **Frameworks** | NIST Privacy Framework · ISO/IEC 27701 · ISO/IEC 27001 · [NIST CSF 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) | | **Regulations** | GDPR · CCPA / CPRA · state privacy laws · breach-notification laws · contractual privacy obligations | | **Environments** | Systems, vendors, processes, and data flows involving personal data or privacy-regulated data | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Ownership Boundary](#2-ownership-boundary) 3. [Privacy Data Inventory](#3-privacy-data-inventory) 4. [Privacy Impact and DPIA Workflow](#4-privacy-impact-and-dpia-workflow) 5. [Data Subject Request Support](#5-data-subject-request-support) 6. [Breach Notification Clock Support](#6-breach-notification-clock-support) 7. [Third-Party Privacy Risk](#7-third-party-privacy-risk) 8. [Retention, Deletion, and Minimization](#8-retention-deletion-and-minimization) 9. [Evidence Library](#9-evidence-library) 10. [Metrics](#10-metrics) 11. [Roles and Responsibilities](#11-roles-and-responsibilities) 12. [Regulatory and Framework Alignment Summary](#12-regulatory-and-framework-alignment-summary) 13. [Document Control](#13-document-control) --- ## 1. Purpose and Scope CERG does not replace the enterprise privacy, legal, or records-management programs. Those programs determine legal obligations, notices, consent requirements, data subject rights, and regulator communications. CERG supplies the cyber, data governance, asset, vendor, incident, risk, and evidence machinery those privacy decisions need. This operational package defines how CERG supports privacy and data protection obligations: privacy data inventory, DPIA support, data subject request support, breach-clock facts, vendor privacy evidence, retention and deletion control support, metrics, and evidence. > **Privacy Fails When Nobody Can Find the Data** > > Legal can interpret the obligation. The business can decide the purpose. But if the organization cannot say where personal data lives, who owns it, which vendors process it, how long it is retained, how it is deleted, and what happened during an incident, privacy becomes guesswork. CERG's role is to remove the guesswork. --- ## 2. Ownership Boundary | **Area** | **Primary Owner** | **CERG Contribution** | |---|---|---| | Legal interpretation of privacy laws | Enterprise legal / privacy process | Supplies data, system, vendor, and control facts. | | Privacy notices, consent, and lawful basis | Enterprise privacy process | Supplies processing inventory and system evidence. | | Data subject request decisioning | Enterprise privacy process | Locates data, verifies systems, supports deletion/export evidence. | | Breach notification decisions | Incident Commander with legal and executive process | Supplies data classification, affected systems, logs, and containment evidence. | | Data classification and handling | Governance Pillar Leader | Owns `CERG-STD-DG-001` and evidence of handling controls. | | Third-party processing risk | Vendor Risk Analyst | Maintains vendor assessment and contractual control evidence. | | Privacy-related residual risk | Risk Pillar Leader | Routes risk and exception decisions through the risk register. | This package intentionally uses CERG canonical roles. Where a privacy or legal function exists outside CERG, the package describes the interface without renaming it as a CERG role. --- ## 3. Privacy Data Inventory The privacy data inventory extends the asset inventory and data classification standard. It identifies where personal data exists and how it moves. Minimum inventory fields: | **Field** | **Description** | |---|---| | Processing Activity | Business process or activity using personal data. | | Business Owner | Accountable business owner or Executive Sponsor. | | Systems / Assets | Asset IDs from `CERG-STD-AM-001`. | | Data Categories | Personal data categories processed. | | Sensitive Data | Special category, financial, health, child, biometric, location, or other sensitive data. | | Data Subjects | Customers, employees, contractors, vendors, applicants, visitors, or other groups. | | Purpose | Business purpose for processing. | | Geography | Jurisdictions where data subjects or processing locations exist. | | Vendors / Processors | Third parties with access to the data. | | Retention Period | Required or intended retention. | | Deletion Method | How data is removed, anonymized, or archived. | | DSR Supportability | Whether search, export, correction, and deletion are technically supported. | | Security Controls | Key controls protecting the data. | | Evidence Location | Evidence library reference. | The inventory is reviewed at least annually and when a new system, vendor, data category, or processing purpose is introduced. --- ## 4. Privacy Impact and DPIA Workflow A privacy impact assessment or Data Protection Impact Assessment (DPIA) is required when a change introduces material privacy risk. Triggers: - new processing of personal data; - new sensitive-data category; - new AI or automated decisioning use case involving people; - new vendor processing personal data; - new cross-border transfer or hosting location; - material change to retention, deletion, or data sharing; - high-volume monitoring, profiling, or behavioral analytics; - incident or finding showing privacy control weakness. CERG supports DPIA with: 1. asset and system inventory; 2. data classification; 3. data-flow and vendor mapping; 4. security controls in place; 5. logging and monitoring posture; 6. deletion and retention capability; 7. third-party control evidence; 8. residual-risk record; 9. evidence package for approval. DPIA outcomes that require controls are tracked as change actions, risk-register entries, vendor-risk actions, or document updates. --- ## 5. Data Subject Request Support Data subject requests are owned by the enterprise privacy process. CERG supports the technical execution and evidence. Support steps: | **Step** | **CERG Support** | |---|---| | Intake confirmation | Confirm whether CERG-managed systems may hold responsive data. | | System search | Identify systems, vendors, backups, archives, and logs in scope. | | Export support | Support data extraction where permitted and technically feasible. | | Correction support | Identify records requiring correction and affected systems. | | Deletion support | Validate deletion, anonymization, retention exception, or legal hold constraints. | | Evidence capture | Preserve request ID, systems searched, actions taken, exceptions, and completion evidence. | CERG does not decide whether a request is valid or whether an exemption applies. CERG supplies facts and executes approved technical actions. --- ## 6. Breach Notification Clock Support Privacy breach notification clocks often start before the full technical story is known. CERG's job is to provide reliable facts quickly. Within the incident process, CERG supplies: - affected systems and asset owners; - data categories and data subject groups; - regulated geographies and contractual obligations known to CERG; - approximate data volume if available; - access logs, DLP events, exfiltration indicators, and containment actions; - vendor involvement; - encryption, tokenization, or other protective control status; - evidence of when the event was detected, escalated, contained, and resolved. Notification decisions remain with the Incident Commander, legal, executive, and enterprise privacy process. CERG preserves the evidence and records residual control gaps. > **The Clock Does Not Wait for Perfect Forensics** > > Privacy deadlines are measured in hours and days, not in the time it takes to reach certainty. CERG therefore supplies decision-grade facts: what is known, what is unknown, what is being validated, and which controls may change the notification analysis. --- ## 7. Third-Party Privacy Risk Third parties processing personal data are assessed through `CERG-PRC-TPRM-001` with privacy-specific evidence added. Minimum vendor privacy evidence: | **Evidence** | **Purpose** | |---|---| | Data categories processed | Confirms scope of personal data exposure. | | Processing location | Supports geography and transfer analysis. | | Subprocessor list | Identifies downstream processing. | | Security control evidence | Confirms protection of personal data. | | Breach notification commitment | Supports notification timing and coordination. | | Deletion / return terms | Supports termination and DSR obligations. | | Audit or assurance report | Supports control reliance. | | Contractual control mapping | Supports privacy and security clauses. | Vendor gaps that expose personal data become vendor-risk findings or risk-register entries. --- ## 8. Retention, Deletion, and Minimization CERG supports retention and minimization by ensuring systems can enforce or evidence the business rule. Requirements: 1. Systems processing personal data have a documented retention expectation. 2. Retention conflicts are escalated to the business owner and enterprise privacy process. 3. Deletion mechanisms are documented for T1/T2 and high-volume personal-data systems. 4. Backups and archives document restoration and deletion limitations. 5. Logs containing personal data are classified and retained only as long as justified. 6. New systems demonstrate minimization and deletion capability during architecture review. 7. Data that cannot be deleted on request due to legal, technical, or backup constraints has a documented rationale and evidence. --- ## 9. Evidence Library Privacy evidence is retained under `CERG-PRC-AUD-001`. | **Evidence Area** | **Contents** | |---|---| | Privacy data inventory | Processing records, systems, vendors, data categories. | | DPIA / privacy impact records | Assessments, approvals, control actions. | | DSR support evidence | Systems searched, exports, deletion evidence, exceptions. | | Breach support evidence | Incident facts, data classification, containment, logs. | | Vendor privacy evidence | Subprocessors, locations, contractual controls, deletion terms. | | Retention and deletion evidence | Retention rules, deletion tests, exceptions. | | Risk and exception records | Privacy-related risks and acceptances. | --- ## 10. Metrics | **Metric** | **Purpose** | |---|---| | Systems with personal data inventory complete | Measures inventory coverage. | | High-risk processing activities with DPIA complete | Measures assessment coverage. | | DSR requests supported within required technical window | Measures response support. | | Privacy incidents with complete CERG evidence package | Measures breach-readiness discipline. | | Vendors processing personal data with current evidence | Measures third-party privacy posture. | | Systems with documented deletion capability | Measures operational privacy readiness. | | Privacy-related risks open by age and severity | Measures remediation posture. | | Data inventory records reviewed on schedule | Measures governance hygiene. | --- ## 11. Roles and Responsibilities Roles below are canonical role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1. | **Role** | **Privacy Support Responsibility** | |---|---| | **Governance Pillar Leader** | Accountable owner for this package, privacy evidence coordination, and data-governance interface. | | **Policy & Standards Manager** | Maintains privacy-support documentation and related standard updates. | | **Evidence Librarian** | Maintains privacy evidence library and request-support evidence. | | **Risk Pillar Leader** | Assesses privacy-related residual risk and treatment. | | **Risk Register Owner** | Records privacy-related risks, exceptions, and review dates. | | **Vendor Risk Analyst** | Assesses vendors processing personal data and maintains vendor privacy evidence. | | **Engineering Pillar Leader** | Coordinates technical support for deletion, export, logging, control validation, and architecture review. | | **Cloud Security Engineer** | Supports SaaS, cloud, storage, and platform privacy evidence. | | **Identity Engineer** | Supports identity, access, and account evidence for privacy investigations and DSR execution. | | **Application Security Engineer** | Supports application data-flow, SDLC, API, and AI privacy-risk reviews. | | **Detection Engineer** | Supplies relevant alerting, logging, and exfiltration evidence where in scope. | | **Incident Commander** | Commands active incident response when a privacy incident is part of a security incident. | | **Chief Information Security Officer (CISO)** | Approves material privacy-security risk acceptance and executive escalation. | --- ## 12. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Reference** | **Where in This Package** | |---|---|---| | GDPR | Records of processing, DPIA, data subject rights, breach notification | Sections 3, 4, 5, 6 | | CCPA / CPRA | Consumer rights, deletion, vendor processing | Sections 3, 5, 7, 8 | | State privacy laws | Breach and rights support | Sections 5, 6, 9 | | NIST Privacy Framework | Identify, Govern, Control, Communicate, Protect | Sections 3 through 10 | | ISO/IEC 27701 | Privacy information management | Sections 3, 4, 7, 9 | | ISO/IEC 27001 | Data protection, risk, suppliers, incidents | Sections 4, 6, 7, 9 | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-PLN-PRIV-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; and on material privacy-law, data-processing, or vendor-scope change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST Privacy Framework; ISO/IEC 27701; ISO/IEC 27001; NIST CSF 2.0 | | **Regulations** | GDPR; CCPA / CPRA; state privacy laws; breach-notification laws; contractual privacy obligations | | **Environments** | Systems, vendors, processes, and data flows involving personal data or privacy-regulated data | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes CERG's privacy support boundary, privacy data inventory, DPIA support workflow, data subject request technical support, breach notification clock support, third-party privacy risk evidence, retention and deletion support, evidence library, metrics, and canonical role responsibilities. | ### Review Triggers - Material change to privacy law or contractual privacy obligation - New high-risk processing activity - Material incident involving personal data - Material change to data governance, vendor-risk, or incident-response process - DPIA or audit finding requiring package update - Direction from the CISO Cyber Governance owns this package. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval and enterprise privacy process concurrence where applicable. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Defines canonical roles and adjacent-program boundary | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control source for privacy-support controls | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Classification, labeling, handling, retention, and DLP support | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | System and ownership inventory | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Vendor risk requirements and privacy evidence workflow | | Incident Response Playbook Set | [`CERG-PRC-IR-002`](../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) | Privacy incident support evidence | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence retention | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Privacy-related risks and exceptions | | Document Catalog and Naming Convention | [`CERG-GOV-CAT-001`](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) | Registers this artifact and the `PRIV` domain | --- ## SOX ITGC OPERATIONAL PACKAGE ### Control Library · SOX-Relevant System Register · Evidence Reuse · Deficiency Workflow --- | | | |---|---| | **Document ID** | CERG-PLN-SOX-001 | | **Version** | 1.22 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (SOX Liaison) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Parent Documents** | [CERG-POL-001](../governance/CERG-POL-001_Cybersecurity_Policy.md) · [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | | **Supporting Documents** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) · [CERG-STD-AC-001](../standards/CERG-STD-AC-001_Access_Management_Standard.md) · [CERG-STD-LM-001](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) · [CERG-STD-CFG-001](../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) · [CERG-STD-RES-001](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) · [CERG-STD-CR-001](../standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md) · [CERG-PRC-AR-001](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [CERG-PRC-AC-002](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) · [CERG-PRC-VM-001](../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) · [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | | **Review Cycle** | Annual / Per SOX year | | **Frameworks** | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) mappings · COBIT 2019 (selected) · COSO (selected) | | **Regulations** | Sarbanes-Oxley Act of 2002 | | **Environments** | SOX-relevant systems supporting financial reporting | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [In-Scope ITGC Domains](#2-in-scope-itgc-domains) 3. [SOX-Relevant System Register](#3-sox-relevant-system-register) 4. [ITGC Control Library](#4-itgc-control-library) 5. [Evidence Reuse Mapping](#5-evidence-reuse-mapping) 6. [SOC 1 Reuse Procedure](#6-soc-1-reuse-procedure) 7. [Deficiency Workflow](#7-deficiency-workflow) 8. [Auditor Interface](#8-auditor-interface) 9. [Operating Cadence](#9-operating-cadence) 10. [Regulatory and Framework Alignment Summary](#10-regulatory-and-framework-alignment-summary) 11. [Document Control](#11-document-control) --- ## 1. Purpose and Scope SOX shows up in the policy, the compliance matrix, the IT and Access standards, the risk procedure, and the operating model, but until this package, there was no SOX ITGC control library, no SOX-relevant system register, and no auditor-facing deficiency workflow. This package fills that gap. It assumes the organization is a publicly-traded U.S. company subject to the Sarbanes-Oxley Act with both external auditor and Internal Audit interaction. Where the organization is private, regulated by an analogous regime, or pre-IPO, the structure of this package adapts but the boundaries, scope by financial-reporting impact, evidence reused from operating controls, remain. > **The CERG SOX Model in One Sentence** > > SOX is not a separate control universe, it is a scope filter over the controls CERG already operates, with formal documentation and quarterly testing for the systems that touch financial reporting. --- ## 2. In-Scope ITGC Domains The six ITGC domains in scope are the standard set for a publicly traded company: | **Domain** | **In Scope Because** | |---|---| | **Access** | Who can read, modify, or post to financial transactions and master data. | | **Change** | What changed in financially-relevant logic, configuration, or interfaces. | | **Operations** | Whether scheduled jobs, interfaces, and batch processing ran as intended. | | **Backup** | Whether financial records can be recovered. | | **Interfaces** | Whether data moving between systems remains complete and accurate. | | **Reports** | Whether financial reports are produced from the intended data and logic. | If the organization's audit firm scopes differently (some include "End-User Computing" or "Cybersecurity" as separate categories), CERG aligns to that scoping and updates the library; the six above are the durable spine. --- ## 3. SOX-Relevant System Register The Register is the scope filter, the list of systems whose controls feed external financial reporting. Every CERG control test under SOX scope is performed against systems in this register. | **Field** | **Description** | |---|---| | System Name / Asset ID | - | | Owner | Named role | | Business Process Supported | E.g., GL, AP, AR, payroll, fixed assets, treasury | | Financial Statement Assertion Relevance | Existence · Completeness · Valuation · Rights & Obligations · Presentation | | Hosted Where | On-prem / IaaS / PaaS / SaaS | | SOC 1 Available? | Y/N (if hosted) | | In-Scope Domains | Multi-select of Section 2 domains | | SOD-Sensitive Roles | Named roles (e.g., AP clerk vs. AP approver) | | Recovery Tier | Per [`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) Section 3 | | Last Walkthrough | Date | | Outstanding Deficiencies | IDs | | Status | In-Scope · Out-of-Scope (with rationale) · Transitional | The register is owned jointly by CERG Governance (SOX liaison) and Finance / Internal Audit; CERG owns the cyber slice. --- ## 4. ITGC Control Library Each control names the SOX domain it supports, the CERG control it reuses from [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md), the SOX-specific evidence the auditor expects, and the test approach. ### 4.1 Access ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | AX-01 Provisioning | Access to SOX-relevant systems is granted only on documented approval by the system owner. | AC-2 ([`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §4) | Sample of provisioning tickets with approvals | Sample of N from period | | AX-02 Termination | Access is removed within defined SLA on user departure. | AC-2 ([`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §3.3) | Sample of terminations with access-removal evidence | Sample of N from period | | AX-03 Recertification | SOX-relevant access is recertified quarterly. | AC-2 ([`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §5) | Quarterly recert campaign results | Full population review of cycle | | AX-04 Segregation of Duties | SOD enforced on financially-sensitive roles. | AC-5 ([`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) §6.1) | SOD matrix; conflict-resolution log | Quarterly SOD report | | AX-05 Privileged Access | Privileged access to SOX-relevant systems via PAM with session recording. | AC-6 ([`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §6) | PAM session log sample; privileged role review | Sample of N | | AX-06 Authentication | MFA enforced on SOX-relevant system access. | IA-2 ([`CERG-PRC-AC-002`](../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) §11) | IdP policy export; exception register | Configuration review | ### 4.2 Change ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | CH-01 Change Authorization | Production changes are authorized before deployment. | CM-3 ([`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) §3) | Change records with named approver | Sample of N | | CH-02 Segregation of Duties - Change | Developer ≠ deployer for SOX-relevant systems. | CM-3 + AC-5 | CI/CD pipeline review; manual deployment SoD evidence | Configuration review + sample | | CH-03 Emergency Change | Emergency changes documented within defined window. | CM-3 | Emergency change records with retrospective approval | Sample of N | | CH-04 Testing | Changes are tested before production deployment. | CM-3 | Test evidence per change record | Sample of N | ### 4.3 Operations ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | OP-01 Scheduled Job Monitoring | Scheduled financial jobs are monitored; failures are investigated and remediated. | SI-4 ([`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md)) | Job monitoring dashboards; failure tickets | Sample of failures + period review | | OP-02 System Monitoring | SOX-relevant systems are monitored for availability and security events. | AU-2 / SI-4 | SIEM source inventory; uptime dashboards | Coverage review | | OP-03 Incident Tracking | Incidents affecting SOX-relevant systems are tracked to closure. | IR family | Incident records with cyber annotation | Sample of N | ### 4.4 Backup ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | BK-01 Backup Execution | SOX-relevant systems are backed up per defined schedule. | CP-9 ([`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md)) | Backup tool report; failure tickets | Period review | | BK-02 Backup Restoration | Restorability is demonstrated at the SOX cadence. | CP-10 ([`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md)) | Restoration test evidence (Section 5.3 of RES-001) | Inspection of test artifact | | BK-03 Backup Protection | Backups are protected (immutability / separation). | CP-9 ([`CERG-STD-RES-001`](../standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md) §4) | Backup configuration evidence | Configuration review | ### 4.5 Interfaces ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | IF-01 Interface Inventory | Interfaces between SOX-relevant systems are inventoried. | CM-8 + SC-7 | Interface inventory document | Inspection | | IF-02 Interface Change Control | Changes to interface logic follow Change ITGCs. | CM-3 | Change records on interface code | Sample of N | | IF-03 Interface Monitoring | Interface job execution is monitored. | SI-4 | Interface monitoring evidence | Period review | | IF-04 Interface Integrity | Data integrity controls applied to interface flows. | SC-8 / SI-7 | Configuration / test evidence | Sample / inspection | ### 4.6 Reports ITGCs | **ITGC** | **Control Statement** | **Reused CERG Control** | **SOX Evidence** | **Test Approach** | |---|---|---|---|---| | RP-01 Report Logic Change Control | Changes to financial report logic follow Change ITGCs. | CM-3 | Change records on report objects | Sample of N | | RP-02 Report Access | Access to financial reports follows Access ITGCs. | AC-2 / AC-6 | Report access review | Sample of N | | RP-03 Report Reconciliation Support | Reports support reconciliation; data sources are documented. | AU-6 / CM-3 | Report-to-source documentation | Inspection | --- ## 5. Evidence Reuse Mapping The mapping in Section 4 reuses CERG's existing evidence library. The principle, repeated: > **SOX Reuses CERG Evidence; CERG Does Not Create SOX-Only Tests** > > If a CERG control test is already running at the cadence the SOX auditor needs, on a system in the SOX register, the SOX test consumes that evidence. CERG does not produce a parallel "SOX-only" version. Where reuse is impossible, e.g., the SOX auditor explicitly requires a different sample period, CERG produces the supplemental sample but documents the reuse principle in the test working paper. Specifically, the most-reused artifacts: - Quarterly access recertification reports (AX-03, AX-04, AX-05). - PAM session logs (AX-05). - Change management records and CI/CD pipeline configuration (CH-01, CH-02, CH-03, CH-04, RP-01). - SIEM source inventory and detection coverage report (OP-01, OP-02, OP-03, IF-03). - Backup tool reports and restoration test evidence (BK-01, BK-02, BK-03). - DISH baseline scan output (where SOX-relevant systems' configuration is tested). --- ## 6. SOC 1 Reuse Procedure CB-001 §10.1 SOX crosswalk and §7.1 Inheritance establish that SOC 1 reports can be reused for hosted financial systems. This procedure operationalises that reuse: it defines how CERG acquires SOC 1 reports, inventories Complementary User Entity Controls (CUECs), performs gap analysis, documents compensating controls, builds an evidence package for the external auditor, and manages the annual refresh cycle. ### 6.1 Report Acquisition | **Step** | **Action** | **Owner** | **Cadence** | |---|---|---|---| | 1 | Identify all SOX-relevant systems hosted by external providers (IaaS, PaaS, SaaS) — sourced from SOX-Relevant System Register (Section 3) | SOX ITGC Lead | Quarterly + on new system onboarding | | 2 | Request SOC 1 Type II report from each provider (covering the most recent audit period) | SOX ITGC Lead | Within 30 days of provider's report issuance OR 90 days before external auditor testing | | 3 | Verify report covers the correct period (must overlap with CERG's SOX year) | SOX ITGC Lead | On receipt | | 4 | Confirm report is from a licensed CPA firm and includes the service auditor's opinion | SOX ITGC Lead | On receipt | | 5 | Archive report in the evidence library under `/frameworks/sox-itgc/soc1-reports///` | Evidence Librarian | On receipt | | 6 | Register report status in SOX-Relevant System Register Section 3 (SOC 1 Available field) | SOX ITGC Lead | On receipt | > **SOC 1 Type II vs. Type I** > > CERG accepts SOC 1 Type II (tested over a period) as the primary reuse evidence. SOC 1 Type I (point-in-time design only) is accepted as interim evidence only when a Type II is not yet available, and must be supplemented with customer-side testing of the operating effectiveness of CUECs. ### 6.2 CUEC Inventory Complementary User Entity Controls (CUECs) are controls the customer (CERG's organization) must operate for the SOC 1 controls to be effective. Missing CUECs create control gaps. | **Step** | **Action** | **Owner** | |---|---|---| | 1 | Extract CUEC section from SOC 1 report (typically Section 4 or Appendix) | SOX ITGC Lead | | 2 | Map each CUEC control objective to a CERG control or CERG process | SOX ITGC Lead + relevant pillar owner | | 3 | Assess each CUEC: Is the control operating? Evidence on file? Cadence satisfied? | SOX ITGC Lead | | 4 | Document CUEC status in the CUEC Inventory table | SOX ITGC Lead | | 5 | Flag any CUEC not implemented or insufficiently evidenced | SOX ITGC Lead | | 6 | Escalate missing CUECs to Governance Pillar Leader within 10 business days | SOX ITGC Lead | #### CUEC Inventory Table | **CUEC Reference** | **Provider Control Objective** | **CUEC Description** | **CERG Control / Process** | **Operating?** | **Evidence Ref** | **Gap?** | |---|---|---|---|---|---|---| | SOC1-ACME-001 | Logical access to hosted application is authorised and reviewed quarterly | Customer must maintain access recertification process for application users | AX-03 (Section 4.1) — Quarterly access recertification | Yes | Q1-2026 recert report | No | | SOC1-ACME-002 | Segregation of duties enforced in financial application | Customer must maintain SOD matrix for financially-sensitive roles | AX-04 (Section 4.1) — SOD review | Partially | SOD matrix exists; quarterly review not yet started | Yes — quarterly cadence not established | ### 6.3 Gap Analysis vs. CB-001 Controls For each SOC 1 control objective that overlaps with a CB-001 control, the gap analysis determines whether CERG's control is sufficient to cover the provider's control objective, or whether a gap exists. | **Gap Category** | **Definition** | **Action** | |---|---|---| | Full Coverage | CERG control fully satisfies the SOC 1 control objective and CUEC | No action; document reuse mapping | | Partial Coverage | CERG control covers the objective but with scope or cadence differences | Document difference; assess materiality; if material, create compensating control or POA&M | | No Coverage | No CERG control maps to the SOC 1 control objective or CUEC | Create compensating control; if not feasible, record as deficiency per Section 6 (Deficiency Workflow) | | Provider-Exclusive | Control objective has no customer-side CUEC — provider handles entirely | Document as inherited; no CERG action required beyond evidence retention | The gap analysis is documented in the [CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) SOX crosswalk (§10.1) and in the SOC 1 evidence package (Section 6.5 below). ### 6.4 Compensating Controls Where a gap exists (Partial or No Coverage), compensating controls are designed and implemented. | **Gap** | **Compensating Control Example** | **Evidence** | **Owner** | **Timeline** | |---|---|---|---|---| | Provider SOC 1 does not cover change management for a hosted financial application | CERG performs quarterly application-level change review; verifies that provider change tickets are reviewed by CERG | Quarterly change review meeting minutes; provider change ticket log | SOX ITGC Lead | Implemented within 30 days of gap identification | | Provider CUEC requires quarterly MFA attestation; CERG currently does annual | Increase MFA attestation to quarterly for the affected user population | Quarterly IdP MFA policy audit report | Identity Engineer | 60 days | | Provider SOC 1 excludes a sub-service organisation | Obtain sub-service organisation SOC report or create customer-side monitoring | Sub-service SOC report OR quarterly manual control test | Vendor Risk Analyst | 90 days | ### 6.5 Evidence Package for External Auditor The SOC 1 Reuse Evidence Package is submitted to the external auditor at the start of SOX testing (interim phase). The package contains: | **Package Element** | **Source** | **Status** | |---|---|---| | Provider SOC 1 Type II report (current period) | Provider (Section 6.1) | Required | | CUEC Inventory (Section 6.2) | CERG | Required | | Gap Analysis (Section 6.3) | CERG | Required | | Compensating Control Documentation (Section 6.4) | CERG | Required if gaps exist | | CERG evidence for each CUEC | CERG evidence library per Section 4 | Required | | Provider sub-service organisation SOC (if applicable) | Provider / sub-service | Required if sub-service is material | | SOC 1 Reuse Summary Memo | CERG (SOX ITGC Lead) | Required | | Provider contract excerpt showing SLA and audit rights | Procurement / Legal | Recommended | #### SOC 1 Reuse Summary Memo A one-to-two-page memo accompanies the package explaining: - Which SOX-relevant systems use SOC 1 reuse - Which ITGC domains are covered by each SOC 1 (per §4 domain mapping) - CUEC status summary (count of implemented / partial / missing) - Gap analysis conclusion (material or immaterial gaps) - Compensating controls in place - Auditor coordination notes (any scope limitations in the SOC 1 report) - Next refresh date ### 6.6 Annual Refresh Cycle | **Activity** | **Cadence** | **Owner** | |---|---|---| | Request updated SOC 1 report from each provider | Within 30 days of provider's new report issuance | SOX ITGC Lead | | Update CUEC Inventory (re-map controls, update status) | Within 30 days of receiving new report | SOX ITGC Lead | | Perform gap analysis on new report vs. prior year | Within 30 days of receiving new report | SOX ITGC Lead | | Update compensating controls where gaps changed | Within 60 days of gap identification | Relevant pillar owner | | Refresh SOC 1 Reuse Evidence Package | Before interim SOX testing (typically Q2) | SOX ITGC Lead | | Submit evidence package to external auditor | Per SOX year timeline (Section 7) | SOX ITGC Lead | | Review provider scope changes (new sub-services, decommissioned systems, changed control objectives) | Upon receipt of new report | SOX ITGC Lead + Vendor Risk Analyst | | Escalate provider report qualifications or adverse opinions to CISO | Immediately on discovery | SOX ITGC Lead | ### 6.7 Roles and Responsibilities | **Role** | **SOC 1 Reuse Responsibility** | |---|---| | SOX ITGC Lead | Owns the end-to-end procedure: report acquisition, CUEC inventory, gap analysis, compensating controls, evidence package, annual refresh | | Evidence Librarian | Archives SOC 1 reports and evidence package in the evidence library | | Governance Pillar Leader | Accountable for the SOC 1 reuse program; approves compensating control decisions | | Vendor Risk Analyst | Coordinates provider report acquisition via TPRM process; sources sub-service organisation reports | | Relevant Pillar Owners (Engineering, Risk) | Implement compensating controls for gaps affecting their pillar | | CISO | Receives escalation for material gaps, qualified opinions, or residual risk acceptance | --- ## 7. Deficiency Workflow | **Step** | **Detail** | |---|---| | Identification | Deficiency identified via control test failure, internal audit, external audit, or self-assessment. | | Categorization | Deficiency / Significant Deficiency / Material Weakness - per the auditor's framework. CERG provides facts; auditor categorizes. | | Root cause analysis | CERG performs RCA; identifies whether issue is design vs. operating. | | Remediation plan | Owner, milestones, target date; recorded in risk register and in this register. | | Compensating control | If applicable, named and evidenced. | | Retest | At completion of remediation, retest performed; result documented. | | Disclosure | Significant Deficiencies and Material Weaknesses follow the organization's disclosure committee process; CERG provides factual content. | --- ## 8. Auditor Interface | **Activity** | **CERG Action** | |---|---| | Scoping meeting with external auditor | Provide SOX-Relevant System Register; reconcile in/out of scope; confirm test approach per Section 4. | | SOC 1 reuse for hosted financial systems | Where the financial SaaS or hosting provider has a SOC 1, complementary user-entity control (CUEC) review is conducted; CERG provides the customer-side evidence required. | | Internal Audit walkthroughs | CERG participates with system owner; provides evidence references. | | External Auditor testing | CERG provides evidence per the library; supports walkthroughs with system owners. | | Findings response | Per Section 7. | | Year-end attestations | CERG produces a summary of control posture by ITGC domain for inclusion in management's assessment. | --- ## 9. Operating Cadence | **Activity** | **Cadence** | |---|---| | SOX-Relevant System Register reconciliation | Quarterly + on material system change | | ITGC control test execution | Quarterly (cumulative; full year by close) | | SOD matrix review | Quarterly | | Internal walkthroughs | Once per period (typically interim Q2 + final Q4) | | External auditor testing | Per SOX year plan (typically interim + roll-forward) | | Deficiency review | Continuous; aggregated quarterly | | Management assessment | Annual at SOX year-end | | Operating model review (with Internal Audit and Finance) | Annual | --- ## 10. Regulatory and Framework Alignment Summary | **Regulation / Framework** | **Where in This Package** | |---|---| | Sarbanes-Oxley Act §404 | Sections 2–8 | | COSO Internal Control - Integrated Framework | Cross-cutting | | COBIT 2019 (selected) | Section 4 | | [NIST 800-53r5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (mappings) | Section 4 reused control IDs | --- ## 11. Document Control | | | |---|---| | **Document ID** | CERG-PLN-SOX-001 | | **Version** | 1.22 | | **Approved By** | CISO | | **Next Review** | Annual / per SOX year | | **Change Log** | 1.0 - Initial publication. ITGC scoping, control library, system register, evidence reuse mapping, deficiency workflow, auditor interface. 1.22 - Added SOC 1 Reuse Procedure (§6) with report acquisition, CUEC inventory, gap analysis vs. CB-001, compensating controls, evidence package for external auditor, and annual refresh cycle. Renumbered §§7–10 accordingly. | --- ## AI INTAKE AND SANCTIONING TEMPLATE ### Use Case · Data Classification · Provider Terms · Human Oversight · Approval Decision --- | | | |---|---| | **Document ID** | CERG-TMPL-AI-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Supporting Documents** | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) · [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Review Cycle** | Annual / On material change to AI use, provider terms, or AI regulation | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 RA / SA / AC · OWASP Top 10 for LLM Applications · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where AI tools, AI-enabled SaaS, embedded AI, or built AI systems are proposed | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This template records the intake and sanctioning decision for a proposed AI use. It applies to consumed AI services, AI-enabled vendor features, embedded AI capabilities, and AI systems the organization builds or integrates. The completed template answers the operating question that CERG requires before AI use begins: what is the AI being used for, what data can enter it, what actions can it take, who reviews its output, what provider or model terms apply, and which CERG path governs the decision. > **Sanctioned AI Is a Governed Path, Not a Blanket Approval** > > Approval of an AI tool or feature is limited to the stated use case, data classification, user population, provider terms, and controls recorded here. Approval for Internal data is not approval for Confidential or Restricted data. Approval for summarization is not approval for autonomous action. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link related vendor assessments, architecture reviews, threat models, risk records, exceptions, and evidence to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. 7. If the request is approved, update the sanctioned AI tools list or AI system register as applicable. --- ## 3. Fill-In Template ### 3.1 Intake Summary | **Field** | **Value** | |---|---| | Intake ID | `[AI-INTAKE-YYYY-NNN]` | | Request Date | `[Date]` | | Requested Tool / Feature / System | `[Name]` | | AI Use Category | `[Consumed AI service / Embedded AI / Built AI]` | | Business Owner | `[Owner]` | | Technical Owner | `[Owner]` | | Requesting Team | `[Team]` | | Proposed Users | `[User population]` | | Proposed Use Case | `[Describe the intended use]` | | Existing Vendor / New Vendor / Internal Build | `[Existing vendor / New vendor / Internal build]` | | Target Go-Live or Use Date | `[Date]` | ### 3.2 Data Classification and Prompt Boundary | **Question** | **Response** | **Evidence / Notes** | |---|---|---| | What is the highest data classification that may enter prompts, uploads, context windows, fine-tuning, or retrieval stores? | `[Public / Internal / Confidential / Restricted]` | `[Data classification record]` | | Will personal data be processed? | `[Yes / No]` | `[Details]` | | Will CUI, FCI, BES Cyber System Information, SOX-relevant data, or other regulated data be processed? | `[Yes / No]` | `[Regulatory scope]` | | Will prompts or uploaded data be retained by a third party? | `[Yes / No / Unknown]` | `[Retention terms]` | | Will prompts, uploads, outputs, or feedback be used to train provider models? | `[Yes / No / Unknown]` | `[Provider assurance or contract term]` | | Is data egress monitored or restricted? | `[Yes / No]` | `[DLP, proxy, CASB, SSPM, or logging evidence]` | | Maximum classification approved for this request | `[Public / Internal / Confidential / Restricted / Not approved]` | `[Rationale]` | ### 3.3 Provider, Model, and Supply Chain | **Question** | **Response** | **Evidence / Notes** | |---|---|---| | Provider or model source | `[Provider / model / repository]` | `[Link or record]` | | Deployment or inference location | `[SaaS / organization cloud / on-premises / endpoint / other]` | `[Details]` | | Provider assessment required? | `[Yes / No]` | `[TPRM record or rationale]` | | Model provenance known and trusted? | `[Yes / No]` | `[Evidence]` | | Subprocessors or downstream services involved? | `[Yes / No]` | `[List or vendor evidence]` | | Contractual protections reviewed? | `[Yes / No]` | `[DPA, security addendum, no-training term, retention term]` | | Material change to existing vendor risk profile? | `[Yes / No]` | `[Reassessment trigger and record]` | ### 3.4 Agency, Access, and Human Oversight | **Question** | **Response** | **Evidence / Notes** | |---|---|---| | Can the AI system take action beyond producing text, code, analysis, or recommendations? | `[Yes / No]` | `[Actions]` | | What systems, APIs, plugins, tools, repositories, or data stores can the AI access? | `[List]` | `[Access design]` | | Are privileges least-privilege and time-bound? | `[Yes / No]` | `[Access control evidence]` | | Are high-consequence actions blocked or subject to human confirmation? | `[Yes / No / Not Applicable]` | `[Control description]` | | Who reviews AI output before reliance? | `[Role / team]` | `[Review process]` | | Is AI used for employment, safety, control system, financial, legal, or other consequential decisions? | `[Yes / No]` | `[Human-in-the-loop control]` | ### 3.5 Security Review Routing | **Routing Question** | **Decision** | **Linked Record** | |---|---|---| | Architecture review required under `CERG-PRC-AR-001`? | `[Yes / No]` | `[Review ID]` | | Threat model required under `CERG-PRC-TM-001`? | `[Yes / No]` | `[Threat model ID]` | | TPRM assessment required under `CERG-PRC-TPRM-001`? | `[Yes / No]` | `[Vendor assessment ID]` | | Secure SDLC gates required under `CERG-STD-SDL-001`? | `[Yes / No]` | `[Project / pipeline evidence]` | | Risk register entry required under `CERG-PRC-RM-001`? | `[Yes / No]` | `[Risk ID]` | | Exception required? | `[Yes / No]` | `[Exception ID]` | ### 3.6 Required Controls and Conditions | **Control / Condition** | **Owner** | **Due Date** | **Evidence** | |---|---|---|---| | `[Condition, such as no Confidential data until contract updated]` | `[Owner]` | `[Date]` | `[Evidence link]` | | `[Condition]` | `[Owner]` | `[Date]` | `[Evidence link]` | ### 3.7 Disposition | **Field** | **Value** | |---|---| | Disposition | `[Approved / Approved with conditions / Limited pilot / Blocked pending remediation / Rejected]` | | Approved Use Cases | `[Use cases]` | | Prohibited Use Cases | `[Use cases]` | | Approved User Population | `[Users / groups]` | | Maximum Approved Data Classification | `[Public / Internal / Confidential / Restricted]` | | Required Register Update | `[Sanctioned AI tools list / AI system register / Both / None]` | | Review Cadence | `[Quarterly / Semiannual / Annual / On material change]` | | Reassessment Triggers | `[Provider term change, new data class, new agency, regulatory change, incident, vendor feature change]` | | Decision Rationale | `[Rationale]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Business Owner | Owns the use case, business need, and operational consequence. | `[Name / Date]` | | Application Security Engineer | Confirms AI-specific technical risks, threat model needs, and secure development implications. | `[Name / Date]` | | Vendor Risk Analyst | Confirms third-party AI service or AI-enabled vendor feature assessment where applicable. | `[Name / Date]` | | Governance Pillar Leader | Approves sanctioned-use decision, maximum data classification, and governance reporting entry. | `[Name / Date]` | | CISO | Approves High or Critical residual risk, Restricted data use, or other material escalation. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by the disposition. Material changes to the use case, data classification, provider terms, model, agency, or regulatory scope require reassessment before expanded use. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-AI-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Review Cycle** | Annual; and on material change to AI use, provider terms, or AI regulation | | **Next Scheduled Review** | 2027-06-17 | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 RA / SA / AC · OWASP Top 10 for LLM Applications · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where AI tools, AI-enabled SaaS, embedded AI, or built AI systems are proposed | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-17 | Cyber Governance | Initial release. Establishes a fill-in AI intake and sanctioning template for proposed AI tools, AI-enabled vendor features, embedded AI capabilities, and built AI systems. | ### Review Triggers - Parent standard or related procedure change - Material change to provider terms, model behavior, training use, retention, or deployment location - New or changed AI regulation - Significant AI-related finding, incident, or audit issue - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Parent standard; defines AI use categories and AI-specific security requirements | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Governs what data may enter AI prompts, uploads, training, and retrieval context | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Routes AI applications and higher-risk AI uses through architecture review | | Threat Modeling Procedure | [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Defines AI-specific abuse cases for built and embedded AI systems | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Assesses third-party AI services and AI-enabled vendor features | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Records material AI risks, shadow AI patterns, and exceptions | --- ## AI SYSTEM AND MODEL REGISTER TEMPLATE ### Model Inventory · Data Sources · Agency Boundary · Integrations · Monitoring · Ownership --- | | | |---|---| | **Document ID** | CERG-TMPL-AI-003 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Application Security Engineer | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Supporting Documents** | [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) · [`CERG-TMPL-AI-002`](CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) · [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) · [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | | **Review Cycle** | Quarterly / On material change to model, data source, agency, integration, or deployment | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 CM / RA / SA / SI · OWASP Top 10 for LLM Applications · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | Built AI systems, embedded AI systems, AI agents, model-serving platforms, RAG systems, and AI-enabled integrations in CERG-managed environments | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Register Template](#3-fill-in-register-template) 4. [Review and Maintenance](#4-review-and-maintenance) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This template provides the inventory record for built and embedded AI systems, models, retrieval stores, agents, and AI-enabled integrations. It complements the sanctioned AI tools register by focusing on systems the organization builds, configures, integrates, or operates as part of a business process or product. The register documents model provenance, data sources, classification, access, agency boundary, integrations, human oversight, monitoring, and lifecycle status. It is the AI-specific extension of asset inventory, secure development, architecture review, and threat modeling. > **A Model Is a Component, Not Magic** > > CERG treats a model like any other material component: it has a source, version, owner, dependencies, access path, data boundary, and change history. AI-specific behavior matters, but it does not erase normal inventory, change, access, logging, and software assurance requirements. --- ## 2. Template Instructions 1. Maintain one current register for built and embedded AI systems and models. 2. Create or update an entry when an AI system is approved through [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md), enters architecture review, changes model/provider, adds a retrieval store, gains new agency, or expands data classification. 3. Record the model as an inventoried component and link the entry to the asset inventory, SBOM, architecture review, threat model, and change record where applicable. 4. Do not treat a third-party model API as invisible. If the system depends on it, record the provider, model family, approved version or version policy, and contractual or technical constraints. 5. Use `Not Applicable` only with an explanation. 6. Store completed register records in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Register Template ### 3.1 Register Metadata | **Field** | **Value** | |---|---| | Register Owner | `[Application Security Engineer / delegated owner]` | | Maintainer | `[Role or team]` | | Register Location | `[System of record / link]` | | Last Review Date | `[Date]` | | Next Review Date | `[Date]` | | Relationship to Asset Inventory | `[Asset inventory link / CMDB reference]` | ### 3.2 AI System Inventory | **Field** | **Value** | |---|---| | AI System ID | `[AI-SYS-YYYY-NNN]` | | System / Product Name | `[Name]` | | Business Owner | `[Owner]` | | Technical Owner | `[Owner]` | | AI Use Category | `[Built AI / Embedded AI / Agent / RAG / Model-serving platform / Other]` | | Business Process Supported | `[Process or product]` | | Production Status | `[Prototype / Pilot / Production / Suspended / Retired]` | | Criticality | `[Critical / High / Moderate / Low]` | | Highest Data Classification | `[Public / Internal / Confidential / Restricted]` | | Regulatory Scope | `[CUI / FCI / BES Cyber System Information / SOX / privacy / contractual / none]` | | Linked AI Intake | `[AI intake ID]` | | Linked Architecture Review | `[Architecture review ID]` | | Linked Threat Model | `[Threat model ID]` | | Linked Asset / CMDB Record | `[Record ID]` | ### 3.3 Model and Provider Record | **Field** | **Value** | |---|---| | Model Name / Family | `[Model]` | | Model Provider / Source | `[Provider, repository, internal team]` | | Model Version or Version Policy | `[Pinned version / provider-managed / internal release]` | | Model Type | `[LLM / classifier / recommender / computer vision / forecasting / other]` | | Deployment Location | `[SaaS API / organization cloud / on-premises / endpoint / embedded vendor platform]` | | Model Provenance Evidence | `[Source validation, attestation, repository, contract, vendor assessment]` | | Fine-Tuned? | `[Yes / No]` | | Fine-Tuning Owner | `[Owner or Not Applicable with reason]` | | Training / Fine-Tuning Data Classification | `[Public / Internal / Confidential / Restricted / Not Applicable with reason]` | | Provider Training Use Allowed? | `[Yes / No / Not Applicable with reason]` | | Retention Position | `[Retention period, deletion capability, or Not Applicable with reason]` | ### 3.4 Data Sources and Retrieval Stores | **Data Source / Store** | **Purpose** | **Classification** | **Owner** | **Trust Level** | **Update Cadence** | **Access Control** | **Evidence** | |---|---|---|---|---|---|---|---| | `[Prompt input / RAG corpus / vector store / database / file share / telemetry source]` | `[Purpose]` | `[Public / Internal / Confidential / Restricted]` | `[Owner]` | `[Trusted / semi-trusted / untrusted]` | `[Cadence]` | `[Control]` | `[Link]` | ### 3.5 Agency, Tools, and Integrations | **Field** | **Value** | |---|---| | Can the AI invoke tools, plugins, APIs, scripts, workflows, or transactions? | `[Yes / No]` | | Tool / Integration List | `[List systems and actions]` | | Maximum Action Authority | `[Read-only / draft-only / recommend / execute low-risk action / execute high-risk action with approval]` | | Human Approval Required For | `[Actions requiring confirmation]` | | Privilege Boundary | `[Service account, role, scope, time limits]` | | Secrets Handling | `[Secret store, no secret access, or other control]` | | Production Change Capability | `[None / proposes changes / executes with approval / executes autonomously]` | | External Communication Capability | `[None / drafts messages / sends with approval / sends autonomously]` | | Kill Switch / Disable Path | `[How to disable model, agent, connector, or feature]` | ### 3.6 Security Controls and Monitoring | **Control Area** | **Required Record** | **Evidence / Link** | |---|---|---| | Architecture review | `[Completed / Not required with rationale]` | `[Link]` | | AI threat model | `[Completed / Not required with rationale]` | `[Link]` | | Secure development gates | `[SAST / DAST / SCA / code review / pipeline evidence]` | `[Link]` | | Prompt injection controls | `[Instruction/data separation, allowlists, output constraints, other]` | `[Link]` | | Output handling controls | `[Validation, encoding, human review, downstream guardrails]` | `[Link]` | | Data loss prevention | `[DLP, logging, masking, access restriction]` | `[Link]` | | Logging and monitoring | `[Prompts, outputs, actions, admin events, errors, abuse signals]` | `[Link]` | | Abuse and anomaly detection | `[Detection logic or monitoring process]` | `[Link]` | | Red-team / adversarial test | `[Completed / scheduled / not required with rationale]` | `[Link]` | | Incident response handoff | `[Playbook or escalation path]` | `[Link]` | ### 3.7 Change and Review Log | **Date** | **Change / Review Trigger** | **Changed By** | **Risk Impact** | **Required Follow-Up** | **Linked Record** | |---|---|---|---|---|---| | `[Date]` | `[Model change / data source added / agency expanded / provider change / quarterly review]` | `[Name / role]` | `[None / Low / Medium / High / Critical]` | `[Action]` | `[Change, risk, review, or evidence link]` | ### 3.8 Disposition | **Field** | **Value** | |---|---| | Current Disposition | `[Approved / Approved with conditions / Pilot / Blocked pending remediation / Suspended / Retired]` | | Conditions of Use | `[Conditions]` | | Maximum Approved Data Classification | `[Public / Internal / Confidential / Restricted]` | | Consequential Decision Use Approved? | `[Yes / No / Not Applicable with reason]` | | Review Cadence | `[Quarterly / Semiannual / Annual / On material change]` | | Next Review Date | `[Date]` | | Retirement / Rollback Plan | `[Plan or Not Applicable with reason]` | --- ## 4. Review and Maintenance | **Role** | **Responsibility** | |---|---| | Application Security Engineer | Owns register content for built and embedded AI systems; confirms model, software, threat model, and AI-specific security controls. | | Engineering Pillar Leader | Accountable for architecture review, secure build, and technical disposition of AI systems. | | Business Owner | Owns business use, consequence, human oversight, and operational acceptance. | | Governance Pillar Leader | Confirms conformance to approved AI use, evidence expectations, and reporting needs. | | Vendor Risk Analyst | Confirms provider, model, or vendor-feature assessment where third-party AI services are used. | | Detection Engineer | Confirms monitoring and detection requirements where AI-system behavior or tool use must be observed. | | Risk Register Owner | Links material findings, residual risk, exceptions, and acceptance decisions to the risk register. | A register entry must be reviewed when any of the following occur: - Model family, model version policy, provider, deployment location, or serving platform changes. - A new data source, retrieval corpus, vector store, plugin, connector, or downstream action is added. - The system gains new agency, privilege, autonomous action, or external communication capability. - The system begins processing Confidential or Restricted data or enters regulated scope. - A threat model, architecture review, test, incident, vendor reassessment, or audit produces a material finding. - The CISO, Engineering Pillar Leader, Risk Pillar Leader, or Governance Pillar Leader directs review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-AI-003 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Application Security Engineer | | **Approved By** | CISO | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Review Cycle** | Quarterly; and on material change to model, data source, agency, integration, or deployment | | **Next Scheduled Review** | 2026-09-17 | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 CM / RA / SA / SI · OWASP Top 10 for LLM Applications · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | Built AI systems, embedded AI systems, AI agents, model-serving platforms, RAG systems, and AI-enabled integrations in CERG-managed environments | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-17 | Cyber Engineering | Initial release. Establishes the AI system and model register template for built and embedded AI systems, including model provenance, data sources, agency boundary, integrations, monitoring, and lifecycle review. | ### Review Triggers - Parent standard or related procedure change - Material change to model, provider, data source, retrieval store, agency, integration, deployment location, or regulated scope - Significant AI-related finding, incident, or audit issue - New or changed AI regulation - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Parent standard; requires models to be inventoried components | | AI Intake and Sanctioning Template | [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | Intake and approval source for AI system entries | | Sanctioned AI Tools Register Template | [`CERG-TMPL-AI-002`](CERG-TMPL-AI-002_Sanctioned_AI_Tools_Register_Template.md) | Companion register for consumed AI tools and AI-enabled vendor features | | Secure Software Development and Application Security Standard | [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) | Governs built AI systems as software | | Asset Management and Inventory Standard | [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) | Governs models as inventoried components | | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Governs review of AI systems and integrations | | Threat Modeling Procedure | [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Defines AI-specific threat model categories | | Logging, Monitoring, and Detection Standard | [`CERG-STD-LM-001`](../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) | Governs monitoring of sensitive AI interactions and anomalous AI-system behavior | --- ## ARCHITECTURE AND PROJECT INTAKE FORM ### Project Intake · Data Scope · Threat Modeling Trigger · Review Routing --- | | | |---|---| | **Document ID** | CERG-TMPL-AR-001 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Document** | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - Architecture Review and Project Intake Procedure | | **Supporting Documents** | [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) · [`CERG-STD-SDL-001`](../standards/CERG-STD-SDL-001_Secure_Software_Development_and_Application_Security_Standard.md) · [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 SA, RA, AC, SC | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This form is the front-door intake artifact for the architecture review procedure. It captures enough information to route a project to the correct CERG review path, trigger threat modeling when needed, and identify data, vendor, regulatory, and deployment scope early. This template does **not** replace the full architecture review record, threat model, pre-production security review, production handoff package, or go-live risk acceptance packet defined in [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) §§6-9. A completed intake form opens and routes the engagement; later procedure records close it. > **The Intake Form Is the Front Door** > > Projects should not discover security requirements at the end. Intake is where ownership, data, architecture, vendors, identity, logging, and deployment risk become visible early enough to matter. Approval of this intake confirms routing, not production readiness or risk acceptance. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md). 5. Use the completed form to record scope determination, review path, and required follow-on artifacts. 6. Do not use the completed form as evidence of architecture approval, pre-production readiness, go-live authorization, or risk acceptance. 7. Link later risks, findings, exceptions, evidence, and approvals to the system of record. 8. Store the completed artifact in the evidence library governed by [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md). --- ## 3. Fill-In Template ### 3.1 Project Summary | **Field** | **Value** | |---|---| | Intake ID | `[AR-YYYY-NNN]` | | Project Name | `[Name]` | | Request Date | `[Date]` | | Business Owner | `[Owner]` | | Technical Owner | `[Owner]` | | Target Go-Live | `[Date]` | | Project Type | `[New system / major change / SaaS / cloud / integration / AI / OT / other]` | | Environment | `[Production / non-production / hybrid]` | ### 3.2 Scope and Data | **Question** | **Answer** | |---|---| | What business process does this support? | `[Answer]` | | What data classifications are involved? | `[Public / Internal / Confidential / Restricted / CUI]` | | Is personal data involved? | `[Yes / No / Unknown]` | | Is CUI involved? | `[Yes / No / Unknown]` | | Is SOX, NERC-CIP, or contractual scope involved? | `[Scope]` | | Are vendors or subprocessors involved? | `[Yes / No / Unknown]` | ### 3.3 Architecture and Control Triggers | **Trigger** | **Yes / No / Unknown** | **Notes** | |---|---|---| | New internet-facing service | `[ ]` | `[Notes]` | | New privileged access path | `[ ]` | `[Notes]` | | New API or integration | `[ ]` | `[Notes]` | | New cloud account, subscription, or tenant | `[ ]` | `[Notes]` | | AI or automated decisioning | `[ ]` | `[Notes]` | | OT, ICS, or safety impact | `[ ]` | `[Notes]` | | New third party | `[ ]` | `[Notes]` | | Threat model required | `[ ]` | `[Reason]` | ### 3.4 Review Routing | **Review Area** | **Owner** | **Required** | **Outcome** | |---|---|---|---| | Architecture review | Engineering Pillar Leader | `[Yes / No]` | `[Outcome]` | | Threat modeling | Application Security Engineer | `[Yes / No]` | `[Outcome]` | | Vendor review | Vendor Risk Analyst | `[Yes / No]` | `[Outcome]` | | Data governance | Governance Pillar Leader | `[Yes / No]` | `[Outcome]` | | Risk review | Risk Pillar Leader | `[Yes / No]` | `[Outcome]` | ### 3.5 Intake Disposition and Follow-On Records | **Disposition Field** | **Value** | |---|---| | Review Path | `[Mandatory / Lightweight / Out of Scope]` | | SLC Tier | `[Tier 1 / Tier 2 / Tier 3 / N/A]` | | Phase 2 Architecture Review Record Required | `[Yes / No; link when created]` | | Threat Model Required | `[Yes / No; link when created]` | | Phase 4 Pre-Production Security Review Required | `[Yes / No; link when created]` | | Production Handoff Package Required | `[Yes / No; link when created]` | | Risk Acceptance Packet Required | `[Yes / No; link when created]` | | Intake Decision Rationale | `[Brief rationale for review path and required follow-on records]` | ### 3.6 Business Decision Box | **Decision Question** | **Business Owner / System Sponsor Response** | |---|---| | What business outcome justifies this project or change? | `[Outcome and priority]` | | What decision is needed from CERG now? | `[Route only / architecture review / go-live support / risk acceptance / other]` | | What date is the business asking CERG to support? | `[Target date and driver]` | | What happens if CERG identifies blocking findings? | `[Delay / reduce scope / fund remediation / request risk acceptance]` | | Who can approve scope, funding, schedule, or residual-risk decisions? | `[Named role(s)]` | | What is the business consequence if the project does not proceed? | `[Consequence]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Engineering Pillar Leader | Confirms routing and architecture review decision. | `[Name / Date]` | | Risk Pillar Leader | Confirms risk treatment path where needed. | `[Name / Date]` | | Governance Pillar Leader | Confirms regulated-scope and evidence requirements. | `[Name / Date]` | Reviewer signatures on this form confirm intake routing and required follow-on records only. Production readiness, go-live authorization, and risk acceptance are documented through the Phase 4 and Phase 5 records governed by [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md). Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-AR-001 | | **Version** | 1.2 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - Architecture Review and Project Intake Procedure | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST CSF 2.0 · NIST 800-53r5 SA, RA, AC, SC | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-18 | Engineering Pillar Leader | Added business-facing decision box for project outcome, requested CERG decision, blocking-finding options, and sponsor authority. | | 1.1 | 2026-06-18 | Engineering Pillar Leader | Clarified that TMPL-AR-001 is the front-door intake artifact and added follow-on record routing fields. | | 1.0 | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for architecture and project intake form. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Architecture Review and Project Intake Procedure | [`CERG-PRC-AR-001`](../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) | Governing procedure | | Threat Modeling Procedure | [`CERG-PRC-TM-001`](../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) | Threat modeling trigger path | | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Evidence library storage and evidence request handling | --- ## BOARD AND CISO REPORTING DECK TEMPLATE ### Executive Narrative · Risk Posture · Metrics · Decisions · Action Tracking --- | | | |---|---| | **Document ID** | CERG-TMPL-MTR-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Document** | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) - Metrics Dashboard and Reporting | | **Supporting Documents** | [`CERG-GOV-MAT-001`](../governance/CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST CSF 2.0 GOVERN · NIST 800-55 · ISO/IEC 27001 Clause 9 | | **Regulations** | Cross-cutting; board, executive, audit, and customer assurance reporting | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This template structures recurring CISO and board reporting. It converts control and risk data into an executive narrative: what changed, what matters, what decisions are needed, and whether the program is improving. > **Executives Need Decisions, Not Dashboard Exhaust** > > A board deck is not a dump of every metric the program can produce. It should show risk movement, material decisions, exceptions, investments, incidents, readiness gaps, and whether leadership action is needed. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link risks, findings, exceptions, evidence, and approvals to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Template ### 3.1 Deck Outline | **Slide** | **Title** | **Purpose** | |---|---|---| | 1 | Executive Summary | One-page answer: better, worse, or stable, and why. | | 2 | Material Risk Changes | High and Critical risks added, closed, accepted, or escalated. | | 3 | Scenario Defense Posture | For each named crown-jewel loss scenario (`CERG-GOV-CJ-001`), red/amber/green on whether the kill chain is fully broken (sourced from RM-007). Top-down companion to the bottom-up top risks. | | 4 | Control Posture | Maturity, control gaps, and major remediation themes. | | 5 | Incident and Resilience Update | Material incidents, exercises, recovery gaps, and lessons. | | 6 | Regulatory and Audit Readiness | SOX, CMMC, CIP, ISO, privacy, customer assurance. | | 7 | Third-Party and Supply Chain Risk | Critical vendors, open findings, concentration risk. | | 8 | Metrics Dashboard | Small set of trend metrics from `CERG-GOV-MTR-001`. | | 9 | Decisions Needed | Risk acceptances, funding, staffing, scope, policy decisions. | | 10 | Action Tracker | Open executive actions and due dates. | ### 3.2 Executive Summary Slide | **Question** | **Answer** | |---|---| | Overall posture | `[Improving / stable / worsening]` | | Top change since last report | `[Change]` | | Most important risk | `[Risk]` | | Decision needed | `[Decision]` | | CISO recommendation | `[Recommendation]` | ### 3.3 Decision Log | **Decision Needed** | **Recommendation** | **Owner** | **Due Date** | **Consequence of Delay** | |---|---|---|---|---| | `[Decision]` | `[Recommendation]` | `[Owner]` | `[Date]` | `[Consequence]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Governance Pillar Leader | Confirms report completeness and narrative quality. | `[Name / Date]` | | Risk Pillar Leader | Confirms risk posture and risk acceptance content. | `[Name / Date]` | | Engineering Pillar Leader | Confirms technical control and resilience content. | `[Name / Date]` | | Chief Information Security Officer (CISO) | Approves final executive message. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-MTR-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) - Metrics Dashboard and Reporting | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST CSF 2.0 GOVERN · NIST 800-55 · ISO/IEC 27001 Clause 9 | | **Regulations** | Cross-cutting; board, executive, audit, and customer assurance reporting | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for board and ciso reporting deck template. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Metrics Dashboard and Reporting | [`CERG-GOV-MTR-001`](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | Governing metric source | | Maturity Self-Assessment and Scorecard | [`CERG-GOV-MAT-001`](../governance/CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) | Maturity reporting input | --- ## CONTROL EVIDENCE AND TEST WORKSHEET ### Control Objective · Sample · Test Steps · Evidence Quality · Result --- | | | |---|---| | **Document ID** | CERG-TMPL-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Evidence Librarian | | **Parent Document** | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) - Audit and Evidence Management Procedure | | **Supporting Documents** | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-GOV-CMX-001`](../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) · [`CERG-PLN-ISO-001`](../plans/CERG-PLN-ISO-001_ISO_IEC_27001_Operational_Package.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST 800-53r5 CA · ISO/IEC 27001 Clause 9 · SOX ITGC | | **Regulations** | SOX ITGC; CMMC; NERC-CIP; ISO; audit and customer assurance | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This worksheet standardizes control testing and evidence review. It records the control objective, test method, population, sample, evidence examined, result, exceptions, and remediation linkage so audit work is repeatable and defensible. > **Evidence Must Prove the Control, Not Decorate the File** > > A screenshot is useful only if it proves the control objective for the right scope and period. Evidence that cannot be tied to the control, sample, date, and result is not audit-ready evidence. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link risks, findings, exceptions, evidence, and approvals to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Template ### 3.1 Control Test Header | **Field** | **Value** | |---|---| | Test ID | `[TEST-YYYY-NNN]` | | Control ID | `[CERG / framework control ID]` | | Control Objective | `[Objective]` | | Framework Mapping | `[SOX / ISO / CMMC / CIP / NIST]` | | Test Period | `[Period]` | | Tester | `[Name / role]` | | Control Owner | `[Canonical role]` | ### 3.2 Population and Sample | **Field** | **Value** | |---|---| | Population Source | `[Report / system / ticket queue]` | | Population Size | `[Number]` | | Sampling Method | `[Full population / judgmental / random / risk-based]` | | Sample Size | `[Number]` | | Sample Items | `[IDs]` | ### 3.3 Test Steps and Results | **Step** | **Procedure** | **Evidence Reviewed** | **Result** | **Notes** | |---|---|---|---|---| | `1` | `[Test step]` | `[Evidence]` | `[Pass / Fail / Exception]` | `[Notes]` | ### 3.4 Exceptions and Remediation | **Exception ID** | **Description** | **Severity** | **Owner** | **POA&M / Risk Link** | |---|---|---|---|---| | `[EXC-001]` | `[Exception]` | `[Severity]` | `[Owner]` | `[Link]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Evidence Librarian | Confirms evidence is stored, complete, and indexed. | `[Name / Date]` | | Governance Pillar Leader | Confirms test is sufficient for audit or assessment use. | `[Name / Date]` | | Control Owner | Confirms factual accuracy and remediation ownership. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-AUD-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Evidence Librarian | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) - Audit and Evidence Management Procedure | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-53r5 CA · ISO/IEC 27001 Clause 9 · SOX ITGC | | **Regulations** | SOX ITGC; CMMC; NERC-CIP; ISO; audit and customer assurance | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for control evidence and test worksheet. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Audit and Evidence Management Procedure | [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | Governing audit and evidence workflow | | Unified Control Baseline | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Control source | --- ## PLAN OF ACTION AND MILESTONES TEMPLATE ### POA&M Register · Milestones · Ownership · Validation · Closure Evidence --- | | | |---|---| | **Document ID** | CERG-TMPL-CUI-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Parent Plan** | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - CUI / CMMC Operational Package | | **Supporting Documents** | [`CERG-TMPL-CUI-001`](CERG-TMPL-CUI-001_System_Security_Plan_Template.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-PRC-AUD-001`](../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) | | **Review Cycle** | Monthly while open / Annual template review | | **Frameworks** | NIST 800-171r3 · NIST 800-172 · CMMC L2 · NIST 800-53r5 CA | | **Regulations** | Controlled Unclassified Information / CMMC contractual obligations | | **Environments** | Systems and programs with open security gaps, assessment findings, or planned control implementations | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [POA&M Discipline](#2-poam-discipline) 3. [POA&M Register Template](#3-poam-register-template) 4. [Milestone Detail Template](#4-milestone-detail-template) 5. [Evidence and Validation](#5-evidence-and-validation) 6. [Closure Criteria](#6-closure-criteria) 7. [Review Cadence](#7-review-cadence) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Use This template creates a Plan of Action and Milestones (POA&M) for security gaps, CMMC / CUI findings, assessment observations, audit findings, and planned control implementations. It is designed to be copied into a system-specific or program-specific POA&M register. A POA&M item is not a wish list entry. It is a dated management commitment with an owner, milestones, evidence expectations, and closure validation. > **No Owner, No Date, No POA&M** > > A row without an accountable owner and target date is not a plan. It is a note. The POA&M exists so leadership can see what remains open, who owns it, when it will be fixed, what risk exists while it remains open, and what evidence proves closure. --- ## 2. POA&M Discipline Use this template when one of the following conditions exists: - a control is partially implemented or planned; - an SSP control statement identifies a gap; - an audit or assessment produces a finding; - a risk treatment plan requires implementation work; - a vulnerability or configuration issue requires coordinated remediation; - a vendor, system, or business owner commits to corrective action. Each POA&M item must link to at least one source: control ID, risk ID, finding ID, assessment ID, vulnerability ID, or SSP section. --- ## 3. POA&M Register Template | **Field** | **Required** | **Instructions** | |---|---|---| | POA&M ID | Yes | Use `POAM-YYYY-NNN`. | | Source | Yes | SSP, audit, assessment, risk, vulnerability, incident, vendor, or self-identified. | | Source ID | Yes | Finding ID, control ID, risk ID, CVE, ticket, or assessment reference. | | Affected System / Asset | Yes | Asset ID or system name. | | Control ID | Yes | NIST, CMMC, CERG, or framework control. | | Gap Statement | Yes | Plain-language description of what is missing. | | Risk Summary | Yes | Business and security consequence while open. | | Owner | Yes | Canonical CERG role or named business owner. | | Supporting Roles | No | Roles needed to complete the work. | | Treatment Approach | Yes | Mitigate, transfer, avoid, accept, or document not applicable. | | Milestones | Yes | Milestone IDs or summary. | | Target Completion Date | Yes | Date. | | Current Status | Yes | Not Started, In Progress, Blocked, Validation, Closed, Cancelled. | | Residual Risk ID | Conditional | Required for High/Critical risk or missed target dates. | | Exception ID | Conditional | Required when a control gap is accepted temporarily. | | Closure Evidence | Yes at closure | Evidence location. | | Closure Validator | Yes at closure | Role validating closure. | | Closure Date | Yes at closure | Date closed. | ### 3.1 POA&M Register Rows | **POA&M ID** | **Source** | **Source ID** | **System / Asset** | **Control ID** | **Gap Statement** | **Owner** | **Target Date** | **Status** | **Risk / Exception Link** | |---|---|---|---|---|---|---|---|---|---| | `[POAM-YYYY-NNN]` | `[Source]` | `[ID]` | `[System]` | `[Control]` | `[Gap]` | `[Owner]` | `[Date]` | `[Status]` | `[Risk ID / Exception ID / None]` | --- ## 4. Milestone Detail Template Every POA&M item has at least one milestone. Complex items should use multiple milestones so progress can be verified before the final due date. | **Milestone ID** | **POA&M ID** | **Description** | **Owner** | **Due Date** | **Status** | **Evidence Expected** | |---|---|---|---|---|---|---| | `[M-001]` | `[POAM-YYYY-NNN]` | `[Milestone]` | `[Owner]` | `[Date]` | `[Status]` | `[Evidence]` | Milestones must describe completion outcomes, not activity. "Deploy MFA to admin group" is valid. "Work on MFA" is not. --- ## 5. Evidence and Validation Closure evidence must prove the gap is fixed or the risk treatment is complete. | **Evidence Type** | **Examples** | |---|---| | Configuration evidence | Screenshot, export, policy file, baseline record. | | Control test evidence | Test worksheet, command output, sampled records. | | Process evidence | Approved procedure, ticket history, review minutes. | | Technical validation | Scan result, restore test, access review result, pipeline check. | | Approval evidence | Risk acceptance, exception approval, CISO decision. | Evidence is stored according to `CERG-PRC-AUD-001` and linked from the POA&M row. --- ## 6. Closure Criteria A POA&M item can close only when all closure criteria are met: 1. required milestones are complete; 2. control implementation or risk treatment is validated; 3. evidence is stored and linked; 4. related SSP, risk register, or control documentation is updated; 5. closure validator signs off; 6. residual risk is accepted or below the treatment threshold. If a due date is missed, the item is not silently re-dated. The owner records the reason, updates the target date, and determines whether the delay creates or changes residual risk. --- ## 7. Review Cadence Open POA&M items are reviewed monthly. High or Critical items are reviewed at the cadence set by the CISO or Risk Pillar Leader. Closed items are sampled during audits and assessments to confirm closure evidence remains available. POA&M review outputs: - overdue item list; - blocked item list; - High/Critical residual-risk list; - items requiring CISO escalation; - items ready for validation; - closed items with evidence exceptions. --- ## 8. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-CUI-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Approved By** | CISO | | **Parent Plan** | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - CUI / CMMC Operational Package | | **Review Cycle** | Monthly while open; annual template review | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-171r3; NIST 800-172; CMMC L2; NIST 800-53r5 CA | | **Regulations** | Controlled Unclassified Information / CMMC contractual obligations | | **Environments** | Systems and programs with open security gaps, assessment findings, or planned control implementations | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes a fill-in POA&M register, milestone detail template, evidence expectations, closure criteria, and review cadence. | ### Review Triggers - CMMC or CUI assessment cycle - Material POA&M process change - Repeated missed target dates - Audit finding related to remediation tracking - Direction from the CISO --- ## RISK ACCEPTANCE MEMO TEMPLATE ### Supporting Memo · Residual Risk · Business Rationale · Conditions · Expiration --- | | | |---|---| | **Document ID** | CERG-TMPL-RM-003 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Supporting Documents** | [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) · [`CERG-TMPL-RM-001`](CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) · [`CERG-TMPL-RM-004`](CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST 800-30r1 · NIST 800-39 · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This memo is a lightweight supporting artifact for a risk acceptance decision governed by [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 and submitted through [`CERG-TMPL-RM-004`](CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md). It may summarize rationale, conditions, and review triggers, but it does not create a separate acceptance path. The completed memo must attach to the Risk Acceptance Request Form, link to the risk register, and must not replace either artifact. > **Acceptance Is a Decision, Not an Absence of Action** > > Risk is not accepted because nobody fixed it. Risk is accepted only when the right authority understands the scenario, impact, residual exposure, conditions, expiration, and alternatives, then records the decision. The Business Owner accepts the business consequence; Security assesses and recommends but does not accept business risk. --- ## 2. Template Instructions 1. Use this memo only as an attachment or supporting decision narrative for [`CERG-TMPL-RM-004`](CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md). 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001` and approval authority from `CERG-GOV-RMF-001` §9.7. 5. Link risks, findings, exceptions, evidence, and approvals to the system of record. 6. Store the completed artifact with the completed Risk Acceptance Request Form and risk-register entry in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Template ### 3.1 Decision Summary | **Field** | **Value** | |---|---| | Memo ID | `[RA-YYYY-NNN]` | | Risk ID | `[Risk ID]` | | Risk Statement | `[Because of..., affecting..., there is a possibility that..., resulting in...]` | | Requesting Owner | `[Owner]` | | Business Owner / Risk Owner | `[Name and role accepting business consequence]` | | Affected Assets / Processes | `[Scope]` | | Regulatory Scope | `[CUI / SOX / CIP / privacy / none]` | | Residual Risk Rating | `[Low / Medium / High / Critical]` | | Acceptance Period | `[Start date to expiration date]` | ### 3.2 Business Rationale `[Explain why acceptance is appropriate compared with mitigation, transfer, or avoidance.]` ### 3.3 Conditions of Acceptance | **Condition** | **Owner** | **Evidence / Monitoring** | |---|---|---| | `[Condition]` | `[Owner]` | `[Evidence]` | ### 3.4 Alternatives Considered | **Alternative** | **Reason Not Selected** | |---|---| | `[Alternative]` | `[Reason]` | ### 3.5 Expiration and Review | **Field** | **Value** | |---|---| | Expiration Date | `[Date]` | | Review Cadence | `[Cadence]` | | Renewal Criteria | `[Criteria]` | | Trigger for Early Review | `[Trigger]` | --- ## 4. Review and Approval Approval authority follows [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7 and is recorded on [`CERG-TMPL-RM-004`](CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md). This memo is not valid unless the required `TMPL-RM-004` approvals are complete. | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Risk Register Owner | Confirms register entry, scoring, and linkage. | `[Name / Date]` | | Risk Pillar Leader | Confirms risk assessment methodology and recommendation. | `[Name / Date]` | | Business Owner | Accepts the business consequence of residual risk. Required for every Low, Medium, or High acceptance. | `[Name / Date]` | | Chief Information Security Officer (CISO) | Approves High and Critical acceptance where required by RMF-001 §9.7. | `[Name / Date]` | | Executive Sponsor | Accepts the business consequence for Critical risk where required by RMF-001 §9.7. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review through `TMPL-RM-004`. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-RM-003 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-30r1 · NIST 800-39 · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader | Recast this memo as a supporting attachment to TMPL-RM-004 and RMF-001 §9.7, added Business Owner / Executive Sponsor acceptance language, and removed standalone acceptance authority. | | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for risk acceptance memo template. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Governing risk acceptance lifecycle | | Risk Acceptance Request Form | [`CERG-TMPL-RM-004`](CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) | Required acceptance form; this memo may attach as support | | Risk Management Framework | [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) | Canonical scoring and acceptance authority (§9.5 and §9.7) | --- ## RISK ACCEPTANCE REQUEST FORM ### Business Owner Acceptance · Residual Risk · Per-RMF-001 Authority · Conditions · Expiration --- | | | |---|---| | **Document ID** | CERG-TMPL-RM-004 | | **Version** | 1.2 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Supporting Documents** | [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) · [`CERG-TMPL-RM-001`](CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) · [`CERG-TMPL-RM-002`](CERG-TMPL-RM-002_Security_Exception_Request_Form.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST 800-30r1 · NIST 800-39 · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This form records a formal **risk acceptance** decision under the authority framework defined in [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. It is used when leadership chooses to accept residual risk rather than mitigate, transfer, or avoid it. **This form is for risk acceptances only.** For deviations from policy or standards (where the control itself is not implemented as written), use the Security Exception Request Form [`CERG-TMPL-RM-002`](CERG-TMPL-RM-002_Security_Exception_Request_Form.md) — which follows the Governance-tracked exception register workflow. **Key distinction per RMF-001 §9.7a:** - **Policy Exception** (→ TMPL-RM-002): A specific control or standard cannot be met. Governance approves. Risk assesses. The exception lives in the exception register. - **Risk Acceptance** (→ this form): The residual risk after controls is within appetite. The **Business Owner** accepts the business consequence. Approval follows the RMF-001 §9.7 authority table. The acceptance lives in the risk register. > **Acceptance Is a Business Decision, Not a Security Decision** > > Security assesses, recommends, and validates. The Business Owner accepts the business consequence of residual risk. No one in Security accepts business risk on behalf of the organization. Every acceptance requires the Business Owner's documented signature at the authority level specified in RMF-001 §9.7. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link risks, findings, acceptances, evidence, and approvals to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. 7. The Business Owner must review and sign Section 4 before submission to CERG. --- ## 3. Fill-In Template ### 3.1 Decision Summary | **Field** | **Value** | |---|---| | Acceptance ID | `[RA-YYYY-NNN]` | | Risk ID | `[Risk ID from risk register]` | | Related Exception ID (if any) | `[EX-YYYY-NNN or N/A]` | | Risk Statement | `[Because of... affecting... there is a possibility that... resulting in...]` | | Requesting Owner | `[Name / Role]` | | Affected Systems / Assets | `[Asset IDs or system names]` | | Environment | `[IT / Cloud / SaaS / OT / Hybrid]` | | Regulatory Scope | `[CUI / SOX / CIP / Privacy / None]` | | Residual Risk Rating | `[Low / Medium / High / Critical]` | | Residual Risk Score | `[Likelihood × Impact]` | | Acceptance Period | `[Start date to expiration date]` | | Acceptance Type | `[Time-bound / Standing]` | ### 3.2 Business Decision Box | **Decision Question** | **Business Owner / Required Authority Response** | |---|---| | What residual business consequence is being accepted? | `[Plain-language consequence]` | | Why is acceptance preferable to immediate treatment? | `[Cost / schedule / operational / reliability / contractual rationale]` | | What funding or resourcing decision would retire this acceptance? | `[Decision, owner, estimate, and timing]` | | What conditions must remain true for this acceptance to stay valid? | `[Controls, monitoring, scope limits, review triggers]` | | What event would require immediate re-review or revocation? | `[Trigger]` | | Who owns treatment after acceptance? | `[Named business or technical owner]` | ### 3.3 Business Rationale `[Explain why acceptance is the appropriate treatment compared with mitigation, transfer, or avoidance. Address: cost-to-fix vs. residual risk, operational constraints, compensating control adequacy, and regulatory implications.]` ### 3.4 Alternatives Considered | **Alternative** | **Reason Not Selected** | |---|---| | `[Mitigation — implement full control]` | `[Reason]` | | `[Transfer — insurance or vendor]` | `[Reason]` | | `[Avoid — cease the activity]` | `[Reason]` | ### 3.5 Risk Assessment (Prepared by CERG Risk) | **Area** | **Assessment** | |---|---| | Inherent Risk (no controls) | `[Likelihood × Impact = Score]` | | Controls in Place | `[List of existing compensating controls]` | | Residual Risk (with controls) | `[Likelihood × Impact = Score]` | | Residual Rating | `[Low / Medium / High / Critical]` | | Threat or Weakness Created | `[Description]` | | Affected Data or Process | `[Scope]` | | Business Consequence if Unaddressed | `[Consequence]` | ### 3.6 Conditions of Acceptance | **Condition** | **Owner** | **Evidence / Monitoring** | **Review Cadence** | |---|---|---|---| | `[Condition]` | `[Owner]` | `[Evidence]` | `[Cadence]` | ### 3.7 Expiration and Review | **Field** | **Value** | |---|---| | Expiration Date | `[Date]` | | Review Cadence | `[Quarterly / Monthly / Per milestone]` | | Renewal Criteria | `[Conditions that must be met for renewal]` | | Trigger for Early Review | `[Control failure, threat intel change, regulatory change]` | --- ## 4. Review and Approval Approval authority follows [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) §9.7. An acceptance is not valid until all required signatures are recorded. | **Role** | **Review Meaning** | **Name** | **Date** | **Decision** | |---|---|---|---|---| | **Risk Register Owner** | Confirms risk register entry, scoring accuracy, and linkage completeness. | `[Name]` | `[Date]` | Verified / Returned | | **Risk Pillar Leader** | Confirms risk assessment methodology and residual score. Recommends disposition. | `[Name]` | `[Date]` | Concur / Returned | | **Engineering Pillar Leader** | Confirms compensating controls are in place and effective (if controls involve Engineering). | `[Name]` | `[Date]` | Concur / Returned | | **Governance Pillar Leader** | Confirms regulatory overlay completeness and documentation adequacy. | `[Name]` | `[Date]` | Concur / Returned | | **Business Owner** | Accepts the business consequence of the residual risk. | `[Name]` | `[Date]` | Accept / Decline | | **CISO** | Approves High and Critical acceptances per RMF-001 §9.7 authority. | `[Name]` | `[Date]` | Approve / Deny | | **Executive Sponsor** | Accepts the business consequence for Critical risk acceptance and/or board-notified items per RMF-001 §9.7. | `[Name]` | `[Date]` | Accept / Escalate to Board | **Approver Note:** Approvers may delegate within their authority but shall document the delegation. No acceptance expires automatically; every acceptance at every tier requires a fresh approval cycle at expiration. Renewal more than twice without material progress toward remediation escalates one approval tier above the original approver. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-RM-004 | | **Version** | 1.2 | | **Status** | Approved | | **Effective Date** | 2026-06-18 | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-06-18 | | **Frameworks** | NIST 800-30r1 · NIST 800-39 · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.2 | 2026-06-18 | Governance Pillar Leader | Added business-facing decision box for residual consequence, treatment funding, validity conditions, and re-review triggers. | | 1.1 | 2026-06-18 | Governance Pillar Leader | Aligned acceptance type and related-template wording with RMF-001 authority; clarified that TMPL-RM-003 is supporting only and that Executive Sponsor accepts Critical business consequence. | | 1.0 | 2026-06-18 | Governance Pillar Leader | Initial release. Establishes Risk Acceptance Request Form as the distinct workflow for risk acceptances (Business Owner + per-RMF-001 authority), separate from Security Exception Requests (TMPL-RM-002). | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Risk Register Templates and Reporting | [`CERG-TMPL-RM-001`](CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Register and reporting schema | | Security Exception Request Form | [`CERG-TMPL-RM-002`](CERG-TMPL-RM-002_Security_Exception_Request_Form.md) | Governance-tracked policy/standard exception workflow | | Risk Acceptance Memo Template | [`CERG-TMPL-RM-003`](CERG-TMPL-RM-003_Risk_Acceptance_Memo_Template.md) | Optional supporting memo; does not replace this form or RMF-001 approval authority | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Governing risk acceptance lifecycle | | Risk Management Framework | [`CERG-GOV-RMF-001`](../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) | Risk acceptance authority table (§9.7) | --- > **SURGE, Cyber Engineering, Risk & Governance** > > *Assess it. Accept it. Own it. Review it.* --- *CERG-TMPL-RM-004 · Version 1.2 · Public* --- ## RISK REGISTER TEMPLATES AND REPORTING ### Register Schema · Exception Request · Scoring Examples · CISO Slice-and-Dice Reporting --- | | | |---|---| | **Document ID** | CERG-TMPL-RM-001 | | **Version** | 1.23 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Risk Register) | | **Parent Procedure** | [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-GOV-MTR-001](../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) | | **Review Cycle** | Annual / On register tooling change | | **Frameworks** | [NIST 800-30r1](https://csrc.nist.gov/pubs/sp/800/30/r1/final) · [NIST 800-39](https://csrc.nist.gov/pubs/sp/800/39/final) · ISO 31000 | | **Regulations** | NERC-CIP · [CMMC L2](https://dodcio.defense.gov/CMMC/) · SOX ITGC | | **Environments** | All in-scope assets | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Risk Statement Standard](#2-risk-statement-standard) 3. [Risk Register Schema](#3-risk-register-schema) 4. [Worked Examples](#4-worked-examples) 5. [Exception Request Template](#5-exception-request-template) 6. [Risk Scoring Guide](#6-risk-scoring-guide) 7. [CISO Slice-and-Dice Reporting Views](#7-ciso-slice-and-dice-reporting-views) 8. [Document Control](#8-document-control) --- ## 1. Purpose and Scope [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) defines how risks and exceptions move through the program. This document is the executable package that makes that procedure operable: the register schema, the exception template, scoring examples, and the reporting views the CISO actually consumes. It is referenced from PRC-RM-001 and from [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) (control-to-evidence mapping). > **Why Bind Risk Statements to Controls** > > A risk that does not map to at least one control is either a controls gap to add to the baseline or an over-broad risk to refine. A control that does not map to at least one risk is a control that nobody can defend. The register is the place those two libraries reconcile. --- ## 2. Risk Statement Standard Every risk register entry has a single sentence, the **Risk Statement**, in this form: > Because of [**threat / weakness**], affecting [**asset / scope**], there is a possibility that [**adverse event**] occurs, resulting in [**business impact**]. The Risk Statement is derived from a control. The derivation pattern is: | **Control State** | **Implied Risk Statement Stem** | |---|---| | Implemented | "If the control fails or is bypassed…" | | Partially Implemented | "Because the control covers only [scope]…" | | Planned | "Until the control is implemented…" | | Risk Accepted | "While the exception is in force…" | | Inherited | "If the provider's control or our inheritance prerequisites fail…" | If a risk does not map to a control in [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md), one of three things happens: (1) the control is added to the baseline as a CERG-X control, (2) the risk is reframed against an existing control, or (3) the risk is rejected as out of scope. --- ## 3. Risk Register Schema The schema below is the system-of-record contract regardless of tool (Excel, ServiceNow, Archer, RSA, custom). | **Field** | **Type** | **Required** | **Description** | |---|---|---|---| | Risk ID | `R-YYYY-NNNN` | Yes | Sequential per calendar year. | | Risk Statement | Free text - Section 2 form | Yes | One sentence. | | Source | Enum: VM · Pen Test · Vendor · Architecture Review · Audit · Threat Intel · Self-Identified · Incident | Yes | What surfaced the risk. | | Linked Control(s) | List of [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) IDs | Yes | At least one. | | Control Evidence Link | URI / artifact reference | Yes | Evidence that the linked control state or compensating control is implemented and independently verifiable. | | Affected Asset(s) | Asset inventory ID(s) | Yes | From the authoritative asset inventory. | | Operating Unit | Enum (OU list) | Yes | Drives CISO slice-and-dice. | | Regulatory Scope | Multi-select: CUI · BES · SOX · None | Yes | Drives overlay scoring. | | Inherent Likelihood | 1–5 | Yes | Before controls. | | Inherent Impact | 1–5 | Yes | Before controls. | | Inherent Score | Likelihood × Impact | Auto | - | | Control Effectiveness | Enum: Strong · Adequate · Weak · None | Yes | Reduces residual score per Section 6. | | Residual Likelihood | 1–5 | Yes | After controls. | | Residual Impact | 1–5 | Yes | After controls. | | Residual Score | Likelihood × Impact | Auto | Drives approval authority per PRC-RM-001 §8. | | Treatment | Enum: Mitigate · Transfer · Avoid · Accept | Yes | - | | Treatment Plan | Free text | Yes | Specific actions, owners, dates. | | Residual Risk Owner / Business Owner | Named role | Yes | Asset/process/business owner accountable for the residual consequence; security may coordinate but does not own business risk. | | CERG Coordinator | Named role | Yes | Pillar contact - keeps it moving. | | Approver | Named role | Yes | Per PRC-RM-001 §8 and RMF-001 §9.7 authority. | | Decision Date | Date | If treatment is selected or changed | Date the treatment decision was recorded. | | Approval Date | Date | If accepted | Date required approval was recorded. | | Review Cadence | Quarterly · Semi-Annual · Annual | Yes | Driven by residual score. | | Last Validated Date | Date | Yes | Last date the risk score, control/evidence state, owner, and treatment status were validated against operational reality. | | Next Review Date | Date | Yes | Next required review date; must align to cadence and shortest applicable regulatory/procedure clock. | | Status | Open · In Treatment · Accepted · Closed · Retired | Yes | - | | Linked Exceptions | Exception ID(s) | If exception in force | - | | Linked Findings | VM finding ID · Pen test finding ID · Audit finding ID | Optional | - | | Linked POA&M | POA&M ID | If CUI scope | - | | Evidence Pointer | URI / artifact reference | Yes | Where the complete evidence package lives; may duplicate Control Evidence Link when one artifact proves both control state and risk treatment. | | Closure / Validation Evidence | URI / artifact reference | If closed, accepted, or score changed | Evidence proving closure, treatment validation, score change, or accepted-residual-risk conditions. | | Trend Indicator | Improving · Steady · Worsening | Yes (at review) | Set at each review. | | Free-Form Notes | Free text | Optional | - | ### 3.1 Computed Fields and Workflow States - **Residual Score** drives auto-routing to the approval queue per PRC-RM-001 §8. - **Review Cadence** is set by residual score: Critical/High = Quarterly, Medium = Semi-Annual, Low = Annual. - **Last Validated Date** is updated whenever the risk is reviewed, treatment status changes, control evidence is refreshed, closure is verified, or acceptance conditions are reapproved. - **Status** transitions: Open → In Treatment → (Closed | Accepted) → Retired. Retired risks are kept for audit history. --- ## 4. Worked Examples ### 4.1 Example A: Risk Derived From a Partially Implemented Control | Field | Value | |---|---| | Risk ID | R-2026-0048 | | Risk Statement | Because phishing-resistant MFA (IA-2) is not enforced on all legacy interactive logons, affecting the on-prem AD-joined Tier 2 application estate (≈ 180 systems), there is a possibility that credential phishing of a privileged user leads to lateral movement, resulting in operational outage and recovery cost. | | Source | Self-Identified | | Linked Control(s) | IA-2 | | Operating Unit | Generation Operations IT | | Regulatory Scope | SOX | | Inherent Likelihood / Impact | 4 / 4 → 16 | | Control Effectiveness | Weak (legacy auth permitted) | | Residual Likelihood / Impact | 4 / 3 → 12 (High) | | Treatment | Mitigate | | Treatment Plan | Q3: enforce phishing-resistant MFA on Tier 2 high-blast-radius admin paths. Q4: extend to remainder. Exceptions tracked. | | Risk Owner | Gen Ops IT Director | | Approver | CISO | | Review Cadence | Quarterly | ### 4.2 Example B: Risk Derived From a Risk-Accepted Exception | Field | Value | |---|---| | Risk ID | R-2026-0102 | | Risk Statement | While exception EX-2026-0017 is in force permitting an unmanaged legacy SCADA HMI to remain in service through 2027, affecting a single substation, there is a possibility that an unpatched RCE is exploited via the local engineering jump server, resulting in localized loss-of-view and breach of CIP-007 R2. | | Source | Architecture Review | | Linked Control(s) | CM-2 / CM-6 / SI-2 | | Regulatory Scope | BES | | Inherent Likelihood / Impact | 3 / 5 → 15 | | Control Effectiveness | Adequate (compensating: isolated jump, monitored, no internet egress) | | Residual Likelihood / Impact | 2 / 4 → 8 (Medium) | | Treatment | Accept (until 2027 replacement) | | Linked Exceptions | EX-2026-0017 | | Review Cadence | Quarterly | ### 4.3 Example C: Risk Derived From an Inheritance Failure Mode | Field | Value | |---|---| | Risk ID | R-2026-0153 | | Risk Statement | If the M365 inherited tenancy isolation control is misconfigured on the customer side (conditional access policy gap), affecting all M365-resident CUI workspaces, there is a possibility that unauthorized cross-tenant access leads to CUI exposure, resulting in [CMMC L2](https://dodcio.defense.gov/CMMC/) finding and DC3 notification. | | Source | Architecture Review | | Linked Control(s) | AC-3 / IA-2 / 800-171 3.1.1 | | Regulatory Scope | CUI | | Residual Likelihood / Impact | 2 / 5 → 10 (High) | | Treatment | Mitigate | | Linked POA&M | POAM-CUI-2026-0019 | --- ## 5. Exception Request Template The exception is a request to deviate from a baseline control. It is a risk register entry once approved. ``` EXCEPTION REQUEST - EX-YYYY-NNNN Requestor : Business Sponsor : Date Submitted : Requested Effective : Requested Expiration : (per RMF §9.7 default durations; shortest applicable regulatory or procedural duration wins) Affected Asset(s) : (inventory ID + name) Operating Unit : Regulatory Scope : CUI / BES / SOX / None Control Being Deviated : ([CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) control ID + family) Subordinate Standard : (CERG-STD-* reference) Standard Language : (quoted parameter that is being relaxed) Proposed Deviation : (precise; not "we won't do X" but "we will do Y in place of X") Business Driver : (why this is needed) Compensating Controls : (specific, named, in place - not future tense) Residual Risk Score : (per Section 6) Risk Statement : (per Section 2) Treatment Plan to : Close the Exception : (what makes this expire - usually a planned control) Risk Owner : CERG Coordinator : Approver Required : (per PRC-RM-001 §8 - Engineering Mgr / CISO / Exec Sponsor) ``` Exception register fields mirror the risk register schema and add: **Exception ID**, **Standard Reference**, **Deviation Text**, **Compensating Controls**, **Expiration Date**, **Renewal Allowed (Y/N)**, **Renewal History**. > **Exceptions Are Not "Forever"** > > Every exception has an expiration date and a treatment plan that retires it. An exception renewed more than twice without movement on the treatment plan is escalated by the Risk Register Owner to the approver one level above the original. --- ## 6. Risk Scoring Guide CERG scores risk on a 5×5 matrix, with **control effectiveness** as a step-down from inherent to residual. ### 6.1 Likelihood (1–5) | **Rating** | **Meaning** | **Indicators** | |---|---|---| | 1 - Rare | Unlikely in any 5-year window. | No known precedent; requires sophisticated, targeted attack. | | 2 - Unlikely | Possible in 5 years. | Known but rare; requires specific conditions. | | 3 - Possible | Plausible within 1 year. | Industry has examples; ordinary skill required. | | 4 - Likely | Expected within 1 year. | Observed in peer organizations or commodity attack. | | 5 - Almost Certain | Expected within 90 days or actively observed. | Active campaign, exposed surface, telemetry indicates attempts. | ### 6.2 Impact (1–5) Impact is scored across **Safety**, **Operational**, **Financial**, **Regulatory**, and **Reputational** dimensions; the **highest** dimension wins. | **Rating** | **Safety** | **Operational** | **Financial** | **Regulatory** | **Reputational** | |---|---|---|---|---|---| | 1 | None | < 1 hr / 1 system | < $100K | None | Internal only | | 2 | Minor injury / near miss | < 4 hr / single BU | $100K–$1M | Informal finding | Localized awareness | | 3 | Recordable injury | < 24 hr / multi-BU | $1M–$10M | Audit finding | Regional press | | 4 | Serious injury | 24–72 hr / multi-OU | $10M–$50M | Material finding / fine | National press | | 5 | Fatality / public safety | > 72 hr / safety event | > $50M | License at risk / criminal exposure | Sustained national / international | ### 6.3 Control Effectiveness Step-Down | **Effectiveness** | **Likelihood Reduction** | **Impact Reduction** | |---|---|---| | Strong | −2 | −1 | | Adequate | −1 | −1 | | Weak | 0 | 0 | | None | 0 | 0 | Residual cannot fall below 1. Step-downs are applied to inherent, never to residual. ### 6.4 Heat Map Bands | **Residual Score** | **Band** | **Approval Authority (per RMF §9.7 / PRC-RM-001 §8)** | |---|---|---| | 20–25 | Critical | CISO + Executive Sponsor; Board notified | | 12–19 | High | CISO + Business Owner | | 6–11 | Medium | Business Owner + Pillar Leader or Governance Pillar Leader | | 2–5 | Low | Business Owner + Risk Register Owner | | 1 | Informational | Risk Register Owner tracks; no formal acceptance required | --- ## 7. CISO Slice-and-Dice Reporting Views The CISO will not consume the operational view. The CISO will consume views that compare and trend. The package below is what gets published, heat-maps, trend lines, and scorecards first; narrative memos in reserve for specific questions. ### 7.1 The Five Standing CISO Views | **View** | **Purpose** | **Data Shape** | |---|---|---| | OU Scorecard | Compare operating units against each other on residual risk volume and trend. | One row per OU. Columns: Critical / High / Medium / Low counts; Δ vs. prior month; Open SLA breaches; Open Exceptions; Trend arrow. | | OU Heat Map | Show where risk concentrates by OU × Family. | Matrix: OU rows × Control Family columns (AC, AU, CM, CP, IA, RA, SC, SI, SR). Cell = count of High/Critical. | | Trend Lines | Are we getting better or worse? | Monthly: total residual score (sum), Critical+High count, mean time to close, open exception count. 13-month rolling. | | Top 10 Risks | The set the board cares about. | The ten highest residual-score open risks with risk statement, owner, treatment, next milestone. | | Regulatory Posture | Per-overlay summary. | CUI / BES / SOX rows; columns: Practices Implemented %, Open POA&M items, Open Exceptions, Next Assessment Date. | ### 7.2 Anti-Shallow-Metrics Guardrails > **Don't Reward Closing Easy Vulns While Criticals Sit** > > The reporting views above deliberately weight *score sum* and *Critical+High count* over raw counts. A view that rewards closing 200 Lows while 4 Criticals sit untouched is a view that lies to the CISO. CERG reports the residual-score weighted sum first; raw counts second. Additional guardrails baked into the views: - **OU Scorecard "Trend Arrow"** is computed on residual-score weighted sum, never on count. - **Top 10 Risks** rows must include the *age of the highest-impact unmitigated finding inside that risk*, so a 6-month-old Critical does not hide behind a freshly closed Low. - **OU Heat Map** colors on Critical+High concentration, not on total count. - **Regulatory Posture** "Practices Implemented %" is computed on the in-scope practice set with **Partially Implemented** counted as 0.5, not as 1. ### 7.3 Cadence | **View** | **Refresh** | **Audience** | |---|---|---| | OU Scorecard | Monthly | CERG Leadership · OU Leadership | | OU Heat Map | Monthly | CISO | | Trend Lines | Monthly | CISO · Cyber Oversight Group | | Top 10 Risks | Monthly + ad hoc | CISO · Cyber Oversight Group · Board (quarterly slice) | | Regulatory Posture | Quarterly | CISO · Audit · Cyber Oversight Group | --- ## 8. Document Control | | | |---|---| | **Document ID** | CERG-TMPL-RM-001 | | **Version** | 1.23 | | **Approved By** | CISO | | **Next Review** | Annual / on tooling change | | **Change Log** | 1.23 - Added explicit Definition of Done fields for residual risk owner, control evidence, decision date, last validated date, next review date, and closure/validation evidence. 1.22 - Aligned scoring bands, approval authorities, and expiration guidance to RMF §9.7 / PRC-RM-001 §8. 1.0 - Initial publication. Schema, examples, exception template, scoring guide, CISO reporting views. | --- ## SANCTIONED AI TOOLS REGISTER TEMPLATE ### Approved Tools · Data Classification Limits · Use Cases · Conditions · Review Cadence --- | | | |---|---| | **Document ID** | CERG-TMPL-AI-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Supporting Documents** | [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) · [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) · [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | | **Review Cycle** | Quarterly / On material change to AI provider terms, data classification, or approved use | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 PM / SA / AC · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where AI tools or AI-enabled vendor features are sanctioned for use | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Register Template](#3-fill-in-register-template) 4. [Review and Maintenance](#4-review-and-maintenance) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This template provides the authoritative local register of sanctioned AI tools and AI-enabled vendor features. It is the operational artifact that makes the approved AI path visible to staff and reviewable by Governance. The register does not approve AI in general. Each entry defines the approved tool, owner, user population, maximum data classification, approved use cases, prohibited use cases, required controls, and reassessment cadence. > **Visibility Is a Control** > > A sanctioned AI list is not only a convenience for users. It is a control surface. Staff can see where approved use exists, Governance can see what must be reviewed, Risk can see which vendor assessments remain current, and Engineering can see which tools require technical monitoring. --- ## 2. Template Instructions 1. Maintain one current register as the authoritative source for sanctioned AI tools. 2. Add a register entry only after intake is completed through [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) or an equivalent local workflow. 3. Do not list a tool as broadly approved unless all data classifications, use cases, and user populations in scope have been explicitly reviewed. 4. Use `Not Approved` rather than blank fields where a classification, use case, or user group is prohibited. 5. Link each entry to its intake, vendor assessment, architecture review, risk record, exception, and evidence where applicable. 6. Review the register at least quarterly and whenever provider terms, AI features, retention, training use, or approved data classification changes. 7. Publish a user-facing subset that is appropriate for staff; retain assessment details in the evidence library where needed. --- ## 3. Fill-In Register Template ### 3.1 Register Metadata | **Field** | **Value** | |---|---| | Register Owner | `[Governance Pillar Leader / delegated owner]` | | Maintainer | `[Policy & Standards Manager or assigned role]` | | Register Location | `[System of record / link]` | | Last Review Date | `[Date]` | | Next Review Date | `[Date]` | | Publication Location for Staff | `[Intranet / portal / policy site]` | ### 3.2 Sanctioned AI Tools Register | **Tool / Feature** | **Provider** | **AI Use Category** | **Business Owner** | **Approved Users** | **Approved Use Cases** | **Prohibited Use Cases** | **Maximum Data Classification** | **Training / Retention Position** | **Required Controls** | **Linked Intake / Evidence** | **Review Cadence** | **Status** | |---|---|---|---|---|---|---|---|---|---|---|---|---| | `[Tool name]` | `[Provider]` | `[Consumed AI service / Embedded AI]` | `[Owner]` | `[Users / groups]` | `[Summarization, coding assistance, analysis, etc.]` | `[Employment decisions, Restricted data, autonomous action, etc.]` | `[Public / Internal / Confidential / Restricted / Not Approved]` | `[No provider training; retention period; enterprise controls]` | `[SSO, DLP, logging, admin controls, contractual terms]` | `[AI intake ID, TPRM ID, evidence links]` | `[Quarterly / Semiannual / Annual / On change]` | `[Approved / Approved with conditions / Pilot / Suspended / Retired]` | ### 3.3 Conditional Approval Tracker Use this section for tools approved only after conditions are satisfied, pilots, or limited exceptions. | **Tool / Feature** | **Condition** | **Owner** | **Due Date** | **Current Status** | **Evidence** | |---|---|---|---|---|---| | `[Tool name]` | `[Condition]` | `[Owner]` | `[Date]` | `[Open / Complete / Overdue]` | `[Evidence link]` | ### 3.4 Staff-Facing Use Statement For each sanctioned tool, publish a short user-facing statement in plain language. | **Tool / Feature** | **Staff-Facing Statement** | |---|---| | `[Tool name]` | `[Example: Approved for Internal data and lower for drafting, summarization, and coding assistance. Do not enter Confidential, Restricted, CUI, BES Cyber System Information, personal data, customer secrets, or production credentials. Human review is required before relying on output.]` | ### 3.5 Reassessment Log | **Date** | **Tool / Feature** | **Trigger** | **Reviewer** | **Outcome** | **Linked Record** | |---|---|---|---|---|---| | `[Date]` | `[Tool name]` | `[Quarterly review / Provider term change / New AI feature / Incident / Regulation change]` | `[Reviewer]` | `[No change / Conditions added / Classification changed / Suspended / Retired]` | `[Record link]` | --- ## 4. Review and Maintenance | **Role** | **Responsibility** | |---|---| | Governance Pillar Leader | Owns the register, approves sanctioned-use entries, and ensures the staff-facing list remains current. | | Policy & Standards Manager | Maintains register content and coordinates periodic review. | | Vendor Risk Analyst | Confirms vendor assessments and provider-term evidence for third-party AI services and AI-enabled vendor features. | | Application Security Engineer | Confirms AI-specific technical control conditions where the tool interacts with code, applications, or built AI systems. | | Cloud Security Engineer | Confirms SaaS, network, DLP, CASB, SSPM, or other technical monitoring where applicable. | | Risk Register Owner | Ensures material AI risk, exceptions, and shadow AI patterns are linked to the risk register. | A register entry must be reassessed when any of the following occur: - The provider changes training, retention, confidentiality, or subprocessor terms. - The tool adds a new AI feature, agent capability, connector, plugin, or data integration. - The approved data classification or user population expands. - The tool is proposed for regulated, safety, financial, employment, legal, or other consequential decisions. - A security incident, audit finding, or material risk finding involves the tool. - The CISO, Governance Pillar Leader, Risk Pillar Leader, or Engineering Pillar Leader directs review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-AI-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-17 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - Artificial Intelligence Security Standard | | **Review Cycle** | Quarterly; and on material change to AI provider terms, data classification, or approved use | | **Next Scheduled Review** | 2026-09-17 | | **Frameworks** | NIST AI RMF 100-1 · NIST 800-53r5 PM / SA / AC · ISO/IEC 42001 | | **Regulations** | Cross-cutting; CMMC L2 / 800-171r3, SOX ITGC, privacy, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where AI tools or AI-enabled vendor features are sanctioned for use | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-17 | Cyber Governance | Initial release. Establishes the sanctioned AI tools register template for recording approved tools, maximum data classifications, use-case limits, conditions, evidence, and review cadence. | ### Review Triggers - Parent standard change - Material change to any sanctioned AI tool, provider term, approved data classification, approved use case, or user population - New or changed AI regulation - Significant AI-related finding, incident, or audit issue - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Artificial Intelligence Security Standard | [`CERG-STD-AI-001`](../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) | Parent standard; requires a sanctioned AI tools list | | AI Intake and Sanctioning Template | [`CERG-TMPL-AI-001`](CERG-TMPL-AI-001_AI_Intake_and_Sanctioning_Template.md) | Source intake and approval record for register entries | | Data Governance and Classification Standard | [`CERG-STD-DG-001`](../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) | Defines data classification limits for AI use | | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Governs assessment of third-party AI services and AI-enabled vendor features | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Tracks material AI risk, exceptions, and shadow AI patterns | --- ## SBOM Evidence Collection Checklist ### Audit-Ready Artifacts for Software Supply Chain --- | | | |---|---| | **Document ID** | CERG-TMPL-SBOM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Vendor Risk Analyst | | **Parent Document** | [CERG-PRC-TPRM-001](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) §11 | | **Supporting Schema** | `machine-readable/cerg-sbom-schema.yaml` | | **Review Cycle** | Annual / On SBOM process change | | **Frameworks** | NIST 800-161r1 · NTIA SBOM · EO 14028 · CSA CCM · NIST 800-53 SR | | **Regulations** | NERC-CIP CIP-013 · CMMC SR.L2 · SOX ITGC · FedRAMP | | **Environments** | All vendor software deliveries; internal production builds | --- ## Purpose Standardizes SBOM evidence collection for vendor-delivered software and internally-built artifacts. Supports CIP-013, CMMC SR.L2, EO 14028, and SOX ITGC evidence requirements. --- ## Evidence by SBOM Source ### Vendor-Delivered SBOM (T1/T2/T3 Software Vendors) | **Artifact** | **Source** | **Frequency** | **CIP-013** | **CMMC** | **SOX** | **Notes** | |---|---|---|---|---|---|---| | SBOM file (CycloneDX/SPDX) | Vendor TPRM portal | Per delivery + material update | ✓ | ✓ | | Validate format on receipt | | SBOM vulnerability scan report | Scanner (Grype/Trivy/OSV) | On receipt + quarterly (T1/T2) | ✓ | ✓ | | Findings → PRC-VM-001 | | VEX statements for Critical/High | Vendor | Per finding | ✓ | ✓ | | `vex_status` in registry | | License scan report | Scanner (FOSSA/Scanner) | Per delivery | | | ✓ | Flag GPL/AGPL in proprietary | | Embedded secrets scan report | Scanner (TruffleHog/Gitleaks) | Per delivery | ✓ | | | Fail if secrets found | | Signature verification log | Cosign / vendor key | Per delivery | ✓ | | | Verify SBOM authenticity | ### Internal Build SBOM (CI/CD Generated) | **Artifact** | **Source** | **Frequency** | **CIP-013** | **CMMC** | **SOX** | **Notes** | |---|---|---|---|---|---|---| | CycloneDX SBOM artifact | CI pipeline (Syft) | Every production build | ✓ | ✓ | ✓ | Signed, in artifact registry | | Pipeline vulnerability scan log | CI pipeline (Grype/Trivy) | Every production build | ✓ | ✓ | ✓ | Gate: fail on Critical/High | | VEX for accepted findings | Developer / Risk | Per finding | ✓ | ✓ | | Documented risk acceptance | | License compliance report | CI pipeline (license-checker) | Every production build | | | ✓ | Policy gate | | Secrets scan log | CI pipeline (TruffleHog) | Every production build | ✓ | | ✓ | Gate: fail on any secret | | SBOM registry record | `machine-readable/cerg-sbom-schema.yaml` | Auto on pipeline success | ✓ | ✓ | | `approval_status = approved` | ### Registry & Reporting | **Artifact** | **Source** | **Frequency** | **CIP-013** | **CMMC** | **SOX** | **Notes** | |---|---|---|---|---|---|---| | SBOM registry export (all records) | SBOM registry / machine-readable | Quarterly | ✓ | ✓ | ✓ | For auditor review | | Stale SBOM report (>90 days no scan) | SBOM registry query | Monthly | ✓ | | | Triggers re-scan | | Critical component inventory (log4j, spring, openssl, etc.) | SBOM registry query | Monthly | ✓ | ✓ | | Rapid response to 0-days | --- ## Collection Workflow 1. **Vendor intake:** TPRM requires SBOM at onboarding (T1/T2/T3 software) 2. **Delivery:** Vendor uploads to TPRM portal → auto-validated for format 3. **Scan:** Risk runs vulnerability + license + secrets scans → findings registered 4. **VEX:** Vendor provides VEX for Critical/High within 10 business days 5. **Approve:** Governance sets `approval_status` → evidence linked in TPRM tool 6. **Internal builds:** CI pipeline auto-generates, scans, signs, publishes SBOM 7. **Quarterly audit:** Governance pulls registry export → evidence library --- ## Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-SBOM-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Vendor Risk Analyst | | **Approved By** | CISO | | **Effective Date** | 2026-06-17 | | **Review Cycle** | Annual / On SBOM process change | | **Next Scheduled Review** | 2027-06-17 | ### Revision History | Version | Date | Author | Change Summary | |---|---|---|---| | 1.0 | 2026-06-17 | Cyber Governance | Initial release - SBOM evidence collection checklist | ### Related Documents | Document | ID | Relationship | |---|---|---| | Third-Party Supply Chain Risk Procedure | CERG-PRC-TPRM-001 | Governing procedure §11 | | SBOM Record Schema | machine-readable/cerg-sbom-schema.yaml | Machine-readable record format | | Exposure Management Procedure | CERG-PRC-VM-001 | SBOM findings pipeline | | Secure Configuration Baseline (DISH) | CERG-STD-CFG-001 | Container image signing gate §7 | | CI/CD SBOM Generation Script | tools/sbom-generate.sh | Pipeline implementation | --- ## SECURITY EXCEPTION REQUEST FORM ### Control Exception · Waiver Request · Compensating Controls · Expiration · Approval --- | | | |---|---| | **Document ID** | CERG-TMPL-RM-002 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Supporting Documents** | [`CERG-TMPL-RM-001`](CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) · [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST 800-30r1 · NIST 800-53r5 RA, CA, PM · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This form captures a temporary security exception or waiver request. It is used when a required control cannot be implemented as written, cannot be implemented by the due date, or must be bypassed temporarily for a justified business reason. The completed form feeds the risk register and cannot be used to create a permanent undocumented control gap. > **Exceptions Expire** > > An exception is a temporary, visible, approved deviation. If it does not have an owner, compensating controls, an expiration date, and approval authority, it is not an exception. It is uncontrolled drift. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link risks, findings, exceptions, evidence, and approvals to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Template ### 3.1 Request Summary | **Field** | **Value** | |---|---| | Exception ID | `[EX-YYYY-NNN]` | | Request Date | `[Date]` | | Requester | `[Name / Role]` | | Affected System / Asset | `[Asset ID or system]` | | Business Owner / Residual Risk Owner | `[Executive Sponsor or owner who accepts residual consequence]` | | Control / Requirement | `[Control ID and title]` | | Exception Type | `[Temporary waiver / delayed implementation / compensating control / emergency exception]` | | Requested Expiration Date | `[Date]` | | Next Review Date | `[Date; must be on or before requested expiration and any shorter regulatory/procedure clock]` | | Related Risk ID | `[Risk ID]` | ### 3.2 Exception Rationale `[Explain why the control cannot be met as written and why the exception is needed now.]` ### 3.3 Risk and Impact | **Area** | **Assessment** | |---|---| | Threat or weakness created | `[Description]` | | Affected data or process | `[Scope]` | | Regulatory scope | `[CUI / SOX / CIP / privacy / none]` | | Inherent risk | `[Likelihood, impact, score]` | | Residual risk with compensating controls | `[Likelihood, impact, score]` | | Business consequence if denied | `[Consequence]` | ### 3.4 Compensating Controls | **Control** | **Owner** | **Compensating Control Evidence Link** | **Last Validated Date** | **Monitoring Cadence** | |---|---|---|---|---| | `[Control]` | `[Owner]` | `[Evidence link]` | `[Date]` | `[Cadence]` | ### 3.5 Expiration and Exit Plan | **Field** | **Value** | |---|---| | Expiration Date | `[Date]` | | Remediation Plan | `[Plan]` | | POA&M ID | `[POA&M ID if applicable]` | | Renewal Allowed | `[Yes / No. If yes, state criteria.]` | | Closure Verification Date | `[Date closure conditions were validated, or Not Applicable until closure]` | | Exit Evidence / Closure Evidence Link | `[Evidence needed to close and link to evidence when closed]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Risk Register Owner | Confirms record completeness, register linkage, next review date, and evidence links. | `[Name / Date]` | | Risk Pillar Leader | Confirms residual risk scoring and approves Low or Medium exceptions where authorized. | `[Name / Date]` | | Business Owner / Residual Risk Owner | Accepts the operational consequence created by the temporary deviation. | `[Name / Date]` | | Chief Information Security Officer (CISO) | Approves High or Critical exceptions and material regulated-scope deviations. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-RM-002 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Risk Register Owner | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - Risk Register and Exception Process | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-30r1 · NIST 800-53r5 RA, CA, PM · ISO 31000 | | **Regulations** | Cross-cutting | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-20 | Governance Pillar Leader | Added Definition of Done fields for residual risk owner, compensating-control evidence, last validation, next review, closure verification, and closure evidence. | | 1.0 | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for security exception request form. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Risk Register Templates and Reporting | [`CERG-TMPL-RM-001`](CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) | Register and reporting schema | | Risk Register and Exception Process | [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) | Governing exception lifecycle | --- ## SYSTEM CONTROL PROFILE TEMPLATE ### Per-System Control Implementation · Evidence · Validation · Review State --- | | | |---|---| | **Document ID** | CERG-TMPL-SCP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Document** | [CERG-GOV-CAT-002](../governance/CERG-GOV-CAT-002_Record_Catalog.md) - Record Catalog | | **Supporting Documents** | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [CERG-GOV-TRC-001](../governance/CERG-GOV-TRC-001_Control_to_Procedure_Traceability_Matrix.md) · [CERG-GOV-AUD-001](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | | **Review Cycle** | Annual / On system classification, control baseline, or evidence model change | | **Frameworks** | NIST 800-53r5 · NIST 800-171r3 · NIST CSF 2.0 · ISO/IEC 27001 | | **Regulations** | CMMC L2 · NERC-CIP · SOX ITGC · Cross-cutting | | **Environments** | All systems or system classes requiring per-system control evidence | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [YAML Structure](#3-yaml-structure) 4. [Fill-In Template](#4-fill-in-template) 5. [Review and Approval](#5-review-and-approval) 6. [Document Control](#6-document-control) --- ## 1. Purpose and Use A System Control Profile (SCP) is a structured per-system or per-system-class record that connects the asset inventory, control baseline, implementation statement, evidence location, validation date, and next review date. The SCP is not a new control framework and does not replace a regulated System Security Plan, POA&M, NERC-CIP evidence package, SOX test record, asset inventory, or risk register. It is the structured control-profile record that lets those artifacts agree with each other. Use this template when an implementation needs to prove control state for a system, regulated boundary, crown-jewel service, OT asset class, CUI enclave, SOX-relevant application, or other system class where control implementation and evidence must be assessed at system level. --- ## 2. Template Instructions 1. Store SCP records as YAML using the schema at [`../machine-readable/schemas/system-control-profile.schema.json`](../machine-readable/schemas/system-control-profile.schema.json). 2. Use one SCP per system or per clearly bounded system class. 3. Use stable asset IDs from the authoritative asset inventory. 4. Use control IDs from [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md). 5. Link each control entry to evidence that is independently verifiable under [`CERG-GOV-AUD-001`](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md). 6. Record `last_validated` and `next_review` for every control entry. 7. Link related risks, exceptions, POA&M items, and findings instead of embedding their full content. 8. Store the completed SCP in the evidence library and index it as a **System Control Profile Record** per [`CERG-GOV-CAT-002`](../governance/CERG-GOV-CAT-002_Record_Catalog.md). --- ## 3. YAML Structure Minimum structure: ```yaml system_id: "[stable asset or system identifier]" name: "[system name]" classification: "[Public / Internal / Confidential / Restricted / CUI / BES Cyber System / SOX-relevant / other]" system_owner: "[Business Owner or System Owner role]" technical_owner: "[Technical Owner role]" environment: "[IT / Cloud / SaaS / OT / Hybrid]" regulatory_scope: - "[CUI / BES / SOX / Privacy / None]" profile_status: "[Draft / Approved / Superseded / Retired]" last_profile_review: "[YYYY-MM-DD]" next_profile_review: "[YYYY-MM-DD]" controls_applied: - control: "[control ID]" implementation: "[how this system implements the control]" evidence: "[evidence link or evidence index ID]" evidence_type: "[export / report / ticket / configuration / attestation / test result / SCP-linked package]" last_validated: "[YYYY-MM-DD]" next_review: "[YYYY-MM-DD]" owner: "[control owner for this system]" status: "[Implemented / Partially Implemented / Planned / Inherited / Exception / Accepted Risk]" related_risks: [] related_exceptions: [] ``` --- ## 4. Fill-In Template A complete example is available at [`../examples/system-control-profile.example.yaml`](../examples/system-control-profile.example.yaml). ```yaml system_id: HIST-47 name: Substation 47 Historian classification: BES Cyber System system_owner: Operations Technology Owner technical_owner: OT Security Engineer environment: OT regulatory_scope: - BES profile_status: Approved last_profile_review: 2026-03-31 next_profile_review: 2026-06-30 controls_applied: - control: AC-2 implementation: AD group S47-Operators controls operator access; quarterly access review performed by the System Owner. evidence: evidence://access-reviews/hist-47/quarterly_access_review_2026-03-31.pdf evidence_type: access_review_record last_validated: 2026-03-31 next_review: 2026-06-30 owner: Identity Engineer status: Implemented related_risks: [] related_exceptions: [] - control: CM-7 implementation: DISH baseline v2.1 applied; local firewall allowlist restricts management services to the OT jump host. evidence: evidence://baselines/hist-47/cm7_baseline_comparison_2026-04-15.xlsx evidence_type: configuration_baseline_record last_validated: 2026-04-15 next_review: 2026-07-15 owner: OT Security Engineer status: Implemented related_risks: [] related_exceptions: [] ``` --- ## 5. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | System Owner / Business Owner | Confirms system scope, business ownership, and accepted residual conditions. | `[Name / Date]` | | Technical Owner | Confirms implementation statements and evidence links are accurate. | `[Name / Date]` | | Engineering Pillar Leader | Confirms control implementation and coverage profile. | `[Name / Date]` | | Governance Pillar Leader | Confirms evidence quality, regulatory traceability, and retention route. | `[Name / Date]` | | Risk Pillar Leader | Confirms linked risk, exception, or accepted-risk entries where residual exposure remains. | `[Name / Date]` | Completed SCP records are reviewed at the cadence defined by their system classification, regulatory scope, and related control requirements. Material system change, control baseline change, ownership change, regulatory-scope change, or major evidence failure requires an SCP refresh. --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-SCP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-20 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Document** | [CERG-GOV-CAT-002](../governance/CERG-GOV-CAT-002_Record_Catalog.md) - Record Catalog | | **Review Cycle** | Annual; and on system classification, control baseline, or evidence model change | | **Next Scheduled Review** | 2027-06-20 | | **Frameworks** | NIST 800-53r5 · NIST 800-171r3 · NIST CSF 2.0 · ISO/IEC 27001 | | **Regulations** | CMMC L2 · NERC-CIP · SOX ITGC · Cross-cutting | | **Environments** | All systems or system classes requiring per-system control evidence | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-20 | Engineering Pillar Leader | Initial publication. Establishes the System Control Profile as a structured per-system control implementation, evidence, validation, and review record. | ### Review Triggers - Control baseline or traceability matrix changes. - Asset classification, ownership, boundary, or regulatory scope changes. - Material system architecture or control implementation change. - Evidence failure, audit finding, or regulator request requiring per-system control proof. - Direction from the CISO. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Record Catalog | [CERG-GOV-CAT-002](../governance/CERG-GOV-CAT-002_Record_Catalog.md) | Defines System Control Profile Record as a canonical record type | | Unified Control Baseline | [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) | Source for control identifiers and control state | | Control-to-Procedure Traceability Matrix | [CERG-GOV-TRC-001](../governance/CERG-GOV-TRC-001_Control_to_Procedure_Traceability_Matrix.md) | Maps controls to procedures and expected evidence records | | Evidence Quality Standard | [CERG-GOV-AUD-001](../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) | Evidence quality rules for SCP-linked artifacts | --- ## SYSTEM SECURITY PLAN TEMPLATE ### System Boundary · Authorization Context · Control Implementation · Inheritance · Evidence Index --- | | | |---|---| | **Document ID** | CERG-TMPL-CUI-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Parent Plan** | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - CUI / CMMC Operational Package | | **Supporting Documents** | [`CERG-GOV-CB-001`](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) · [`CERG-STD-CUI-001`](../standards/CERG-STD-CUI-001_CUI_Handling_Standard.md) · [`CERG-STD-AM-001`](../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) · [`CERG-PRC-RM-001`](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) · [`CERG-TMPL-CUI-002`](CERG-TMPL-CUI-002_POAM_Template.md) | | **Review Cycle** | Annual / On system boundary, CUI scope, or authorization change | | **Frameworks** | NIST 800-171r3 · NIST 800-172 · CMMC L2 · NIST 800-53r5 | | **Regulations** | Controlled Unclassified Information / CMMC contractual obligations | | **Environments** | Systems that store, process, transmit, or protect CUI | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [SSP Cover Page](#3-ssp-cover-page) 4. [System Boundary](#4-system-boundary) 5. [System Environment](#5-system-environment) 6. [CUI Data Flow](#6-cui-data-flow) 7. [Roles and Responsibilities](#7-roles-and-responsibilities) 8. [Control Implementation Matrix](#8-control-implementation-matrix) 9. [Inherited Controls](#9-inherited-controls) 10. [External Providers and Interconnections](#10-external-providers-and-interconnections) 11. [Open Items and POA&M Linkage](#11-open-items-and-poam-linkage) 12. [Evidence Index](#12-evidence-index) 13. [Approval and Maintenance](#13-approval-and-maintenance) 14. [Document Control](#14-document-control) --- ## 1. Purpose and Use This template creates a System Security Plan (SSP) for a system that stores, processes, transmits, or protects Controlled Unclassified Information (CUI). It is designed to be copied into a system-specific artifact and completed by the system owner, technical owners, and CMMC / Federal Compliance Manager. The SSP explains the system boundary, CUI data flow, implemented security controls, inherited controls, external dependencies, open gaps, and evidence locations. It supports CMMC readiness, federal customer assurance, and internal authorization decisions. > **An SSP Is a Control Story, Not a Form Dump** > > A useful SSP tells a reviewer what the system is, where CUI moves, which controls protect it, which controls are inherited, where the evidence lives, and what remains unfinished. If a control answer cannot be tied to evidence or a POA&M item, the SSP is not ready. --- ## 2. Template Instructions 1. Copy this template and rename the copy for the specific system. 2. Replace bracketed fields such as `[System Name]` with system-specific content. 3. Do not delete sections that are not applicable. Mark them `Not Applicable` and explain why. 4. Use asset IDs from `CERG-STD-AM-001` wherever possible. 5. Link all open control gaps to `CERG-TMPL-CUI-002` POA&M entries. 6. Link material residual risks to `CERG-PRC-RM-001` risk-register entries. 7. Store evidence in the evidence library governed by `CERG-PRC-AUD-001`. 8. Review the completed SSP annually and when the system boundary changes. --- ## 3. SSP Cover Page | **Field** | **Value** | |---|---| | System Name | `[System Name]` | | System Acronym | `[Acronym]` | | System Owner | `[Executive Sponsor or Business Owner]` | | Technical Owner | `[Engineering Pillar Leader or delegated technical owner]` | | CUI Scope | `[In Scope / Out of Scope / Partial]` | | Authorization Status | `[Draft / Under Review / Authorized / Not Authorized]` | | Environment | `[Production / Non-production / Hybrid]` | | Hosting Model | `[On-premises / Cloud / SaaS / Hybrid]` | | Highest Data Classification | `[Public / Internal / Confidential / Restricted / CUI]` | | External Providers | `[Provider names or None]` | | SSP Version | `[Version]` | | SSP Date | `[Date]` | --- ## 4. System Boundary ### 4.1 Boundary Narrative Describe the system boundary in plain language. `[Insert system boundary narrative. Include major components, users, locations, cloud accounts, network zones, and excluded components.]` ### 4.2 Boundary Components | **Component / Asset ID** | **Type** | **Owner** | **Location** | **CUI Role** | **Notes** | |---|---|---|---|---|---| | `[Asset ID]` | `[Application / Server / Database / SaaS / Network / Endpoint]` | `[Owner]` | `[Location]` | `[Stores / Processes / Transmits / Protects]` | `[Notes]` | ### 4.3 Boundary Exclusions | **Excluded Component** | **Reason Excluded** | **Evidence / Rationale** | |---|---|---| | `[Component]` | `[Reason]` | `[Evidence location]` | --- ## 5. System Environment | **Area** | **Description** | |---|---| | Users | `[User populations and access paths]` | | Administrators | `[Privileged user groups]` | | Identity Provider | `[IdP, MFA, federation, PAM]` | | Network Zones | `[Network segments and trust boundaries]` | | Endpoints | `[Managed endpoints, VDI, mobile, BYOD constraints]` | | Logging | `[Log sources and retention]` | | Backup and Recovery | `[Backup tier, RTO, RPO, restore evidence]` | | Encryption | `[Data-at-rest and data-in-transit controls]` | | Exposure Management | `[Scanner, cadence, SLA]` | | Configuration Baseline | `[Baseline source and exception handling]` | --- ## 6. CUI Data Flow ### 6.1 Data Categories | **CUI Category** | **Source** | **Storage Location** | **Transmission Path** | **Recipient** | **Protection Notes** | |---|---|---|---|---|---| | `[Category]` | `[Source]` | `[System / database / repository]` | `[Path]` | `[Recipient]` | `[Controls]` | ### 6.2 Data Flow Narrative `[Describe how CUI enters, moves through, exits, and is retained or deleted from the system.]` ### 6.3 Data Flow Diagram Reference | **Diagram Name** | **Location** | **Last Updated** | |---|---|---| | `[Diagram]` | `[Repository / evidence location]` | `[Date]` | --- ## 7. Roles and Responsibilities Use canonical CERG roles from `CERG-GOV-OM-001`. | **Role** | **SSP Responsibility** | **Named Person / Team** | |---|---|---| | CMMC / Federal Compliance Manager | Owns SSP governance, review cycle, and CMMC mapping. | `[Name]` | | Engineering Pillar Leader | Owns technical implementation accuracy. | `[Name]` | | Governance Pillar Leader | Owns evidence and policy alignment. | `[Name]` | | Risk Pillar Leader | Owns residual-risk linkage. | `[Name]` | | Evidence Librarian | Maintains SSP evidence index. | `[Name]` | | Risk Register Owner | Tracks risk and exception entries. | `[Name]` | --- ## 8. Control Implementation Matrix Create one row per applicable requirement or control. | **Control ID** | **Control Title** | **Status** | **Implementation Statement** | **Owner** | **Evidence** | **POA&M / Risk Link** | |---|---|---|---|---|---|---| | `[800-171 / CMMC / CERG ID]` | `[Title]` | `[Implemented / Partially Implemented / Planned / Inherited / Not Applicable]` | `[How the system satisfies the control]` | `[Canonical role]` | `[Evidence location]` | `[POA&M ID / Risk ID / None]` | Implementation statements must be specific enough that an assessor can understand what exists without interviewing the whole team. --- ## 9. Inherited Controls | **Inherited Control** | **Inherited From** | **Inheritance Condition** | **Evidence Owner** | **Evidence Location** | |---|---|---|---|---| | `[Control ID]` | `[Enterprise / Cloud Provider / SaaS / Shared Platform]` | `[Condition for inheritance]` | `[Owner]` | `[Location]` | Inherited controls are valid only when the system still satisfies the conditions required to inherit them. --- ## 10. External Providers and Interconnections | **Provider / Connection** | **Purpose** | **Data Shared** | **Security Requirements** | **Evidence** | |---|---|---|---|---| | `[Provider or connection]` | `[Purpose]` | `[Data]` | `[Requirements]` | `[Evidence]` | Vendor and interconnection risks are linked to `CERG-PRC-TPRM-001` and `CERG-PRC-RM-001`. --- ## 11. Open Items and POA&M Linkage | **POA&M ID** | **Related Control** | **Gap Summary** | **Owner** | **Target Date** | **Current Status** | |---|---|---|---|---|---| | `[POA&M ID]` | `[Control ID]` | `[Gap]` | `[Owner]` | `[Date]` | `[Status]` | No known control gap may remain only in narrative text. Every gap must have a POA&M item, risk-register entry, or documented not-applicable rationale. --- ## 12. Evidence Index | **Evidence ID** | **Evidence Name** | **Control(s)** | **Location** | **Owner** | **Refresh Cadence** | |---|---|---|---|---|---| | `[EV-001]` | `[Evidence name]` | `[Control IDs]` | `[Location]` | `[Owner]` | `[Cadence]` | --- ## 13. Approval and Maintenance | **Approval Role** | **Approval Meaning** | **Name / Date** | |---|---|---| | CMMC / Federal Compliance Manager | SSP is complete enough for CMMC / CUI governance. | `[Name / Date]` | | Engineering Pillar Leader | Technical statements are accurate. | `[Name / Date]` | | Risk Pillar Leader | Open risks and POA&M items are correctly recorded. | `[Name / Date]` | | Chief Information Security Officer (CISO) | Authorization or acceptance decision is recorded. | `[Name / Date]` | --- ## 14. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-CUI-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | CMMC / Federal Compliance Manager | | **Approved By** | CISO | | **Parent Plan** | [`CERG-PLN-CUI-001`](../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - CUI / CMMC Operational Package | | **Review Cycle** | Annual; and on system boundary, CUI scope, or authorization change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST 800-171r3; NIST 800-172; CMMC L2; NIST 800-53r5 | | **Regulations** | Controlled Unclassified Information / CMMC contractual obligations | | **Environments** | Systems that store, process, transmit, or protect CUI | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 Draft | 2026-05-22 | Cyber Governance | Initial release. Establishes a fill-in System Security Plan template for system boundary, CUI data flow, control implementation, inherited controls, external providers, POA&M linkage, evidence index, and approval workflow. | ### Review Triggers - System boundary change - CUI data-flow change - Authorization or assessment event - Material control implementation change - POA&M or residual-risk change requiring SSP update - Direction from the CISO --- ## SaaS Evidence Collection Checklist ### Audit-Ready Artifacts for Tier 1/2 SaaS Tenants --- | | | |---|---| | **Document ID** | CERG-TMPL-SAAS-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Document** | [CERG-STD-IT-001](../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) | | **Review Cycle** | Annual / On SaaS baseline change | | **Frameworks** | NIST 800-53 AU, CM, AC · SOX ITGC · CMMC · CSA CCM | | **Regulations** | SOX ITGC · CMMC (where applicable) | | **Environments** | Tier 1/2 SaaS tenants | --- ## Purpose This checklist ensures consistent, auditable evidence collection from Tier 1 and Tier 2 SaaS tenants for compliance (SOX, CMMC, ISO 27001) and CERG internal assurance. Evidence is stored in the CERG evidence library per CERG-PRC-AUD-001. --- ## Evidence by Category ### Identity & Access | **Artifact** | **Source** | **Frequency** | **SOX** | **CMMC** | **Notes** | |---|---|---|---|---|---| | Admin role assignments export | SaaS admin console / API | Quarterly | ✓ | ✓ | Filter to privileged roles | | Conditional Access / MFA policies | IdP / SaaS security center | Quarterly | ✓ | ✓ | Include named locations, device compliance | | OAuth / third-party app grants inventory | SaaS admin console / API | Quarterly | ✓ | ✓ | Scope, publisher, risk rank | | User provisioning / deprovisioning logs | IdP / SCIM audit log | Monthly | ✓ | | 90-day lookback | | Break-glass / emergency access log | SaaS / PAM | Per use | ✓ | | Must have post-use review | ### Configuration & Hardening | **Artifact** | **Source** | **Frequency** | **SOX** | **CMMC** | **Notes** | |---|---|---|---|---|---| | Tenant baseline scan results (CIS/CERG) | SSPM / CSPM | Monthly | ✓ | ✓ | Drift findings → PRC-VM-001 | | DLP policy configuration export | SaaS security center | Quarterly | ✓ | | For Restricted data tenants | | Data residency / region config | SaaS admin console | Annual | | ✓ (CUI) | Verify approved regions only | | Sharing / external access settings | SaaS admin console | Quarterly | ✓ | ✓ | Anonymous links, domain allowlist | ### Logging & Monitoring | **Artifact** | **Source** | **Frequency** | **SOX** | **CMMC** | **Notes** | |---|---|---|---|---|---| | Admin activity audit log sample (90 days) | SaaS audit log export / SIEM | Quarterly | ✓ | ✓ | Verify completeness, tamper-resistance | | Authentication / sign-in log sample | IdP / SaaS auth logs | Monthly | ✓ | | Include MFA events, failures | | Alert / detection rule coverage matrix | SIEM / SSPM | Quarterly | | ✓ | Map to MITRE ATT&CK SaaS | | Failed login / brute-force alerts | SIEM | Monthly | ✓ | | Correlate with lockout policy | ### Data Protection | **Artifact** | **Source** | **Frequency** | **SOX** | **CMMC** | **Notes** | |---|---|---|---|---|---| | Encryption at rest verification (CMK/BYOK) | KMS / SaaS security center | Annual | | ✓ (CUI) | Key rotation evidence | | Backup configuration & test results | SaaS backup / native | Annual | ✓ (ITGC) | ✓ | RPO/RTO, restoration test | | Retention / legal hold policies | SaaS admin / compliance center | Annual | ✓ | | Per regulatory requirements | ### Incident & Vendor | **Artifact** | **Source** | **Frequency** | **SOX** | **CMMC** | **Notes** | |---|---|---|---|---|---| | Provider SOC 2 Type II report | Vendor portal | Annual | ✓ | ✓ | Review carve-outs, CUECs | | Provider incident notification log | TPRM tool / email | Per incident | | ✓ | Verify 24/72hr SLA met | | Subprocessor list & changes | Vendor trust portal | Quarterly | | ✓ (CUI) | New subprocessor = reassessment | --- ## Collection Workflow 1. **Scheduler** (Governance): Quarterly calendar invite to SaaS tenant owners with this checklist 2. **Collector** (Engineering/Risk): Pull artifacts via API / admin console / SSPM export 3. **Reviewer** (Governance): Verify completeness, link to evidence library, note gaps 4. **Gaps**: Open findings in risk register per PRC-RM-001; track to closure --- ## Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-SAAS-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Effective Date** | 2026-06-17 | | **Review Cycle** | Annual / On SaaS baseline change | | **Next Scheduled Review** | 2027-06-17 | ### Revision History | Version | Date | Author | Change Summary | |---|---|---|---| | 1.0 | 2026-06-17 | Cyber Governance | Initial release - SaaS evidence collection checklist for Tier 1/2 tenants | ### Related Documents | Document | ID | Relationship | |---|---|---| | IT/Cloud/SaaS Security Standard | CERG-STD-IT-001 | Governing standard §5.4, §5.5 | | Access Management Standard | CERG-STD-AC-001 | NHI, ITDR evidence cross-reference | | Audit and Evidence Management Procedure | CERG-PRC-AUD-001 | Evidence library governance | | Exposure Management Procedure | CERG-PRC-VM-001 | Baseline drift findings pipeline | --- ## VENDOR SECURITY QUESTIONNAIRE AND TPRM ASSESSMENT TEMPLATE ### Vendor Intake · Data Scope · Control Evidence · Residual Risk · Approval --- | | | |---|---| | **Document ID** | CERG-TMPL-TPRM-001 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Vendor Risk Analyst | | **Parent Document** | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - Third-Party and Supply Chain Risk Procedure | | **Supporting Documents** | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) · [`CERG-PLN-PRIV-001`](../plans/CERG-PLN-PRIV-001_Privacy_and_Data_Protection_Operational_Package.md) | | **Review Cycle** | Annual / On process or control change | | **Frameworks** | NIST CSF 2.0 GV.SC · NIST 800-53r5 SR · ISO/IEC 27001 A.5.19 through A.5.23 | | **Regulations** | Cross-cutting; privacy, CUI, SOX, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where this template is used | --- ## Table of Contents 1. [Purpose and Use](#1-purpose-and-use) 2. [Template Instructions](#2-template-instructions) 3. [Fill-In Template](#3-fill-in-template) 4. [Review and Approval](#4-review-and-approval) 5. [Document Control](#5-document-control) --- ## 1. Purpose and Use This template captures vendor security intake, questionnaire responses, evidence review, risk rating, required remediation, and approval. It is designed to support repeatable third-party and supply-chain risk decisions without forcing every vendor into the same depth of review. > **Vendor Risk Is Inherited Only If Conditions Hold** > > A SOC 2 report or ISO certificate is not a blanket pass. Reliance depends on the service scope, data processed, subprocessor chain, control exceptions, and the customer responsibilities the organization must actually perform. --- ## 2. Template Instructions 1. Copy this template before use. 2. Replace every bracketed field with case-specific information. 3. Do not delete fields that appear not applicable. Mark them `Not Applicable` and explain why. 4. Use canonical CERG role names from `CERG-GOV-OM-001`. 5. Link risks, findings, exceptions, evidence, and approvals to the system of record. 6. Store the completed artifact in the evidence library governed by `CERG-PRC-AUD-001`. --- ## 3. Fill-In Template ### 3.1 Vendor Intake | **Field** | **Value** | |---|---| | Vendor Name | `[Name]` | | Service Name | `[Service]` | | Business Owner | `[Owner]` | | Vendor Risk Analyst | `[Name]` | | Contract Stage | `[Prospect / Renewal / Existing / Termination]` | | Service Criticality | `[Critical / High / Moderate / Low]` | | Data Classification | `[Highest classification]` | | Personal Data | `[Yes / No]` | | CUI / Regulated Data | `[Yes / No / Details]` | ### 3.2 Questionnaire | **Question** | **Vendor Response** | **Evidence Required** | **Reviewer Notes** | |---|---|---|---| | Does the vendor maintain a security program? | `[Response]` | `[SOC 2 / ISO / policy]` | `[Notes]` | | Is MFA required for administrative access? | `[Response]` | `[Config / policy]` | `[Notes]` | | Is data encrypted in transit and at rest? | `[Response]` | `[Evidence]` | `[Notes]` | | Are vulnerabilities managed with defined SLAs? | `[Response]` | `[Report / policy]` | `[Notes]` | | Are incidents reported within contractual timelines? | `[Response]` | `[Contract / policy]` | `[Notes]` | | Are subprocessors disclosed? | `[Response]` | `[List]` | `[Notes]` | | Is deletion or return supported at termination? | `[Response]` | `[Terms / procedure]` | `[Notes]` | ### 3.3 Risk Decision | **Area** | **Rating / Decision** | **Rationale** | |---|---|---| | Inherent vendor risk | `[Low / Medium / High / Critical]` | `[Rationale]` | | Control evidence quality | `[Strong / Adequate / Weak / None]` | `[Rationale]` | | Residual vendor risk | `[Low / Medium / High / Critical]` | `[Rationale]` | | Required remediation | `[Actions]` | `[Owner and due date]` | | Approval decision | `[Approve / approve with conditions / reject / defer]` | `[Rationale]` | ### 3.4 Business Decision Box | **Decision Question** | **Business Owner Response** | |---|---| | What business capability depends on this vendor? | `[Capability and priority]` | | What decision is being requested? | `[Proceed / proceed with conditions / renew / defer / reject / terminate]` | | What alternatives were considered? | `[Alternative vendors / internal option / delay / no action]` | | What vendor risk conditions must the business fund or enforce? | `[Contract clause / remediation / compensating control / monitoring]` | | What happens if the vendor is not approved or renewal is delayed? | `[Operational, financial, regulatory, or customer consequence]` | | Who owns vendor-risk conditions after approval? | `[Business owner and technical owner]` | --- ## 4. Review and Approval | **Reviewer / Approver** | **Review Meaning** | **Name / Date** | |---|---|---| | Vendor Risk Analyst | Completes assessment and recommended decision. | `[Name / Date]` | | Business Owner | Accepts business need, owns vendor conditions, and confirms whether to proceed, defer, reject, or terminate. | `[Name / Date]` | | Risk Pillar Leader | Approves vendor residual-risk treatment. | `[Name / Date]` | | Chief Information Security Officer (CISO) | Approves High or Critical vendor risk acceptance where required. | `[Name / Date]` | Completed templates are reviewed at the cadence defined by their parent procedure or plan. Material changes require a new review. --- ## 5. Document Control | Field | Value | |---|---| | **Document ID** | CERG-TMPL-TPRM-001 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-05-22 | | **Classification** | Public | | **Owner** | Vendor Risk Analyst | | **Approved By** | CISO | | **Parent Document** | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - Third-Party and Supply Chain Risk Procedure | | **Review Cycle** | Annual; and on process or control change | | **Next Scheduled Review** | 2027-05-22 | | **Frameworks** | NIST CSF 2.0 GV.SC · NIST 800-53r5 SR · ISO/IEC 27001 A.5.19 through A.5.23 | | **Regulations** | Cross-cutting; privacy, CUI, SOX, and contractual obligations where applicable | | **Environments** | All in-scope CERG environments where this template is used | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Vendor Risk Analyst | Added business-facing decision box and Business Owner review line for vendor proceed/defer/reject decisions and post-approval conditions. | | 1.0 | 2026-05-22 | Cyber Governance | Initial release. Establishes a standalone fill-in template for vendor security questionnaire and TPRM assessment template. | ### Review Triggers - Parent procedure or plan change - Audit, assessment, or tabletop finding related to this template - Role or approval model change - Direction from the CISO ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Third-Party and Supply Chain Risk Procedure | [`CERG-PRC-TPRM-001`](../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) | Governing procedure | | Privacy and Data Protection Operational Package | [`CERG-PLN-PRIV-001`](../plans/CERG-PLN-PRIV-001_Privacy_and_Data_Protection_Operational_Package.md) | Privacy vendor evidence interface | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-000 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Family Overview](#1-family-overview) 2. [Roles in This Family](#2-roles-in-this-family) 3. [Family-Level Career Path](#3-family-level-career-path) 4. [Shared Certifications](#4-shared-certifications) 5. [Cross-References](#5-cross-references) 6. [Document Control](#6-document-control) --- ## 1. Family Overview Incident Response (JF-ADJUNCT) — Respond to and investigate cybersecurity incidents. | Attribute | Value | |-----------|-------| | **NICE Categories** | PR (Protect and Defend), IN (Investigate) | | **Entry Grade** | S2 | | **Terminal Grade** | S4/M4 | | **Career Track** | SME / Dual-track | | **Number of Roles** | 2 | This family groups roles that share a core competency profile and career progression path. Members of this family progress through four levels (L1-L4), mapped to CERG's S1-S4/M1-M4 grade framework. See [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md) for the complete level definitions and progression gates. --- ## 2. Roles in This Family | Role | Document | Description | |------|----------|-------------| | **Incident Commander** | [`CERG-GOV-JD-ADJUNCT-001`](CERG-GOV-JD-ADJUNCT-001_Incident_Commander.md) | Single-decision authority during active incidents. Coordinates containment, investigation, recovery, and post-incident lessons learned. | | **Lead Investigator** | [`CERG-GOV-JD-ADJUNCT-002`](CERG-GOV-JD-ADJUNCT-002_Lead_Investigator.md) | Leads technical investigation during incidents. Conducts root cause analysis, evidence collection, and forensic investigation. | --- ## 3. Family-Level Career Path Progression within the Incident Response family follows the standard four-tier structure: - **L1 (Associate)** → **L2 (Practitioner)** → **L3 (Senior)** → **L4 (Principal)** See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for the standard progression gates (L1→L2, L2→L3, L3→L4). See [JF-001 §9](../CERG-GOV-JF-001_Job_Families_Overview.md) for family-specific level definitions. Cross-family movement is encouraged per the [Family-to-Family Career Lattice](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize this movement. --- ## 4. Shared Certifications Certifications relevant to the Incident Response family are detailed in [TRN-001](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md). Each role's certification matrix specifies Required, Recommended, and Aspirational certifications at each grade level. Consult the individual role description for role-specific certification requirements. --- ## 5. Cross-References | Document | ID | Relevance | |----------|-----|-----------| | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure, levels, progression gates | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping for each role | | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-000 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Family-level index for Incident Response (JF-ADJUNCT). | ### Review Triggers - Addition or retirement of a role in this family - Change to the NICE Work Role mappings for roles in this family - Revision to the family-level definitions in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-000 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Family Overview](#1-family-overview) 2. [Roles in This Family](#2-roles-in-this-family) 3. [Family-Level Career Path](#3-family-level-career-path) 4. [Shared Certifications](#4-shared-certifications) 5. [Cross-References](#5-cross-references) 6. [Document Control](#6-document-control) --- ## 1. Family Overview Executive Leadership (JF-EXEC) — Set strategy, approve risk, report to board, lead the function. | Attribute | Value | |-----------|-------| | **NICE Categories** | OV (Oversee and Govern) | | **Entry Grade** | Executive | | **Terminal Grade** | Executive | | **Career Track** | Executive | | **Number of Roles** | 1 | This family groups roles that share a core competency profile and career progression path. Members of this family progress through four levels (L1-L4), mapped to CERG's S1-S4/M1-M4 grade framework. See [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md) for the complete level definitions and progression gates. --- ## 2. Roles in This Family | Role | Document | Description | |------|----------|-------------| | **Chief Information Security Officer (CISO)** | [`CERG-GOV-JD-EXEC-001`](CERG-GOV-JD-EXEC-001_Chief_Information_Security_Officer.md) | Accountable for the cybersecurity program: strategy, board reporting, risk acceptance, budget, and organizational accountability. | --- ## 3. Family-Level Career Path Progression within the Executive Leadership family follows the standard four-tier structure: - **L1 (Associate)** → **L2 (Practitioner)** → **L3 (Senior)** → **L4 (Principal)** See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for the standard progression gates (L1→L2, L2→L3, L3→L4). See [JF-001 §9](../CERG-GOV-JF-001_Job_Families_Overview.md) for family-specific level definitions. Cross-family movement is encouraged per the [Family-to-Family Career Lattice](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize this movement. --- ## 4. Shared Certifications Certifications relevant to the Executive Leadership family are detailed in [TRN-001](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md). Each role's certification matrix specifies Required, Recommended, and Aspirational certifications at each grade level. Consult the individual role description for role-specific certification requirements. --- ## 5. Cross-References | Document | ID | Relevance | |----------|-----|-----------| | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure, levels, progression gates | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping for each role | | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-000 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | CISO | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Family-level index for Executive Leadership (JF-EXEC). | ### Review Triggers - Addition or retirement of a role in this family - Change to the NICE Work Role mappings for roles in this family - Revision to the family-level definitions in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-000 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Family Overview](#1-family-overview) 2. [Roles in This Family](#2-roles-in-this-family) 3. [Family-Level Career Path](#3-family-level-career-path) 4. [Shared Certifications](#4-shared-certifications) 5. [Cross-References](#5-cross-references) 6. [Document Control](#6-document-control) --- ## 1. Family Overview Governance & Compliance (JF-GOVCOMP) — Own policy, compliance posture, risk register, and evidence; translate regulation into action. | Attribute | Value | |-----------|-------| | **NICE Categories** | OV (Oversee and Govern) | | **Entry Grade** | S1 | | **Terminal Grade** | S4/M3 | | **Career Track** | SME / Dual-track | | **Number of Roles** | 6 | This family groups roles that share a core competency profile and career progression path. Members of this family progress through four levels (L1-L4), mapped to CERG's S1-S4/M1-M4 grade framework. See [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md) for the complete level definitions and progression gates. --- ## 2. Roles in This Family | Role | Document | Description | |------|----------|-------------| | **NERC-CIP Compliance Manager** | [`CERG-GOV-JD-GOVCOMP-001`](CERG-GOV-JD-GOVCOMP-001_NERC-CIP_Compliance_Manager.md) | Owns NERC-CIP compliance: CIP standards adherence, evidence collection, regulatory filings, and audit readiness. | | **CMMC / Federal Compliance Manager** | [`CERG-GOV-JD-GOVCOMP-002`](CERG-GOV-JD-GOVCOMP-002_CMMC_Federal_Compliance_Manager.md) | Owns CMMC and federal compliance: CUI handling, SSP maintenance, POA&M management, and assessor engagement. | | **SOX ITGC Lead** | [`CERG-GOV-JD-GOVCOMP-003`](CERG-GOV-JD-GOVCOMP-003_SOX_ITGC_Lead.md) | Owns SOX ITGC compliance: control design, operating effectiveness testing, control evidence, and auditor liaison. | | **Policy & Standards Manager** | [`CERG-GOV-JD-GOVCOMP-004`](CERG-GOV-JD-GOVCOMP-004_Policy_and_Standards_Manager.md) | Owns the policy and standards library: authoring, maintenance, version control, and cross-reference integrity. | | **Risk Register Owner** | [`CERG-GOV-JD-GOVCOMP-005`](CERG-GOV-JD-GOVCOMP-005_Risk_Register_Owner.md) | Owns the enterprise risk register: risk identification, scoring, treatment tracking, acceptance, and reporting. | | **Evidence Librarian** | [`CERG-GOV-JD-GOVCOMP-006`](CERG-GOV-JD-GOVCOMP-006_Evidence_Librarian.md) | Owns the evidence library: collection, validation, freshness monitoring, chain of custody, and audit package assembly. | --- ## 3. Family-Level Career Path Progression within the Governance & Compliance family follows the standard four-tier structure: - **L1 (Associate)** → **L2 (Practitioner)** → **L3 (Senior)** → **L4 (Principal)** See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for the standard progression gates (L1→L2, L2→L3, L3→L4). See [JF-001 §9](../CERG-GOV-JF-001_Job_Families_Overview.md) for family-specific level definitions. Cross-family movement is encouraged per the [Family-to-Family Career Lattice](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize this movement. --- ## 4. Shared Certifications Certifications relevant to the Governance & Compliance family are detailed in [TRN-001](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md). Each role's certification matrix specifies Required, Recommended, and Aspirational certifications at each grade level. Consult the individual role description for role-specific certification requirements. --- ## 5. Cross-References | Document | ID | Relevance | |----------|-----|-----------| | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure, levels, progression gates | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping for each role | | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-000 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Family-level index for Governance & Compliance (JF-GOVCOMP). | ### Review Triggers - Addition or retirement of a role in this family - Change to the NICE Work Role mappings for roles in this family - Revision to the family-level definitions in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-000 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Family Overview](#1-family-overview) 2. [Roles in This Family](#2-roles-in-this-family) 3. [Family-Level Career Path](#3-family-level-career-path) 4. [Shared Certifications](#4-shared-certifications) 5. [Cross-References](#5-cross-references) 6. [Document Control](#6-document-control) --- ## 1. Family Overview Risk Operations (JF-RISKOPS) — Maintain continuous visibility into organizational exposure; test controls; drive remediation. | Attribute | Value | |-----------|-------| | **NICE Categories** | PR (Protect and Defend), AN (Analyze) | | **Entry Grade** | S1 | | **Terminal Grade** | S4/M3 | | **Career Track** | SME / Dual-track | | **Number of Roles** | 7 | This family groups roles that share a core competency profile and career progression path. Members of this family progress through four levels (L1-L4), mapped to CERG's S1-S4/M1-M4 grade framework. See [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md) for the complete level definitions and progression gates. --- ## 2. Roles in This Family | Role | Document | Description | |------|----------|-------------| | **Exposure Management Lead** | [`CERG-GOV-JD-RISKOPS-001`](CERG-GOV-JD-RISKOPS-001_Exposure_Management_Lead.md) | Owns the exposure management program: scanning, triage, SLA-driven remediation tracking. | | **Adversarial Testing Lead** | [`CERG-GOV-JD-RISKOPS-002`](CERG-GOV-JD-RISKOPS-002_Adversarial_Testing_Lead.md) | Owns adversarial testing: pen testing, red team operations, purple team exercises, and control validation. | | **Threat Intelligence Analyst** | [`CERG-GOV-JD-RISKOPS-003`](CERG-GOV-JD-RISKOPS-003_Threat_Intelligence_Analyst.md) | Owns threat intelligence collection, analysis, production, and dissemination. | | **Detection Engineer** | [`CERG-GOV-JD-RISKOPS-004`](CERG-GOV-JD-RISKOPS-004_Detection_Engineer.md) | Owns detection engineering: SIEM rules, detection pipelines, ATT&CK coverage, signal-to-noise optimization. | | **OT Risk Analyst** | [`CERG-GOV-JD-RISKOPS-005`](CERG-GOV-JD-RISKOPS-005_OT_Risk_Analyst.md) | Owns OT/ICS risk assessment, threat analysis for grid control systems, and OT vulnerability prioritization. | | **Identity Risk Analyst** | [`CERG-GOV-JD-RISKOPS-006`](CERG-GOV-JD-RISKOPS-006_Identity_Risk_Analyst.md) | Owns identity risk analysis: privileged access risk, identity hygiene, credential exposure monitoring. | | **Vendor Risk Analyst** | [`CERG-GOV-JD-RISKOPS-007`](CERG-GOV-JD-RISKOPS-007_Vendor_Risk_Analyst.md) | Owns TPRM: vendor security assessments, supply chain risk monitoring, vendor remediation tracking. | --- ## 3. Family-Level Career Path Progression within the Risk Operations family follows the standard four-tier structure: - **L1 (Associate)** → **L2 (Practitioner)** → **L3 (Senior)** → **L4 (Principal)** See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for the standard progression gates (L1→L2, L2→L3, L3→L4). See [JF-001 §9](../CERG-GOV-JF-001_Job_Families_Overview.md) for family-specific level definitions. Cross-family movement is encouraged per the [Family-to-Family Career Lattice](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize this movement. --- ## 4. Shared Certifications Certifications relevant to the Risk Operations family are detailed in [TRN-001](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md). Each role's certification matrix specifies Required, Recommended, and Aspirational certifications at each grade level. Consult the individual role description for role-specific certification requirements. --- ## 5. Cross-References | Document | ID | Relevance | |----------|-----|-----------| | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure, levels, progression gates | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping for each role | | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-000 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Family-level index for Risk Operations (JF-RISKOPS). | ### Review Triggers - Addition or retirement of a role in this family - Change to the NICE Work Role mappings for roles in this family - Revision to the family-level definitions in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-000 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Family Overview](#1-family-overview) 2. [Roles in This Family](#2-roles-in-this-family) 3. [Family-Level Career Path](#3-family-level-career-path) 4. [Shared Certifications](#4-shared-certifications) 5. [Cross-References](#5-cross-references) 6. [Document Control](#6-document-control) --- ## 1. Family Overview Security Engineering (JF-SECENG) — Design and build secure systems, platforms, and infrastructure. | Attribute | Value | |-----------|-------| | **NICE Categories** | SP (Securely Provision), OM (Operate and Maintain) | | **Entry Grade** | S1 | | **Terminal Grade** | S4 | | **Career Track** | SME (Individual Contributor) | | **Number of Roles** | 6 | This family groups roles that share a core competency profile and career progression path. Members of this family progress through four levels (L1-L4), mapped to CERG's S1-S4/M1-M4 grade framework. See [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md) for the complete level definitions and progression gates. --- ## 2. Roles in This Family | Role | Document | Description | |------|----------|-------------| | **Cloud Security Engineer** | [`CERG-GOV-JD-SECENG-001`](CERG-GOV-JD-SECENG-001_Cloud_Security_Engineer.md) | Owns cloud platform security architecture, IaC security, CSPM operations, and SaaS security. | | **Identity Engineer** | [`CERG-GOV-JD-SECENG-002`](CERG-GOV-JD-SECENG-002_Identity_Engineer.md) | Owns identity fabric: IAM architecture, PAM, federation, directory services, and access governance. | | **OT Security Engineer** | [`CERG-GOV-JD-SECENG-003`](CERG-GOV-JD-SECENG-003_OT_Security_Engineer.md) | Owns OT/ICS security architecture, network segmentation, secure remote access, and grid control system defense. | | **Application Security Engineer** | [`CERG-GOV-JD-SECENG-004`](CERG-GOV-JD-SECENG-004_Application_Security_Engineer.md) | Owns secure SDLC, SAST/DAST integration, application threat modeling, and developer security enablement. | | **Endpoint Engineer** | [`CERG-GOV-JD-SECENG-005`](CERG-GOV-JD-SECENG-005_Endpoint_Engineer.md) | Owns endpoint security architecture, secure configuration baselines, EDR/XDR operations, and mobile device security. | | **Cryptography Engineer** | [`CERG-GOV-JD-SECENG-006`](CERG-GOV-JD-SECENG-006_Cryptography_Engineer.md) | Owns cryptography architecture, PKI, key management, encryption standards, and cryptographic agility. | --- ## 3. Family-Level Career Path Progression within the Security Engineering family follows the standard four-tier structure: - **L1 (Associate)** → **L2 (Practitioner)** → **L3 (Senior)** → **L4 (Principal)** See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for the standard progression gates (L1→L2, L2→L3, L3→L4). See [JF-001 §9](../CERG-GOV-JF-001_Job_Families_Overview.md) for family-specific level definitions. Cross-family movement is encouraged per the [Family-to-Family Career Lattice](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize this movement. --- ## 4. Shared Certifications Certifications relevant to the Security Engineering family are detailed in [TRN-001](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md). Each role's certification matrix specifies Required, Recommended, and Aspirational certifications at each grade level. Consult the individual role description for role-specific certification requirements. --- ## 5. Cross-References | Document | ID | Relevance | |----------|-----|-----------| | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure, levels, progression gates | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping for each role | | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Behavioral anchors | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | --- ## 6. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-000 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Family-level index for Security Engineering (JF-SECENG). | ### Review Triggers - Addition or retirement of a role in this family - Change to the NICE Work Role mappings for roles in this family - Revision to the family-level definitions in JF-001 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JF-001 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [What a Job Family Is](#2-what-a-job-family-is) 3. [The Five CERG Job Families](#3-the-five-cerg-job-families) 4. [Family-to-Family Career Lattice](#4-family-to-family-career-lattice) 5. [Why Five Families Instead of Three](#5-why-five-families-instead-of-three) 6. [Job Levels Within Each Family](#6-job-levels-within-each-family) 7. [How Levels Interact With CERG's Grade Framework](#7-how-levels-interact-with-cergs-grade-framework) 8. [Level Progression Gates](#8-level-progression-gates) 9. [Per-Family Level Definitions](#9-per-family-level-definitions) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope This document establishes the formal Job Family structure for CERG's workforce architecture. It groups the 27 canonical CERG roles into five job families, defines career progression tiers within each family, and maps those tiers to CERG's existing grade framework (S1-S4 / M1-M4). This document does NOT rename, add, or remove canonical roles. The authoritative role roster remains [OM-001 §6.1](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md). Job families are a VIEW into the role architecture — a career-development and hiring lens — not a replacement for the operating model's pillar structure. ### 1.1 Workforce System Map Use the workforce documents in this order: | **Question** | **Use** | **Do Not Use It For** | |---|---|---| | What roles exist and what pillar owns them? | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 | Career level or job-posting detail | | Who does what in processes and artifacts? | [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Changing the role roster | | What job family does a role belong to? | This document | Approval authority or process RACI | | What grade or level is the role? | [`CERG-GOV-JA-001`](../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Operating accountability | | What competencies and behaviors matter? | [`CERG-GOV-CMP-001`](../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Document ownership | | What does an individual role description look like? | The per-role JD under `roles/jf-*` | Rewriting CERG's operating model | | How does NICE map to CERG roles? | [`CERG-GOV-JF-002`](CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | Replacing CERG role names | --- ## 2. What a Job Family Is A Job Family is a grouping of similar roles that share a core competency profile, career progression path, and broad functional purpose. Job families enable: - **Career tracks.** A person can see: "I am in the Security Engineering family. From here I can progress to Advisor, Sr. Advisor, or laterally to the Risk Operations family." - **Hiring clarity.** Requisitions are opened against a family, a level, and a specific role. HR and compensation can calibrate within and across families. - **Training alignment.** Certification and training pathways are defined per family, not per role. --- ## 3. The Five CERG Job Families | Family ID | Family Name | Description | CERG Roles (Canonical) | NICE Categories | Entry Grade | Terminal Grade | |-----------|-------------|-------------|------------------------|-----------------|-------------|----------------| | **JF-SECENG** | Security Engineering | Design and build secure systems, platforms, and infrastructure | Cloud Security Engineer, Identity Engineer, OT Security Engineer, Application Security Engineer, Endpoint Engineer, Cryptography Engineer | SP, OM | S1 | S4 | | **JF-RISKOPS** | Risk Operations | Maintain continuous visibility into organizational exposure; test controls; drive remediation | Exposure Management Lead, Adversarial Testing Lead, Threat Intelligence Analyst, Detection Engineer, OT Risk Analyst, Identity Risk Analyst, Vendor Risk Analyst | PR, AN | S1 | S4/M3 | | **JF-GOVCOMP** | Governance & Compliance | Own policy, compliance posture, risk register, and evidence; translate regulation into action | NERC-CIP Compliance Manager, CMMC/Federal Compliance Manager, SOX ITGC Lead, Policy & Standards Manager, Risk Register Owner, Evidence Librarian | OV | S1 | S4/M3 | | **JF-EXEC** | Cybersecurity Executive Leadership | Set strategy, approve risk, report to board, lead the function | Chief Information Security Officer (CISO) | OV | Executive | Executive | | **JF-ADJUNCT** | Incident Response & Investigation | Respond to and investigate cybersecurity incidents | Incident Commander, Lead Investigator | PR, IN | S2 | S4/M4 | --- ## 4. Family-to-Family Career Lattice ``` ┌──────────────────────────────────────┐ │ JF-EXEC (CISO) │ │ Entry: Executive | Terminal: Exec │ └──────────────────────────────────────┘ ▲ ┌───────────────────────────┼───────────────────────────┐ │ │ │ ┌─────────┴─────────┐ ┌──────────┴──────────┐ ┌──────────┴──────────┐ │ JF-SECENG │ │ JF-RISKOPS │ │ JF-GOVCOMP │ │ Security Eng. │◄───►│ Risk Operations │◄───►│ Governance & │ │ S1→S4 │ │ S1→S4/M3 │ │ Compliance │ │ │ │ │ │ S1→S4/M3 │ └─────────┬─────────┘ └──────────┬───────────┘ └──────────┬──────────┘ │ │ │ └───────────────────────────┼───────────────────────────┘ │ ┌───────────┴───────────┐ │ JF-ADJUNCT │ │ Incident Response │ │ S2→S4/M4 │ └───────────────────────┘ ``` Left-right arrows (◄──►) indicate encouraged cross-family movement. Vertical arrows indicate progression toward executive leadership. CERG's existing "Left-Right Knowledge Model" ([FRM-001 §9.2](../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) are the operational mechanisms that make this lattice real. --- ## 5. Why Five Families Instead of Three The current three-pillar structure (Engineering, Risk, Governance) works well for the operating model but conflates functional grouping with career grouping: - **Engineering Pillar** maps cleanly to JF-SECENG (one family = one pillar). No change needed. - **Risk Pillar** contains two distinct functional families: JF-RISKOPS (exposure management, threat intel, detection — operations work) and adjacent roles that are more incident-response-oriented (JF-ADJUNCT). The current structure puts Detection Engineer and Threat Intelligence Analyst in the same pillar as Vendor Risk Analyst, but their day-to-day work, certifications, and career paths differ significantly. This proposal keeps them in the same pillar operationally but gives them distinct family designations for career development. - **Governance Pillar** maps cleanly to JF-GOVCOMP (one family = one pillar). No change needed. The distinction between JF-RISKOPS and JF-ADJUNCT is important: Incident Commander and Lead Investigator are NOT CERG roles (they belong to the standing IR team per [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4). They appear in CERG documents only for cross-functional clarity. Giving them their own family makes this boundary explicit in the career architecture. --- ## 6. Job Levels Within Each Family Each Job Family has 4 tiers that map directly to CERG's existing SME grade structure (S1-S4) and Management grade structure (M1-M4). This section defines what each tier means WITHIN each family — providing family-specific expectations that a hiring manager and a team member can reference without consulting multiple documents. See Section 9 for per-family level definition tables. --- ## 7. How Levels Interact With CERG's Grade Framework The Job Family levels (L1-L4) are a VIEW into the grade framework, not a replacement for it. Think of them as: - **CERG Grades (S1-S4, M1-M4)** = the internal calibration standard used by HR, compensation, and promotion panels. These are precise, defined in [JA-001](../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md), and carry compensation bands. - **Job Family Levels (L1-L4)** = the external-facing and career-development language. These appear in job postings, career conversations, and succession plans. The mapping is: ``` Job Family Level | SME Track Grade | Management Track Grade L1 | S1 | N/A L2 | S2 | N/A L3 | S3 | M1-M2 L4 | S4 | M3-M4 ``` An "L3 Security Engineer" could be an S3 Advisor (SME track) or an M1 Manager (Management track). The external title is the same; the internal grade reflects whether their primary contribution is through individual expertise or people leadership. --- ## 8. Level Progression Gates Progression from one level to the next requires demonstration of capabilities. The gates below define what a promotion case must show. These supplement (not replace) the JA-001 grade definitions and [CMP-001](../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) behavioral anchors. ### 8.1 L1 → L2 Gate (All Families) - Has completed at least one full cycle of the family's core process (e.g., for JF-SECENG: a project from intake to go-live; for JF-GOVCOMP: a compliance cycle from preparation to audit close) - No longer needs direction on daily work - Has identified and corrected at least one process gap or documentation error - Peer feedback confirms reliability ### 8.2 L2 → L3 Gate (All Families) - Has led at least one cross-pillar initiative or authored/revised a standard or procedure - Has formally mentored at least one L1 or L2 team member (documented in [PERF-001](../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md)) - Has represented the pillar in at least two cross-functional forums or engagements - Manager confirms self-direction against objectives ### 8.3 L3 → L4 Gate (All Families) - Has contributed to CISO-level decisions (documented: strategy input, risk assessment, budget recommendation) - Has mentored across pillars, not just within the home pillar - Has represented the organization externally (conference, regulatory forum, industry working group, publication) - Peer pillar leaders confirm cross-organizational influence - For JF-SECENG specifically: has authored at least one standard or reference architecture adopted organization-wide - For JF-RISKOPS specifically: has led an organization-wide risk posture assessment - For JF-GOVCOMP specifically: has represented the organization to an external auditor or regulator without supervision --- ## 9. Per-Family Level Definitions ### 9.1 JF-SECENG — Security Engineering Levels | Tier | CERG Grade(s) | Title Suffix | Scope | Autonomy | Influence | Key Differentiator | |------|--------------|--------------|-------|----------|-----------|-------------------| | **L1: Associate Engineer** | S1 | "Associate" or "I" | Single domain, defined tasks | Requires direction on approach | Immediate team | Follows engineering procedures | | **L2: Engineer** | S2 | (no suffix) or "II" | Primary domain + awareness of adjacencies | Independent day-to-day | Recognized within pillar | Owns engineering work streams end-to-end | | **L3: Senior Engineer** | S3 | "Senior" or "Staff" | Cross-pillar awareness; shapes engineering approach | Self-directed against objectives | Trusted by pillar leaders | Authors standards and leads engineering initiatives | | **L4: Principal Engineer** | S4 | "Principal" or "Distinguished" | Organization-wide; sets engineering agenda | Defines what problems matter | Influences CISO-level decisions | Sets the technical bar for the entire pillar | | **Engineering Manager** | M1-M3 | "Manager," "Senior Manager" | Team/function/pillar-segment | Translates goals into plans | Team and cross-team | Delivers through others; develops engineers | | **Director of Engineering** | M4 | "Director" | Full Engineering pillar | Sets multi-year direction | CISO, board, regulators | Pillar leader accountability | ### 9.2 JF-RISKOPS — Risk Operations Levels | Tier | CERG Grade(s) | Title Suffix | Scope | Key Differentiator | |------|--------------|--------------|-------|-------------------| | **L1: Associate Analyst** | S1 | "Associate" or "I" | Single risk domain (e.g., vulnerability scanning, basic threat feed triage) | Follows risk procedures | | **L2: Analyst** | S2 | (no suffix) or "II" | Primary domain; owns a risk work stream | Independently operates risk processes | | **L3: Senior Analyst** | S3 | "Senior" or "Lead" | Cross-pillar; shapes risk assessment approach | Authors risk procedures; mentors analysts | | **L4: Principal Analyst** | S4 | "Principal" or "Distinguished" | Organization-wide risk posture | Influences CISO risk decisions | | **Risk Operations Manager** | M1-M3 | "Manager," "Senior Manager" | Team/function within Risk | Leads risk operations teams | ### 9.3 JF-GOVCOMP — Governance & Compliance Levels | Tier | CERG Grade(s) | Title Suffix | Scope | Key Differentiator | |------|--------------|--------------|-------|-------------------| | **L1: Associate** | S1 | "Associate" or "I" | Single compliance domain (e.g., evidence collection for one framework) | Follows governance procedures | | **L2: Specialist** | S2 | (no suffix) or "II" | Owns a compliance work stream (e.g., one regulatory framework) | Independently manages compliance activities | | **L3: Senior Specialist** | S3 | "Senior" or "Lead" | Cross-framework; shapes compliance approach | Authors compliance procedures; represents org to auditors | | **L4: Principal Specialist** | S4 | "Principal" or "Distinguished" | Organization-wide governance | Influences regulatory strategy; trusted by CISO | | **Governance Manager** | M1-M3 | "Manager," "Senior Manager" | Team/function within Governance | Leads compliance teams | | **Director of Governance** | M4 | "Director" | Full Governance pillar | Pillar leader accountability | ### 9.4 JF-EXEC — Executive Leadership Levels | Tier | Grade | Title | Scope | Key Differentiator | |------|-------|-------|-------|-------------------| | **L1: CISO** | Executive | Chief Information Security Officer | Full cybersecurity program | See [JD-001 §3.1](../governance/CERG-GOV-JD-001_CERG_Job_Descriptions.md) for full description | ### 9.5 JF-ADJUNCT — Incident Response Levels | Tier | CERG Grade | Title | Scope | Key Differentiator | |------|-----------|-------|-------|-------------------| | **L2: Investigator** | S2 | "Investigator" or "Responder" | Executes IR procedures under IC direction | Operates during incidents | | **L3: Senior Investigator** | S3 | "Senior Investigator" | Leads investigation workstreams | Technical lead during incidents | | **L4: Incident Commander** | S4/M4 | "Incident Commander" | Single-decision authority during active incidents | Highest IR authority per incident | --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JF-001 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader | Added workforce system map showing which workforce document answers each role, RACI, family, grade, competency, JD, and NICE-mapping question. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Established five CERG Job Families, four-tier level structure, progression gates, and mapping to existing grade framework. | ### Review Triggers - Addition or retirement of a canonical role in [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to the NICE Workforce Framework affecting CERG role mappings - Revision to JA-001 grade definitions - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Consolidated Roles and RACI | [`CERG-GOV-RAC-001`](../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | Role descriptions and RACI assignments | | Job Architecture | [`CERG-GOV-JA-001`](../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE mapping for each role | --- | | | |---|---| | **Document ID** | CERG-GOV-JF-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; or upon NICE framework update | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- ## Table of Contents 1. [Purpose and Scope](#1-purpose-and-scope) 2. [Mapping Methodology](#2-mapping-methodology) 3. [JF-SECENG — Security Engineering NICE Mapping](#3-jf-seceng--security-engineering-nice-mapping) 4. [JF-RISKOPS — Risk Operations NICE Mapping](#4-jf-riskops--risk-operations-nice-mapping) 5. [JF-GOVCOMP — Governance & Compliance NICE Mapping](#5-jf-govcomp--governance--compliance-nice-mapping) 6. [JF-EXEC — Executive Leadership NICE Mapping](#6-jf-exec--executive-leadership-nice-mapping) 7. [JF-ADJUNCT — Incident Response NICE Mapping](#7-jf-adjunct--incident-response-nice-mapping) 8. [Complete Crosswalk Table](#8-complete-crosswalk-table) 9. [NICE Work Role Categories Reference](#9-nice-work-role-categories-reference) 10. [Document Control](#10-document-control) --- ## 1. Purpose and Scope This document provides the complete mapping of all 27 canonical CERG roles to NIST NICE Work Roles (NIST SP 800-181r1). It is the authoritative crosswalk for CERG's workforce architecture, enabling: - **Hiring precision.** Job postings can reference NICE work roles so candidates from other industries understand the role immediately. - **Regulatory alignment.** NERC-CIP, CMMC, and DoD 8140.03 all reference NICE; CERG compliance managers benefit from a shared taxonomy with their regulators. - **Skills-gap analysis.** Mapping CERG roles to NICE TKS statements enables systematic identification of team-wide skill gaps. - **Career portability.** Team members who understand their NICE mapping can pursue external certifications and career paths aligned to recognized standards. --- ## 2. Mapping Methodology Each CERG canonical role is mapped to 1–3 NICE Work Roles. The mapping follows these rules: 1. **Primary NICE Work Role** = the single NICE role that most closely describes the CERG role's core accountability. If a job posting references only one NICE code, use this one. 2. **Secondary NICE Work Role(s)** = NICE roles that describe significant portions of the CERG role's work. Useful for skills-gap analysis. 3. **NICE Work Role Category** = the high-level category the primary role belongs to. Used for job family alignment. **Note on NICE Work Role IDs:** The IDs below use a simplified format (e.g., `SP-ARC-001`) for readability. Actual NIST SP 800-181r1 Work Role IDs should be verified against the authoritative source at https://niccs.cisa.gov/tools/nice-framework. --- ## 3. JF-SECENG — Security Engineering NICE Mapping | CERG Canonical Role | Primary NICE Work Role | Primary NICE Code | Secondary NICE Work Role(s) | NICE Category | |---------------------|----------------------|-------------------|-----------------------------|--------------| | **Cloud Security Engineer** | Security Architect | SP-ARC-001 | Systems Security Analyst (OM-ANA-001), Enterprise Architect (SP-ARC-002) | SP | | **Identity Engineer** | Systems Security Analyst | OM-ANA-001 | Security Architect (SP-ARC-001) | OM / SP | | **OT Security Engineer** | Security Architect | SP-ARC-001 | Systems Security Analyst (OM-ANA-001), Network Operations Specialist (OM-NET-001) | SP | | **Application Security Engineer** | Secure Software Assessor | SP-DEV-001 | Software Developer (SP-DEV-002), Vulnerability Assessment Analyst (PR-VAM-001) | SP | | **Endpoint Engineer** | Systems Security Analyst | OM-ANA-001 | Cyber Defense Infrastructure Support (PR-INF-001) | OM | | **Cryptography Engineer** | Security Architect | SP-ARC-001 | Systems Security Analyst (OM-ANA-001) | SP | --- ## 4. JF-RISKOPS — Risk Operations NICE Mapping | CERG Canonical Role | Primary NICE Work Role | Primary NICE Code | Secondary NICE Work Role(s) | NICE Category | |---------------------|----------------------|-------------------|-----------------------------|--------------| | **Exposure Management Lead** | Vulnerability Assessment Analyst | PR-VAM-001 | Cyber Defense Analyst (PR-CDA-001), Security Control Assessor (OV-SCA-001) | PR | | **Adversarial Testing Lead** | Vulnerability Assessment Analyst | PR-VAM-001 | (limited CO overlap) | PR | | **Threat Intelligence Analyst** | Threat/Warning Analyst | AN-TWA-001 | All-Source Analyst (AN-ASA-001), Cyber Intelligence Planner (CO-CIP-001) | AN | | **Detection Engineer** | Cyber Defense Analyst | PR-CDA-001 | Systems Security Analyst (OM-ANA-001), Threat/Warning Analyst (AN-TWA-001) | PR | | **OT Risk Analyst** | Threat/Warning Analyst | AN-TWA-001 | Vulnerability Assessment Analyst (PR-VAM-001) | AN | | **Identity Risk Analyst** | Cyber Defense Analyst | PR-CDA-001 | Systems Security Analyst (OM-ANA-001) | PR | | **Vendor Risk Analyst** | Security Control Assessor | OV-SCA-001 | Threat/Warning Analyst (AN-TWA-001) | OV | --- ## 5. JF-GOVCOMP — Governance & Compliance NICE Mapping | CERG Canonical Role | Primary NICE Work Role | Primary NICE Code | Secondary NICE Work Role(s) | NICE Category | |---------------------|----------------------|-------------------|-----------------------------|--------------| | **NERC-CIP Compliance Manager** | Security Control Assessor | OV-SCA-001 | Systems Authorization (OV-SAA-001), Cyber Policy and Strategy Planner (OV-PSP-001) | OV | | **CMMC / Federal Compliance Manager** | Security Control Assessor | OV-SCA-001 | Systems Authorization (OV-SAA-001), Cyber Policy and Strategy Planner (OV-PSP-001) | OV | | **SOX ITGC Lead** | Security Control Assessor | OV-SCA-001 | IT Program Auditor (OV-PMA-001) | OV | | **Policy & Standards Manager** | Cyber Policy and Strategy Planner | OV-PSP-001 | Cyber Workforce Developer and Manager (OV-WDM-001), Information Systems Security Manager (OV-ISSN-001) | OV | | **Risk Register Owner** | Information Systems Security Manager | OV-ISSN-001 | Security Control Assessor (OV-SCA-001) | OV | | **Evidence Librarian** | Security Control Assessor | OV-SCA-001 | Knowledge Manager (OM-KMG-001) | OV | --- ## 6. JF-EXEC — Executive Leadership NICE Mapping | CERG Canonical Role | Primary NICE Work Role | Primary NICE Code | NICE Category | |---------------------|----------------------|-------------------|---------------| | **Chief Information Security Officer (CISO)** | Executive Cyber Leader | OG-WRL-001 | OV | | **Executive Sponsor** | (Business-side role; not mapped to NICE) | N/A | N/A | --- ## 7. JF-ADJUNCT — Incident Response NICE Mapping | CERG Canonical Role | Primary NICE Work Role | Primary NICE Code | NICE Category | Notes | |---------------------|----------------------|-------------------|---------------|-------| | **Incident Commander** | Cyber Defense Incident Responder | PR-CIR-001 | PR | Not a CERG role per [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4; mapped for cross-reference | | **Lead Investigator** | Cyber Defense Incident Responder | PR-CIR-001 | PR | Not a CERG role per [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4; mapped for cross-reference | --- ## 8. Complete Crosswalk Table This table provides the complete mapping of all 27 canonical CERG roles plus the three Pillar Leaders to NICE Work Roles. It is the single-source reference for NICE alignment. | CERG Canonical Role | Job Family | CERG Pillar | Primary NICE Work Role | NICE Category | Secondary NICE Work Role(s) | NICE Work Role ID (Primary) | |---------------------|-----------|-------------|----------------------|---------------|-----------------------------|----------------------------| | Chief Information Security Officer (CISO) | JF-EXEC | Executive | Executive Cyber Leader | OV | — | OG-WRL-001 | | Executive Sponsor | JF-EXEC | Business/Executive | (Business role; N/A) | — | — | — | | Engineering Pillar Leader | JF-SECENG | Engineering | Executive Cyber Leader / Security Architect | OV / SP | — | OG-WRL-001 / SP-ARC-001 | | Cloud Security Engineer | JF-SECENG | Engineering | Security Architect | SP | Systems Security Analyst | SP-ARC-001 | | Identity Engineer | JF-SECENG | Engineering | Systems Security Analyst | OM | Security Architect | OM-ANA-001 | | OT Security Engineer | JF-SECENG | Engineering | Security Architect | SP | Systems Security Analyst | SP-ARC-001 | | Application Security Engineer | JF-SECENG | Engineering | Secure Software Assessor | SP | Software Developer | SP-DEV-001 | | Endpoint Engineer | JF-SECENG | Engineering | Systems Security Analyst | OM | Cyber Defense Infrastructure Support | OM-ANA-001 | | Cryptography Engineer | JF-SECENG | Engineering | Security Architect | SP | Systems Security Analyst | SP-ARC-001 | | Pre-production Reviewer | JF-SECENG | Engineering | Security Control Assessor | OV | Systems Security Analyst | OV-SCA-001 | | Risk Pillar Leader | JF-RISKOPS | Risk | Executive Cyber Leader / Vulnerability Assessment Analyst | OV / PR | — | OG-WRL-001 / PR-VAM-001 | | Exposure Management Lead | JF-RISKOPS | Risk | Vulnerability Assessment Analyst | PR | Cyber Defense Analyst | PR-VAM-001 | | Adversarial Testing Lead | JF-RISKOPS | Risk | Vulnerability Assessment Analyst | PR | (limited CO overlap) | PR-VAM-001 | | Threat Intelligence Analyst | JF-RISKOPS | Risk | Threat/Warning Analyst | AN | All-Source Analyst | AN-TWA-001 | | Detection Engineer | JF-RISKOPS | Risk | Cyber Defense Analyst | PR | Systems Security Analyst | PR-CDA-001 | | OT Risk Analyst | JF-RISKOPS | Risk | Threat/Warning Analyst | AN | Vulnerability Assessment Analyst | AN-TWA-001 | | Identity Risk Analyst | JF-RISKOPS | Risk | Cyber Defense Analyst | PR | Systems Security Analyst | PR-CDA-001 | | Vendor Risk Analyst | JF-RISKOPS | Risk | Security Control Assessor | OV | Threat/Warning Analyst | OV-SCA-001 | | Governance Pillar Leader | JF-GOVCOMP | Governance | Executive Cyber Leader / Security Control Assessor | OV | — | OG-WRL-001 / OV-SCA-001 | | NERC-CIP Compliance Manager | JF-GOVCOMP | Governance | Security Control Assessor | OV | Systems Authorization | OV-SCA-001 | | CMMC / Federal Compliance Manager | JF-GOVCOMP | Governance | Security Control Assessor | OV | Systems Authorization | OV-SCA-001 | | SOX ITGC Lead | JF-GOVCOMP | Governance | Security Control Assessor | OV | IT Program Auditor | OV-SCA-001 | | Policy & Standards Manager | JF-GOVCOMP | Governance | Cyber Policy and Strategy Planner | OV | Cyber Workforce Developer and Manager | OV-PSP-001 | | Risk Register Owner | JF-GOVCOMP | Governance | Information Systems Security Manager | OV | Security Control Assessor | OV-ISSN-001 | | Evidence Librarian | JF-GOVCOMP | Governance | Security Control Assessor | OV | Knowledge Manager | OV-SCA-001 | | Incident Commander | JF-ADJUNCT | Adjacent (IR) | Cyber Defense Incident Responder | PR | — | PR-CIR-001 | | Lead Investigator | JF-ADJUNCT | Adjacent (IR) | Cyber Defense Incident Responder | PR | Cyber Crime Investigator | PR-CIR-001 | --- ## 9. NICE Work Role Categories Reference The seven NICE Work Role Categories (NIST SP 800-181r1) with their official descriptions: | Category Code | Category Name | Official NICE Description | |---------------|---------------|---------------------------| | **SP** | Securely Provision | Conceptualizes, designs, procures, and/or builds secure information technology (IT) systems, with responsibility for aspects of system and/or network development. | | **OM** | Operate and Maintain | Provides the support, administration, and maintenance necessary to ensure effective and efficient information technology (IT) system performance and security. | | **OV** | Oversee and Govern | Provides leadership, management, direction, or development and advocacy so the organization may effectively conduct cybersecurity work. | | **PR** | Protect and Defend | Identifies, analyzes, and mitigates threats to internal information technology (IT) systems and/or networks. | | **AN** | Analyze | Performs highly-specialized review and evaluation of incoming cybersecurity information to determine its usefulness for intelligence. | | **CO** | Collect and Operate | Provides specialized denial and deception operations and collection of cybersecurity information that may be used to develop intelligence. | | **IN** | Investigate | Investigates cybersecurity events or crimes related to information technology (IT) systems, networks, and digital evidence. | **Reference:** NIST SP 800-181r1, Workforce Framework for Cybersecurity (NICE Framework). Available at https://www.nist.gov/itl/applied-cybersecurity/nice --- ## 10. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JF-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader (Policy & Standards) | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual; or upon NICE framework update | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Complete NICE-to-CERG crosswalk for all 27 canonical roles, plus Pillar Leaders. Includes NICE Work Role Categories reference. | ### Review Triggers - Update to NIST SP 800-181r1 (NICE Framework) - Addition or retirement of a canonical role in [CERG-GOV-OM-001](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change in NICE Work Role codes or categories - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](CERG-GOV-JF-001_Job_Families_Overview.md) | Job family structure and level definitions | | CERG Operating Model | [`CERG-GOV-OM-001`](../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role roster | | Competency Model | [`CERG-GOV-CMP-001`](../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Competency-to-NICE crosswalk | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Adversarial Testing Lead **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Adversarial Testing Lead ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Adversarial Testing Lead operates the Adversarial Validation Procedure. They own the penetration testing, red team, and purple team programs. They think like an adversary to find the paths that scanners miss, then translate those findings into actionable remediation that Engineering and IT teams can act on. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Vulnerability Assessment Analyst | PR-VAM-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Plan, execute, and report on internal penetration tests across IT, cloud, and OT environments - Design and execute red team exercises: objective-based adversary simulation testing detection and response capabilities - Run purple team exercises: collaborative testing with the Detection Engineer to validate and improve detection coverage - Document findings with clear attack paths, evidence, severity ratings, and actionable remediation guidance - Track finding remediation and verify closure through retesting - Maintain the offensive security tooling and lab environment - Coordinate external penetration testing and red team engagements when external providers are used - Contribute threat-emulation scenarios to detection engineering - Provide adversary-perspective input to threat modeling and architecture review ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in offensive security: network penetration testing, web application testing, cloud security testing, and social engineering - Red team operations: C2 frameworks (Cobalt Strike, Mythic, Sliver), evasion techniques, operational security - Active Directory attack paths and modern Windows enterprise attack techniques - Cloud penetration testing across AWS, Azure, and/or GCP - OT/ICS security testing awareness (if the organization has OT) - Strong written communication: penetration test reports are read by engineers, executives, and possibly regulators - Relevant certifications: OSCP, OSCE, GPEN, GXPN, CREST, or equivalent ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-007 — Adversarial Testing Lead primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1091 | Perform authorized penetration testing on enterprise network assets | Core work activity for this NICE Work Role | | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Task | T1041 | Determine impact of software configurations | Core work activity for this NICE Work Role | | Task | T1069 | Evaluate organizational cybersecurity policy regulatory compliance | Core work activity for this NICE Work Role | | Task | T1070 | Evaluate organizational cybersecurity policy alignment with organizational directives | Core work activity for this NICE Work Role | | Knowledge | K0797 | Knowledge of ethical hacking tools and techniques | Foundational knowledge for this role | | Knowledge | K0956 | Knowledge of penetration testing tools and techniques | Foundational knowledge for this role | | Knowledge | K1087 | Knowledge of social engineering tools and techniques | Foundational knowledge for this role | | Knowledge | K0677 | Knowledge of cybersecurity policies and procedures | Foundational knowledge for this role | | Knowledge | K0679 | Knowledge of privacy policies and procedures | Foundational knowledge for this role | | Skill | S0591 | Skill in performing social engineering | Core capability for this role | | Skill | S0483 | Skill in identifying software communications vulnerabilities | Core capability for this role | | Skill | S0492 | Skill in performing threat environment analysis | Core capability for this role | | Skill | S0532 | Skill in analyzing software configurations | Core capability for this role | | Skill | S0543 | Skill in scanning for vulnerabilities | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-VAM-001 → PD-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-12+ years in cybersecurity, with 3+ years in offensive security - Bachelor's degree or equivalent experience - One or more advanced offensive security certifications required ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Adversarial Testing Lead is successful when the organization understands its real-world security posture through validated attack simulation. Key indicators: every test has a clear scope, approved rules of engagement, and a structured findings report; findings are reproducible and include validated exploitation paths; remediation verification testing confirms fixes are effective; the test calendar covers all in-scope systems on a risk-prioritized schedule. The lead ensures that testing is a learning tool for the defense team, not a gotcha exercise. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, this lead role can progress on either a management path or a senior SME path depending on organizational scale. In larger teams, progression usually runs through M1 Manager to M3 Principal Manager as the role gains team leadership, KPI ownership, budget input, and cross-functional delivery scope. In smaller teams, the same title may operate as an S3-S4 expert lead, with progression shown through authoritative risk analysis, procedure ownership, measurable exposure reduction, and influence on CISO-level risk decisions. See [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels) and [JA-001 §7.3](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#73-risk-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-004 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Application Security Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Application Security Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Application Security Engineer owns application security: the tools, rulesets, and practices that find and fix vulnerabilities before code reaches production. They govern SAST, DAST, SCA, and container scanning, set secure development gates, lead threat modeling for applications, and ensure the security of in-house and embedded AI systems. They are accountable for the Secure Software Development and Artificial Intelligence Security standards. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Secure Software Assessor | SP-DEV-001 | SP | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Govern application security testing tooling: SAST, DAST, SCA, container scanning, and API security testing - Define and enforce secure development gates in CI/CD pipelines - Lead threat modeling for in-house applications per the Threat Modeling Procedure - Review application architectures for security adequacy during the architecture review process - Own the security assessment of in-house AI systems, including prompt injection, data leakage, excessive agency, and model supply chain risks - Maintain the Secure Software Development and Application Security Standard and the Artificial Intelligence Security Standard - Triage and prioritize application security findings, working with development teams on remediation - Develop and deliver secure coding guidance and training materials for development teams - Support incident response for application-level compromises: injection attacks, authentication bypass, data exfiltration via application vulnerabilities ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in application security testing: SAST, DAST, SCA, IAST, RASP - Secure coding practices across multiple languages and frameworks - Threat modeling methodologies (STRIDE, PASTA, attack trees) - OWASP Top 10, OWASP ASVS, and OWASP API Security Top 10 - CI/CD pipeline security and DevSecOps practices - AI/ML security: OWASP Top 10 for LLM Applications, model supply chain risks, prompt injection defenses - Web application architecture: microservices, APIs, SPAs, serverless ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [DD-WRL-005 — Application Security Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1202 | Determine software development security implications within centralized and decentralized environments across the ent... | Core work activity for this NICE Work Role | | Task | T1203 | Implement software development cybersecurity methodologies within centralized and decentralized environments across t... | Core work activity for this NICE Work Role | | Task | T1624 | Conduct vulnerability analysis of software patches and updates | Core work activity for this NICE Work Role | | Task | T0311 | Consult with customers about software system design and maintenance | Core work activity for this NICE Work Role | | Task | T1052 | Integrate black-box security testing tools into quality assurance processes | Core work activity for this NICE Work Role | | Knowledge | K0722 | Knowledge of software development principles and practices | Foundational knowledge for this role | | Knowledge | K0764 | Knowledge of software development models and frameworks | Foundational knowledge for this role | | Knowledge | K0846 | Knowledge of secure software deployment principles and practices | Foundational knowledge for this role | | Knowledge | K0847 | Knowledge of secure software deployment tools and techniques | Foundational knowledge for this role | | Knowledge | K1079 | Knowledge of web application security risks | Foundational knowledge for this role | | Skill | S0616 | Skill in applying black-box software testing | Core capability for this role | | Skill | S0175 | Skill in performing root cause analysis | Core capability for this role | | Skill | S0465 | Skill in identifying critical infrastructure systems | Core capability for this role | | Skill | S0466 | Skill in identifying systems designed without security considerations | Core capability for this role | | Skill | S0543 | Skill in scanning for vulnerabilities | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (SP-DEV-001 → DD-WRL-005) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in application security or secure software development - Bachelor's degree in computer science or equivalent development experience - Relevant certifications: GWEB, CSSLP, OSWE, or equivalent - Development experience in at least one modern language/framework preferred ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Application Security Engineer is successful when security is a natural, frictionless part of the software development lifecycle. Key indicators: SAST/DAST/SCA tools are integrated into CI/CD pipelines with low false-positive rates; findings from security reviews are fixed before deployment, not tracked as technical debt; developers seek security input early in the design phase; the mean time to remediate a critical application vulnerability is measured in hours, not days. The engineer makes it easier to build securely than to cut corners. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, progression follows the Security Engineering level ladder in [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels): L1 Associate Engineer/S1, L2 Engineer/S2, L3 Senior or Staff Engineer/S3, and L4 Principal Engineer/S4. Promotion evidence should show increasing autonomy in secure design and implementation, ownership of engineering work streams, authorship or improvement of standards and reference architectures, cross-pillar influence, and mentoring of less experienced engineers. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-004 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # CMMC / Federal Compliance Manager **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** CMMC / Federal Compliance Manager ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The CMMC / Federal Compliance Manager owns the organization's compliance posture for the Cybersecurity Maturity Model Certification and NIST 800-171. They maintain the System Security Plan, the Plan of Action and Milestones, the CUI handling program, and the evidence required for CMMC assessment. They are the organization's authority on what it means to handle Controlled Unclassified Information securely. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the CUI/CMMC compliance program: NIST 800-171 control implementation, CMMC assessment readiness, and CUI handling governance - Maintain the System Security Plan (SSP): system boundaries, control implementation descriptions, and responsible parties - Maintain the Plan of Action and Milestones (POA&M): track open findings, remediation progress, and milestone dates - Manage the CUI / CMMC Operational Package: procedures, templates, evidence requirements, and assessment preparation materials - Coordinate CMMC assessments: C3PAO logistics, evidence production, subject-matter-expert preparation, and finding response - Govern CUI handling: marking, storage, transmission, and destruction requirements across the organization - Monitor federal cybersecurity requirements (DFARS, Executive Orders, NIST updates) and prepare the organization for changes - Report CMMC compliance posture to the Governance Pillar Leader and CISO - Support federal contract security requirements beyond CMMC where applicable ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in NIST 800-171 and CMMC 2.0 requirements and assessment methodology - SSP and POA&M management - CUI handling requirements: marking, storage, transmission, and destruction per 32 CFR Part 2002 - Federal acquisition regulations (DFARS 252.204-7012, 7019, 7020, 7021) as they relate to cybersecurity - Experience with CMMC assessment preparation and execution - NIST 800-53 familiarity (the parent framework for 800-171) ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — CMMC / Federal Compliance Manager primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T1339 | Develop cybersecurity compliance processes for external services | Core work activity for this NICE Work Role | | Task | T1340 | Develop cybersecurity audit processes for external services | Core work activity for this NICE Work Role | | Task | T1368 | Support cybersecurity compliance activities | Core work activity for this NICE Work Role | | Task | T0495 | Manage Accreditation Packages (e.g., ISO/IEC 15026-2) | Core work activity for this NICE Work Role | | Knowledge | K0685 | Knowledge of access control principles and practices | Foundational knowledge for this role | | Knowledge | K0692 | Knowledge of vulnerability assessment tools and techniques | Foundational knowledge for this role | | Knowledge | K0720 | Knowledge of Security Assessment and Authorization (SA&A) processes | Foundational knowledge for this role | | Knowledge | K0746 | Knowledge of policy-based access controls | Foundational knowledge for this role | | Knowledge | K0747 | Knowledge of Risk Adaptive (Adaptable) Access Controls (RAdAC) | Foundational knowledge for this role | | Skill | S0097 | Skill in applying security controls | Core capability for this role | | Skill | S0393 | Skill in developing assessments | Core capability for this role | | Skill | S0394 | Skill in developing security assessments | Core capability for this role | | Skill | S0463 | Skill in implementing software quality control processes | Core capability for this role | | Skill | S0574 | Skill in developing security system controls | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 7-15+ years in federal cybersecurity compliance, defense industrial base security, or related field - Bachelor's degree or equivalent experience - Relevant certifications: CISSP, CISA, CMMC-CCP, CMMC-CCA, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A CMMC / Federal Compliance Manager is successful when the organization can demonstrate compliance to any federal assessor on any day without a panic. Key indicators: CUI is properly identified and protected across all environments; POA&Ms are actively managed with clear owners and due dates; assessment readiness reviews reveal fewer findings each cycle; DIBCAC and C3PAO interactions are professional, efficient, and predictable. The manager ensures that CMMC Level 2 certification is a baseline, not a stretch goal. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, this role can progress on either a senior SME path or a management path depending on organizational scale. The SME path follows L2/S2 through L4/S4 as the role gains deeper regulatory interpretation authority, audit representation capability, policy authorship, and cross-framework judgment. The management path generally runs from M1 to M3 when the role leads analysts, owns a compliance function, manages calendars and evidence operations, and contributes to budget and staffing decisions. See [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels) and [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Chief Information Security Officer (CISO) **Job Family:** JF-EXEC — Executive Leadership **Job Level Range:** L1-L4 (CERG Grade Executive) **CERG Canonical Role:** Chief Information Security Officer (CISO) ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The CISO is the senior-most cybersecurity executive, accountable for the organization's cybersecurity program as a whole. They set strategy, report posture and material risk to executive leadership and the board, hold final authority on High and Critical risk acceptance, and lead the CERG, Security Awareness, and Incident Response functions. The CISO ensures that cybersecurity enables the business to move with confidence, not slows it with reflexive refusal. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Executive Cyber Leader | OG-WRL-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-EXEC — Executive Leadership | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | Executive | | Terminal Grade | Executive — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | Executive | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Set the cybersecurity strategy and multi-year roadmap, aligned to business objectives and the threat landscape - Report cybersecurity posture, material risks, and program health to executive leadership and the board at least quarterly - Hold final approval authority on High and Critical risk acceptance decisions per the Risk Management Framework - Lead the CISO organization: CERG (Engineering, Risk, Governance), Security Awareness, and Incident Response - Own the Cybersecurity Policy and the CERG Framework, ensuring they remain current and authoritative - Approve the cybersecurity budget and resource allocation across all functions - Represent the organization's cybersecurity posture to regulators, auditors, industry peers, and public stakeholders - Chair the Cyber Oversight Group and ensure cross-functional risk treatment alignment - Develop the cybersecurity leadership bench and ensure succession readiness for critical roles - Serve as the ultimate escalation point for cybersecurity incidents, regulatory findings, and unresolved cross-pillar disputes ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep understanding of cybersecurity risk management, governance, and operational models - Executive communication: ability to translate technical risk into business terms for boards, regulators, and non-technical executives - Strategic leadership: demonstrated ability to build and lead multi-function cybersecurity organizations - Regulatory fluency across the frameworks in the organization's scope (e.g., NIST, NERC-CIP, CMMC, SOX, ISO 27001) - Budget and resource management at organizational scale - Crisis leadership: ability to guide the organization through significant security incidents - Industry engagement: active in cybersecurity leadership forums, threat-sharing communities, or regulatory working groups ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-007 — Chief Information Security Officer (CISO) primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1476 | Promote awareness of cybersecurity policy and strategy among management | Core work activity for this NICE Work Role | | Task | T1056 | Acquire resources to support cybersecurity program goals and objectives | Core work activity for this NICE Work Role | | Task | T1088 | Communicate the value of cybersecurity to organizational stakeholders | Core work activity for this NICE Work Role | | Task | T1226 | Align cybersecurity priorities with organizational security strategy | Core work activity for this NICE Work Role | | Task | T1227 | Manage cybersecurity budget, staffing, and contracting | Core work activity for this NICE Work Role | | Knowledge | K0644 | Knowledge of cybersecurity operation policies and procedures | Foundational knowledge for this role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0676 | Knowledge of cybersecurity laws and regulations | Foundational knowledge for this role | | Knowledge | K0677 | Knowledge of cybersecurity policies and procedures | Foundational knowledge for this role | | Knowledge | K0680 | Knowledge of cybersecurity principles and practices | Foundational knowledge for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0821 | Skill in collaborating with internal and external stakeholders | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | | Skill | S0414 | Skill in evaluating laws | Core capability for this role | | Skill | S0415 | Skill in evaluating regulations | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OG-WRL-001 → OG-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 15+ years in cybersecurity or IT risk management, with 8+ years in senior leadership roles - Bachelor's degree in a relevant field; advanced degree (MBA, MS) preferred - Relevant certifications: CISSP, CISM, or equivalent - Experience reporting to a board or board committee - Experience with at least two of: NERC-CIP regulated environments, defense industrial base / CMMC, public company SOX ITGC, critical infrastructure ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Management Track Competency Addendum ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7). The five management-specific domains are: People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. Grade-level expectations (M1-M4) for each domain are in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. This role is also expected to demonstrate SME competencies in the relevant home pillar at or above S2 level, as defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §1. | [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7 Domain | M1 Expectation | M2 Expectation | M3 Expectation | M4 Expectation | |-------------------|----------------|----------------|----------------|----------------| | People Leadership | Conducts regular, meaningful 1:1s. Sets clear expectations. Delivers honest performance feedback promptly. | Develops the Managers reporting to them. Ensures consistent people-management practices. | Builds a leadership bench. Shapes the people strategy. | Accountable for the entire pillar's talent health. Develops next generation of leaders. | | Strategic Thinking | Translates pillar goals into actionable team tasks. Prioritizes team work against organizational objectives. | Defines a function strategy and roadmap. Anticipates changes affecting priorities. | Shapes pillar strategy. Identifies emerging organizational needs. | Sets multi-year strategic direction. Aligns pillar with org strategy. | | Resource and Budget Management | Manages team resources effectively. Identifies resource gaps. | Owns the function's budget input. Manages vendor relationships. | Owns significant budget lines. Builds multi-year resource plans. | Owns the pillar's budget. Makes investment cases to leadership. | | Stakeholder Management | Represents the team effectively. Manages stakeholder expectations honestly. | Manages complex stakeholder relationships across functions. | Manages executive stakeholder relationships. Represents CERG externally. | Manages the organization's most critical stakeholder relationships. | | Organizational Development | Contributes to team culture and morale. Recognizes contributions publicly. | Builds a positive, high-performance culture within the function. | Shapes organizational culture across the pillar. Leads change initiatives. | Shapes organizational culture across CERG. Designs org model. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7 for the complete Management Track Competency Addendum. Grade definitions (M1-M4) are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5. The role-specific SME competency matrix from the home pillar is available in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §4-6 as applicable. ## 10. Success Profile A CISO is successful when the organization's cybersecurity risk is understood, accepted by leadership, and managed within appetite. Key indicators: the CISO has the confidence of the board and executive leadership; cybersecurity metrics are presented in business terms and drive decisions; the security program has adequate budget and resources; incident response is effective without requiring the CISO's direct involvement in every call. The CISO builds a program that survives their departure and a culture where security is everyone's business. ## 11. Career Path ### 11.1 Within-Family Progression The CISO is the terminal executive role in CERG's cybersecurity career architecture. Within-family progression is succession-based rather than grade-based: typical feeders include M4 pillar leaders, S4 senior advisors with executive readiness, or equivalent external cybersecurity executives. Growth within the role is measured by program maturity, board confidence, risk decision quality, budget and talent stewardship, and enterprise influence. Next-step movement is outside the CERG grade framework, such as enterprise risk executive, CIO/CTO/CRO path, or broader business executive accountability. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option The CISO is an organizational leadership role that sits above the standard SME/Management track duality. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5.4 (Director Grade M4) for the CISO level definition. Management competencies for leaders are documented in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7 (Management Track Competency Addendum), including People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | CISO | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Cloud Security Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Cloud Security Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Cloud Security Engineer owns cloud and SaaS platform security. They design, implement, and govern security controls across IaaS, PaaS, and SaaS environments, including infrastructure-as-code security, cloud posture management, landing zone architecture, cloud network security, and the security of email and messaging platforms where delivered as SaaS. They are the organization's authority on what a secure cloud deployment looks like and the person who ensures that authority is embedded in the platforms Engineering and IT teams use every day. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Architect | SP-ARC-001 | SP | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Design and maintain cloud security reference architecture, including landing zone controls, network segmentation, identity integration, and logging - Govern cloud security posture management (CSPM): policy definition, alert triage, and remediation tracking - Review infrastructure-as-code (Terraform, CloudFormation, Bicep) for security adequacy before deployment - Own the security configuration of SaaS platforms, including email, messaging, and collaboration tools - Discover and assess shadow-IT and shadow-AI usage through cloud signals and CASB tooling - Partner with IT and DevOps teams to embed security controls into CI/CD pipelines - Contribute to the IT / Cloud / SaaS Security Standard and maintain its cloud-specific requirements - Support architecture review for projects with cloud components, providing cloud-specific threat and control analysis - Investigate and respond to cloud security incidents in coordination with the Incident Response team ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in at least one major cloud platform (AWS, Azure, GCP); working knowledge of a second - Infrastructure-as-code proficiency: Terraform, CloudFormation, or equivalent - Cloud-native security tooling: CSPM, CWPP, CIEM, cloud network security - Identity and access management in cloud contexts: IAM, federation, service accounts, workload identity - Container and serverless security - SaaS security assessment and configuration management - Scripting and automation (Python, PowerShell, or equivalent) ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [DD-WRL-001 — Cloud Security Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1010 | Communicate enterprise information technology architecture | Core work activity for this NICE Work Role | | Task | T1027 | Integrate organizational goals and objectives into security architecture | Core work activity for this NICE Work Role | | Task | T1077 | Assess the organization's cybersecurity architecture | Core work activity for this NICE Work Role | | Task | T1100 | Configure network hubs, routers, and switches | Core work activity for this NICE Work Role | | Task | T1101 | Optimize network hubs, routers, and switches | Core work activity for this NICE Work Role | | Knowledge | K0689 | Knowledge of network infrastructure principles and practices | Foundational knowledge for this role | | Knowledge | K0742 | Knowledge of identity and access management (IAM) principles and practices | Foundational knowledge for this role | | Knowledge | K0915 | Knowledge of network architecture principles and practices | Foundational knowledge for this role | | Knowledge | K0055 | Knowledge of microprocessors | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Skill | S0418 | Skill in applying secure network architectures | Core capability for this role | | Skill | S0657 | Skill in implementing Public Key Infrastructure (PKI) encryption | Core capability for this role | | Skill | S0383 | Skill in analyzing an organization's enterprise information technology architecture | Core capability for this role | | Skill | S0428 | Skill in designing architectures | Core capability for this role | | Skill | S0465 | Skill in identifying critical infrastructure systems | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (SP-ARC-001 → DD-WRL-001) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity or cloud engineering, with increasing cloud security focus - Bachelor's degree in a relevant technical field or equivalent experience - Relevant certifications: AWS Certified Security, Azure Security Engineer, CCSP, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Cloud Security Engineer is successful when cloud and SaaS platforms are designed, deployed, and operated with security embedded, not bolted on. Key indicators: every cloud landing zone ships with guardrails, not gates; CSPM posture is green and findings are triaged within SLA; IaC reviews are fast, consistent, and rarely find the same issue twice; Engineering teams treat security as part of the deployment pipeline, not a separate review step. The engineer is the person project teams seek out for cloud security advice — and that advice is actioned, not debated. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, progression follows the Security Engineering level ladder in [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels): L1 Associate Engineer/S1, L2 Engineer/S2, L3 Senior or Staff Engineer/S3, and L4 Principal Engineer/S4. Promotion evidence should show increasing autonomy in secure design and implementation, ownership of engineering work streams, authorship or improvement of standards and reference architectures, cross-pillar influence, and mentoring of less experienced engineers. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-006 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Cryptography Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Cryptography Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Cryptography Engineer owns cryptography and key management: the key management platforms, the certificate authority hierarchy, the transport security posture, and FIPS compliance. They ensure that encryption is correctly implemented, keys are protected, certificates do not expire unexpectedly, and cryptographic standards are met across the estate. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Architect | SP-ARC-001 | SP | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Design, implement, and maintain the enterprise key management infrastructure (HSM, cloud KMS, secrets vaults) - Govern the certificate authority (CA) hierarchy: internal CA, public CA integrations, certificate lifecycle automation - Define and enforce transport security requirements: TLS versions, cipher suites, certificate validation - Manage secrets rotation for machine identities, API keys, and service accounts - Ensure FIPS 140-2/140-3 compliance for cryptographic modules in regulated environments - Conduct cryptographic assessments of new systems, applications, and vendor products - Support the rotation of exposed secrets during incident response - Contribute to the Cryptography and Key Management Standard and maintain its technical requirements - Advise Engineering and IT teams on cryptographic design decisions ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in cryptographic principles: symmetric and asymmetric encryption, hashing, digital signatures, key agreement protocols - PKI architecture and certificate lifecycle management - Key management platforms: HashiCorp Vault, cloud-native KMS, Thales/CipherTrust, Utimaco - Hardware security modules (HSMs) - TLS/PKI tools and protocols: ACME, OCSP, CRL, S/MIME, code signing - FIPS 140-2/140-3 and Common Criteria standards - Post-quantum cryptography awareness (preparing for transition, not yet implementing) ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [DD-WRL-001 — Cryptography Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0084 | Employ secure configuration management processes | Core work activity for this NICE Work Role | | Task | T0542 | Translate proposed capabilities into technical requirements | Core work activity for this NICE Work Role | | Task | T1010 | Communicate enterprise information technology architecture | Core work activity for this NICE Work Role | | Task | T1019 | Determine special needs of cyber-physical systems | Core work activity for this NICE Work Role | | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Knowledge | K0698 | Knowledge of cryptographic key management principles and practices | Foundational knowledge for this role | | Knowledge | K0876 | Knowledge of key management service (KMS) key rotation policies and procedures | Foundational knowledge for this role | | Knowledge | K0694 | Knowledge of computer algorithm capabilities and applications | Foundational knowledge for this role | | Knowledge | K0859 | Knowledge of encryption tools and techniques | Foundational knowledge for this role | | Knowledge | K0874 | Knowledge of key management service (KMS) principles and practices | Foundational knowledge for this role | | Skill | S0657 | Skill in implementing Public Key Infrastructure (PKI) encryption | Core capability for this role | | Skill | S0658 | Skill in implementing digital signatures | Core capability for this role | | Skill | S0141 | Skill in assessing security systems designs | Core capability for this role | | Skill | S0172 | Skill in applying secure coding techniques | Core capability for this role | | Skill | S0383 | Skill in analyzing an organization's enterprise information technology architecture | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (SP-ARC-001 → DD-WRL-001) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-15+ years in cybersecurity, with 3+ years focused on cryptography or PKI - Bachelor's degree in computer science, mathematics, or a related field - Relevant certifications: CISSP, CISM, vendor-specific HSM/KMS certifications, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Cryptography Engineer is successful when the organization's cryptographic posture is correct by design and sustainable over time. Key indicators: all cryptographic keys are managed through a centralized key management system with full lifecycle tracking; certificate expiry is never an emergency; TLS configurations across the estate score A+ on every assessment; cryptographic algorithms and key lengths are consistent with current best practice. The engineer makes crypto "boring" — it works correctly, automatically, and nobody has to think about it. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, progression follows the Security Engineering level ladder in [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels): L1 Associate Engineer/S1, L2 Engineer/S2, L3 Senior or Staff Engineer/S3, and L4 Principal Engineer/S4. Promotion evidence should show increasing autonomy in secure design and implementation, ownership of engineering work streams, authorship or improvement of standards and reference architectures, cross-pillar influence, and mentoring of less experienced engineers. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-006 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-004 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Detection Engineer **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Detection Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Detection Engineer owns detection-rule authoring, MITRE ATT&CK coverage, and the detection tuning lifecycle. They turn threat intelligence, vulnerability data, and red team findings into detection content that finds adversaries before the adversary achieves their objective. They are the bridge between knowing what threats exist and being able to see them in the environment. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Cyber Defense Analyst | PR-CDA-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Author, test, and deploy detection rules across SIEM, EDR, NDR, and cloud detection platforms - Map detection coverage to MITRE ATT&CK and maintain the coverage matrix - Tune detection rules to reduce false positives while maintaining true-positive sensitivity - Translate threat intelligence into detection content: new rules, updated logic, expanded data sources - Incorporate adversarial testing findings: write detections for the TTPs the red team successfully executed - Govern the detection lifecycle: new rule authoring, testing, deployment, performance monitoring, tuning, and retirement - Hand off confirmed detections to the Incident Response team per the defined procedure - Maintain and improve the logging and monitoring coverage required to support detection content - Contribute to the Logging, Monitoring, and Detection Standard ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - SIEM expertise: Splunk, Elastic, Microsoft Sentinel, or equivalent - Detection rule authoring: Sigma, KQL, SPL, YARA, YARA-L - MITRE ATT&CK framework fluency: technique-level understanding and mapping - Log analysis: Windows Event Log, Sysmon, network traffic, cloud audit logs, endpoint telemetry - Understanding of adversary TTPs and how they manifest in logs - Scripting and automation: Python, PowerShell, or equivalent - Data engineering: understanding of log pipelines, data normalization, and detection architecture ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-001 — Detection Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1387 | Validate intrusion detection system alerts | Core work activity for this NICE Work Role | | Task | T1112 | Validate network alerts | Core work activity for this NICE Work Role | | Task | T1290 | Communicate daily network event and activity reports | Core work activity for this NICE Work Role | | Task | T1299 | Determine causes of network alerts | Core work activity for this NICE Work Role | | Task | T1349 | Communicate cybersecurity attacks and intrusions alerts | Core work activity for this NICE Work Role | | Knowledge | K0723 | Knowledge of vulnerability data sources | Foundational knowledge for this role | | Knowledge | K0732 | Knowledge of intrusion detection tools and techniques | Foundational knowledge for this role | | Knowledge | K0860 | Knowledge of malware signature principles and practices | Foundational knowledge for this role | | Knowledge | K0950 | Knowledge of Intrusion Detection System (IDS) tools and techniques | Foundational knowledge for this role | | Knowledge | K0951 | Knowledge of Intrusion Prevention System (IPS) tools and techniques | Foundational knowledge for this role | | Skill | S0859 | Skill in performing event correlation | Core capability for this role | | Skill | S0566 | Skill in developing signatures | Core capability for this role | | Skill | S0567 | Skill in deploying signatures | Core capability for this role | | Skill | S0627 | Skill in reading signatures | Core capability for this role | | Skill | S0712 | Skill in evaluating data source quality | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-CDA-001 → PD-WRL-001) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity, security operations, or detection engineering - Bachelor's degree in a relevant technical field or equivalent experience - Relevant certifications: GCIH, GCIA, GMON, GCDA, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Detection Engineer is successful when the organization detects malicious activity before it causes material harm. Key indicators: detection coverage maps to the MITRE ATT&CK framework with measurable gaps identified and prioritized; alert-to-investigation time is trending down; false positive rates for production detection rules are below 5%; detection rules are tested against known adversary behavior before deployment. The engineer's detections catch real threats while generating noise only when the security team should actually pay attention. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, progression follows the Risk Operations level ladder in [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels): L1 Associate Analyst/S1, L2 Analyst/S2, L3 Senior or Lead Analyst/S3, and L4 Principal Analyst/S4. Promotion evidence should show increasing ownership of risk workflows, stronger analytical judgment, documented influence on remediation or risk acceptance decisions, cross-pillar collaboration with Engineering and Governance, and mentoring of less experienced analysts. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-004 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader | Corrected role body content so Detection Engineer responsibilities, KSAs, qualifications, and profile align to detection engineering rather than vendor risk. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-005 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Endpoint Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Endpoint Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Endpoint Engineer owns endpoint and mobile security: the operating system baselines, the endpoint detection and response platform, the mobile device management controls, and the device posture signal that feeds network and access decisions. They ensure that every device accessing CERG-protected resources, whether corporate-managed or BYOD, meets a defined security baseline. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Systems Security Analyst | OM-ANA-001 | OM | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Design, implement, and maintain endpoint security baselines for Windows, macOS, and Linux - Govern the endpoint detection and response (EDR) platform: agent deployment, policy tuning, alert triage, and investigation support - Own mobile device management (MDM) and mobile threat defense (MTD) configuration - Define and enforce device posture requirements for conditional access (patch level, disk encryption, firewall status, EDR health) - Manage endpoint configuration drift: detect, report, and remediate deviations from the baseline - Contribute to the Endpoint and Mobile Security Standard and maintain its technical requirements - Support the Secure Configuration Baseline Standard with endpoint-specific hardening guidance - Investigate endpoint-compromise scenarios: malware execution, credential theft, lateral movement from compromised endpoints - Partner with IT operations on endpoint deployment, patching, and lifecycle management ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise with at least two endpoint platforms: Windows, macOS, and/or Linux - EDR platform expertise: CrowdStrike, Microsoft Defender for Endpoint, SentinelOne, or equivalent - Mobile device management: Intune, Jamf, Workspace ONE, or equivalent - Endpoint hardening frameworks: CIS Benchmarks, DISA STIGs, Microsoft security baselines - Scripting and automation: PowerShell, Bash, Python - Understanding of modern endpoint threats: ransomware, fileless malware, LOLBins, supply chain compromise ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [IO-WRL-006 — Endpoint Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1172 | Determine if systems security operations and maintenance activities are property documented and updated | Core work activity for this NICE Work Role | | Task | T1173 | Determine that the application of security patches for commercial products meets timeline requirements | Core work activity for this NICE Work Role | | Task | T1218 | Integrate automated capabilities for updating or patching system software | Core work activity for this NICE Work Role | | Task | T1219 | Develop processes and procedures for manual updating and patching of system software | Core work activity for this NICE Work Role | | Task | T1327 | Update security documentation to reflect current application and system security design features | Core work activity for this NICE Work Role | | Knowledge | K0744 | Knowledge of operating system (OS) systems and software | Foundational knowledge for this role | | Knowledge | K0755 | Knowledge of configuration management (CM) tools and techniques | Foundational knowledge for this role | | Knowledge | K0758 | Knowledge of server administration principles and practices | Foundational knowledge for this role | | Knowledge | K0759 | Knowledge of client and server architecture | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Skill | S0141 | Skill in assessing security systems designs | Core capability for this role | | Skill | S0479 | Skill in evaluating supplier trustworthiness | Core capability for this role | | Skill | S0480 | Skill in evaluating product trustworthiness | Core capability for this role | | Skill | S0483 | Skill in identifying software communications vulnerabilities | Core capability for this role | | Skill | S0484 | Skill in developing user credential management systems | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OM-ANA-001 → IO-WRL-006) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-10+ years in endpoint management, IT operations, or cybersecurity - Bachelor's degree in a relevant technical field or equivalent experience - Relevant certifications: GCFE, GCFA, vendor-specific EDR certifications, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Endpoint Engineer is successful when every managed device is a controlled, defensible platform regardless of its location or user. Key indicators: endpoint configuration drift is detected and remediated automatically within hours; EDR coverage is complete with zero stale agents; patch compliance for critical vulnerabilities exceeds 95% within the defined window; mobile and remote devices are indistinguishable from office devices in their security posture. The engineer's work is measured in coverage percentage and response time, not tickets closed. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, Endpoint Engineer progression normally follows L1 Associate Engineer/S1, L2 Engineer/S2, and L3 Senior Engineer/S3 per [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels). The role-specific terminal grade is S3 in [JA-001 §7.2](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#72-engineering-pillar). Continued growth beyond S3 generally requires broadening into a cross-domain Engineering Advisor role, transitioning into Cloud Security Engineering or another adjacent engineering specialty, or moving to the Management track. Promotion evidence should show endpoint control ownership, measurable hardening outcomes, automation of endpoint operations, and effective partnership with Risk and Governance. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-005 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-007 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Engineering Pillar Leader **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Engineering Pillar Leader ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Engineering Pillar Leader is accountable for the Cyber Engineering pillar: the internal security consulting practice that embeds engineers in projects from concept through production. They own project intake, reference architecture, and the secure build of the estate. They lead a team of domain-specialist engineers (Cloud, Identity, OT, Application, Endpoint, Cryptography) and ensure that every system going live has been reviewed, hardened, and handed off with a known security posture. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Executive Cyber Leader / Security Architect | OG-WRL-001 / SP-ARC-001 | OV / SP | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the Engineering pillar's strategy, delivery, budget, and talent - Govern the project intake and architecture review process, ensuring every material project receives appropriate security engagement - Maintain reference architecture authority for cloud, identity, OT, application, endpoint, and cryptography domains - Lead the pre-production review function and ensure go-live decisions are security-informed - Develop and maintain the technical standards authored by Engineering (configuration, resilience, cryptography, secure development, asset management, network, endpoint, AI, email security) - Align engineering resources to business verticals and ensure engineers develop genuine fluency in the systems they support - Resolve software risk-tier disputes and architectural disagreements within the pillar - Develop the Engineering leadership bench and manage team health, retention, and growth - Report Engineering posture, project portfolio status, and key risks to the CISO - Coordinate with Risk and Governance pillars to ensure threat intelligence feeds architecture decisions and standards are implementable ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Broad and deep cybersecurity engineering expertise across multiple domains (cloud, identity, application security, or OT) - Architecture and design review leadership: ability to evaluate complex system designs for security adequacy - People leadership: demonstrated ability to lead, develop, and retain a team of senior technical engineers - Program management: ability to manage a portfolio of 50+ concurrent project engagements - Cross-functional collaboration: ability to work effectively with IT, OT, business, and vendor engineering teams - Budget and vendor management: experience with security tooling procurement and vendor relationship management ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-007 — Engineering Pillar Leader primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1342 | Oversee policy standards and implementation strategy development | Core work activity for this NICE Work Role | | Task | T1476 | Promote awareness of cybersecurity policy and strategy among management | Core work activity for this NICE Work Role | | Task | T1906 | Establish a cybersecurity risk management program | Core work activity for this NICE Work Role | | Task | T1056 | Acquire resources to support cybersecurity program goals and objectives | Core work activity for this NICE Work Role | | Task | T1036 | Integrate leadership priorities | Core work activity for this NICE Work Role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0818 | Knowledge of new and emerging cybersecurity risks | Foundational knowledge for this role | | Knowledge | K0820 | Knowledge of supply chain risks | Foundational knowledge for this role | | Knowledge | K1079 | Knowledge of web application security risks | Foundational knowledge for this role | | Knowledge | K1209 | Knowledge of risk mitigation principles and practices | Foundational knowledge for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0686 | Skill in performing risk assessments | Core capability for this role | | Skill | S0707 | Skill in developing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0708 | Skill in executing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0821 | Skill in collaborating with internal and external stakeholders | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OG-WRL-001 → OG-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 15+ years in cybersecurity or IT, with 8+ years in security engineering or architecture leadership - 5+ years of people management at increasing scope - Bachelor's degree in a relevant technical field; advanced degree preferred - Relevant certifications: CISSP, CCSP, SANS GIAC, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) with the addition of the Management Track Competency Addendum ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7) for leadership-specific domains: People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Engineering Pillar Leader is successful when the engineering organization is delivering security outcomes reliably, sustainably, and measurably. Key indicators: the team's standards are published, adopted, and enforced; architecture reviews are completed within SLA with no systemic finding patterns; team members can articulate their growth trajectory; the pillar's evidence is audit-ready without fire drills. The leader is trusted by the CISO to set technical direction and by the team to advocate for the resources and conditions they need to succeed. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, the Engineering Pillar Leader is the M4/Director family leadership role. Typical feeder paths are S4 Principal Engineer or Sr. Advisor roles, M3 Engineering Manager roles, or equivalent external security engineering leadership. Growth within this role is measured by Engineering pillar maturity, quality of reference architectures and standards, delivery through managers and senior engineers, cross-pillar trust, and contribution to CISO-level strategy. Next-step movement is generally toward CISO or broader technology/security executive accountability, not a higher CERG grade. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-007 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-006 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Evidence Librarian **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Evidence Librarian ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Evidence Librarian owns the cross-framework evidence library. They collect, curate, and retain control evidence so that when an auditor, assessor, or regulator asks for proof that a control is operating effectively, the evidence exists, is current, and is retrievable. They turn audit preparation from a project into a steady state. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the evidence library: organize control evidence by framework, control, and collection period - Collect evidence from Engineering and Risk operations: vulnerability scan results, access review records, configuration baselines, pen test reports, threat intelligence products, and change management records - Curate evidence: ensure evidence meets the quality bar (dated, attributable, complete, and relevant to the control) - Retain evidence per the defined retention schedule and ensure it is retrievable on demand - Support audit and assessment evidence requests: produce the requested evidence within the auditor's timeline - Maintain the evidence collection calendar: ensure evidence is collected before it is needed, not after - Identify evidence gaps and coordinate with control owners to close them - Contribute to the Audit and Evidence Management Procedure - Partner with compliance managers (NERC-CIP, CMMC, SOX ITGC) to ensure their framework-specific evidence requirements are met ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Evidence management and organization: ability to maintain a multi-framework library where any item can be found in under a minute - Understanding of control frameworks and what constitutes valid evidence for each - Attention to detail: evidence that is misdated, unattributable, or incomplete is not evidence - Data management and information organization - GRC platform or document management system proficiency - Understanding of the CERG control baseline and evidence requirements ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — Evidence Librarian primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1038 | Integrate organization objectives in intelligence collection | Core work activity for this NICE Work Role | | Task | T1294 | Advise on Risk Management Framework process activities and documentation | Core work activity for this NICE Work Role | | Task | T1327 | Update security documentation to reflect current application and system security design features | Core work activity for this NICE Work Role | | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T0495 | Manage Accreditation Packages (e.g., ISO/IEC 15026-2) | Core work activity for this NICE Work Role | | Knowledge | K0800 | Knowledge of evidence admissibility laws and regulations | Foundational knowledge for this role | | Knowledge | K0476 | Knowledge of language processing tools and techniques | Foundational knowledge for this role | | Knowledge | K0653 | Knowledge of cybersecurity practices in the acquisition process | Foundational knowledge for this role | | Knowledge | K0655 | Knowledge of intelligence fusion | Foundational knowledge for this role | | Knowledge | K0658 | Knowledge of cognitive biases | Foundational knowledge for this role | | Skill | S0391 | Skill in creating technical documentation | Core capability for this role | | Skill | S0642 | Skill in identifying evidence of past intrusions | Core capability for this role | | Skill | S0711 | Skill in interpreting metadata | Core capability for this role | | Skill | S0775 | Skill in developing intelligence collection plans | Core capability for this role | | Skill | S0777 | Skill in developing collection strategies | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 1-8+ years in cybersecurity governance, compliance, audit support, or records management - Bachelor's degree or equivalent experience - Relevant certifications: CISA or equivalent valued but not required at entry level ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Evidence Librarian is successful when evidence is treated as a managed asset rather than a scramble before every audit. Key indicators: every control has a current, valid evidence artifact with a known location and retention date; evidence collection is automated or scheduled, not manually triggered; retrieval time for any evidence artifact is measured in minutes, not days; evidence gaps are identified and remediated before the audit calendar triggers them. The librarian's work means the organization passes audits on process, not on heroics. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, Evidence Librarian progression normally follows L1 Associate/S1, L2 Specialist/S2, and L3 Senior Specialist/S3 per [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels). The role-specific terminal grade is S3 in [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). Continued growth beyond S3 generally requires broadening into a Governance Advisor, Policy and Standards, Compliance Manager, or audit-facing role with wider regulatory judgment. Promotion evidence should show evidence quality improvement, reduction in audit rework, reliable evidence retrieval, and disciplined operation of the evidence lifecycle. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-006 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Executive Sponsor **Job Family:** JF-EXEC — Executive Leadership **Job Level Range:** L1-L4 (CERG Grade Executive) **CERG Canonical Role:** Executive Sponsor ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Executive Sponsor is the business voice in the cybersecurity program. They are a senior business or operational leader who provides concurrence for Critical risk acceptance, sits on the Cyber Oversight Group, and endorses the Cybersecurity Policy on behalf of the business. The Executive Sponsor is not a cybersecurity professional; they are the bridge that ensures cybersecurity risk decisions are made with business context. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Business role; not mapped to NICE | N/A | N/A | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-EXEC — Executive Leadership | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | Executive | | Terminal Grade | Executive — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | Executive | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Concur on Critical risk acceptance decisions, providing the independent business view required by the Risk Management Framework - Serve on the Cyber Oversight Group as the business representative - Endorse the Cybersecurity Policy on behalf of the business - Escalate business concerns about cybersecurity controls, friction, or risk posture to the CISO - Ensure that cybersecurity risk decisions account for operational, financial, and strategic business impact - Advocate for cybersecurity investment with business-unit peers ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep understanding of the organization's business model, operations, and risk tolerance - Senior leadership credibility within the organization - Ability to evaluate risk in business terms: revenue impact, operational disruption, regulatory exposure, reputational harm - No cybersecurity expertise required; this is a business role, not a technical one ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-007 — Executive Sponsor primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1056 | Acquire resources to support cybersecurity program goals and objectives | Core work activity for this NICE Work Role | | Task | T0006 | Advocate organization's official position in legal and legislative proceedings | Core work activity for this NICE Work Role | | Task | T1055 | Determine if priority information requirements are satisfied | Core work activity for this NICE Work Role | | Task | T1057 | Conduct an effective enterprise continuity of operations program | Core work activity for this NICE Work Role | | Task | T1059 | Perform cost/benefit analyses of cybersecurity programs, policies, processes, systems, and elements | Core work activity for this NICE Work Role | | Knowledge | K1025 | Knowledge of decision-making policies and procedures | Foundational knowledge for this role | | Knowledge | K0644 | Knowledge of cybersecurity operation policies and procedures | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0676 | Knowledge of cybersecurity laws and regulations | Foundational knowledge for this role | | Skill | S0707 | Skill in developing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0708 | Skill in executing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0414 | Skill in evaluating laws | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OG-WRL-001 → OG-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - Senior business or operational leader (VP, SVP, or equivalent) - Accountable for business outcomes that depend on the systems and data CERG protects - Appointed by the CEO or COO in consultation with the CISO ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Management Track Competency Addendum ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7). The five management-specific domains are: People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. Grade-level expectations (M1-M4) for each domain are in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. This role is also expected to demonstrate SME competencies in the relevant home pillar at or above S2 level, as defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §1. | [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7 Domain | M1 Expectation | M2 Expectation | M3 Expectation | M4 Expectation | |-------------------|----------------|----------------|----------------|----------------| | People Leadership | Conducts regular, meaningful 1:1s. Sets clear expectations. Delivers honest performance feedback promptly. | Develops the Managers reporting to them. Ensures consistent people-management practices. | Builds a leadership bench. Shapes the people strategy. | Accountable for the entire pillar's talent health. Develops next generation of leaders. | | Strategic Thinking | Translates pillar goals into actionable team tasks. Prioritizes team work against organizational objectives. | Defines a function strategy and roadmap. Anticipates changes affecting priorities. | Shapes pillar strategy. Identifies emerging organizational needs. | Sets multi-year strategic direction. Aligns pillar with org strategy. | | Resource and Budget Management | Manages team resources effectively. Identifies resource gaps. | Owns the function's budget input. Manages vendor relationships. | Owns significant budget lines. Builds multi-year resource plans. | Owns the pillar's budget. Makes investment cases to leadership. | | Stakeholder Management | Represents the team effectively. Manages stakeholder expectations honestly. | Manages complex stakeholder relationships across functions. | Manages executive stakeholder relationships. Represents CERG externally. | Manages the organization's most critical stakeholder relationships. | | Organizational Development | Contributes to team culture and morale. Recognizes contributions publicly. | Builds a positive, high-performance culture within the function. | Shapes organizational culture across the pillar. Leads change initiatives. | Shapes organizational culture across CERG. Designs org model. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7 for the complete Management Track Competency Addendum. Grade definitions (M1-M4) are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5. The role-specific SME competency matrix from the home pillar is available in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §4-6 as applicable. ## 10. Success Profile An Executive Sponsor is successful when cybersecurity is resourced and governed as a business priority, not a technical cost center. Key indicators: the sponsor ensures that cybersecurity has a seat at the leadership table; budget requests are evaluated against risk, not against last year's spend; the sponsor champions security culture from the top; the CISO has direct access to the sponsor without going through intermediaries. The sponsor's success is measured by whether the organization's security posture improves during their tenure, not by whether an incident occurred. ## 11. Career Path ### 11.1 Within-Family Progression The Executive Sponsor is a business-side accountability, not a CERG employee progression path. Selection is based on executive authority over the affected business risk, ability to commit resources, and accountability for accepted risk. The role may rotate among senior business leaders as business scope, regulatory exposure, or transformation priorities change. No CERG grade promotion is attached to this role. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option The Executive Sponsor is a business leadership role outside the CERG grade structure. See [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §5 for the Executive Sponsor's role definition. CERG's Management track for internal roles is documented in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 and [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-EXEC-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | CISO | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Exposure Management Lead **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Exposure Management Lead ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Exposure Management Lead operates the Exposure Management Procedure. They own the observation intake, scanner integration, exposure validation, finding triage, remediation SLAs, and exposure posture metrics that feed the CISO dashboard. They ensure that every material exposure is known, prioritized, assigned, tracked to treatment, and reported. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Vulnerability Assessment Analyst | PR-VAM-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Operate and maintain exposure observation sources across IT, cloud, and OT environments, including vulnerability scanners, CSPM, SSPM, SCA, and OT passive monitoring - Define and enforce triage criteria: validation state, reachability, exploitability, asset criticality, and exposure classification - Own remediation SLAs and track compliance, escalating overdue findings per the defined process - Report exposure posture metrics: open findings by severity and age, SLA compliance, mean time to remediate, coverage gaps - Coordinate with IT, OT, and Engineering teams to drive remediation - Manage scanner-artifact triage and tuning to maintain signal quality - Govern OT-safe scanning procedures, ensuring scan techniques do not introduce operational risk - Contribute to exposure management tooling selection, configuration, and optimization - Support incident response with vulnerability and exposure context for compromised systems ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in exposure management platforms: Tenable, Qualys, Rapid7, CrowdStrike Spotlight, or equivalent - Vulnerability scoring and prioritization: CVSS, EPSS, CISA KEV, asset-contextual risk scoring - Understanding of remediation workflows and the operational constraints on patching - OT/ICS exposure management awareness (if the organization has OT) - Data analysis and reporting: ability to produce actionable metrics from scan data - Scripting and automation: Python, PowerShell, or equivalent ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-007 — Exposure Management Lead primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1119 | Recommend vulnerability remediation strategies | Core work activity for this NICE Work Role | | Task | T1091 | Perform authorized penetration testing on enterprise network assets | Core work activity for this NICE Work Role | | Task | T1619 | Perform risk and vulnerability assessments | Core work activity for this NICE Work Role | | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Task | T1041 | Determine impact of software configurations | Core work activity for this NICE Work Role | | Knowledge | K1076 | Knowledge of risk scoring principles and practices | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0676 | Knowledge of cybersecurity laws and regulations | Foundational knowledge for this role | | Knowledge | K0677 | Knowledge of cybersecurity policies and procedures | Foundational knowledge for this role | | Skill | S0543 | Skill in scanning for vulnerabilities | Core capability for this role | | Skill | S0483 | Skill in identifying software communications vulnerabilities | Core capability for this role | | Skill | S0492 | Skill in performing threat environment analysis | Core capability for this role | | Skill | S0532 | Skill in analyzing software configurations | Core capability for this role | | Skill | S0544 | Skill in recognizing vulnerabilities | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-VAM-001 → PD-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-12+ years in cybersecurity, with 3+ years in exposure management - Bachelor's degree or equivalent experience - Relevant certifications: CISSP, GCIH, GMON, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Exposure Management Lead is successful when the organization knows its exposure posture in real time and is actively reducing it. Key indicators: observation coverage is complete across all in-scope assets; confirmed exposure age is trending down, not up; remediation SLAs are met for each severity tier; the exposure backlog is the authoritative source of truth for exposure decisions. The lead ensures that every Critical and High finding has an owner, a plan, and a due date — and that the CISO can report exposure status to the board in under an hour. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, this lead role can progress on either a management path or a senior SME path depending on organizational scale. In larger teams, progression usually runs through M1 Manager to M3 Principal Manager as the role gains team leadership, KPI ownership, budget input, and cross-functional delivery scope. In smaller teams, the same title may operate as an S3-S4 expert lead, with progression shown through authoritative risk analysis, procedure ownership, measurable exposure reduction, and influence on CISO-level risk decisions. See [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels) and [JA-001 §7.3](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#73-risk-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-007 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Governance Pillar Leader **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Governance Pillar Leader ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Governance Pillar Leader is accountable for the Cyber Governance pillar: the policies, standards, compliance tracking, control evidence, risk register, and audit response that make the organization's security program demonstrable. They set the rules, track the work, and ensure that when a regulator or auditor asks "prove it," the evidence exists. They hold Low and Informational severity risk-acceptance authority. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Executive Cyber Leader / Security Control Assessor | OG-WRL-001 / OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the Governance pillar's strategy, delivery, budget, and talent - Own the policy and standards library: authorship, review cycles, version control, and cross-referencing - Govern the compliance portfolio: NERC-CIP, CMMC, SOX ITGC, ISO 27001, and any additional regulatory frameworks in scope - Lead regulator and auditor liaison: exam management, audit response, finding remediation, and evidence production - Govern the risk register and exception process through the Risk Register Owner - Govern the cross-framework evidence library through the Evidence Librarian - Produce the CISO dashboard and board reporting metrics - Hold Low and Informational severity risk-acceptance authority per the Risk Management Framework - Approve standards with CISO endorsement - Develop the Governance leadership bench and manage team health, retention, and growth - Coordinate with Engineering to ensure standards are implementable and with Risk to ensure risk data feeds compliance tracking ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in cybersecurity governance, compliance, and audit management - Multi-framework regulatory fluency: NERC-CIP, CMMC/NIST 800-171, SOX ITGC, ISO 27001, state/federal regulations as applicable - Policy and standards authorship: ability to write implementable requirements, not aspirational statements - Auditor and regulator relationship management - People leadership: ability to lead a multi-domain governance team - Data analysis and reporting: ability to produce executive-ready metrics from compliance and risk data - Cross-functional collaboration: Governance is the pillar that touches every other function ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-007 — Governance Pillar Leader primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1342 | Oversee policy standards and implementation strategy development | Core work activity for this NICE Work Role | | Task | T1476 | Promote awareness of cybersecurity policy and strategy among management | Core work activity for this NICE Work Role | | Task | T1036 | Integrate leadership priorities | Core work activity for this NICE Work Role | | Task | T1088 | Communicate the value of cybersecurity to organizational stakeholders | Core work activity for this NICE Work Role | | Task | T1226 | Align cybersecurity priorities with organizational security strategy | Core work activity for this NICE Work Role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0818 | Knowledge of new and emerging cybersecurity risks | Foundational knowledge for this role | | Knowledge | K0820 | Knowledge of supply chain risks | Foundational knowledge for this role | | Knowledge | K1079 | Knowledge of web application security risks | Foundational knowledge for this role | | Knowledge | K1209 | Knowledge of risk mitigation principles and practices | Foundational knowledge for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0686 | Skill in performing risk assessments | Core capability for this role | | Skill | S0821 | Skill in collaborating with internal and external stakeholders | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | | Skill | S0414 | Skill in evaluating laws | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OG-WRL-001 → OG-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 15+ years in cybersecurity, IT audit, or governance, risk, and compliance (GRC) - 5+ years of people management at increasing scope - Bachelor's degree in a relevant field; advanced degree (JD, MBA, MPA) valued - Relevant certifications: CISA, CISM, CISSP, CRISC, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) with the addition of the Management Track Competency Addendum ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7) for leadership-specific domains: People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Governance Pillar Leader is successful when the governance program enables rather than constrains the organization. Key indicators: compliance calendars are predictable and auditable; the policy library is current and comprehensive; standards are technically validated and adopted by Engineering; regulatory changes are assessed and actioned before they become compliance gaps. The leader is the CISO's trusted advisor on regulatory strategy and the person who ensures the governance machine runs quietly in the background. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, the Governance Pillar Leader is the M4/Director family leadership role. Typical feeder paths are S4 Principal Governance or Compliance specialists, M3 compliance leaders, or equivalent external governance and regulatory leadership. Growth within this role is measured by audit readiness, quality of regulatory interpretation, policy system maturity, evidence reliability, and the ability to represent the organization to auditors, regulators, and the board. Next-step movement is generally toward CISO, enterprise risk leadership, or broader governance executive accountability, not a higher CERG grade. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-007 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Identity Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Identity Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Identity Engineer owns identity and access engineering: the identity provider, multi-factor authentication, single sign-on, privileged access management, secrets management, and federation. They are accountable for the technical implementation of the Access Management Standard and the Access Management Runbook. They ensure that every identity, human or machine, accessing a CERG-protected system is authenticated, authorized, and auditable. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Systems Security Analyst | OM-ANA-001 | OM | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Design, implement, and maintain the identity provider (IdP), MFA, SSO, and federation infrastructure - Own privileged access management (PAM): credential vaulting, session management, just-in-time access, and privilege elevation workflows - Manage secrets: rotation, access control, and lifecycle for API keys, service accounts, certificates, and machine credentials - Govern access provisioning and periodic access review, ensuring least-privilege principles are maintained - Operate the Access Management Runbook: joiner, mover, leaver workflows, emergency access procedures, and break-glass accounts - Design and enforce conditional access policies based on device posture, location, and risk signals - Support architecture review for projects with identity components, ensuring authentication and authorization patterns meet the standard - Contribute to the Access Management Standard and maintain its technical requirements - Support incident response for identity-compromise scenarios: token theft, session hijacking, credential dumping ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in identity platforms: Entra ID / Azure AD, Okta, Ping, or equivalent - Federation protocols: SAML, OAuth 2.0, OIDC, WS-Fed - Privileged access management platforms: CyberArk, BeyondTrust, Delinea, or equivalent - Secrets management: HashiCorp Vault, cloud-native KMS, or equivalent - Directory services: Active Directory, LDAP, cloud-native directories - Conditional access and zero-trust architecture principles - Authentication standards: FIDO2, WebAuthn, PKI-based authentication ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [IO-WRL-006 — Identity Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1548 | Determine adequacy of access controls | Core work activity for this NICE Work Role | | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Task | T1023 | Identify critical technology procurement requirements | Core work activity for this NICE Work Role | | Task | T1075 | Implement application cybersecurity policies | Core work activity for this NICE Work Role | | Knowledge | K0686 | Knowledge of authentication and authorization tools and techniques | Foundational knowledge for this role | | Knowledge | K0742 | Knowledge of identity and access management (IAM) principles and practices | Foundational knowledge for this role | | Knowledge | K0685 | Knowledge of access control principles and practices | Foundational knowledge for this role | | Knowledge | K0880 | Knowledge of access control models and frameworks | Foundational knowledge for this role | | Knowledge | K0930 | Knowledge of credential management systems and software | Foundational knowledge for this role | | Skill | S0484 | Skill in developing user credential management systems | Core capability for this role | | Skill | S0485 | Skill in implementing user credential management systems | Core capability for this role | | Skill | S0141 | Skill in assessing security systems designs | Core capability for this role | | Skill | S0479 | Skill in evaluating supplier trustworthiness | Core capability for this role | | Skill | S0480 | Skill in evaluating product trustworthiness | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OM-ANA-001 → IO-WRL-006) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity or identity/access management - Bachelor's degree in a relevant technical field or equivalent experience - Relevant certifications: CIAM, CISSP, Microsoft Identity and Access Administrator, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Identity Engineer is successful when the identity and access control infrastructure is invisible to legitimate users and impenetrable to attackers. Key indicators: access decisions are made in milliseconds against authoritative data; privilege escalation attempts are detected in real time; user access certifications complete on schedule with minimal exceptions; the identity architecture scales without redesign as the organization grows. The engineer's work means that when an auditor asks "who has access to what," the answer is immediate, complete, and accurate. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, progression follows the Security Engineering level ladder in [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels): L1 Associate Engineer/S1, L2 Engineer/S2, L3 Senior or Staff Engineer/S3, and L4 Principal Engineer/S4. Promotion evidence should show increasing autonomy in secure design and implementation, ownership of engineering work streams, authorship or improvement of standards and reference architectures, cross-pillar influence, and mentoring of less experienced engineers. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-006 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Identity Risk Analyst **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Identity Risk Analyst ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Identity Risk Analyst owns identity-threat detection: user and entity behavior analytics, OAuth and token risk, and the detection of identity-based attacks. They focus on what happens after authentication: anomalous behavior, privilege escalation, lateral movement, and credential misuse that bypasses preventive controls. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Cyber Defense Analyst | PR-CDA-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Operate and tune user and entity behavior analytics (UEBA) platforms - Monitor for identity-based threats: compromised credentials, token theft, session hijacking, MFA fatigue, OAuth application abuse - Develop and maintain identity-risk detection rules and alerts - Investigate identity-related security events and escalate confirmed compromises to Incident Response - Assess OAuth and API token risk: excessive permissions, unused tokens, suspicious grant patterns - Monitor privileged account usage and detect anomalous privileged behavior - Partner with the Identity Engineer to ensure identity security controls are informed by observed attack patterns - Contribute identity-threat intelligence to the Threat Intelligence Analyst - Support incident response for identity-compromise scenarios ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Identity platforms: Entra ID / Azure AD, Okta, Ping, Active Directory - UEBA platforms: Microsoft Advanced Threat Analytics, Splunk UBA, Exabeam, or equivalent - Authentication protocols and their abuse: OAuth 2.0, SAML, Kerberos, NTLM - Identity attack techniques: Golden Ticket, Silver Ticket, Pass-the-Hash, Pass-the-Ticket, token replay, MFA fatigue - Cloud identity threats: Azure AD Connect compromise, cross-tenant attacks, B2B trust abuse - SIEM and log analysis for identity data sources ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-001 — Identity Risk Analyst primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1266 | Recommend risk mitigation strategies | Core work activity for this NICE Work Role | | Task | T1603 | Recommend threat and vulnerability risk mitigation strategies | Core work activity for this NICE Work Role | | Task | T1176 | Determine if cybersecurity-enabled products reduce identified risk to acceptable levels | Core work activity for this NICE Work Role | | Task | T1177 | Determine if security control technologies reduce identified risk to acceptable levels | Core work activity for this NICE Work Role | | Task | T1548 | Determine adequacy of access controls | Core work activity for this NICE Work Role | | Knowledge | K0742 | Knowledge of identity and access management (IAM) principles and practices | Foundational knowledge for this role | | Knowledge | K0747 | Knowledge of Risk Adaptive (Adaptable) Access Controls (RAdAC) | Foundational knowledge for this role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0685 | Knowledge of access control principles and practices | Foundational knowledge for this role | | Knowledge | K0716 | Knowledge of host access control (HAC) systems and software | Foundational knowledge for this role | | Skill | S0156 | Skill in performing packet-level analysis | Core capability for this role | | Skill | S0483 | Skill in identifying software communications vulnerabilities | Core capability for this role | | Skill | S0490 | Skill in recreating network topologies | Core capability for this role | | Skill | S0509 | Skill in evaluating security products | Core capability for this role | | Skill | S0543 | Skill in scanning for vulnerabilities | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-CDA-001 → PD-WRL-001) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity, identity management, or security operations - Bachelor's degree or equivalent experience - Relevant certifications: CIAM, CISSP, GCIH, GCIA, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An Identity Risk Analyst is successful when identity-related risk is visible, measurable, and actively managed. Key indicators: the identity risk register captures access-related findings from across the organization; user access risk scoring identifies anomalous behavior before it becomes an incident; access certification results are analyzed for risk patterns, not just checked off; SOD violations are identified and remediated before they cause audit findings. The analyst connects identity events to business risk in terms leadership understands. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, progression follows the Risk Operations level ladder in [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels): L1 Associate Analyst/S1, L2 Analyst/S2, L3 Senior or Lead Analyst/S3, and L4 Principal Analyst/S4. Promotion evidence should show increasing ownership of risk workflows, stronger analytical judgment, documented influence on remediation or risk acceptance decisions, cross-pillar collaboration with Engineering and Governance, and mentoring of less experienced analysts. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-006 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Incident Commander **Job Family:** JF-ADJUNCT — Incident Response & Investigation **Job Level Range:** L1-L4 (CERG Grade S2-S4/M4) **CERG Canonical Role:** Incident Commander ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary > **ADJACENT ROLE — Not a CERG position.** This role belongs to the standing Incident Response team, not to CERG. Per [OM-001 §3.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md), Incident Commander and Lead Investigator are IR team roles included in CERG documentation for cross-functional clarity only. CERG provides a liaison to the IR team. **Role Summary (CERG-facing):** Single-decision authority during an active incident. The Incident Commander owns the incident response, makes time-critical containment and recovery decisions, and coordinates the response team. CERG provides the Engineering Lead, Lead Investigator, and Governance Lead roles when the Incident Commander calls for them. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Cyber Defense Incident Responder | PR-CIR-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-ADJUNCT — Incident Response & Investigation | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S2-S4/M4 | | Terminal Grade | S4/M4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the incident response command structure during active cybersecurity incidents: establish command, assign roles, manage the bridge, and coordinate response actions across technical, legal, communications, and business continuity teams - Make containment, eradication, and recovery decisions under time pressure with incomplete information, documenting the rationale for post-incident review - Communicate incident status to stakeholders at all levels: technical team (actionable direction), management (business impact), legal (regulatory obligations), and executive leadership (strategic decisions) - Triage incoming incidents to determine severity, scope, and appropriate response tier per the Incident Response Plan - Coordinate with external parties: law enforcement, regulators, incident response retainers, PR/crisis communications, and affected third parties - Lead post-incident reviews (PIRs) and ensure action items are tracked to closure - Maintain incident response readiness: tabletop exercises, playbook reviews, contact list validation, and tooling readiness checks - Contribute to the Incident Response Plan and playbook set as a subject matter expert - Serve as the primary CERG liaison during incidents requiring cross-pillar coordination ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Incident response command and coordination: bridge management, decision-making under uncertainty, escalation management - Incident handling lifecycle: preparation, detection & analysis, containment, eradication, recovery, post-incident activity - Cybersecurity fundamentals: network security, endpoint security, identity and access management, threat detection - Crisis management and emergency communications - Business continuity and disaster recovery principles - Regulatory incident notification requirements (breach notification laws, NERC-CIP, CMMC, SOX reporting) - Legal and evidentiary requirements for incident documentation ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-003 — Incident Commander primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0510 | Coordinate incident response functions | Core work activity for this NICE Work Role | | Task | T1250 | Perform cyber defense incident triage | Core work activity for this NICE Work Role | | Task | T1109 | Resolve cyber defense incidents | Core work activity for this NICE Work Role | | Task | T1251 | Recommend incident remediation strategies | Core work activity for this NICE Work Role | | Task | T1252 | Determine the scope, urgency, and impact of cyber defense incidents | Core work activity for this NICE Work Role | | Knowledge | K0724 | Knowledge of incident response principles and practices | Foundational knowledge for this role | | Knowledge | K0725 | Knowledge of incident response tools and techniques | Foundational knowledge for this role | | Knowledge | K0701 | Knowledge of data backup and recovery policies and procedures | Foundational knowledge for this role | | Knowledge | K0709 | Knowledge of business continuity and disaster recovery (BCDR) policies and procedures | Foundational knowledge for this role | | Knowledge | K0718 | Knowledge of network communications principles and practices | Foundational knowledge for this role | | Skill | S0805 | Skill in designing incident responses | Core capability for this role | | Skill | S0806 | Skill in performing incident responses | Core capability for this role | | Skill | S0077 | Skill in securing network communications | Core capability for this role | | Skill | S0483 | Skill in identifying software communications vulnerabilities | Core capability for this role | | Skill | S0080 | Skill in performing damage assessments | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-CIR-001 → PD-WRL-003) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-15+ years in cybersecurity, with at least 3 years in incident response leadership or security operations management - Bachelor's degree in cybersecurity, information technology, or equivalent experience - Relevant certifications: CISSP, GCIH, GCFE, GCFA, CISM, or equivalent - Demonstrated experience leading multi-team incident response efforts (tabletop or real-world) ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade The two Adjacent Incident Response roles are out of scope for the CERG Competency Model ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §1). Behavioral anchors for these roles follow the Incident Response team's competency framework. For reference, the eight CERG competency domains are listed below; contact the Incident Response team for domain-specific anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Cross-Pillar Fluency | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Risk Judgment | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Communication | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Operational Discipline | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Influence and Mentorship | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Compliance and Regulatory Literacy | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Continuous Learning | See IR team framework | See IR team framework | See IR team framework | See IR team framework | > **Note:** CMP-001 competency domains provide the organizing structure; actual anchor text must be sourced from the Incident Response team's competency framework per [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4. ## 10. Success Profile An Incident Commander is successful when incidents are managed efficiently, decisively, and with minimal business impact. Key indicators: every incident has a clear commander, a documented timeline, and a post-incident report; containment decisions are made within the SLA for the severity level; communication to stakeholders is regular and accurate; post-incident actions are tracked to closure. The commander keeps the response team focused and effective under pressure, ensuring that the organization learns from every incident. ## 11. Career Path ### 11.1 Within-Family Progression Progression within the Incident Response & Investigation family follows the standard four-tier structure. See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for standard progression gates. ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option Management track progression for Adjacent roles follows the Incident Response team's career framework, not CERG's. See [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4 for the Adjacent Function boundary definition. CERG's Management track is documented in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 (Management Progression: Grade Definitions) and §8.1 (SME to Management Transition). ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-002 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Lead Investigator **Job Family:** JF-ADJUNCT — Incident Response & Investigation **Job Level Range:** L1-L4 (CERG Grade S2-S4/M4) **CERG Canonical Role:** Lead Investigator ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary > **ADJACENT ROLE — Not a CERG position.** This role belongs to the standing Incident Response team, not to CERG. Per [OM-001 §3.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md), Incident Commander and Lead Investigator are IR team roles included in CERG documentation for cross-functional clarity only. CERG provides a liaison to the IR team. **Role Summary (CERG-facing):** The risk-side technical lead during an active incident. The Lead Investigator conducts forensic analysis, traces adversary activity, and identifies the scope of compromise. CERG supplies a qualified practitioner into this role when the IR team calls for one. --- ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Cyber Defense Incident Responder | PR-CIR-001 | PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-ADJUNCT — Incident Response & Investigation | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S2-S4/M4 | | Terminal Grade | S4/M4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Lead the forensic investigation of cybersecurity incidents: collect and preserve digital evidence, trace adversary activity, determine scope of compromise, and produce a documented timeline of events - Perform forensic analysis of systems, networks, and applications using industry-standard tools and methodologies - Collect forensically sound images of affected systems, maintaining chain of custody throughout the investigation - Analyze malware, network artifacts, logs, and memory dumps to determine the root cause and tactics, techniques, and procedures (TTPs) of the adversary - Produce detailed investigative reports suitable for legal, regulatory, and executive audiences - Support the Incident Commander with technical findings during active incidents to inform containment and eradication decisions - Coordinate with law enforcement as a technical expert when criminal activity is identified - Maintain the organization's forensic tooling, forensic workstation environment, and analysis methodologies - Stay current on adversary TTPs, forensic techniques, and anti-forensic countermeasures - Testify or provide written expert evidence in legal proceedings as required ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Digital forensics: disk forensics, memory forensics, network forensics, mobile device forensics, cloud forensics - Malware analysis: static analysis, dynamic analysis, reverse engineering, sandboxing - Evidence handling: forensic imaging, chain of custody, evidence preservation, documentation standards - Operating system internals: Windows, Linux, macOS — file systems, registry, logs, artifacts, persistence mechanisms - Network analysis: packet capture (PCAP) analysis, network flow analysis, proxy and firewall log analysis - Log analysis: SIEM platforms, centralized logging, log correlation, timestamp normalization - Legal and regulatory frameworks: rules of evidence, e-discovery, witness testimony, data privacy laws ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-003 — Lead Investigator primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0164 | Perform cyber defense trend analysis and reporting | Core work activity for this NICE Work Role | | Task | T1256 | Perform forensically sound image collection | Core work activity for this NICE Work Role | | Task | T1372 | Advise law enforcement personnel as technical expert | Core work activity for this NICE Work Role | | Task | T0262 | Employ approved defense-in-depth principles and practices (e.g., defense-in-multiple places, layered defenses, securi... | Core work activity for this NICE Work Role | | Task | T0510 | Coordinate incident response functions | Core work activity for this NICE Work Role | | Knowledge | K0857 | Knowledge of malware analysis tools and techniques | Foundational knowledge for this role | | Knowledge | K0916 | Knowledge of malware analysis principles and practices | Foundational knowledge for this role | | Knowledge | K0924 | Knowledge of network analysis tools and techniques | Foundational knowledge for this role | | Knowledge | K0686 | Knowledge of authentication and authorization tools and techniques | Foundational knowledge for this role | | Knowledge | K0725 | Knowledge of incident response tools and techniques | Foundational knowledge for this role | | Skill | S0651 | Skill in performing malware analysis | Core capability for this role | | Skill | S0550 | Skill in reporting malware | Core capability for this role | | Skill | S0688 | Skill in performing network data analysis | Core capability for this role | | Skill | S0854 | Skill in performing data analysis | Core capability for this role | | Skill | S0866 | Skill in performing log file analysis | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (PR-CIR-001 → PD-WRL-003) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-15+ years in cybersecurity, with at least 3 years in digital forensics or incident response investigation - Bachelor's degree in cybersecurity, computer science, or equivalent experience - Relevant certifications: GCFA, GCFE, GNFA, GREM, EnCE, or equivalent - Experience producing expert reports and providing testimony in legal proceedings preferred ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade The two Adjacent Incident Response roles are out of scope for the CERG Competency Model ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §1). Behavioral anchors for these roles follow the Incident Response team's competency framework. For reference, the eight CERG competency domains are listed below; contact the Incident Response team for domain-specific anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Cross-Pillar Fluency | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Risk Judgment | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Communication | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Operational Discipline | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Influence and Mentorship | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Compliance and Regulatory Literacy | See IR team framework | See IR team framework | See IR team framework | See IR team framework | | Continuous Learning | See IR team framework | See IR team framework | See IR team framework | See IR team framework | > **Note:** CMP-001 competency domains provide the organizing structure; actual anchor text must be sourced from the Incident Response team's competency framework per [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4. ## 10. Success Profile A Lead Investigator is successful when every investigation produces defensible findings that stand up to legal and regulatory scrutiny. Key indicators: evidence is collected and preserved with a complete chain of custody; the investigation timeline is documented and repeatable; findings are specific enough that the organization can act on them; post-incident reports are structured, complete, and filed within SLA. The investigator's work ensures that the organization can explain exactly what happened, when, and why — to a regulator, a court, or the board. ## 11. Career Path ### 11.1 Within-Family Progression Progression within the Incident Response & Investigation family follows the standard four-tier structure. See [JF-001 §8](../CERG-GOV-JF-001_Job_Families_Overview.md) for standard progression gates. ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option Management track progression for Adjacent roles follows the Incident Response team's career framework, not CERG's. See [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §3.4 for the Adjacent Function boundary definition. CERG's Management track is documented in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 (Management Progression: Grade Definitions) and §8.1 (SME to Management Transition). ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-ADJUNCT-002 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # NERC-CIP Compliance Manager **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** NERC-CIP Compliance Manager ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The NERC-CIP Compliance Manager owns the organization's compliance posture for NERC Critical Infrastructure Protection standards. They manage the NERC-CIP evidence library, coordinate regulatory exams and audits, track deviations and mitigation plans, and ensure that BES Cyber System compliance is a steady state, not a pre-audit scramble. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the NERC-CIP compliance program: CIP-002 through CIP-011, plus CIP-014 (physical security) where applicable - Maintain the NERC-CIP Operational Package: procedures, evidence requirements, compliance calendar, and self-assessment tools - Manage the NERC-CIP evidence library: ensure every CIP requirement has current, auditable evidence - Track CIP deviations and mitigation plans, ensuring timely remediation and regulatory reporting - Coordinate NERC-CIP audits and regulatory exams: auditor logistics, evidence production, subject-matter-expert coordination, and response drafting - Serve as the primary liaison to the Regional Entity and NERC for compliance matters - Monitor NERC-CIP standards development and prepare the organization for new and revised requirements - Partner with OT Security Engineer and OT Risk Analyst to ensure compliance activities reflect operational reality - Report CIP compliance posture to the Governance Pillar Leader and CISO - Manage the CIP compliance team in large organizations; operate as an individual contributor in small ones ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in NERC-CIP standards (CIP-002 through CIP-011) and the NERC compliance monitoring and enforcement program - Evidence management and audit preparation for regulatory exams - OT/ICS operational awareness: understanding of BES Cyber Systems, ESP design, and OT operational constraints - Regulatory communication: ability to represent the organization to NERC, Regional Entities, and auditors - Experience with compliance documentation tools and evidence management platforms ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — NERC-CIP Compliance Manager primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1328 | Verify implementation of software, network, and system cybersecurity postures | Core work activity for this NICE Work Role | | Task | T1339 | Develop cybersecurity compliance processes for external services | Core work activity for this NICE Work Role | | Task | T1340 | Develop cybersecurity audit processes for external services | Core work activity for this NICE Work Role | | Task | T1361 | Determine the impact of new system and interface implementations on organization's cybersecurity posture | Core work activity for this NICE Work Role | | Task | T1362 | Document impact of new system and interface implementations on organization's cybersecurity posture | Core work activity for this NICE Work Role | | Knowledge | K0680 | Knowledge of cybersecurity principles and practices | Foundational knowledge for this role | | Knowledge | K0681 | Knowledge of privacy principles and practices | Foundational knowledge for this role | | Knowledge | K0685 | Knowledge of access control principles and practices | Foundational knowledge for this role | | Knowledge | K0687 | Knowledge of business operations standards and best practices | Foundational knowledge for this role | | Knowledge | K0689 | Knowledge of network infrastructure principles and practices | Foundational knowledge for this role | | Skill | S0136 | Skill in network systems management principles, models, methods (e.g., end-to-end systems performance monitoring), an... | Core capability for this role | | Skill | S0465 | Skill in identifying critical infrastructure systems | Core capability for this role | | Skill | S0642 | Skill in identifying evidence of past intrusions | Core capability for this role | | Skill | S0015 | Skill in conducting test events | Core capability for this role | | Skill | S0097 | Skill in applying security controls | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 7-15+ years in NERC compliance, OT cybersecurity, or regulated energy-sector organization operations - Bachelor's degree or equivalent experience in the regulated energy-sector organization industry - Relevant certifications: CISSP, CISA, NERC-specific training credentials, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A NERC-CIP Compliance Manager is successful when compliance is a continuous operational state, not a periodic audit event. Key indicators: evidence packages are audit-ready at all times, not just during audit windows; NERC-CIP non-compliance findings are trending down; the evidence collection burden on Engineering is stable or decreasing year over year; the compliance calendar is accurate to within a week for every filing deadline. The manager ensures that the answer to "can you prove compliance?" is always yes, with a single click. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, this role can progress on either a senior SME path or a management path depending on organizational scale. The SME path follows L2/S2 through L4/S4 as the role gains deeper regulatory interpretation authority, audit representation capability, policy authorship, and cross-framework judgment. The management path generally runs from M1 to M3 when the role leads analysts, owns a compliance function, manages calendars and evidence operations, and contributes to budget and staffing decisions. See [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels) and [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-001 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-005 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # OT Risk Analyst **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** OT Risk Analyst ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The OT Risk Analyst owns OT-safe vulnerability assessment and industrial control system threat intelligence. They are the Risk pillar's specialist for operational technology environments, where a misconfigured scan can have physical consequences and threat actors have different motivations and techniques than in enterprise IT. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Threat/Warning Analyst | AN-TWA-001 | AN | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Conduct OT-safe vulnerability assessments: passive scanning, protocol-aware assessment, and where appropriate, controlled active scanning during maintenance windows - Track ICS-specific threat actors and campaigns: their targets, TTPs, and relevance to the organization's OT environment - Produce OT threat intelligence products for OT operators, Engineering, and leadership - Map OT threats to MITRE ATT&CK for ICS and translate into detection and control recommendations - Partner with OT Security Engineer to prioritize remediation based on operational context - Support the NERC-CIP compliance program with OT vulnerability data and risk assessments - Support incident response for OT incidents with threat context and containment guidance that respects operational constraints - Maintain OT-specific vulnerability and threat intelligence tooling ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in OT/ICS environments and their operational constraints - OT vulnerability assessment tools and techniques (passive and active) - ICS threat landscape: actors, campaigns, malware (BlackEnergy, CrashOverride, Triton/Trisis, Pipedream/Incontroller) - MITRE ATT&CK for ICS - NERC-CIP requirements, particularly CIP-007 and CIP-010 - Understanding of OT operational constraints: safety systems, real-time requirements, change windows ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-006 — OT Risk Analyst primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Task | T0685 | Evaluate threat decision-making processes | Core work activity for this NICE Work Role | | Task | T0845 | Identify cyber threat tactics and methodologies | Core work activity for this NICE Work Role | | Task | T1772 | Identify indications and warnings of target communication changes or processing failures | Core work activity for this NICE Work Role | | Task | T1799 | Notify appropriate personnel of imminent hostile intentions or activities | Core work activity for this NICE Work Role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Knowledge | K0684 | Knowledge of cybersecurity threat characteristics | Foundational knowledge for this role | | Knowledge | K0786 | Knowledge of physical computer components | Foundational knowledge for this role | | Knowledge | K0788 | Knowledge of adversarial tactics principles and practices | Foundational knowledge for this role | | Skill | S0430 | Skill in collaborating with others | Core capability for this role | | Skill | S0433 | Skill in creating analytics | Core capability for this role | | Skill | S0516 | Skill in performing threat emulation tactics | Core capability for this role | | Skill | S0709 | Skill in developing analytics | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (AN-TWA-001 → PD-WRL-006) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-15+ years in OT/ICS environments, with 3+ years of cybersecurity focus - Bachelor's degree in engineering or equivalent OT experience - Relevant certifications: GICSP, GRID, CISSP, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An OT Risk Analyst is successful when OT risk is measured, tracked, and managed with the same rigor as IT risk — while respecting OT operational constraints. Key indicators: the OT risk register covers all critical industrial control systems; risk assessments incorporate both cybersecurity and safety impact; findings are prioritized by actual operational risk, not CVSS alone; OT-specific threat intelligence feeds into risk assessments. The analyst speaks the language of both control engineers and security professionals fluently. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, progression follows the Risk Operations level ladder in [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels): L1 Associate Analyst/S1, L2 Analyst/S2, L3 Senior or Lead Analyst/S3, and L4 Principal Analyst/S4. Promotion evidence should show increasing ownership of risk workflows, stronger analytical judgment, documented influence on remediation or risk acceptance decisions, cross-pillar collaboration with Engineering and Governance, and mentoring of less experienced analysts. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-005 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-003 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # OT Security Engineer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** OT Security Engineer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The OT Security Engineer owns operational technology security engineering for industrial control systems, grid control systems, and the IT/OT boundary. They design and govern the electronic security perimeter (ESP), the BES Cyber System baselines, and the secure architecture of SCADA, DCS, EMS, and other OT environments. They are the bridge between cybersecurity and operations: they must understand both the security controls and why a particular scanning technique could trip a protection relay. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Architect | SP-ARC-001 | SP | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Design and maintain the OT security reference architecture, including the ESP, IT/OT boundary controls, and OT network segmentation - Develop and maintain BES Cyber System security baselines aligned to NERC-CIP requirements - Conduct OT-safe asset discovery and ensure OT assets are accurately represented in the asset inventory - Govern transient cyber asset control: laptops, media, and devices connecting to OT environments - Partner with OT operations and engineering teams to embed security controls without disrupting operational reliability - Support NERC-CIP compliance activities: CIP-005 (electronic security perimeter), CIP-007 (systems security management), CIP-010 (configuration management and vulnerability assessments) - Review OT projects through the architecture review process, providing OT-specific threat and control analysis - Contribute to the Grid Control Systems Security Standard and maintain its technical requirements - Support OT incident response: containment within the ESP, forensics without disrupting operations, evidence preservation for regulatory reporting ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in OT/ICS environments: SCADA, DCS, PLC, RTU, EMS, historian systems - OT network protocols: Modbus, DNP3, IEC 61850, OPC, ICCP - NERC-CIP standards, particularly CIP-002 through CIP-011 - IT/OT convergence architecture: firewalls, data diodes, unidirectional gateways, DMZ design - OT-safe vulnerability assessment techniques - Understanding of OT operational constraints: safety systems, real-time requirements, change management windows, vendor support limitations - Ability to communicate with both cybersecurity teams and OT operators/engineers in their respective languages ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [DD-WRL-001 — OT Security Engineer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1019 | Determine special needs of cyber-physical systems | Core work activity for this NICE Work Role | | Task | T1556 | Identify system and network protection needs | Core work activity for this NICE Work Role | | Task | T1020 | Determine the operational and safety impacts of cybersecurity lapses | Core work activity for this NICE Work Role | | Task | T1100 | Configure network hubs, routers, and switches | Core work activity for this NICE Work Role | | Task | T1101 | Optimize network hubs, routers, and switches | Core work activity for this NICE Work Role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Knowledge | K1049 | Knowledge of routing protocols | Foundational knowledge for this role | | Knowledge | K0684 | Knowledge of cybersecurity threat characteristics | Foundational knowledge for this role | | Knowledge | K0689 | Knowledge of network infrastructure principles and practices | Foundational knowledge for this role | | Knowledge | K0718 | Knowledge of network communications principles and practices | Foundational knowledge for this role | | Skill | S0418 | Skill in applying secure network architectures | Core capability for this role | | Skill | S0430 | Skill in collaborating with others | Core capability for this role | | Skill | S0596 | Skill in encrypting network communications | Core capability for this role | | Skill | S0613 | Skill in configuring software-based computer protection tools | Core capability for this role | | Skill | S0683 | Skill in implementing network segregation | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (SP-ARC-001 → DD-WRL-001) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-15+ years in OT/ICS environments, with 3+ years of cybersecurity focus - Bachelor's degree in engineering, computer science, or equivalent experience in OT environments - Relevant certifications: GICSP, GRID, CISSP, or equivalent - Experience with NERC-CIP regulated environments strongly preferred ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile An OT Security Engineer is successful when operational technology environments are secured without disrupting production. Key indicators: the Purdue model is implemented and enforced; OT asset inventory is complete and current; vulnerabilities in the OT environment are discovered before they cause incidents; engineering and operations teams understand and respect the security controls in their environment. The engineer bridges the gap between IT security practices and OT reliability requirements, earning trust from both sides. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-SECENG, progression follows the Security Engineering level ladder in [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels): L1 Associate Engineer/S1, L2 Engineer/S2, L3 Senior or Staff Engineer/S3, and L4 Principal Engineer/S4. Promotion evidence should show increasing autonomy in secure design and implementation, ownership of engineering work streams, authorship or improvement of standards and reference architectures, cross-pillar influence, and mentoring of less experienced engineers. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-003 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-004 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Policy & Standards Manager **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Policy & Standards Manager ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Policy & Standards Manager owns the CERG document library: the policies, standards, procedures, plans, templates, and governance instruments that make up the program. They govern version control, review cycles, naming-convention discipline, and the cross-referencing integrity that keeps the library coherent. They are the librarian for the CISO's authority. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Cyber Policy and Strategy Planner | OV-PSP-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the document library: version control, document IDs, naming convention compliance, and the single-source-of-truth principle - Govern document review cycles: ensure no document exceeds its review interval without a documented reason and a rescheduled review - Maintain the Document Catalog: register new artifacts, update statuses, and retire obsolete documents - Own the Organization Adaptation Profile (token/variable scheme) and the Implementation and Adaptation Guide - Coordinate cross-pillar QA reviews when a standard or procedure is updated to ensure cross-reference integrity - Manage the policy exception workflow: track approved exceptions to policies and standards, ensure they have expiration dates, and flag expired exceptions for review - Support Security Awareness with policy and procedure content for training materials - Manage the Policy & Standards team in large organizations; operate as an individual contributor in small ones ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Document management and version control (Git-based workflows preferred) - Policy and standards authorship: ability to write clear, implementable requirements - Quality assurance: ability to review a standard for consistency, completeness, and cross-reference integrity - Project management: ability to coordinate multi-author document updates across review cycles - Understanding of the CERG naming convention, document types, and status lifecycle - Attention to detail: a broken cross-reference in the catalog is a governance failure ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-002 — Policy & Standards Manager primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1397 | Determine if research and design processes and procedures are in compliance with cybersecurity requirements | Core work activity for this NICE Work Role | | Task | T1464 | Determine if cybersecurity workforce management policies and procedures comply with legal and organizational requirem... | Core work activity for this NICE Work Role | | Task | T0226 | Serve on agency and interagency policy boards | Core work activity for this NICE Work Role | | Task | T1107 | Evaluate functional requirements | Core work activity for this NICE Work Role | | Task | T1158 | Develop cybersecurity implementation policies and guidelines | Core work activity for this NICE Work Role | | Knowledge | K0677 | Knowledge of cybersecurity policies and procedures | Foundational knowledge for this role | | Knowledge | K0679 | Knowledge of privacy policies and procedures | Foundational knowledge for this role | | Knowledge | K1137 | Knowledge of cybersecurity requirements | Foundational knowledge for this role | | Knowledge | K1183 | Knowledge of organizational cybersecurity policies and procedures | Foundational knowledge for this role | | Knowledge | K1186 | Knowledge of organizational human resource (HR) policies and procedures | Foundational knowledge for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0687 | Skill in performing administrative planning activities | Core capability for this role | | Skill | S0497 | Skill in developing client organization profiles | Core capability for this role | | Skill | S0515 | Skill in identifying partner capabilities | Core capability for this role | | Skill | S0519 | Skill in detecting exploitation activities | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-PSP-001 → OG-WRL-002) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-12+ years in cybersecurity governance, policy management, technical writing, or related field - Bachelor's degree or equivalent experience - Relevant certifications: CISSP, CISA, CISM, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Policy & Standards Manager is successful when CERG policies and standards are actually followed, not just filed. Key indicators: policy exceptions are rare and documented; standards are referenced in architecture reviews, risk assessments, and compliance testing by name; the policy library is current — no document is past its review date by more than 30 days; feedback from standards users results in documented improvements. The manager ensures that every CERG document is findable, readable, and usable by the person who needs it. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, this role can progress on either a senior SME path or a management path depending on organizational scale. The SME path follows L2/S2 through L4/S4 as the role gains deeper regulatory interpretation authority, audit representation capability, policy authorship, and cross-framework judgment. The management path generally runs from M1 to M3 when the role leads analysts, owns a compliance function, manages calendars and evidence operations, and contributes to budget and staffing decisions. See [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels) and [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-004 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-008 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Pre-production Reviewer **Job Family:** JF-SECENG — Security Engineering **Job Level Range:** L1-L4 (CERG Grade S1-S4) **CERG Canonical Role:** Pre-production Reviewer ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Pre-production Reviewer is a rotated Engineering role, not a permanent position. They own the pre-production checklist and sign off on go-live readiness: confirming that pre-production findings are remediated or risk-accepted, that handoff documentation is complete, and that the team inheriting the system knows its security posture. The role rotates among qualified Engineers to ensure cross-training and to prevent any single person from becoming a go-live bottleneck. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-SECENG — Security Engineering | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4 | | Terminal Grade | S4 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own and maintain the pre-production review checklist, keeping it current with evolving standards and threat landscape - Conduct pre-production reviews for systems approaching go-live: verify that architecture review findings are closed, vulnerability scans are clean or accepted, threat model findings are resolved, and handoff documentation is complete - Sign off on go-live readiness, confirming that the system meets the security bar defined in the Architecture Review Procedure - Escalate unresolved pre-production findings to the Engineering Pillar Leader and the project's Executive Sponsor - Ensure the post-go-live operations team receives a complete security handoff package: known risks, accepted findings, monitoring requirements, incident response contacts, and configuration documentation - Coordinate with Risk to confirm that pre-production vulnerability scans and adversarial testing results meet the defined bar - Coordinate with Governance to confirm that compliance-required evidence is collected before go-live ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Broad cybersecurity engineering knowledge across multiple domains (cloud, identity, application, endpoint) - Deep familiarity with the CERG Architecture Review Procedure and pre-production review process - Ability to evaluate security findings in context: what is truly blocking versus what can be accepted and tracked - Strong written communication: the pre-production review sign-off is a durable record that may be reviewed by auditors - Sufficient seniority to push back on project pressure to go live with unresolved material findings ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — Pre-production Reviewer primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T1021 | Review cyber defense service provider reporting structure | Core work activity for this NICE Work Role | | Task | T1022 | Review enterprise information technology (IT) goals and objectives | Core work activity for this NICE Work Role | | Task | T1263 | Perform security reviews | Core work activity for this NICE Work Role | | Task | T1269 | Conduct risk analysis of applications and systems undergoing major changes | Core work activity for this NICE Work Role | | Knowledge | K0711 | Knowledge of evaluation and validation principles and practices | Foundational knowledge for this role | | Knowledge | K0692 | Knowledge of vulnerability assessment tools and techniques | Foundational knowledge for this role | | Knowledge | K0720 | Knowledge of Security Assessment and Authorization (SA&A) processes | Foundational knowledge for this role | | Knowledge | K0881 | Knowledge of learning assessment tools and techniques | Foundational knowledge for this role | | Knowledge | K0955 | Knowledge of penetration testing principles and practices | Foundational knowledge for this role | | Skill | S0097 | Skill in applying security controls | Core capability for this role | | Skill | S0393 | Skill in developing assessments | Core capability for this role | | Skill | S0394 | Skill in developing security assessments | Core capability for this role | | Skill | S0463 | Skill in implementing software quality control processes | Core capability for this role | | Skill | S0632 | Skill in designing Test and Evaluation Strategies (TES) | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - An active CERG Engineer at S2 or above, nominated by the Engineering Pillar Leader - Rotation period: typically 6-12 months - No additional certifications required beyond the engineer's existing qualifications ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Engineering pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Executes assigned engineering tasks (IaC module, configuration change, architecture review checklist item) from established procedures. Recognizes when a task result does not match expected output and escalates with context. Learning the organization's technology stack: can name the major platforms, their purpose, and their security control points. | Owns a technology domain (e.g., AWS security, Azure AD, Kubernetes admission control). Designs and implements security controls independently within that domain. Performs architecture reviews in their domain and produces findings that require minimal rework from the reviewer. Authors and improves procedures for their domain. | Shapes the organization's technical security strategy in their domain. Designs reference architectures adopted by other engineers. Anticipates how changes in the technology stack will affect security posture before they land. Performs architecture reviews across domains with credibility. | Sets the technical bar for the entire Engineering pillar. Called upon for the hardest cross-domain problems. Represents the organization's engineering position to vendors, industry working groups, and regulators. Can step into any Engineering domain and contribute meaningfully within days. | | Cross-Pillar Fluency | Understands that Risk and Governance pillars exist and can describe their basic functions. Reads vulnerability reports and compliance findings that affect their work. | Consumes Risk pillar output (vulnerability data, threat intelligence) and incorporates it into engineering decisions. Understands what Governance needs from Engineering for an audit and provides it without being chased. | Anticipates what Risk and Governance will need from an engineering decision before they ask. Participates in cross-pillar working groups as the Engineering voice. Can represent Engineering's position to a regulator or auditor without a Governance handler. | Operates fluently across all three pillars. Contributes to Risk assessments and Governance standards as a peer, not a guest. Is the person a pillar leader calls when a cross-pillar problem does not fit any procedure. | | Risk Judgment | Follows the risk taxonomy when documenting findings. Can distinguish between a configuration drift alert that needs a ticket and one that needs an incident response page. | Independently assesses the severity and likelihood of findings in their domain. Assigns risk ratings that are consistent with the taxonomy and rarely adjusted by a senior reviewer. | Evaluates risk across domains and articulates the business impact in terms an executive can act on. Identifies compensating controls that reduce risk below what a pure vulnerability score would suggest. | Shapes the organization's risk appetite through technical judgment. Called upon by the CISO for independent risk assessments on material decisions. Their risk evaluation carries the same weight as a pillar leader's. | | Communication | Writes clear ticket updates and status reports. Explains a technical finding to their immediate team without ambiguity. | Writes architecture review findings that a project manager or business owner can understand and act on. Presents technical topics to their pillar. Authors clear, usable procedures. | Represents Engineering in cross-functional forums with credibility. Writes decision memos that frame technical options in business terms. Presents to senior leadership and external stakeholders. | Communicates complex technical risk to the CISO, the board (as requested), regulators, and industry peers. Writes the organization's public technical positions. Represents the organization at conferences and in industry working groups. | | Operational Discipline | Follows procedures correctly. Updates tickets and documentation when work is complete. Meets assigned SLAs. Admits when they do not know something rather than guessing. | Owns operational SLAs for their domain work streams. Ensures evidence is collected and stored per the evidence procedure. Improves procedures when they find gaps. Their work is consistently auditable without retroactive cleanup. | Designs procedures that are operationally sustainable, not just technically correct. Ensures the evidence trail for their domain is audit-ready at all times. Identifies and eliminates toil: automates repetitive operational tasks. | Sets operational standards for the pillar. Defines what "good" looks like for procedure compliance, evidence quality, and SLA management. Holds the pillar accountable to its own operational commitments. | | Influence and Mentorship | Actively learns from senior engineers. Asks good questions. Shares what they learn with peers. | Onboards new Specialists without assistance. Peer-reviews code and configurations with constructive feedback. Their technical opinion is sought by other engineers in their domain. | Mentors Specialists and Sr. Specialists across domains. Leads technical initiatives without formal authority. Their architectural recommendations are rarely overruled. | Shapes the development of the entire Engineering team. Sets the technical bar through their own work and their mentoring. Influences hiring profiles, team composition, and organizational design. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply to their organization. Can describe the security implications of the major ones (NERC-CIP, CMMC, SOX) at a high level. | Understands the specific regulatory requirements that affect their domain. Can explain to an auditor how a control they implemented satisfies a regulatory requirement. | Anticipates regulatory implications of engineering decisions. Advises project teams on compliance requirements before design is complete. Represents Engineering in regulatory audits without a Governance chaperone. | Contributes to the organization's regulatory strategy. Engages with regulators on technical matters. Shapes standards so that compliance is a byproduct of good engineering, not a separate activity. | | Continuous Learning | Completes assigned training. Pursues foundational certifications relevant to their domain. Learns the organization's technology stack. | Maintains current certifications. Stays current on developments in their domain. Shares what they learn with the team. | Pursues advanced certifications. Contributes to the team's knowledge base through documented research, brown-bag sessions, or internal training. Evaluates new technologies for organizational adoption. | Recognized externally for expertise. Shapes the organization's technology and certification roadmap. The person other engineers go to when they need to understand an emerging technology or threat. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Pre-production Reviewer is successful when security issues are identified and resolved before they reach production, not after. Key indicators: architecture reviews are completed before any infrastructure is provisioned; findings are specific enough that project teams can act on them without reinterpretation; the review cycle time does not delay releases; recurring findings trigger standard updates rather than repeated manual reviews. The reviewer is seen as an enabler of secure delivery, not a gate that slows things down. ## 11. Career Path ### 11.1 Within-Family Progression The Pre-production Reviewer is a rotated Engineering function rather than a permanent career destination. Progression occurs through the individual's home Engineering role under [JF-001 §9.1](../CERG-GOV-JF-001_Job_Families_Overview.md#91-jf-seceng--security-engineering-levels) and [JA-001 §7.2](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#72-engineering-pillar). Reviewer qualification is evidence of readiness for higher Engineering levels when the reviewer demonstrates consistent judgment, clear findings, reusable review patterns, and the ability to coach project teams before defects reach production. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-SECENG-008 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Engineering Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-008 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Risk Pillar Leader **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Risk Pillar Leader ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Risk Pillar Leader is accountable for the Cyber Risk pillar: the continuous assessment and management of the organization's exposure. They own exposure management, adversarial testing, threat intelligence, vendor risk, and the specialized OT and identity risk functions. They report the organization's exposure posture to the CISO and hold Medium severity risk-acceptance authority. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Executive Cyber Leader / Vulnerability Assessment Analyst | OG-WRL-001 / PR-VAM-001 | OV / PR | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the Risk pillar's strategy, delivery, budget, and talent - Govern exposure management operations: scanning coverage, finding triage, SLA enforcement, and remediation tracking - Govern adversarial testing: penetration testing, red team operations, and purple team exercises - Govern threat intelligence: collection, analysis, dissemination, and translation into detection and control priorities - Govern vendor and third-party risk assessment: tiering, assessment, and supply chain risk monitoring - Hold Medium severity risk-acceptance authority per the Risk Management Framework - Report exposure posture to the CISO: vulnerability trends, adversary activity, vendor risk portfolio, and key risk indicators - Coordinate with Engineering to ensure vulnerability and testing findings drive architectural improvements - Coordinate with Governance to ensure risk data feeds the risk register, compliance posture, and metrics dashboard - Develop the Risk leadership bench and manage team health, retention, and growth ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in exposure management, penetration testing, threat intelligence, or vendor risk management - Risk quantification and reporting: ability to translate technical exposure data into business-risk terms - People leadership: demonstrated ability to lead, develop, and retain a multi-function risk team - Cross-functional collaboration: ability to work with Engineering on remediation and with Governance on risk register and compliance alignment - Experience with OT risk considerations (if the organization has an OT footprint) - Budget and vendor management: security testing vendors, threat intelligence feeds, exposure management platforms ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-007 — Risk Pillar Leader primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1342 | Oversee policy standards and implementation strategy development | Core work activity for this NICE Work Role | | Task | T1476 | Promote awareness of cybersecurity policy and strategy among management | Core work activity for this NICE Work Role | | Task | T1906 | Establish a cybersecurity risk management program | Core work activity for this NICE Work Role | | Task | T1036 | Integrate leadership priorities | Core work activity for this NICE Work Role | | Task | T1056 | Acquire resources to support cybersecurity program goals and objectives | Core work activity for this NICE Work Role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0644 | Knowledge of cybersecurity operation policies and procedures | Foundational knowledge for this role | | Knowledge | K0674 | Knowledge of computer networking protocols | Foundational knowledge for this role | | Knowledge | K0676 | Knowledge of cybersecurity laws and regulations | Foundational knowledge for this role | | Knowledge | K0677 | Knowledge of cybersecurity policies and procedures | Foundational knowledge for this role | | Skill | S0406 | Skill in developing policy plans | Core capability for this role | | Skill | S0707 | Skill in developing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0708 | Skill in executing comprehensive cyber operations assessment programs | Core capability for this role | | Skill | S0821 | Skill in collaborating with internal and external stakeholders | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OG-WRL-001 → OG-WRL-007) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 15+ years in cybersecurity, with 8+ years in risk management or offensive security leadership - 5+ years of people management at increasing scope - Bachelor's degree in a relevant field; advanced degree preferred - Relevant certifications: CISSP, CISM, CRISC, GPEN, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) with the addition of the Management Track Competency Addendum ([CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7) for leadership-specific domains: People Leadership, Strategic Thinking, Resource and Budget Management, Stakeholder Management, and Organizational Development. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Risk Pillar Leader is successful when the Risk pillar's output drives organizational risk reduction, not just risk tracking. Key indicators: the risk register is the authoritative source that the CISO, Engineering, and Governance all use for prioritization; exposure posture is improving quarter over quarter across measurable dimensions; the pillar's findings are actionable and acted upon; team members can describe the pillar's strategy and how their work contributes to it. The leader is trusted to represent the CISO in risk decisions and to defend those decisions to leadership. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, the Risk Pillar Leader is the M4/Director family leadership role. Typical feeder paths are S4 Principal Analyst or Sr. Advisor roles, M3 risk operations leadership roles, or equivalent external risk leadership. Growth within this role is measured by risk posture visibility, quality of risk prioritization, reduction of unmanaged exposure, maturity of risk operations, and the ability to give the CISO defensible risk decisions. Next-step movement is generally toward CISO or broader enterprise risk/security executive accountability, not a higher CERG grade. --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-008 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-005 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Risk Register Owner **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Risk Register Owner ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Risk Register Owner operates the Risk Register and Exception Process. They curate the register, run the Monthly Risk Register Review, track risk treatment decisions, and ensure that every identified risk has an owner, a disposition, and a review date. They are the organization's memory for what risks have been accepted, why, and by whom. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Information Systems Security Manager | OV-ISSN-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Operate and maintain the risk register: ensure every identified risk is recorded with owner, severity, disposition, treatment plan, and review date - Run the Monthly Risk Register Review: prepare the agenda, facilitate the review, record decisions, and track action items - Govern the risk exception process: track exception requests, compensating controls, approval authority, and expiration dates - Record post-incident risks from Incident Response after-action reviews - Ensure risk data feeds the CISO dashboard and board reporting - Maintain the risk taxonomy and ensure consistent risk scoring across the register - Escalate overdue risk reviews, unowned risks, and risks approaching their acceptance expiration - Partner with pillar leaders to ensure risk treatment plans are actionable and tracked ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Risk management methodology: identification, assessment, treatment, monitoring, and reporting - Risk register operations and maintenance - Facilitation: ability to run a productive risk review meeting with senior stakeholders - Data discipline: the risk register is only as good as the data in it. Inconsistent scoring, missing owners, or stale entries degrade the entire program - Understanding of the CERG risk taxonomy, scoring methodology, and acceptance authority per the Risk Management Framework - GRC platform proficiency: Archer, ServiceNow GRC, SimpleRisk, or equivalent ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-014 — Risk Register Owner primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1058 | Advise senior management on risk levels and security posture | Core work activity for this NICE Work Role | | Task | T1224 | Determine impact of noncompliance on organizational risk levels | Core work activity for this NICE Work Role | | Task | T1317 | Determine if appropriate threat mitigation actions have been taken | Core work activity for this NICE Work Role | | Task | T1343 | Provide cybersecurity guidance to organizational risk governance processes | Core work activity for this NICE Work Role | | Task | T1344 | Determine if procurement activities sufficiently address supply chain risks | Core work activity for this NICE Work Role | | Knowledge | K1209 | Knowledge of risk mitigation principles and practices | Foundational knowledge for this role | | Knowledge | K0675 | Knowledge of risk management processes | Foundational knowledge for this role | | Knowledge | K0721 | Knowledge of risk management principles and practices | Foundational knowledge for this role | | Knowledge | K0734 | Knowledge of Risk Management Framework (RMF) requirements | Foundational knowledge for this role | | Knowledge | K0735 | Knowledge of risk management models and frameworks | Foundational knowledge for this role | | Skill | S0878 | Skill in performing risk analysis | Core capability for this role | | Skill | S0462 | Skill in integrating information security requirements in the acquisitions process | Core capability for this role | | Skill | S0463 | Skill in implementing software quality control processes | Core capability for this role | | Skill | S0465 | Skill in identifying critical infrastructure systems | Core capability for this role | | Skill | S0466 | Skill in identifying systems designed without security considerations | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-ISSN-001 → OG-WRL-014) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 5-12+ years in cybersecurity, risk management, or GRC - Bachelor's degree or equivalent experience - Relevant certifications: CRISC, CISA, CISSP, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Risk Register Owner is successful when the risk register is a decision-support tool, not a compliance artifact. Key indicators: risk entries are complete, current, and consistently scored; aging risks have documented reasons and treatment plans; the register is referenced in every material decision (architecture changes, vendor selection, budget allocation); leadership reviews risk trends quarterly and acts on them. The owner ensures that when someone asks "what are our top five risks," the answer is in the register, current, and actionable. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, this role can progress on either a senior SME path or a management path depending on organizational scale. The SME path follows L2/S2 through L4/S4 as the role gains deeper regulatory interpretation authority, audit representation capability, policy authorship, and cross-framework judgment. The management path generally runs from M1 to M3 when the role leads analysts, owns a compliance function, manages calendars and evidence operations, and contributes to budget and staffing decisions. See [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels) and [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-005 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-003 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # SOX ITGC Lead **Job Family:** JF-GOVCOMP — Governance & Compliance **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** SOX ITGC Lead ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The SOX ITGC Lead owns the organization's IT General Controls compliance for Sarbanes-Oxley. They manage the ITGC control evidence, coordinate SOX audits, and ensure that financially relevant systems have documented, tested, and effective controls. They are the bridge between cybersecurity governance and financial audit. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-GOVCOMP — Governance & Compliance | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Own the SOX ITGC compliance program: control scoping, design assessment, operating effectiveness testing, and deficiency management - Maintain the SOX ITGC Operational Package: control matrix, test scripts, evidence requirements, and audit coordination materials - Manage the ITGC evidence library: ensure every in-scope control has current, testable evidence - Coordinate SOX ITGC audits: external auditor logistics, evidence production, walkthrough facilitation, and deficiency response - Track ITGC deficiencies: remediation plans, compensating controls, and retesting schedules - Partner with IT operations, application owners, and business process owners to ensure controls are designed and operated as documented - Integrate SOX ITGC requirements with the broader CERG control baseline and evidence library - Report ITGC compliance posture to the Governance Pillar Leader and CISO - Monitor changes to financially relevant systems and assess impact on the ITGC control scope ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep expertise in SOX ITGC requirements: access management, change management, computer operations, and program development controls - IT audit methodology: control design assessment, operating effectiveness testing, sampling, and deficiency evaluation - COSO and COBIT frameworks - External auditor coordination and relationship management - IT general controls across ERP systems, databases, operating systems, and network infrastructure - Integration of SOX ITGC with broader cybersecurity controls to avoid duplicate testing ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — SOX ITGC Lead primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1340 | Develop cybersecurity audit processes for external services | Core work activity for this NICE Work Role | | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T0495 | Manage Accreditation Packages (e.g., ISO/IEC 15026-2) | Core work activity for this NICE Work Role | | Task | T1012 | Expand network access | Core work activity for this NICE Work Role | | Task | T1013 | Conduct technical exploitation of a target | Core work activity for this NICE Work Role | | Knowledge | K0742 | Knowledge of identity and access management (IAM) principles and practices | Foundational knowledge for this role | | Knowledge | K0476 | Knowledge of language processing tools and techniques | Foundational knowledge for this role | | Knowledge | K0653 | Knowledge of cybersecurity practices in the acquisition process | Foundational knowledge for this role | | Knowledge | K0655 | Knowledge of intelligence fusion | Foundational knowledge for this role | | Knowledge | K0658 | Knowledge of cognitive biases | Foundational knowledge for this role | | Skill | S0015 | Skill in conducting test events | Core capability for this role | | Skill | S0097 | Skill in applying security controls | Core capability for this role | | Skill | S0111 | Skill in interfacing with customers | Core capability for this role | | Skill | S0136 | Skill in network systems management principles, models, methods (e.g., end-to-end systems performance monitoring), an... | Core capability for this role | | Skill | S0141 | Skill in assessing security systems designs | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 7-15+ years in IT audit, SOX compliance, or information security governance - Bachelor's degree in accounting, information systems, or a related field - Relevant certifications: CISA, CISSP, CPA, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Governance pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Governance pillar's tools (document management system, evidence library, GRC platform). Executes evidence collection, control testing, or policy review tasks from established procedures. Reads and correctly interprets CERG standards and regulatory requirements in their assigned domain. | Owns a compliance domain. Independently collects, organizes, and presents evidence for audits and assessments. Maps regulatory requirements to CERG controls and identifies gaps. Authors compliance documentation that requires minimal revision. | Shapes the organization's compliance strategy for their domain. Designs evidence collection workflows that survive auditor scrutiny. Interprets ambiguous regulatory guidance and produces defensible organizational positions. | Sets the compliance and governance bar for the entire Governance pillar. Called upon for the hardest regulatory interpretation questions. Represents the organization to regulators, assessors, and auditors as the authoritative technical voice. | | Cross-Pillar Fluency | Understands the basic functions of Engineering and Risk pillars. Reads engineering architecture outputs and risk assessments that affect their compliance work. | Engages Engineering and Risk as partners in compliance, not subjects of it. Understands the technical reality behind the controls they are assessing. Requests evidence in terms the providing pillar understands. | Translates between regulatory language and technical reality in both directions. Anticipates which engineering or risk decisions will have compliance implications before they are made. | Operates fluently across all three pillars. Engages with Engineering on architecture and Risk on exposure posture as a peer. | | Risk Judgment | Applies the risk taxonomy when documenting compliance findings. Understands the relationship between control failures and organizational risk. | Assesses the risk implication of control gaps in their domain. Prioritizes compliance findings by actual risk to the organization, not by framework numbering. | Evaluates the risk impact of regulatory changes. Advises leadership on the risk trade-offs of compliance decisions. Correlates compliance findings with vulnerability and threat data. | Shapes organizational risk decisions through the compliance lens. Advises the CISO on the risk implications of regulatory strategy. | | Communication | Writes clear evidence descriptions, control test results, and compliance status updates. Communicates evidence requests to Engineering and Risk without ambiguity. | Presents compliance status and findings to pillar leadership. Translates regulatory requirements into language project teams can act on. Writes policy and standard sections that are clear and enforceable. | Represents the organization to auditors, assessors, and regulators as a primary point of contact. Writes regulatory responses and compliance positions adopted by leadership. | Communicates the organization's compliance posture to the board, regulators, and external stakeholders. Shapes the organization's regulatory narrative. | | Operational Discipline | Follows evidence management procedures. Documents compliance activities in the designated systems. Meets regulatory filing deadlines. Maintains organized, retrievable evidence packages. | Owns the compliance calendar for their domain. Ensures evidence is collected, reviewed, and stored on schedule. Maintains audit-ready evidence packages at all times. | Designs compliance operations that are sustainable year-round. Ensures the Governance pillar's operational cadence is documented, measured, and improving. | Sets operational standards for the Governance pillar. Defines what "audit-ready" means in measurable terms. | | Influence and Mentorship | Learns from senior Governance staff. Asks good questions about regulatory interpretation and evidence standards. Supports peers during audit preparation. | Trains new Governance staff on compliance domains and evidence procedures. Peer-reviews compliance documentation. Their regulatory knowledge is sought by Engineering and Risk staff. | Mentors Governance staff across compliance domains. Influences how the organization approaches regulatory compliance, moving from reactive to proactive. | Develops the compliance capability of the entire Governance team and the broader organization. Sets the quality bar for regulatory interpretation, evidence standards, and auditor engagement. | | Compliance and Regulatory Literacy | Knows the regulatory frameworks in the organization's scope. Can describe the structure and key requirements of each. Correctly applies framework terminology. | Deep knowledge of the regulatory frameworks in their domain. Independently interprets regulatory requirements and maps them to organizational controls. | Authority on their regulatory domain. Interprets ambiguous regulatory guidance and produces defensible positions. Anticipates regulatory changes. | Shapes the organization's regulatory strategy. Engages directly with regulators and industry bodies on regulatory development. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's regulatory landscape. | Maintains current certifications. Tracks regulatory developments and framework updates relevant to their domain. | Pursues advanced certifications. Contributes to the Governance body of knowledge through documented regulatory analysis. | Recognized externally for regulatory or compliance expertise. Contributes to regulatory development, industry standards, or professional certification bodies. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A SOX ITGC Lead is successful when ITGC audits are boring — no material weaknesses, no significant deficiencies, no surprises. Key indicators: control testing pass rates are above 90% with a clear trend line; control deficiencies are identified by internal testing before the external auditors find them; remediation plans for any control failures are documented and tracked; SOD conflicts are identified and remediated proactively. The lead ensures that ITGC is a well-oiled machine that the external auditors trust. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-GOVCOMP, this role can progress on either a senior SME path or a management path depending on organizational scale. The SME path follows L2/S2 through L4/S4 as the role gains deeper regulatory interpretation authority, audit representation capability, policy authorship, and cross-framework judgment. The management path generally runs from M1 to M3 when the role leads analysts, owns a compliance function, manages calendars and evidence operations, and contributes to budget and staffing decisions. See [JF-001 §9.3](../CERG-GOV-JF-001_Job_Families_Overview.md#93-jf-govcomp--governance--compliance-levels) and [JA-001 §7.4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#74-governance-pillar). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-GOVCOMP-003 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Governance Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-003 | | **Version** | 1.0 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Threat Intelligence Analyst **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Threat Intelligence Analyst ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Threat Intelligence Analyst owns threat-actor tracking, intelligence collection and analysis, and the translation of threat intelligence into actionable priorities for detection, exposure management, and risk decisions. They produce intelligence products that tell the organization who is threatening it, how, and what to do about it. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Threat/Warning Analyst | AN-TWA-001 | AN | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Collect, process, and analyze threat intelligence from open-source, commercial, industry (E-ISAC, ISACs), and government sources - Track threat actors relevant to the organization's industry, geography, and technology footprint - Produce threat intelligence products: daily/weekly briefs, actor profiles, campaign reports, and strategic assessments - Disseminate actionable intelligence to Detection Engineering (new detection rules), Exposure Management (prioritize by active exploitation), and Engineering (design decisions informed by threat activity) - Maintain the organization's threat profile: what actors are targeting us, what techniques they use, what our most likely attack scenarios are - Support incident response with threat actor attribution and TTP context - Manage threat intelligence platform (TIP) and feed integrations - Build and maintain relationships with industry peers, ISACs, and government cybersecurity agencies ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Deep understanding of the threat intelligence lifecycle: collection, processing, analysis, dissemination, feedback - Threat actor tracking: APT groups, criminal enterprises, hacktivists, and their TTPs - MITRE ATT&CK framework fluency: mapping threat activity to techniques and translating to detection opportunities - Intelligence analysis techniques: structured analytic techniques, confidence levels, intelligence writing - ICS/OT threat landscape awareness (if the organization has OT) - Open-source intelligence (OSINT) collection and analysis - Threat intelligence platforms: MISP, ThreatConnect, Anomali, or equivalent ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [PD-WRL-006 — Threat Intelligence Analyst primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T0845 | Identify cyber threat tactics and methodologies | Core work activity for this NICE Work Role | | Task | T1798 | Provide intelligence analysis and support | Core work activity for this NICE Work Role | | Task | T0685 | Evaluate threat decision-making processes | Core work activity for this NICE Work Role | | Task | T0698 | Facilitate continuously updated intelligence, surveillance, and visualization input to common operational picture man... | Core work activity for this NICE Work Role | | Task | T0718 | Identify intelligence gaps and shortfalls | Core work activity for this NICE Work Role | | Knowledge | K1009 | Knowledge of threat intelligence principles and practices | Foundational knowledge for this role | | Knowledge | K0789 | Knowledge of adversarial tactics tools and techniques | Foundational knowledge for this role | | Knowledge | K0857 | Knowledge of malware analysis tools and techniques | Foundational knowledge for this role | | Knowledge | K0480 | Knowledge of malware | Foundational knowledge for this role | | Knowledge | K0655 | Knowledge of intelligence fusion | Foundational knowledge for this role | | Skill | S0446 | Skill in mimicking threat actors | Core capability for this role | | Skill | S0516 | Skill in performing threat emulation tactics | Core capability for this role | | Skill | S0535 | Skill in performing threat factor analysis | Core capability for this role | | Skill | S0436 | Skill in creating target intelligence products | Core capability for this role | | Skill | S0517 | Skill in anticipating threats | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (AN-TWA-001 → PD-WRL-006) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity, threat intelligence, or intelligence analysis - Bachelor's degree in a relevant field (international relations, cybersecurity, intelligence studies) or equivalent experience - Relevant certifications: GCTI, CTIA, CISSP, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Threat Intelligence Analyst is successful when intelligence drives organizational decisions rather than filling a report nobody reads. Key indicators: intelligence products are consumed by Engineering (to prioritize controls), by Risk (to update exposure assessments), and by leadership (to inform budget and strategy); intelligence informs detection rule creation with measurable improvements in detection coverage; finished intelligence is delivered before the relevant threat events. The analyst is the person leadership asks "what should we worry about this quarter?" ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, progression follows the Risk Operations level ladder in [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels): L1 Associate Analyst/S1, L2 Analyst/S2, L3 Senior or Lead Analyst/S3, and L4 Principal Analyst/S4. Promotion evidence should show increasing ownership of risk workflows, stronger analytical judgment, documented influence on remediation or risk acceptance decisions, cross-pillar collaboration with Engineering and Governance, and mentoring of less experienced analysts. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-003 | | **Version** | 1.0 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- | | | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-007 | | **Version** | 1.1 | | **Status** | Approved | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | --- # Vendor Risk Analyst **Job Family:** JF-RISKOPS — Risk Operations **Job Level Range:** L1-L4 (CERG Grade S1-S4/M3) **CERG Canonical Role:** Vendor Risk Analyst ([CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1) --- ## 1. Role Summary The Vendor Risk Analyst operates the Third-Party and Supply Chain Risk Procedure. They assess the security posture of vendors, suppliers, and service providers before and during the relationship. They tier vendors by risk, conduct assessments, track findings, and ensure that the organization's supply chain does not become its weakest security link. ## 2. NICE Workforce Framework Mapping | Mapping Level | NICE Work Role | NICE Work Role ID | NICE Work Role Category | |---------------|----------------|-------------------|-------------------------| | Primary | Security Control Assessor | OV-SCA-001 | OV | **NICE Work Role Definition:** See [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) for the official NICE Work Role definition and complete CERG-to-NICE mapping. The NICE TKS database is available at https://www.nist.gov/nice/framework/. ## 3. Job Family & Level Placement | Family | JF-RISKOPS — Risk Operations | |--------|---------------------------| | Level Range | L1 through L4 | | CERG Grade Range | S1-S4/M3 | | Terminal Grade | S4/M3 — see [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) for details | | Track | SME / Dual-track | ## 4. Key Responsibilities ### 4.1 Core Responsibilities (All Grades) - Tier vendors by risk based on data access, system integration, and business criticality - Conduct vendor security assessments: questionnaires, evidence review, and where warranted, remote or on-site assessment - Review vendor contracts for security requirements, including breach notification, data handling, right-to-audit, and termination clauses - Track vendor assessment findings and verify remediation - Maintain the vendor risk register: tiering, assessment status, findings, and risk ratings - Monitor vendor security posture changes: breach notifications, merger/acquisition, service changes - Assess third-party AI services for security risk: data handling, model supply chain, prompt injection exposure - Coordinate with Legal, Procurement, and business owners to ensure security requirements are included in vendor relationships - Support incident response for supply-chain compromises: identifying affected vendors, assessing exposure, and coordinating vendor communication - Participate in Supply Chain Coordination Team (SCCT) activities ### 4.2 Grade-Level Responsibility Differentiation Grade-level responsibility differentiation for this role is defined in [JA-001 §7](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) (Role-to-Grade Mapping). The grade definitions (S1-S4 SME Track, M1-M4 Management Track) and leveling dimensions are in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §4-5. Behavioral anchors at each grade are in [CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). ## 5. Required Knowledge, Skills, and Abilities (KSAs) ### 5.1 Domain Expertise - Third-party risk management frameworks and methodologies - Vendor security assessment techniques: questionnaire design, evidence evaluation, control validation - Contract review for security and data protection requirements - Understanding of common vendor risks: data residency, subcontractor cascading, concentration risk, shared responsibility model misunderstandings - Cloud and SaaS security assessment - Supply chain risk: software supply chain (SBOM, dependency risk), hardware supply chain, managed service providers - Regulatory requirements for vendor oversight under applicable frameworks (NERC-CIP, CMMC, SOX, GDPR) ### 5.2 Technical Skills Technical skills for this role are documented in the original JD-001 content extracted into this file (see §5.1 Domain Expertise). Additional technical skill definitions aligned to NICE Skill Statements are maintained in [JF-002](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md). ### 5.3 CERG-Specific Knowledge CERG-specific knowledge requirements for this role are defined in [OM-001 §6](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) (Canonical Role Roster) and [RAC-001 §7](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) (Role Descriptions). See §12 (Related CERG Documents) for the complete list of standards and procedures relevant to this role. ## 6. NICE TKS Statement References The following Task, Knowledge, and Skill statements are extracted from the NIST NICE Framework v2.2.0 Work Role [OG-WRL-012 — Vendor Risk Analyst primary mapping] and filtered by relevance to this CERG role. The full TKS database is maintained at https://www.nist.gov/nice/framework/. | NICE TKS Type | Statement ID | Statement Summary | Relevance to This Role | |---------------|-------------|-------------------|------------------------| | Task | T1054 | Scope analysis reports to various audiences that accounts for data sharing classification restrictions | Core work activity for this NICE Work Role | | Task | T0309 | Assess the effectiveness of security controls | Core work activity for this NICE Work Role | | Task | T0495 | Manage Accreditation Packages (e.g., ISO/IEC 15026-2) | Core work activity for this NICE Work Role | | Task | T1012 | Expand network access | Core work activity for this NICE Work Role | | Task | T1013 | Conduct technical exploitation of a target | Core work activity for this NICE Work Role | | Knowledge | K0692 | Knowledge of vulnerability assessment tools and techniques | Foundational knowledge for this role | | Knowledge | K0720 | Knowledge of Security Assessment and Authorization (SA&A) processes | Foundational knowledge for this role | | Knowledge | K0803 | Knowledge of supply chain risk management principles and practices | Foundational knowledge for this role | | Knowledge | K0820 | Knowledge of supply chain risks | Foundational knowledge for this role | | Knowledge | K0838 | Knowledge of supply chain risk management policies and procedures | Foundational knowledge for this role | | Skill | S0686 | Skill in performing risk assessments | Core capability for this role | | Skill | S0393 | Skill in developing assessments | Core capability for this role | | Skill | S0394 | Skill in developing security assessments | Core capability for this role | | Skill | S0673 | Skill in translating operational requirements into security controls | Core capability for this role | | Skill | S0015 | Skill in conducting test events | Core capability for this role | > **Full TKS Reference:** The complete TKS statement set for the primary NICE Work Role (OV-SCA-001 → OG-WRL-012) is in the NICE Framework Components v2.2.0 dataset ([download](https://csrc.nist.gov/csrc/media/Projects/cprt/documents/nice/v2-2-0_nf_components.json)). JF-002 contains the complete CERG-to-NICE crosswalk with secondary role mappings. ## 7. Typical Qualifications ### 7.1 Education - 3-12+ years in cybersecurity, vendor risk management, or IT audit - Bachelor's degree or equivalent experience - Relevant certifications: CISA, CISSP, CTPRP, or equivalent ### 7.2 Certifications Certifications for this role are defined in [TRN-001 §3](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) (Certification Matrix). The matrix specifies Required, Recommended, and Aspirational certifications per role and grade. ### 7.3 Experience Typical experience ranges by grade are defined in [JA-001 §4-5](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md). See §7.1 (Education) above for education requirements. ## 8. Key Performance Indicators (KPIs) KPIs for this role are defined in [MTR-001](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (Metrics, Dashboard, and CISO/Board Reporting). KPI allocation by job family and grade-level thresholds are documented in [PERF-001](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md). Each role's evaluation criteria are embedded in the per-role JD document structure defined by [JF-001](../CERG-GOV-JF-001_Job_Families_Overview.md). ## 9. Competency Expectations by Grade Competency expectations for this role follow the Risk pillar behavioral anchors from [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md). Each cell describes observable behavior demonstrating the competency at that grade. Anchors are cumulative: an L3 expectation includes the L1 and L2 anchors. | Competency Domain (CMP-001) | L1 Expectation | L2 Expectation | L3 Expectation | L4 Expectation | |-----------------------------|----------------|----------------|----------------|----------------| | Technical Depth | Operates the Risk pillar's tools (vulnerability scanner, CSPM platform, threat intel platform, detection pipeline) under supervision. Triages alerts following established procedures. Recognizes false positives and true positives with increasing accuracy. | Owns a Risk domain (e.g., exposure management for a platform class, vendor assessments for a business unit, a set of detection rules). Tunes tools to reduce noise and improve signal. Independently investigates findings and determines root cause. | Shapes the Risk pillar's approach to exposure management. Designs assessment methodologies. Correlates findings across tools to identify systemic weaknesses that individual alerts miss. | Sets the analytical bar for the entire Risk pillar. Called upon for the hardest exposure questions. Represents the organization's risk posture to regulators, auditors, and industry peers. | | Cross-Pillar Fluency | Understands that Engineering builds systems and Governance owns compliance. Reads architecture review outputs and compliance standards that affect their risk assessments. | Delivers risk findings in a format Engineering can act on. Understands what evidence Governance needs from Risk assessments and provides it proactively. Participates in cross-pillar threat modeling sessions. | Collaborates with Engineering to design controls that address risk findings, not just report them. Feeds risk intelligence into Governance's compliance calendar. Anticipates which risk findings will become audit findings. | Operates fluently across all three pillars. Contributes to Engineering architecture decisions and Governance standards as a peer. The person a pillar leader calls when a risk question spans all three pillars. | | Risk Judgment | Applies the risk taxonomy correctly when triaging findings. Distinguishes between Critical, High, Medium, and Low severity using the defined criteria. Escalates findings that exceed SLA without delay. | Independently assesses the business impact of findings in their domain. Adjusts risk ratings based on context and documents the rationale. Produces risk assessments that the Risk Pillar Leader accepts without material revision. | Assesses systemic risk: identifies patterns across individual findings that indicate a deeper weakness. Evaluates risk from new technologies, vendors, or business initiatives before they are operational. | Shapes the organization's risk appetite. Called upon by the CISO for independent risk evaluation on material decisions. Their risk judgment on novel or ambiguous situations is treated as authoritative. | | Communication | Writes clear finding descriptions with reproducible steps, impact statements, and remediation guidance. Updates stakeholders on finding status without being prompted. | Delivers risk briefings to business owners and project teams. Translates vulnerability data into business risk without losing technical accuracy. Writes vendor risk assessment reports that procurement and legal can act on. | Presents risk posture to executive audiences. Communicates threat landscape changes and their organizational implications. Writes threat intelligence products consumed by leadership. | Communicates organizational risk posture to the board, regulators, and external stakeholders. Represents the organization's risk position in industry forums. | | Operational Discipline | Triages findings within SLA. Documents assessment results in the designated system. Follows the exposure management and risk register procedures. | Owns operational SLAs for their domain. Ensures risk register entries are current and complete. Maintains scanning schedules, detection rule lifecycles, or vendor assessment cadences without gaps. | Designs risk assessment workflows that produce consistent, auditable output. Ensures the Risk pillar's operational cadence is documented, measured, and improving. Identifies and automates repetitive risk assessment tasks. | Sets operational standards for the Risk pillar. Defines what "defensible" risk assessment looks like under regulatory scrutiny. | | Influence and Mentorship | Learns from senior analysts. Asks good questions about methodology and judgment. Shares interesting findings with the team. | Trains new analysts on Risk tools and procedures. Peer-reviews risk assessments and detection rules. Their analytical judgment is sought by other team members. | Mentors analysts across Risk domains. Leads cross-functional risk initiatives. Their risk assessments shape how Engineering and business owners prioritize remediation. | Develops the analytical capability of the entire Risk team. Sets the quality bar for risk assessment, threat intelligence, and detection engineering. Influences organizational risk culture. | | Compliance and Regulatory Literacy | Knows which regulatory frameworks apply and can describe how Risk assessments support compliance. | Understands the specific regulatory requirements that govern their Risk domain. Produces risk assessments that meet the evidence standards of the relevant frameworks. | Anticipates how regulatory changes will affect the Risk program's scope and cadence. Advises Governance on the risk implications of compliance findings. | Contributes to the organization's regulatory strategy from a risk perspective. Engages with regulators on risk methodology. | | Continuous Learning | Completes assigned training. Pursues foundational certifications. Learns the organization's threat landscape. | Maintains current certifications. Tracks the threat actors, TTPs, and vulnerabilities relevant to the organization's industry. | Pursues advanced certifications. Contributes threat research or methodology improvements adopted by the team. Represents the organization in threat-sharing communities. | Recognized externally for risk or threat expertise. Contributes to industry threat intelligence, risk methodology, or detection frameworks. | > **Full Reference:** See [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) for the complete competency model, including the Management Track addendum (§7) and guidance on using the model for hiring, development, and promotion (§8). ## 10. Success Profile A Vendor Risk Analyst is successful when vendor risk is managed systematically rather than through fire drills triggered by news events. Key indicators: every in-scope vendor has a current risk assessment with a clear risk rating; vendor onboarding SLAs are met without security being the bottleneck; high-risk vendor findings have documented remediation plans with owner and due date; the vendor register is current enough that leadership can answer "what is our supply chain risk exposure?" in a single meeting. ## 11. Career Path ### 11.1 Within-Family Progression Within JF-RISKOPS, progression follows the Risk Operations level ladder in [JF-001 §9.2](../CERG-GOV-JF-001_Job_Families_Overview.md#92-jf-riskops--risk-operations-levels): L1 Associate Analyst/S1, L2 Analyst/S2, L3 Senior or Lead Analyst/S3, and L4 Principal Analyst/S4. Promotion evidence should show increasing ownership of risk workflows, stronger analytical judgment, documented influence on remediation or risk acceptance decisions, cross-pillar collaboration with Engineering and Governance, and mentoring of less experienced analysts. The grade definitions and progression dimensions are maintained in [JA-001 §4](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md#4-sme-progression-grade-definitions). --- ### 11.2 Cross-Family Movement Cross-family movement options are defined in the [Family-to-Family Career Lattice (JF-001 §4)](../CERG-GOV-JF-001_Job_Families_Overview.md#4-family-to-family-career-lattice). The Left-Right Knowledge Model ([FRM-001 §9.2](../../governance/CERG-GOV-FRM-001_CERG_Framework.md)) and cross-training expectations ([OM-001 §10.4](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md)) operationalize cross-family career movement. ### 11.3 Management Track Option At L3+ (SME track), a Management track option may be available per [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §8.1 (SME to Management Transition). Readiness indicators include: consistently sought out for guidance by junior team members, leading cross-functional initiatives without formal authority, and communicating clearly with non-technical stakeholders. The transition is a track change, not a grade promotion — an S3 Advisor moving to M1 Manager carries their technical credibility into the management role. Management competencies are defined in [CERG-GOV-CMP-001](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) §7. See [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §5 for Management grade definitions (M1-M4) and §9 (Span of Control and Team Design) for when to create a management role. ## 12. Related CERG Documents | Document | ID | Relevance | |----------|-----|-----------| | Operating Model | [`CERG-GOV-OM-001`](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) | Canonical role name; pillar structure | | RACI Instrument | [`CERG-GOV-RAC-001`](../../governance/CERG-GOV-RAC-001_Consolidated_Roles_and_RACI_Instrument.md) | This role's accountability assignments | | Job Architecture | [`CERG-GOV-JA-001`](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) | Grade definitions; progression criteria | | Competency Model | [`CERG-GOV-CMP-001`](../../governance/CERG-GOV-CMP-001_Competency_Model_and_Behavioral_Anchors.md) | Full behavioral anchors | | Performance Framework | [`CERG-GOV-PERF-001`](../../governance/CERG-GOV-PERF-001_Performance_Management_and_Promotion_Framework.md) | Performance review cadence and calibration | | Training Framework | [`CERG-GOV-TRN-001`](../../governance/CERG-GOV-TRN-001_Training_Development_and_Certification_Framework.md) | Certification matrix | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- ## 13. Document Control | Field | Value | |---|---| | **Document ID** | CERG-GOV-JD-RISKOPS-007 | | **Version** | 1.1 | | **Status** | Approved | | **Effective Date** | 2026-06-11 | | **Classification** | Public | | **Owner** | Risk Pillar Leader | | **Approved By** | CISO | | **Parent Policy** | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - Cybersecurity Policy | | **Review Cycle** | Annual | | **Next Scheduled Review** | 2027-06-11 | | **Frameworks** | NIST SP 800-181r1 (NICE) | | **Regulations** | Cross-cutting | | **Environments** | All CERG-managed workforce | ### Revision History | **Version** | **Date** | **Author** | **Change Summary** | |---|---|---|---| | 1.1 | 2026-06-18 | Governance Pillar Leader | Corrected role body content so Vendor Risk Analyst responsibilities, KSAs, qualifications, and profile align to third-party and supply-chain risk rather than detection engineering. | | 1.0 | 2026-06-11 | Governance Pillar Leader | Initial release. Extracted from monolithic JD-001 into enhanced per-role format with NICE mapping, KPI sections, and competency anchor sections. | ### Review Triggers - Change to this role's definition in [CERG-GOV-OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) §6.1 - Change to this role's NICE Work Role mapping in JF-002 - Change to this role's grade range in [CERG-GOV-JA-001](../../governance/CERG-GOV-JA-001_Job_Architecture_and_Grade_Framework.md) §7 - Direction from the CISO Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining approval for all changes. ### Related Documents | **Document** | **ID** | **Relationship** | |---|---|---| | Cybersecurity Policy | [`CERG-POL-001`](../../governance/CERG-POL-001_Cybersecurity_Policy.md) | Parent policy | | Job Families Overview | [`CERG-GOV-JF-001`](../CERG-GOV-JF-001_Job_Families_Overview.md) | Family structure and level definitions | | NICE Crosswalk | [`CERG-GOV-JF-002`](../CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md) | NICE Work Role mapping | --- # CERG Machine-Readable Artifacts This directory contains machine-readable YAML specifications generated from the CERG corpus. These files are designed for consumption by LLMs, automation tools, and programmatic validation. > **⚠ These are DERIVED ARTIFACTS.** The CERG markdown corpus is authoritative. If a YAML file and its source disagree, the source wins. YAML files are regenerated when source documents change; manual edits are overwritten. See `METADATA.yaml` for per-file governance information. ## Maturity Status | File | Status | Notes | |------|--------|-------| | `cerg-llm-index.json` | Production | Full local Markdown corpus index (131 docs, including README/meta/example files) | | `cerg-manifest.yaml` | Production | Governed source artifact inventory (118 artifacts) with hashes, canonical paths, and LLM flags | | `cerg-publication-manifest.yaml` | Production | Publication eligibility per governed artifact | | `cerg-content-tags.yaml` | Production | Section-level content tags | | `cerg-document-tiers.yaml` | Stable | Agent-friendly adoption tiers, loading order, and deferral guidance | | `cerg-agent-extension-roadmap.yaml` | Stable | Guardrails for optional agent, schema, detection, and evidence-collection extensions | | `cerg-flows.yaml` | Production | 7 cross-pillar flow specifications | | `cerg-record-schemas.yaml` | Production | Core operational record schemas | | `cerg-runtime-model.yaml` | Stable | Core operational objects | | `cerg-requirements.yaml` | **Pilot** | 85 atomic requirements extracted from 8 normative source documents. `owner_role` and `evidence_required` fields require population during adoption — see file header for instructions. | | `cerg-vulnerability-priority-model.yaml` | Stable | Priority formula references CVSS-weighting — adopters should calibrate weights to their environment | | All other schemas | Stable | Single-purpose companion schema files — adopt as-is or adapt | ## Adoption Checklist For each machine-readable artifact: 1. **Verify source alignment.** Confirm the YAML matches the current state of its source CERG document(s). 2. **Populate adoption fields.** For `cerg-requirements.yaml`, assign `owner_role` and `evidence_required` for every mandatory requirement. 3. **Calibrate models.** For `cerg-vulnerability-priority-model.yaml`, validate that weights and SLAs match organizational policy. 4. **Test consumption.** Load the artifacts into your target system (GRC tool, SIEM, automation pipeline) and verify schema compatibility. 5. **Set regeneration triggers.** Define what source-document changes trigger artifact regeneration in your CI/CD pipeline. ## File Inventory | File | Purpose | Source | |------|---------|--------| | `cerg-llm-index.json` | Full local Markdown corpus index for LLM/agent consumption | Repo-local Markdown corpus | | `cerg-manifest.yaml` | Canonical manifest of all 118 governed CERG source artifacts with metadata, hashes, canonical paths, and LLM consumption flags | Governed Markdown artifact metadata | | `cerg-publication-manifest.yaml` | Publication eligibility for each governed artifact — separates lifecycle approval from "safe to publish" | Document metadata | | `cerg-content-tags.yaml` | Content type tags for every section heading in the corpus | All CERG documents | | `cerg-document-tiers.yaml` | Adoption tiers, loading order, safe deferrals, and agent task mapping | README, START-HERE, IMP-005, MVC spine, adoption aids | | `cerg-agent-extension-roadmap.yaml` | Structured disposition of optional extension ideas so agents do not expand core CERG by default | Maintainer review of agent/automation extension proposals | | `cerg-requirements.yaml` | Atomic requirements extracted from 8 normative source documents (pilot; not the MVC spine) | POL-001, STD-AC/IT/LM/RES/CR, CB-001, RMF-001 | | `cerg-flows.yaml` | Cross-pillar operational flow specifications (7 flows) | FLOW-001 | | `cerg-record-schemas.yaml` | Record template schemas (5 record types) | FLOW-001 §16 | | `cerg-runtime-model.yaml` | Core operational objects and their relationships | CERG-ACT-006 | | `cerg-control-evidence-map.yaml` | Control-to-evidence traceability | CB-001 | | `cerg-evidence-schema.yaml` | Evidence lifecycle and object schema | CERG-ACT-008 | | `cerg-metrics-model.yaml` | Decision-grade metrics model and CISO dashboard sections | MTR-001, CERG-ACT-009 | | `cerg-crown-jewel-schema.yaml` | Crown Jewel register schema and criticality tiers | CERG-ACT-010 | | `cerg-vulnerability-priority-model.yaml` | Risk-weighted vulnerability prioritization model | CERG-ACT-011 | | `cerg-control-test-plan.yaml` | Control efficacy test plan schema | CERG-ACT-012 | | `cerg-ir-interface.yaml` | CERG-to-IR interface contract | CERG-ACT-013 | | `cerg-vendor-kill-switch.yaml` | Vendor access disablement procedure schema | CERG-ACT-014 | | `cerg-tier-0-identity-profile.yaml` | Tier 0 identity controls for Crown Jewel systems | CERG-ACT-015 | | `cerg-segmentation-schema.yaml` | Network segmentation verification schema | CERG-ACT-016 | | `cerg-ai-system-intake.yaml` | AI/ML system security intake schema | CERG-ACT-017 | | `cerg-workforce-capacity-model.yaml` | Workforce capacity model schema | CERG-ACT-018 | | `cerg-decision-log.yaml` | Governance decision log schema | CERG-ACT-019 | ## How These Are Generated Core indexes and manifests are generated from the repo-local CERG Markdown corpus during the build process. `cerg-manifest.yaml` and `cerg-publication-manifest.yaml` are regenerated with `python3 tools/regenerate-machine-readable.py`. `cerg-llm-index.json` is regenerated with `python3 tools/regenerate-llm-index.py`. The requirement register is regenerated when its normative source documents change. Single-purpose schema files are maintained alongside the documents they describe. ## For LLM Consumers Start with `cerg-document-tiers.yaml` when choosing what to load for an adoption task, then use `cerg-agent-extension-roadmap.yaml` before implementing automation-heavy extension ideas. Use `cerg-llm-index.json` for the complete Markdown corpus map. Use `cerg-manifest.yaml` for governed source artifacts and canonical paths, then load `cerg-content-tags.yaml` to understand what each section contains. Use `cerg-requirements.yaml` for traceable obligations after populating adoption-specific fields. Use the individual schema files for structured field definitions. --- --- name: Validation / CI error about: Report a CI validation failure or catalog error title: "[VALIDATION] " labels: bug, validation assignees: '' --- **What failed?** (paste the error message or describe the CI failure) **File(s) affected:** **Steps to reproduce:** 1. `python3 tools/cerg-validate.py` 2. ... **Expected result:** Validation passes with 0 errors **Actual result:** --- **Note:** 43 pre-existing PLACEHOLDER_IN_APPROVED warnings are expected and not a problem. New *errors* are. --- # Adopt CERG With an Agent This guide gives humans and AI assistants a safe way to start CERG adoption without turning the full repository into an overwhelming rewrite project. ## 1. Operating rules for the agent Use these rules in every adoption session: 1. Ask one question at a time when collecting organization-specific facts. 2. Do not mark documents approved for the organization without explicit human confirmation. 3. Do not claim regulatory compliance or certification readiness. 4. Preserve CERG document IDs unless the user intentionally creates a local numbering system. 5. Prefer tailoring, deferral, and role consolidation over deleting core operating-model content. 6. Record assumptions separately from facts. 7. Produce records and decisions, not just rewritten prose. 8. Keep the first adoption focused on the MVC spine unless a regulated overlay is clearly in scope. ## 2. Recommended agent context Before helping with adoption, load these files: 1. [README.md](README.md) 2. [START-HERE.md](START-HERE.md) 3. [adoption-packs/cerg-lite/README.md](adoption-packs/cerg-lite/README.md) 4. [machine-readable/cerg-document-tiers.yaml](machine-readable/cerg-document-tiers.yaml) 5. [machine-readable/cerg-llm-index.json](machine-readable/cerg-llm-index.json) Load additional documents only when the task requires them. ## 3. First prompt for CERG Lite Copy and paste this into your agent: ```text You are helping me adopt CERG Lite. Do not rewrite documents yet. First, help me decide whether CERG is appropriate for my organization and whether Lite, Standard, or Regulated applies. Ask one question at a time. Track assumptions separately from confirmed facts. When we are done, produce: adoption path recommendation, initial scope statement, role assignment draft, first 30-day checklist, and list of documents to defer. ``` ## 4. Organization profile prompt ```text Help me complete the CERG Organization Adaptation Profile. Use the CERG source documents as reference. Ask one question at a time for organization name, sector, headcount, systems in scope, data types, regulators, executive sponsor, security owner, risk acceptance authority, record locations, and review cadence. Do not invent answers. If I do not know, write "preliminary default requiring organizational calibration" and explain what decision is needed. ``` ## 5. First records prompt ```text Using CERG Lite, help me create the first operating records. Produce draft records for: role assignment, scope statement, evidence index, first risk register entry, first exposure backlog item, and first decision log entry. Keep each record short. Use fields from the CERG Record Catalog and Risk Register Templates where applicable. ``` ## 6. Deferral prompt ```text Review the CERG document tiers and help me decide what to defer for the first 30 days. For each deferred document or document group, give the reason, dependency risk, trigger for adoption, and whether the deferral is safe, conditional, or unsafe. ``` ## 7. Regulated overlay prompt Use this only if CUI, CMMC, NERC-CIP, SOX, ISO 27001, privacy, OT, or similar obligations are in scope. ```text Help me identify CERG regulated overlays that may apply. Do not claim compliance. Ask about data types, contracts, systems, business processes, regulators, and assessment goals. Then produce a recommended overlay list, evidence implications, and documents that become required because of the overlay. ``` ## 8. Contributor prompt ```text I want to contribute to CERG. Read CONTRIBUTING.md and the document style guide before suggesting changes. Prefer improving existing documents over adding new ones. For any new artifact proposal, explain the adoption path, dependency, record produced, and why the content cannot fit in an existing document. ``` ## 9. Automation scope guardrails CERG can support automation, but the core framework is an operating model first. Do not transform CERG into a tooling framework unless the human explicitly asks for that extension. Safe automation tasks: - Build adoption checklists from existing CERG documents. - Map chosen documents to owners, records, and evidence locations. - Generate draft register rows, decision log entries, and deferral rationales. - Use [Implementation Cards](governance/CERG-GOV-IMP-004_Implementation_Cards.md) as staged security-intent adoption paths. - Use [Maturity Self-Assessment](governance/CERG-GOV-MAT-001_Maturity_Self_Assessment_and_Scorecard.md) to identify next maturity moves. Do not add these to the core repo by default: - New control catalogs that replace CERG security intents. - MCP servers, APIs, or agent services. - Detection-as-code packs, Sigma rules, or SIEM queries. - ATT&CK graph databases or adversary emulation playbooks. - OSQuery, Elastic, Wazuh, or other collector configurations. Those may become optional extensions later, but they should not be part of first adoption and should not be generated without explicit maintainer approval. ## 10. Agent deliverables checklist A good first agent-assisted session should produce: - Adoption path recommendation - Initial scope statement - Role assignment draft - MVC document list - Deferred document list with rationale - First 30-day checklist - First risk register entry - First exposure backlog entry - Questions requiring leadership decision If the agent only rewrites policy text, it is not helping you adopt CERG. Adoption means owners, decisions, records, cadence, and evidence. --- --- name: Document improvement about: Suggest a change to an existing CERG document title: "[IMPROVE] " labels: improvement assignees: '' --- **Document:** `CERG-XXX-XXX-XXX` (or file path) **Current state:** What the document currently says or does (quote the relevant section if possible). **Proposed change:** What should be different and why. **Which pillar does this affect?** Engineering / Risk / Governance / Cross-cutting **Does this require a new catalog entry or domain code?** Yes / No --- **Checklist:** - [ ] I have read the relevant section of STY-001 (style guide) - [ ] I have run `python3 tools/cerg-validate.py` on my proposed changes (or will do so in the PR) - [ ] If this is a new document, I have registered the domain code in CAT-001 §2.1 --- ## Before you submit Read [CONTRIBUTING.md](../CONTRIBUTING.md) for the editing conventions, especially: - Do NOT use the `patch` tool (it collides with `---` separators) - Use the full 11-field STY-001 §4 metadata table - No em dashes in prose (STY-001 §9.2) --- --- name: New document proposal about: Propose a new CERG document (standard, procedure, template, etc.) title: "[NEW] " labels: new-document assignees: '' --- **Proposed Document ID:** `CERG-TYPE-DOMAIN-NNN` (see [CAT-001 §2.1](../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) for available domain codes; propose a new one if needed) **Document type:** POL / STD / PRC / PLN / GOV / TMPL **Owning pillar:** Engineering / Risk / Governance **Parent document:** What existing artifact does this extend or implement? **What gap does this fill?** 1-3 sentences on what's missing from the current framework and why it matters. **Draft outline:** A rough section outline is welcome but not required at the proposal stage. --- ## Before you submit - [ ] I have checked CAT-001 §5 to confirm no existing document already covers this scope - [ ] I have read [CONTRIBUTING.md](../CONTRIBUTING.md), especially the document conventions section - [ ] If a new domain code is needed, I have proposed it in the issue for discussion before registering it in CAT-001 §2.1 --- # Beginner Guide to Using CERG This guide is for people who are not GitHub users, do not write code, or just want to use CERG without learning developer workflows first. ## 1. What CERG is CERG is a cybersecurity operating model. It gives you reusable documents and workflows for running a security program: policy, standards, procedures, records, roles, and evidence. Do not approve everything on day one. Start small, assign owners, produce records from real work, and expand only when the operating loop is working. ## 2. What this repository is A GitHub repository is a shared folder with version history. In CERG, most files are Markdown documents. Markdown is plain text with simple formatting. You can use CERG in three ways: | Method | Best for | |---|---| | Download ZIP | Beginners who just want the files | | Fork repository | Teams that want their own editable copy with history | | Agent-assisted adoption | Teams using an AI assistant to guide setup | ## 3. Fastest no-code start 1. Open the GitHub repository in a browser. 2. Select **Code**. 3. Select **Download ZIP**. 4. Unzip the folder on your computer. 5. Open `START-HERE.md`. 6. If you are a small team, open `adoption-packs/cerg-lite/README.md` next. You can copy Markdown text into Word, Google Docs, Notion, Confluence, or a GRC tool. Keep the CERG document identifiers unless you intentionally create your own local numbering system. ## 4. What to read first Read only these at the beginning: 1. [START-HERE.md](START-HERE.md) 2. [CERG Lite adoption pack](adoption-packs/cerg-lite/README.md) 3. [Cybersecurity Policy](governance/CERG-POL-001_Cybersecurity_Policy.md) 4. [CERG Framework](governance/CERG-GOV-FRM-001_CERG_Framework.md) 5. [Organization Adaptation Profile](governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) 6. [Risk Register Templates](templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) Do not start with the full document catalog unless you are already comfortable navigating large frameworks. ## 5. First records to create CERG becomes real when it creates records. In the first week, aim for these: - Named security owner - Executive sponsor or business approver - Initial scope statement - First risk register entry - First exposure or vulnerability backlog entry - First exception or decision log entry, if a risk cannot be fixed immediately ## 6. Using an AI assistant safely If you are using an AI assistant, start with [ADOPT-WITH-AN-AGENT.md](ADOPT-WITH-AN-AGENT.md). Give the agent small tasks. Good examples: - "Help me choose CERG Lite, Standard, or Regulated." - "Ask me the questions needed to complete the Organization Adaptation Profile." - "Create a first 30-day checklist from the CERG Lite adoption pack." - "Summarize which documents I can defer and why." Avoid unsafe prompts: - "Make us compliant." - "Approve all documents." - "Delete sections that look complicated." - "Claim CMMC/NERC/SOX readiness without evidence." ## 7. When to fork instead of download Download ZIP if you are exploring. Fork the repository if you want to: - Track changes over time. - Review edits before approval. - Run validation checks. - Keep your local CERG program synchronized with upstream improvements. If GitHub is unfamiliar, start with ZIP, learn the shape of the program, then fork later. ## 8. What not to change first Do not begin by editing every standard. Start by tailoring: 1. Organization name and scope. 2. Owners and approvers. 3. Review cadence. 4. Risk thresholds and acceptance authority. 5. Record locations. Keep the core operating model intact until you understand the dependencies. ## 9. Getting help Open a GitHub issue or discussion if you find broken links, confusing adoption guidance, unclear document dependencies, or missing beginner examples. --- # CERG (surge) · Cybersecurity Operating Model **An operating model for teams that need security to actually run.** CERG helps security teams build capability, not just collect tools or chase compliance. It gives you the policy spine, roles, standards, procedures, templates, records, and evidence habits needed to turn scattered security work into a repeatable program. The goal is operating leverage: clearer decisions, fewer ad hoc meetings, less duplicated effort, better handoffs, and evidence created as work happens. A well-run security program should scale through clarity and repeatability, not by throwing more bodies at every new requirement. CERG is not a control framework, certification shortcut, or tooling project. Compliance alignment matters, but it is a byproduct of operating well. --- ## What CERG helps you build CERG is built around three accountable pillars: - **Cyber Engineering**: build security in early through standards, architecture review, secure development, resilience, logging, identity, cloud, SaaS, AI, and OT guardrails. - **Cyber Risk**: understand exposure, track risk decisions, manage exceptions, and drive treatment. - **Cyber Governance**: set clear rules, record decisions, define ownership, and keep evidence usable. Use CERG to: - make security ownership explicit; - turn tribal knowledge into repeatable workflows; - give engineering teams clear guardrails instead of vague security asks; - reduce toil from recurring reviews, audits, exceptions, and reporting; - create reusable evidence as work happens; - build a security function that can grow without making every problem a staffing problem. --- ## Start here | If you are... | Start with | |---|---| | New to CERG | [START-HERE.md](START-HERE.md) | | New to GitHub or Markdown | [BEGINNER-GUIDE.md](BEGINNER-GUIDE.md) | | Using an AI assistant or coding agent | [ADOPT-WITH-AN-AGENT.md](ADOPT-WITH-AN-AGENT.md) | | A small team adopting the minimum spine | [CERG Lite adoption pack](adoption-packs/cerg-lite/README.md) | | Looking for operational examples | [Day in the Life examples](examples/day-in-the-life/README.md) | | Comparing adoption paths | [Adoption Decision Tree](governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | | Contributing | [CONTRIBUTING.md](CONTRIBUTING.md) | --- ## Adoption modes You do not adopt the full library in week one. Start with the spine, prove the operating rhythm, then add depth where the organization actually needs it. - **CERG Lite**: the minimum viable program for a small or early security function. - **CERG Standard**: the core operating model for an established security team. - **CERG Regulated**: Standard plus overlays for regulated, audited, privacy, OT, or critical infrastructure scope. The minimum viable CERG spine is eight documents: Policy, Framework, Operating Model, Document Catalog, Risk Management Framework, Risk Register Procedure, Risk Register Templates, and Exposure Management Procedure. --- ## What is in the repo CERG includes: - `governance/`: policy, operating model, risk framework, RACI, metrics, maturity, workforce governance, and program structure. - `standards/`: technical standards that define what good looks like across major security domains. - `procedures/`: repeatable workflows for risk, exposure, architecture review, TPRM, audit/evidence, change, threat modeling, and related work. - `plans/`: operational packages for regulated or specialized scopes. - `templates/`: practical forms, registers, and records teams can use directly. - `roles/`: workforce architecture, job families, job descriptions, competencies, and onboarding. - `machine-readable/`: indexes, manifests, schemas, flow models, and agent-friendly metadata. - `examples/`: adoption examples and day-in-the-life walkthroughs. The authoritative inventory is the [Document Catalog](governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md). --- ## LLM and automation use Use these entry points before loading the full corpus: - [`machine-readable/cerg-llm-index.json`](machine-readable/cerg-llm-index.json): complete local corpus map. - [`machine-readable/cerg-document-tiers.yaml`](machine-readable/cerg-document-tiers.yaml): adoption tiers and recommended loading order. - [`llms.txt`](https://cerg.nexus/llms.txt): public LLM index. - [`llms-full.txt`](https://cerg.nexus/llms-full.txt): full public corpus mirror. The GitHub repository is authoritative. The website is a convenience mirror and may lag the repo. --- ## When CERG is not a good fit Do not adopt CERG yet if there is no named security owner, no executive support for guardrails and evidence, unclear scope, or no willingness to track decisions and exceptions. Start lighter, establish ownership and evidence discipline, then return when the organization is ready to operate security as a real function. CERG does not determine legal obligations or certification readiness. Validate regulatory applicability with qualified counsel, compliance leadership, and assessors. ## License [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) · Fork freely - adapt openly - attribute generously :) --- # CERG Example Profiles Sample organization profiles for different sectors and sizes. Use these as starting points for your [Organization Adaptation Profile](../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md). ## Available profiles | Profile | Sector | Size | Team | Key regulatory | |---------|--------|------|------|----------------| | [Regulated Utility](regulated-utility-profile/) | Electric utility | 14,000 employees | 60-person CERG | NERC-CIP, CMMC, SOX | ## Operational stories | Story set | Purpose | |-----------|---------| | [Day in the Life](day-in-the-life/) | Narrative walkthroughs for common three-pillar cyber operations scenarios | More profiles coming: small-team SaaS, healthcare, manufacturing/OT, financial services, MSP-heavy nonprofit/municipality. ## Using a profile 1. Read the profile's README to understand the organizational context. 2. Copy the token values to your `cerg-org-profile.yml`. 3. Adjust headcount, sector, and regulators to match your reality. 4. Run `python3 tools/cerg-render.py` to produce your organization-specific corpus. **These are examples, not defaults.** The CERG framework itself is sector-agnostic. --- # CERG Example: Day in the Life Operational Stories These examples show how CERG flows, roles, records, and evidence come together during normal operations. They are not new requirements. They are narrative walkthroughs that help a reader see how existing CERG artifacts are used in real work. **If you are a leader or SME new to CERG, read Story 2 or Story 3 first.** They show the program producing outcomes under pressure without requiring prior knowledge of every artifact. **If you are adopting CERG Lite (2-8 people), read [Story 8](story-8-cerg-lite-maria.md) first.** It is the only story written for a small team that owns everything. **If you are running CERG Standard or Regulated, any story applies directly.** Each one names the primary flow, supporting procedures and standards, the pillar that owns each step, and the records and evidence produced. --- ## How to use these stories - **Onboarding.** Use them to explain how the three pillars interact without requiring every pillar to own every task. - **Tabletop exercises.** Run the walkthrough as a scenario. Test whether your local records, evidence stores, and dashboards can support the steps. - **Implementation planning.** Use them to identify missing integrations between intake, ticketing, GRC, evidence storage, identity, vulnerability, and reporting systems. - **Adoption storytelling.** Adapt the roles, systems, and timing to your [Organization Adaptation Profile](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) without changing the underlying accountability model. These stories are illustrative, not normative. They may reference documents or stories that are planned for a future V1.x release. Where they do, the link or marker says so. **Inventory note:** Stories 1-7 and 11 are embedded below for fast scanning. Stories 8-10 are standalone files because they are longer adoption narratives. This README is the authoritative examples index for the day-in-the-life set. ## Stories at a glance | # | Story | Primary flow | Best for | |---|---|---|---| | 1 | New SaaS application | F-02 Project Intake, Architecture Review, and Threat Modeling | Intake and Architecture Review procedure walkthrough | | 2 | Critical vulnerability | F-04 Finding to Remediation, Exception, or Residual Risk | Exposure Management and SLA discipline under pressure | | 3 | Audit request | F-07 Metrics, Oversight, and Improvement Routing | Evidence quality and audit response | | 4 | Major cloud workload launch | F-02 + F-03 + F-05 | Architecture, asset registration, and release routing together | | 5 | Privileged access review finds excessive access | F-04 + F-07 | Access reviews and recurring-finding program improvement | | 6 | Third-party security incident notification | F-06 + F-04 | Vendor incidents and handoff to IR | | 7 | Enterprise AI assistant rollout | F-02 | AI standard application and controlled pilot pattern | | 8 | [CERG Lite - Maria and the Tuesday scanner report](story-8-cerg-lite-maria.md) | F-04 | Small-team MVC operations and exposure triage | | 9 | [F-01 Control Intent - when the regulator changes the rule](story-9-f-01-control-intent.md) | F-01 | Translating regulatory change into implementation work | | 10 | [The new CISO's first 90 days](story-10-new-ciso-90-days.md) | MVC + F-07 | First-quarter operating rhythm for a new security leader | | 11 | OT maintenance-window patch deferral | F-04 | OT/BES patch deferral, CIP routing, and compensating controls | --- ## Story 1: New SaaS application ### Situation A business team wants to adopt a customer success SaaS platform. The tool will process customer contact data, integrate with the identity provider, and export activity logs to the enterprise SIEM. The business wants go-live in six weeks. ### CERG flow pattern Primary flow: [F-02 Project Intake, Architecture Review, and Threat Modeling](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#10-flow-f-02--project-intake-architecture-review-and-threat-modeling) Supporting procedures and standards: - [Architecture Review and Project Intake Procedure](../../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - [Third Party and Supply Chain Risk Procedure](../../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - [Data Governance and Classification Standard](../../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) - [Access Management Standard](../../standards/CERG-STD-AC-001_Access_Management_Standard.md) - [Logging, Monitoring, and Detection Standard](../../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - [Evidence Quality Standard](../../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | The Business Owner submits a project intake for the new SaaS vendor. | Business Owner | Project Intake Record | | 2 | Governance confirms required intake fields, expected go-live date, business owner, data types, and regulatory scope. | Governance Pillar | Intake completeness check | | 3 | Engineering applies the tiering model. Because the service is internet-facing SaaS with identity integration and customer data, it is not routed as a low-risk known pattern. | Engineering Pillar | Architecture Review Record | | 4 | Risk initiates vendor risk assessment and requests security documentation, subprocessors, breach history, data residency, and contract security terms. | Risk Pillar | Vendor assessment file | | 5 | Data classification is confirmed. The project is tagged for customer data handling requirements and retention expectations. | Governance Pillar | Data classification decision | | 6 | Access requirements are defined: SSO required, MFA inherited from the IdP, role-based access, least privilege groups, named admin accounts, and periodic access review scope. | Engineering Pillar | Access design evidence | | 7 | Logging requirements are applied: administrative activity, authentication events, privilege changes, export events, and integration failures must be available for monitoring. | Engineering Pillar | Logging requirement checklist | | 8 | Open risks are dispositioned. A missing vendor feature becomes either a remediation before go-live, a time-bound exception, or a risk acceptance package. | Risk Pillar | Risk Record or Exception Record | | 9 | Evidence is stored with the intake package: review notes, vendor questionnaire, contract clauses, data classification, access design, logging validation, and final disposition. | Evidence Librarian | Evidence index entries | | 10 | Metrics update after closure: intake cycle time, reviews by tier, vendor risk completion, exceptions opened, and pre-go-live issues remediated. | Governance Pillar | Reporting Metric Record | ### Example day-in-the-life narrative On Monday morning, the business sponsor opens the intake record and identifies the system owner, target go-live date, expected users, data elements, and vendor contact. Governance reviews the intake the same day and sends one clarification: the initial request says "customer data" but does not identify whether regulated data is included. By Wednesday, Engineering completes the architecture review. The design uses SSO, two privileged admin groups, SCIM provisioning, and a vendor-hosted API. Engineering confirms that the application cannot go live unless admin activity and user authentication logs are exportable. Risk starts the third-party assessment in parallel instead of waiting for architecture review closure. The vendor returns a SOC report, penetration test summary, subprocessors list, and data processing addendum. Risk identifies one gap: customer data exports are logged in the vendor console but are not available through the standard log API. The Business Owner agrees that exports will be limited to two approved roles until the vendor API feature is available. At the go-live decision meeting, Engineering confirms SSO, access groups, and log ingestion for authentication and admin events. Risk documents the export-log limitation as a time-bound exception with compensating controls. Governance verifies that evidence is indexed and that the exception expiration date is on the calendar. ### Operational outputs - Project Intake Record closed with security disposition. - Architecture Review Record approved with conditions. - Vendor assessment completed and linked. - Data classification decision recorded. - Access model and logging evidence stored. - Exception Record created if a requirement is deferred. - Metrics updated for intake throughput, cycle time, and exception volume. --- ## Story 2: Critical vulnerability ### Situation A vulnerability scanner reports a critical remote-code-execution exposure on an internet-facing application server. Threat intelligence indicates public exploit code is available. The affected application supports a customer portal. ### CERG flow pattern Primary flow: [F-04 Finding to Remediation, Exception, or Residual Risk](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) Supporting procedures and standards: - [Exposure Management Procedure](../../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - [Security Change Management Procedure](../../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) - [Lessons Learned and Program Improvement Procedure](../../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) - [Metrics Dashboard and Reporting](../../governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Scanner creates a critical finding for an internet-facing server. | Risk Pillar | Finding Record | | 2 | Risk validates reachability, asset ownership, exploitability, compensating controls, and whether active exploitation indicators exist. | Risk Pillar | Triage notes and severity decision | | 3 | Engineering owns remediation planning and coordinates patching, configuration change, WAF rule, or service isolation. | Engineering Pillar | Change Record | | 4 | Governance checks the applicable SLA, evidence expectations, and whether required records are complete. | Governance Pillar | SLA and evidence review | | 5 | If remediation will miss SLA, the Technical Owner submits an exception request with rationale, compensating controls, and expiration date. | Technical Owner | Exception Record | | 6 | If residual risk is material, the Business Owner and CISO review the risk package and approve, reject, or require further treatment. | Business Owner and CISO | Risk acceptance memo | | 7 | Metrics update for critical findings, SLA performance, exceptions, reopen rate, and time to validate remediation. | Governance Pillar | Reporting Metric Record | | 8 | Lessons learned determine whether standards, baselines, scanning coverage, or patch windows need updates. | Risk Pillar | Improvement Record | ### Example day-in-the-life narrative At 8:15 a.m., the scanner imports a critical finding and automatically maps it to the customer portal asset record. Risk confirms the server is internet-facing and that exploit code is available. Because public exploitation is plausible, the finding remains Critical and receives the critical SLA. By 9:00 a.m., Engineering owns the remediation bridge. The application team reports that the vendor patch requires a minor version upgrade and a brief outage. The Business Owner approves an emergency maintenance window at noon. Engineering also applies a temporary WAF rule while preparing the patch. Governance does not run the patch. Governance confirms the SLA clock, expected evidence, and required linkage between the Finding Record and Change Record. Risk monitors for indicators of compromise and confirms that no incident declaration is required based on current evidence. At 12:30 p.m., Engineering completes the emergency change and uploads patch output, service validation, and rollback-not-used confirmation. Risk rescans the asset and validates closure. Governance records that the critical SLA was met and the dashboard updates that evening. During lessons learned, the team discovers that this application missed a monthly dependency owner review. The action is not just "patch faster." The program improvement is to update the secure configuration baseline and require explicit owner validation for internet-facing dependencies. ### Operational outputs - Finding Record created, triaged, and closed or promoted. - Change Record linked to remediation evidence. - Exception or Risk Record created only if remediation misses SLA or residual risk remains. - CISO or Business Owner acceptance captured when required. - Metrics updated for critical vulnerability operations. - Improvement Record created when the issue reveals a systemic control gap. --- ## Story 3: Audit request ### Situation An external auditor requests evidence that privileged access reviews were performed for a SOX-relevant financial application during the prior quarter. The auditor asks for the review population, reviewer sign-off, exceptions, and evidence that removals were completed. ### CERG flow pattern Primary flow: [F-07 Metrics, Oversight, and Improvement Routing](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#15-flow-f-07--metrics-oversight-and-improvement-routing) Supporting procedures and standards: - [Audit and Evidence Management Procedure](../../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) - [Evidence Quality Standard](../../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) - [Access Management Runbook](../../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) - [Access Management Standard](../../standards/CERG-STD-AC-001_Access_Management_Standard.md) - [Compliance Matrix](../../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) - [Program Improvement Register](../../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Auditor requests privileged access review evidence for a defined system and period. | Auditor or Governance Pillar | Audit request ticket | | 2 | Governance pulls the evidence index and maps the request to control, system, period, and required evidence quality tier. | Governance Pillar | Evidence index extract | | 3 | Engineering supplies the IdP export, application role export, reviewer attestation, and removal tickets. | Engineering Pillar | IdP and application evidence | | 4 | Risk explains open exceptions, overdue removals, or residual access risks that existed during the period. | Risk Pillar | Exception or Risk Record summary | | 5 | Governance applies evidence quality rules and checks completeness, timestamp integrity, reviewer authority, population accuracy, and chain of custody. | Governance Pillar | Evidence quality assessment | | 6 | If evidence gaps or control failures are found, they become program work rather than ad hoc audit responses. | Governance Pillar | Finding Record or Improvement Record | ### Example day-in-the-life narrative The auditor sends the request on Tuesday afternoon. Governance translates the request into the control language used internally: quarterly privileged access review for the SOX-relevant finance application. The Evidence Librarian locates the prior quarter evidence package and sees that the reviewer attestation is present but the IdP export file name does not include the extraction timestamp. Engineering regenerates a current export for comparison and supplies the original system-generated export from the access review tool. The application owner confirms that the review population included all privileged groups and all break-glass accounts. Two removals were requested during the review period, and Engineering links the completed removal tickets. Risk adds context for one exception. A privileged service account could not be removed because a replacement integration was still being tested. The exception had compensating monitoring, a named owner, and an expiration date. Governance includes that explanation in the audit response package instead of letting the auditor infer that the exception was unmanaged. Governance applies the evidence quality tier and identifies one improvement: export naming was inconsistent across applications. The audit response is completed, but the work does not stop there. Governance creates a program improvement item to standardize evidence naming and extraction metadata for all access reviews. ### Evidence request package example | Request Element | CERG Handling | Evidence Included | |---|---|---| | Control and period | Governance maps the auditor's wording to the access review control and the prior-quarter review window. | Control mapping, request ticket, period definition | | Population completeness | Engineering proves which accounts and privileged groups were in scope at extraction time. | IdP export, application role export, break-glass account list | | Reviewer authority | Governance confirms the reviewer was the named system owner or delegated approver. | Reviewer attestation, delegation record if applicable | | Exceptions and removals | Risk explains open exceptions; Engineering proves completed removals. | Exception summary, removal tickets, closure timestamps | | Evidence quality | Governance checks source, timestamp, immutability, chain of custody, and naming discipline. | Evidence quality checklist, evidence index links | | Response package | Governance sends the package with an answer narrative instead of loose screenshots. | Final response memo, linked evidence bundle, improvement item if needed | The auditor receives a coherent evidence package, not a zip file of screenshots. The Business Owner sees whether the control actually ran. CERG gets a reusable improvement when evidence quality is weaker than the control itself. ### Operational outputs - Audit request mapped to control, system, period, and evidence requirements. - Evidence package assembled from the evidence index. - IdP, application, attestation, and removal evidence linked. - Exceptions and risks explained with current status. - Evidence quality tier applied. - Findings or improvements created for evidence gaps. --- ## Story 4: Major cloud workload launch ### Situation A product team is moving a customer-facing API from a data center to a cloud platform. The workload will use managed compute, managed database, object storage, secrets management, and centralized logging. The launch is tied to a business commitment, so the team needs clear security gates without creating avoidable delay. ### CERG flow pattern Primary flows: [F-02 Project Intake, Architecture Review, and Threat Modeling](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#10-flow-f-02--project-intake-architecture-review-and-threat-modeling), [F-03 Asset Registration and Coverage Validation](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#11-flow-f-03--asset-registration-and-coverage-validation), and [F-05 Change and Release Security Routing](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#13-flow-f-05--change-and-release-security-routing) Supporting procedures and standards: - [Architecture Review and Project Intake Procedure](../../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - [Threat Modeling Procedure](../../procedures/CERG-PRC-TM-001_Threat_Modeling_Procedure.md) - [Asset Management and Inventory Standard](../../standards/CERG-STD-AM-001_Asset_Management_and_Inventory_Standard.md) - [IT, Cloud, and SaaS Security Standard](../../standards/CERG-STD-IT-001_IT_Cloud_SaaS_Security_Standard.md) - [Logging, Monitoring, and Detection Standard](../../standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md) - [Security Change Management Procedure](../../procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Business submits the launch request with go-live date, customer impact, data types, and service owner. | Business Owner | Project Intake Record | | 2 | Engineering reviews the reference architecture, network paths, identity model, encryption, secrets, and deployment pipeline. | Engineering Pillar | Architecture Review Record | | 3 | Risk facilitates threat modeling because the workload is internet-facing and handles customer data. | Risk Pillar | Threat Model Record | | 4 | Governance confirms the applicable cloud, logging, evidence, and change requirements before release approval. | Governance Pillar | Control conformance checklist | | 5 | Engineering registers cloud assets, owners, criticality, data classification, monitoring coverage, and backup expectations. | Engineering Pillar | Asset Records | | 6 | Risk validates residual launch risks, such as incomplete rate limiting or delayed DDoS testing, and determines whether an exception is needed. | Risk Pillar | Risk Record or Exception Record | | 7 | Governance verifies release evidence and updates metrics for architecture reviews, threat models, asset coverage, and launch exceptions. | Governance Pillar | Reporting Metric Record | ### Example day-in-the-life narrative The project arrives with a firm go-live date, so Engineering immediately routes it as a regulated internet-facing workload rather than a routine infrastructure change. The first architecture review identifies two issues: object storage needs explicit public-access blocking, and secrets must move from pipeline variables to the managed secrets service. Risk runs a short threat model with the product team. The highest-priority scenario is credential theft leading to API abuse and data export. Engineering adds rate limiting, privileged workflow logging, and alerting for abnormal export volume. Governance confirms that the evidence package must include asset registration, logging validation, threat model decisions, and the final change approval. Two days before launch, Engineering proves that logs are flowing to the SIEM and that cloud assets have owners and classifications. Risk validates and recommends the disposition for one low residual risk around delayed DDoS exercise completion with a 30-day due date; the Business Owner accepts the consequence under the RMF authority path. Governance confirms the exception is time-bound and visible in reporting. The release proceeds with clear ownership rather than informal verbal approval. ### Operational outputs - Intake, architecture review, threat model, asset, and change records linked. - Cloud assets registered with ownership, classification, and monitoring status. - Logging and alerting evidence captured before go-live. - Residual launch risks recorded with owners and due dates. - Metrics updated for review cycle time, asset coverage, and exceptions. --- ## Story 5: Privileged access review finds excessive access ### Situation A quarterly privileged access review finds that several users retained administrator access after changing roles. One account belongs to a contractor whose engagement ended two weeks earlier. The application supports a sensitive business process. ### CERG flow pattern Primary flows: [F-04 Finding to Remediation, Exception, or Residual Risk](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) and [F-07 Metrics, Oversight, and Improvement Routing](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#15-flow-f-07--metrics-oversight-and-improvement-routing) Supporting procedures and standards: - [Access Management Runbook](../../procedures/CERG-PRC-AC-002_Access_Management_Runbook.md) - [Access Management Standard](../../standards/CERG-STD-AC-001_Access_Management_Standard.md) - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - [Audit and Evidence Management Procedure](../../procedures/CERG-PRC-AUD-001_Audit_and_Evidence_Management_Procedure.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Governance identifies excessive privileged access during the scheduled review. | Governance Pillar | Access review evidence | | 2 | Engineering removes access, disables stale accounts, and validates group membership after remediation. | Engineering Pillar | Access removal tickets | | 3 | Risk evaluates whether the access created material exposure, whether activity review is needed, and whether the issue is systemic. | Risk Pillar | Finding Record | | 4 | Governance checks evidence quality, reviewer sign-off, removal timestamps, and whether review SLA was met. | Governance Pillar | Evidence quality assessment | | 5 | If access cannot be removed immediately, the owner requests a time-bound exception with monitoring or compensating controls. | Asset Owner | Exception Record | | 6 | Metrics update for review completion, excessive access rate, removal cycle time, contractor access defects, and recurring findings. | Governance Pillar | Reporting Metric Record | | 7 | Lessons learned feed standards, joiner-mover-leaver controls, contractor offboarding, or role engineering work. | Risk Pillar | Improvement Record | ### Example day-in-the-life narrative Governance starts the quarterly review by pulling the privileged group membership and sending it to the approved application owner. The owner flags five users who no longer need administrator access. Engineering removes four immediately but discovers that the contractor account is still active in the IdP. Risk opens a finding because the contractor access represents exposure after engagement end. Risk asks Engineering to review recent privileged activity and confirms that no suspicious activity is visible. Governance verifies that the reviewer decision, removal ticket, timestamped export, and validation export are all stored in the evidence package. The team does not treat this as a one-off cleanup. Risk notices the same mover issue appeared in another application last quarter. Governance creates an improvement item to strengthen role-change triggers and contractor offboarding evidence. Engineering agrees to add automated group-owner notification when a privileged user changes department or employment type. ### Operational outputs - Access review evidence completed and quality-checked. - Excess access removed and independently validated. - Finding opened for stale privileged access exposure. - Exception created only where immediate removal is not possible. - Metrics and program improvement items updated. --- ## Story 6: Third-party security incident notification ### Situation A vendor notifies the organization that its file transfer platform was compromised. The organization uses the vendor to exchange operational reports with customers. The vendor cannot yet confirm whether customer files were accessed. ### CERG flow pattern Primary flows: [F-06 Incident to Recovery to Standards Feedback](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#14-flow-f-06--incident-to-recovery-to-standards-feedback) and [F-04 Finding to Remediation, Exception, or Residual Risk](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) Supporting procedures and standards: - [Incident Response Plan](../../plans/CERG-PLN-IR-001_Incident_Response_Plan.md) - [Incident Response Playbook Set](../../procedures/CERG-PRC-IR-002_Incident_Response_Playbook_Set.md) - [Third Party and Supply Chain Risk Procedure](../../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - [Lessons Learned and Program Improvement Procedure](../../procedures/CERG-PRC-LL-001_Lessons_Learned_and_Program_Improvement_Procedure.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Vendor notification is received and triaged for affected services, data, dates, and contract obligations. | Risk Pillar / Vendor Risk Analyst | Third-party incident triage record | | 2 | The Incident Commander determines whether to declare an internal incident, assigns severity if needed, and sets the next decision time. | Incident Commander / Standing IR Team | IR-owned Incident Record or documented no-declaration rationale | | 3 | Engineering identifies integrations, disables risky transfer paths if approved by the IC, rotates credentials, and preserves logs. | Engineering Pillar | Containment and log evidence | | 4 | Governance supplies evidence requirements, regulatory mapping support, and decision-log indexing to the IC / Legal process. | Governance Pillar | CERG evidence index and support log | | 5 | Risk coordinates vendor questions, exposure analysis, and residual third-party risk. | Risk Pillar | Vendor Risk Record or Risk Record | | 6 | Engineering implements technical recovery actions, such as credential rotation, endpoint validation, and alternate transfer process. | Engineering Pillar | Change or recovery records | | 7 | Governance tracks CERG support actions, customer or regulator evidence needs, and metrics for third-party incident response. | Governance Pillar | Reporting Metric Record | | 8 | Lessons learned update vendor requirements, contract clauses, monitoring expectations, or exit criteria. | Risk Pillar | Improvement Record | ### Example day-in-the-life narrative The vendor notice arrives at 4:30 p.m. Risk opens the triage record and asks three questions immediately: what data types were exchanged, what dates are in scope, and what indicators or logs are available. Because customer operational reports may be involved, Risk notifies the Incident Commander. The IC does not delegate the incident decision to CERG; the IC determines whether this is an internal incident, names the next decision time, and tells CERG what support is needed. Engineering identifies the integration owner, pauses scheduled transfers after IC approval, rotates API credentials, and preserves local transfer logs. Governance opens the CERG evidence/support log, maps possible notification obligations for Legal and the IC, and records who will approve customer communications if data exposure is confirmed. The CISO receives a short status summary with known facts, unknowns, next decision time, and current containment actions. Risk pushes the vendor for file-level access evidence and maps the scenario to the vendor risk record. The next morning, the vendor confirms that no organization files were accessed, and the IC documents that no internal incident declaration is required. The vendor still cannot meet the evidence quality the organization normally requires. Risk records residual third-party risk. Governance requires the evidence limitation to be visible in the file, not hidden in email. Engineering implements an alternate encrypted transfer path for the most sensitive reports until the vendor completes remediation. ### Operational outputs - Third-party incident triage and IC declaration/no-declaration rationale recorded. - Integrations, credentials, and logs preserved or remediated. - Vendor risk record updated with incident facts and residual risk. - Governance evidence package prepared for executive, customer, regulator, or audit use under IC / Legal direction. - Vendor standards and contract requirements updated if gaps are found. --- ## Story 7: Enterprise AI assistant rollout ### Situation A business function wants to deploy an enterprise AI assistant for summarizing documents, drafting communications, and searching internal knowledge. The tool may process confidential information and has browser, email, or document repository integrations. ### CERG flow pattern Primary flow: [F-02 Project Intake, Architecture Review, and Threat Modeling](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#10-flow-f-02--project-intake-architecture-review-and-threat-modeling) Supporting procedures and standards: - [Artificial Intelligence Security Standard](../../standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md) - [Architecture Review and Project Intake Procedure](../../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - [Data Governance and Classification Standard](../../standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md) - [Access Management Standard](../../standards/CERG-STD-AC-001_Access_Management_Standard.md) - [Third Party and Supply Chain Risk Procedure](../../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Business submits the AI use case, user population, data sources, integrations, and desired productivity outcomes. | Business Owner | Project Intake Record | | 2 | Governance confirms whether the use case is allowed, restricted, or prohibited under the AI standard and data classification rules. | Governance Pillar | AI use-case disposition | | 3 | Engineering reviews identity integration, permissions inheritance, connector scope, logging, retention, and administrative controls. | Engineering Pillar | Architecture Review Record | | 4 | Risk assesses vendor controls, model/data handling, prompt and output risks, sensitive data exposure, and abuse scenarios. | Risk Pillar | Vendor assessment and Threat Model Record | | 5 | Governance defines required user guidance, evidence, monitoring metrics, and approval conditions for pilot or production rollout. | Governance Pillar | Control conformance checklist | | 6 | Engineering implements scoped pilot access, connector restrictions, logging, and administrative guardrails. | Engineering Pillar | Implementation evidence | | 7 | Risk reviews pilot outcomes and open risks before expansion. | Risk Pillar | Risk Record or approval notes | | 8 | Metrics update for AI use cases reviewed, approved, restricted, exceptions, incidents, and user population. | Governance Pillar | Reporting Metric Record | ### Example day-in-the-life narrative The business request starts as a simple productivity ask, but the intake reveals that the assistant will index internal documents and email content. Governance checks the AI standard and determines that the use case is allowed only as a controlled pilot because confidential information may be processed. Engineering reviews the connector model and finds that the assistant inherits user permissions from the document repository. That reduces some risk, but Engineering still restricts the pilot to one business unit, disables unapproved external plugins, and enables admin audit logs. Risk reviews the vendor's data handling terms and threat models accidental oversharing, prompt injection through documents, and unauthorized connector expansion. The pilot launches with user guidance, logging, and a named Business Owner. After 30 days, Risk reports no material incidents but identifies repeated attempts to use the assistant with restricted data. Governance updates the user guidance and requires a data-handling reminder before expansion. Engineering keeps connector approvals centralized until the control is proven stable. ### Operational outputs - AI use case intake and disposition recorded. - Architecture, vendor, data, and access reviews completed. - Pilot restrictions and administrative controls evidenced. - Risk review completed before broad rollout. - Metrics updated for AI governance and adoption oversight. --- ## Story 11: OT maintenance-window patch deferral ### Situation A monthly exposure review finds a High vulnerability on an OT historian that supports a substation operations view. The vendor patch is available, but the OT owner says the patch cannot be applied until the next approved maintenance window without risking operational disruption. The asset is adjacent to BES monitoring data but is not itself a BES Cyber System. ### CERG flow pattern Primary flow: [F-04 Finding to Remediation, Exception, or Residual Risk](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) Supporting procedures and standards: - [Exposure Management Procedure](../../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) §7.4 - [Grid Control Systems Security Standard](../../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) §11 - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - [Risk Acceptance Request Form](../../templates/CERG-TMPL-RM-004_Risk_Acceptance_Request_Form.md) - [Record Catalog](../../governance/CERG-GOV-CAT-002_Record_Catalog.md) ### Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Risk validates the scanner finding with OT-safe context: affected version, exploitability, network reachability, and whether the asset is BES Cyber System scope. | Risk Pillar / OT Risk Analyst | Finding Record | | 2 | Engineering and OT operations confirm that immediate patching would disrupt the operational window and identify non-patch treatments. | Engineering Pillar / OT Security Engineer | Treatment analysis | | 3 | Governance confirms the route: non-BES OT operational-window deferral, not a CIP deviation. | Governance Pillar / NERC-CIP Compliance Manager if needed | Routing note | | 4 | Engineering implements compensating controls: restrict management access, block the vulnerable service path, confirm monitoring, and document rollback. | Engineering Pillar | Compensating-control evidence | | 5 | Risk keeps the finding open, records the next maintenance window as the treatment date, and monitors for threat-intelligence changes. | Risk Pillar | Exposure pipeline update | | 6 | If the asset is later determined to be BES Cyber System scope or the deferral would create a CIP compliance gap, Governance reroutes to the BES/CIP deviation path. | Governance Pillar | CIP applicability / deviation record | | 7 | After the maintenance window, Engineering applies the patch, verifies service health, and supplies closure evidence. | Engineering Pillar | Closure evidence | ### Example day-in-the-life narrative The scanner report arrives Monday morning, but the finding does not become a generic 30-day patch ticket. Risk checks reachability and confirms that the vulnerable service is only reachable from the OT management subnet. Engineering confirms that the affected historian feeds an operator dashboard and that an immediate reboot would interrupt a scheduled reliability test. The OT Security Engineer proposes three non-patch treatments for the deferral window: block the vulnerable service from non-management subnets, require jump-host access for administration, and add a detection for unexpected connection attempts. Governance checks the asset classification and confirms this is a non-BES OT operational-window deferral. Because CIP compliance is not affected, the team does not open a CIP deviation; it documents the CIP applicability note and stores the evidence with the Finding Record. The Business Owner accepts the short operational deferral only after seeing the compensating controls, the maintenance-window date, and the consequence if exploitation occurs. Risk does not close the finding. The exposure remains open with a deferral route, a named owner, and a review date. Two weeks later, threat intelligence reports active exploitation of the same product in the sector. Risk reopens the decision, Engineering adds a temporary allow-list rule, and the Business Owner confirms the maintenance window will not slip. During the maintenance window, Engineering patches the historian, validates service health with OT operations, and captures version evidence. Governance verifies that the record names match the Record Catalog and that the closure evidence is audit-ready. The finding closes only after the patch and verification are complete. ### Operational outputs - Finding Record with OT/BES scope determination. - Non-patch treatment analysis and compensating-control evidence. - Maintenance-window deferral route documented under PRC-VM §7.4. - CIP applicability note or CIP deviation record when applicable. - Business Owner consequence decision if residual risk remains during the deferral. - Verified closure evidence after patching. --- --- # CERG Example: Regulated Utility Profile This is a **sample organization profile** for a regulated electrical utility adopting CERG. It is provided as a reference example, not the default. If your organization matches this profile, use it as a starting point for your [Organization Adaptation Profile](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md). --- ## Organization context | Field | Value | |-------|-------| | **Sector** | Electric utility (generation, transmission, distribution) | | **Employees** | ~14,000 | | **Contractors** | ~14,000 (roughly equal population) | | **Protected population** | ~28,000 identities, devices, access relationships | | **CERG team size** | 60 (14 Engineering, 15 Risk, 13 Governance, plus CISO, pillar leaders, management) | | **Regulators** | NERC-CIP (dozens of registered entities, hundreds of BES Cyber Systems), CMMC L2, SOX ITGC, state regulatory | | **Environments** | Enterprise IT, OT/ICS (SCADA, substations, EMS), cloud (IaaS/PaaS/SaaS), owned data centers | | **Scale tier** | Large | ## VAR-001 token values | Token | Value | |-------|-------| | `{{ORG_NAME}}` | `[Your Utility Name]` | | `{{ORG_SECTOR}}` | `electric utility` | | `{{TOTAL_EMPLOYEES}}` | `14,000` | | `{{PROTECTED_POPULATION}}` | `28,000` | | `{{CERG_TEAM_SIZE}}` | `60` | | `{{ENG_STAFF}}` | `14` | | `{{RISK_STAFF}}` | `15` | | `{{GOV_STAFF}}` | `13` | | `{{SCALE_TIER}}` | `large` | | `{{REGULATORS}}` | `NERC-CIP, CMMC L2, SOX ITGC` | | `{{PRIMARY_REGULATOR}}` | `NERC-CIP` | ## Operational context 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 IT infrastructure, enterprise applications, OT modernization, cloud migrations, and third-party integrations. Engineers are aligned to specific business verticals (generation, transmission, distribution, enterprise IT, corporate functions) and develop fluency in the systems they support — a generation-aligned engineer who doesn't understand how a historian feeds an EMS is less effective. **Risk** operates at equivalent velocity. The vendor risk program covers more than 2,500 active vendors. Exposure management covers more than 100,000 assets across enterprise IT, OT networks, substations, and cloud environments, with OT-safe scanning disciplines. Penetration testing and red team operations run on continuous cycles across IT and OT targets. Threat intelligence is a production function with ICS/OT-specific coverage given bulk electric system exposure. **Governance** operates as a domain-expert function, not a generalist compliance team. The compliance portfolio spans NERC-CIP (across dozens of registered entities and hundreds of categorized BES Cyber Systems), CMMC, SOX ITGC, and state regulatory requirements. Policy and standards are actively maintained, version-controlled, and tied to regulatory citation. ## Key operational packages - [NERC-CIP Operational Package](../../plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) - [CUI / CMMC Operational Package](../../plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - [SOX ITGC Operational Package](../../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) - [Grid Control Systems Security Standard](../../standards/CERG-STD-OT-001_Grid_Control_Systems_Security_Standard.md) - [Business Continuity & DR Plan](../../plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md) ## See also - [CERG Framework §9](../../governance/CERG-GOV-FRM-001_CERG_Framework.md) — Team Structure and Talent Model - [Organization Adaptation Profile](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) — Token scheme and render tool - [Small Team Adoption Path](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) — Contrast with small-scale adoption --- # CERG Lite Adoption Pack CERG Lite is the minimum viable adoption path for a small or early security function. It is designed for teams that need a real operating loop without adopting the full CERG library at once. ## 1. Who should use this pack Use CERG Lite if: - The security team has roughly 2 to 8 active participants. - Security ownership exists, even if part time. - Leadership supports documented guardrails, risk decisions, and evidence. - The organization can name its core systems, owners, and regulatory concerns. If there is only one security person, use CERG as a planning reference until there is an executive sponsor and an independent approver for High or Critical risk decisions. ## 2. What to adopt first Adopt only the MVC spine first: 1. [Cybersecurity Policy](../../governance/CERG-POL-001_Cybersecurity_Policy.md) 2. [CERG Framework](../../governance/CERG-GOV-FRM-001_CERG_Framework.md) 3. [Operating Model](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) 4. [Document Catalog](../../governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md) 5. [Risk Management Framework](../../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) 6. [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) 7. [Risk Register Templates](../../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md) 8. [Exposure Management Procedure](../../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) Use the [Organization Adaptation Profile](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md), [Small Team Adoption Path](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md), and [Role-Based Implementation Checklists](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) as aids, not extra first-week obligations. ## 3. First 48 hours 1. Confirm executive sponsor and security owner. 2. Select CERG Lite and document why. 3. Fill the Organization Adaptation Profile at a draft level. 4. Assign consolidated roles for Engineering, Risk, and Governance accountabilities. 5. Create the first risk register entry. 6. Create the first exposure backlog item. 7. Decide where records will live. 8. Schedule the first monthly risk and exposure review. ## 4. First 30 days | Week | Outcome | |---|---| | Week 1 | Scope, owners, record locations, first risk, first exposure item | | Week 2 | Risk register cadence, exception path, initial asset/source inventory | | Week 3 | First exposure management cycle and remediation ownership | | Week 4 | First evidence review, deferral list, and next adoption decision | ## 5. Safe deferrals These are normally safe to defer during the first 30 days: - Most standards, unless an immediate environment or regulator requires them. - Detailed job descriptions. - Workforce planning, succession, and performance frameworks. - Regulated operational packages unless CMMC, NERC-CIP, SOX, ISO, privacy, OT, or CUI scope applies. - Advanced machine-readable schemas. Do not defer the risk register, exception process, owner assignment, or exposure management loop. ## 6. Files in this pack - `README.md`: human adoption guide. - `document-list.yaml`: structured MVC and helper document list. - `agent-prompt.md`: copy/paste prompt for agent-assisted adoption. ## 7. Success test CERG Lite is working when the team can show: - Named owners for the three pillars, even if consolidated. - A current risk register. - A current exposure backlog. - A documented exception or risk acceptance path. - Evidence that at least one exposure cycle was run. - A deferral list explaining what is not yet adopted and why. --- # CERG Lite Agent Prompt Copy this prompt into an AI assistant when starting a small-team CERG adoption. ```text You are helping me adopt CERG Lite. Use the CERG repository as the source of truth. Start with README.md, START-HERE.md, adoption-packs/cerg-lite/README.md, adoption-packs/cerg-lite/document-list.yaml, and machine-readable/cerg-document-tiers.yaml. Rules: 1. Ask one question at a time. 2. Do not rewrite the full library. 3. Do not approve documents for my organization without explicit confirmation. 4. Do not claim regulatory compliance or certification readiness. 5. Track assumptions separately from confirmed facts. 6. Preserve CERG document IDs unless I explicitly choose a local numbering model. 7. Prefer safe deferral and role consolidation over deleting content. 8. Focus first on owners, records, cadence, and evidence. First, determine whether CERG Lite is appropriate. Then help me produce: - adoption path recommendation - initial scope statement - role assignment draft - MVC document list - deferred document list with rationale - first 30-day checklist - first risk register entry - first exposure backlog entry - open leadership decisions ``` ## Follow-up prompt for first records ```text Now create draft first records for CERG Lite: role assignment, scope statement, evidence index, first risk register entry, first exposure backlog item, and decision log entry. Keep each record short and mark unknown values as preliminary defaults requiring organizational calibration. ``` --- # CERG Role Descriptions This directory contains per-role job description documents extracted from the monolithic JD-001 file. Each role description follows the Enhanced Role Description Template (§7.2 of the NICE alignment specification). ## Directory Structure ``` roles/ ├── CERG-GOV-JF-001_Job_Families_Overview.md # Job Family structure, levels, progression gates ├── CERG-GOV-JF-002_NICE_Workforce_Framework_Crosswalk.md # NICE-to-CERG role mapping ├── jf-seceng/ Security Engineering (8 roles) ├── jf-riskops/ Risk Operations (8 roles) ├── jf-govcomp/ Governance & Compliance (7 roles) ├── jf-exec/ Executive Leadership (2 roles) └── jf-adjunct/ Incident Response (2 roles) ``` ## Document Format Each per-role document follows this structure: 1. Role Summary 2. NICE Workforce Framework Mapping 3. Job Family & Level Placement 4. Key Responsibilities (Core + Grade-Level Differentiation) 5. Required Knowledge, Skills, and Abilities (KSAs) 6. NICE TKS Statement References 7. Typical Qualifications 8. Key Performance Indicators (KPIs) — from MTR-001 9. Competency Expectations by Grade — from CMP-001 10. Success Profile 11. Career Path 12. Related CERG Documents 13. Document Control ## Related Documents - **OM-001** — Canonical role roster (authoritative source of role names) - **RAC-001** — Role descriptions and master RACI assignments - **JA-001** — Grade framework and role-to-grade mapping - **CMP-001** — Competency model and behavioral anchors - **TRN-001** — Certification matrix - **PERF-001** — Performance management framework ## Status All 32 per-role and role-family job description files are Approved. NICE TKS references, KPI alignment, and competency anchors are populated from the NICE Framework dataset, MTR-001 canonical metrics, and CMP-001 behavioral anchors. --- # CERG — Guide for AI Agents This file is loaded automatically by AI agents (Claude Code, Copilot, Codex CLI, Cursor, etc.) to understand the CERG cybersecurity operating model repository and work effectively with it. --- ## Project Overview CERG is an open‑source cybersecurity operating model — not a control framework or compliance checklist. It gives security teams the policies, standards, procedures, workforce architecture, and evidence model to run a real program. Three pillars: Engineering, Risk, and Governance. ## Directory Layout ``` governance/ Policies, governance instruments, competency models, risk framework standards/ Technical security standards (15 docs) procedures/ Operational procedures (12 docs) plans/ Regulatory operational packages (7 docs) templates/ Fill‑in artifacts for routine work roles/ Workforce architecture: JF-001.md Job Families Overview JF-002.md NICE Workforce Framework Crosswalk jf-exec/ Executive leadership JDs jf-seceng/ Security engineering JDs jf-riskops/ Risk operations JDs jf-govcomp/ Governance & compliance JDs jf-adjunct/ Adjunct function JDs machine-readable/ YAML + JSON artifacts derived from markdown source tools/ Validation and population scripts examples/ Adoption profiles ``` ## Document Anatomy Every CERG document follows STY‑001 conventions: ### Metadata Table (top of file) 11‑field table in STY‑001 §4 format: ``` | | | |---|---| | **Identifier field** | document identifier value | | **Version** | X.X | | **Status** | Approved | | **Classification** | Public / Internal / Confidential | | **Owner** | Role Name | | **Parent Policy** | CERG-POL-001 | | **Review Cycle** | Quarterly / Annual | | **Frameworks** | NIST CSF 2.0 · NIST 800‑53r5 · … | | **Regulations** | NERC‑CIP · CMMC L2 · SOX ITGC · … | | **Environments** | All in‑scope environments | ``` ### Section Numbering - Top‑level: `## N. Section Title` - Subsection: `### N.M Subsection Title` - Must be sequential — no gaps. Section renumbering works from HIGHEST number to LOWEST to prevent cascading replacements. ### Links - Resolved relative to source file's directory - Same‑dir: `FILENAME.md` - Parent dir: `../governance/FILENAME.md` - Grandparent: `../../governance/FILENAME.md` - `roles/` → `governance/`: `../governance/FILENAME.md` - `roles/jf-seceng/` → `governance/`: `../../governance/FILENAME.md` ### Cross‑References Format: link the CERG document ID to the source Markdown file, not just the ID. ### Document Control Section (last section before appendices) Contains Revision History (a table), Review Triggers, Related Documents. ## Machine‑Readable Index `machine-readable/cerg-llm-index.json` contains: - Per‑document metadata (id, title, type, pillar, status, version, owner, repo-relative path, virtual local-corpus line range, token estimate, summary) - Prefix registry (POL, STD, PRC, GOV, PLN, TMPL, JF, JD meanings) - Pillar breakdowns - Document counts **Load this first** — it gives you the complete local corpus map. If context is tight, load only the top-level counts and the `documents[].id/path/summary` fields you need. ## Validation ### CI Gate (must pass before committing) ```bash python3 tools/cerg-validate.py ``` This is the authoritative CI check — requires 0 errors. Common error classes: - `FILE_NOT_IN_CATALOG` — document not registered in CAT‑001 §5 - `ID_NOT_IN_CATALOG` — cross‑reference to an unregistered ID - `STATUS_MISMATCH` — file status ≠ catalog status - `LINK_MISSING` — markdown link target doesn't exist on disk - `DRAFT_VERSION` — status says Approved but version contains "Draft" - `RESTRICTED_CLASSIFICATION` — Public doc references Internal/Confidential doc ### Integrity Checker (supplementary) ```bash python3 tools/cerg-integrity-check.py ``` Broader scan — finds metadata issues, catalog drift, orphan files. It is useful for discovery but is not currently a release gate; prefer `cerg-validate.py` for pass/fail decisions. The validator already supports 4-part workforce IDs such as `CERG-GOV-JD-SECENG-001`. ## Git Workflow for Agents ### Branching - For cross‑cutting changes (renames, restructures, bulk link fixes): create a feature branch from `main`, work there, merge back. - For single‑document edits: work directly on `main`. ### Committing - **One commit per file.** Do not batch multiple files into one commit. - Commit messages: very short, human‑readable. Examples: - `add missing Roles section, renumber` - `fix version inconsistency` - `update metadata table to STY-001 §4 format` - For mechanical batch fixes (e.g., same regex applied to 20 files): single commit with a message like `bulk fix: unify Ownership field across per-role JDs` ### Pushing Push immediately after each commit. Do not accumulate local commits. ```bash git add FILENAME.md git commit -m "short message" git push origin main ``` ### Git Config Use the repository's existing Git identity unless the human owner instructs otherwise. Do not overwrite user.name or user.email just because an example in this file differs. ## Editing Rules ### CRITICAL: Do NOT use the `patch` tool The `patch` tool's fuzzy matching fails catastrophically on CERG docs because `---` (markdown section separator) appears 30‑80 times per file. The pattern `---` matches ALL separator lines regardless of surrounding context. Also: `**Version**`, `**Status**`, `**Document ID**` appear in BOTH the front‑matter metadata table AND the Document Control section AND Revision History column headers. String replacement hits all occurrences. **Safe approach:** use exact, uniquely matched replacements or line-targeted scripts. Keep replacement blocks small and verify the diff before committing. ```python path = 'governance/CERG-GOV-XXXXX_Title.md' with open(path) as f: lines = f.read().split('\n') # Find the exact line and replace it # e.g. lines[12] = '| **Status** | Approved |' lines[target_line] = new_value with open(path, 'w') as f: f.write('\n'.join(lines)) ``` ### Verify After Every Edit ```bash cd /workspace/CERG git diff --stat # Check changed-line count — should match expected python3 tools/cerg-validate.py # Must pass with 0 errors ``` ### Section Renumbering When inserting or deleting sections: 1. Renumber from HIGHEST to LOWEST to prevent cascading replacement 2. Update TOC entries (both numbers and anchor links) 3. Fix cross‑references in text that point to old numbers 4. Verify with: `grep -n '^## [0-9]' FILENAME.md` ### Document Status Rules - CERG-owned documents pushed to `main` should use lifecycle status `Approved` unless they are intentionally Draft, For Review, Retired, or Planned. - Publication eligibility is not a lifecycle status; use the publication manifest for public-release decisions. - Exception: IR documents (PLN‑IR‑001, PRC‑IR‑002) use `External Interface` status, are owned by `Standing IR Team / Incident Commander`, and carry an ADJACENT FUNCTION banner. - Status, owner, and approval authority must be consistent across the metadata table, Document Control section, and CAT‑001 catalog entry. ### Stale Placeholders Do NOT leave bare "Placeholder", "TBD", or "N/A —" in Approved documents. Use the pattern: "Preliminary default requiring organizational calibration" with a stated basis. ## Document Prefix Registry | Prefix | Type | Pillar | |--------|------|--------| | POL | Policy | governance | | GOV | Governance Instrument | governance | | STD | Standard | engineering | | PRC | Procedure | risk | | PLN | Plan / Operational Package | governance | | GL | Guideline | governance | | TMPL | Template | governance | | JF | Job Family | workforce | | JD | Job Description | workforce | ## Available Tools ### `tools/cerg-validate.py` CI gate. Validates markdown links, catalog references, file inventory, metadata consistency. **0 errors required.** This is the authoritative validator. ### `tools/cerg-integrity-check.py` Supplementary metadata and cross‑reference scanner. Broader than the validator but less precise (more false positives). Use for discovery, not gate‑keeping. ### `tools/cerg-render.py` Renders CERG markdown with {{TOKEN}} placeholder substitution from an org profile YAML. For adopters customizing the framework for their organization. ### `tools/regenerate-machine-readable.py` Regenerates `machine-readable/cerg-manifest.yaml` and `machine-readable/cerg-publication-manifest.yaml` from repo-local governed Markdown artifacts. Run after governed document metadata, paths, or inventory changes. ### `tools/regenerate-llm-index.py` Regenerates `machine-readable/cerg-llm-index.json` from repo-local Markdown. Run after any Markdown document is added, removed, renamed, or materially reclassified. ### `tools/populate-nice-tks.py` Populates §6 (NICE TKS Statement References) in per‑role JD files from NIST NICE Framework v2.2.0 dataset. ### `tools/populate-jd-sections.py` Populates §9 (Competency Anchors from CMP‑001), §10 (Success Profiles), and §11.3 (Management Track from JA‑001) in per‑role JDs. ## Common Pitfalls 1. **Patch tool on `---` separator** — catastrophic false matches. Use line‑targeted Python. 2. **Anchor collision on `**Version**`, `**Status**`, `**Document ID**`** — appears 3+ times in every file (metadata table, DC section, Revision History). Target by line number, not string match. 3. **Section renumbering cascade** — `replace("## 2. ", "## 3. ")` then `replace("## 3. ", "## 4. ")` hits the REPLACED §2 too. Renumber HIGHEST→LOWEST. 4. **Link prefix depth** — files in `roles/jf-seceng/` need `../../` for root docs, `../` for `roles/` files, bare name for same‑subdir. 5. **Status in multiple places** — change metadata table Status, Document Control status/approval fields, and CAT‑001 catalog entry together. They must agree. 6. **Lifecycle vs publication** — do not set document status to Published. Lifecycle status is `Approved`; public-release eligibility lives in `cerg-publication-manifest.yaml`. 7. **Generated artifact drift** — after governed metadata or inventory changes, run `python3 tools/regenerate-machine-readable.py` and `python3 tools/regenerate-llm-index.py`. 8. **CI runs committed code only** — `git stash` → test → `git stash pop` to distinguish local fixes from committed state. ## Quick‑Start Checklist (First Visit) 1. `cd /workspace/CERG` — set working directory 2. Read `machine-readable/cerg-llm-index.json` — understand the document landscape 3. Read `README.md` — understand CERG's purpose and adoption paths 4. Read `CONTRIBUTING.md` — contribution guidelines 5. Read a spine document: `governance/CERG-POL-001_Cybersecurity_Policy.md` — understand document structure 6. Run `python3 tools/cerg-validate.py` — confirm current state 7. For editing, use exact replacements or line-targeted Python — never fuzzy patching against repeated separators 8. After each file edit: commit with a short message; push only when the environment and human owner expect it ## CERG in Context Windows For briefings where CERG content must fit in a small context window (e.g., instructing a separate LLM about the framework): - **Full index:** `machine-readable/cerg-llm-index.json` — complete local document map with repo-relative paths and summaries - **Regeneration scripts:** `tools/regenerate-machine-readable.py` and `tools/regenerate-llm-index.py` — regenerate core manifests and the JSON index from local Markdown. - **Condensed reference (optional):** A ~5,000‑token summary of core principles, pillar model, document taxonomy, key rules, and risk framework. Generate on demand. The full concatenated corpus is at `https://cerg.nexus/llms-full.txt` (2.9 MB, ~800K tokens) — too large for most context windows. --- # Code of Conduct ## Our pledge We pledge to make participation in this project a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, and inclusive community. ## Our standards Examples of behavior that contributes to a positive environment: - Using welcoming and inclusive language - Being respectful of differing viewpoints and experiences - Gracefully accepting constructive criticism - Focusing on what is best for the framework and its users - Showing empathy towards other community members Examples of unacceptable behavior: - Trolling, insulting or derogatory comments, and personal attacks - Public or private harassment - Publishing others' private information without explicit permission - Other conduct which could reasonably be considered inappropriate in a professional setting ## Scope This code of conduct applies within all project spaces, including GitHub issues, pull requests, discussions, and any other channels associated with the project. It also applies when an individual is representing the project or its community in public spaces. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening a [GitHub issue](https://github.com/m0dernz/CERG/issues) or contacting the project maintainers directly. All complaints will be reviewed and investigated promptly and fairly. Project maintainers are responsible for clarifying and enforcing standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1. --- # Contributing to CERG CERG is open source (CC BY 4.0) and contributions are welcome. This document explains how to contribute effectively. ## Ways to contribute **Improve existing documents.** Fix gaps, clarify language, add missing cross-references, or update regulatory citations. **Propose new documents.** New standards, procedures, templates, or operational packages that fit the CERG model. **Write example profiles.** Sector-specific or size-specific adaptation examples in `/examples/`. **Report bugs.** Broken links, catalog errors, metadata inconsistencies, or validation failures. **Suggest structural improvements.** New workstreams, maturity model domains, or metrics. ## Before you start 1. **Read the framework first.** At minimum: [README](README.md), [START-HERE](START-HERE.md), [CERG Framework](governance/CERG-GOV-FRM-001_CERG_Framework.md), and [Operating Model](governance/CERG-GOV-OM-001_CERG_Operating_Model.md). Contributions that don't fit the three-pillar model or the document conventions will need rework. 2. **Check the catalog.** Every document has a `CERG-TYPE-DOMAIN-NNN` ID registered in [CAT-001](governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md). New documents need a new domain code registered in §2.1 before the catalog row is added in §5. 3. **Understand the conventions.** Read [STY-001](governance/CERG-GOV-STY-001_Document_Authoring_and_Style_Guide.md) (metadata tables, section numbering, no em dashes in prose). See [AGENTS.md](AGENTS.md) for editing pitfalls — especially the `patch` tool collision with `---` separators. ## How to submit changes **For small fixes** (typos, single-link fixes, metadata corrections): open a PR directly. One commit per file edited, short human-readable messages. **For new documents or structural changes**: open an issue first so the approach can be discussed before you invest in a full draft. Include the proposed Document ID, which pillar owns it, and which existing documents it cross-references. **For everything**: make sure `python3 tools/cerg-validate.py` passes with 0 errors before submitting. Warnings should be resolved before submitting unless they are intentionally documented and accepted by maintainers; errors are not acceptable. ## Optional: pre-commit hook A `.pre-commit-config.yaml` is provided that runs the validator, integrity checker, and validator tests on every commit. This is **optional** — the CERG CI workflow runs the same checks on every push and pull request, so pre-commit is a faster local feedback loop, not an additional gate. To enable: ```bash pip install pre-commit pre-commit install ``` To skip on a specific commit when intentional: ```bash git commit --no-verify ``` The pre-commit hooks run against the full corpus, so every commit triggers a repo-wide check. This is intentional: a link fix in one file can break references in another, and a per-file subset would miss that. ## Document conventions (quick reference) - **Metadata table**: full 11-field STY-001 §4 format (Document ID, Version, Status, Classification, Owner, Parent Policy, Review Cycle, Frameworks, Regulations, Environments). Copy the shape from [EDG-001](governance/CERG-GOV-EDG-001_Edge_Register.md). - **Status**: every CERG-owned document pushed to `main` must be `Approved` with `Approved By: CISO` in the Document Control section. (IR docs are the only exception.) - **Editing**: do NOT use the `patch` tool on CERG docs — the `---` separator and `**Version**`/`**Status**` table headers collide. Use line-targeted Python via `execute_code`, reading with `open(path).read()`. - **Links**: resolve relative to the source file's directory. Files in `governance/` linking to other `governance/` files use bare filenames. Files in `governance/` linking to `procedures/` use `../procedures/FILENAME.md`. - **No em dashes** in prose (STY-001 §9.2). Use hyphens or restructure. - **No bare unfilled values** in Approved documents. Use "preliminary default requiring organizational calibration" with a stated basis, per RMF-001 §12. ## Code of conduct Be respectful, assume good faith, and keep discussions focused on making the framework better. Disagreements about approach are healthy; personal criticism is not. ## Questions? Open an issue with the `question` label, or start a [GitHub Discussion](https://github.com/m0dernz/CERG/discussions). --- # Policy-as-Code Examples for CERG This directory contains reference implementations of **policy-as-code** patterns that map CERG controls to machine-enforceable rules. These examples support the CERG principles described in: - **FRM-001 §3.2** — Policy-as-code as a core Engineering activity - **OM-001 §3.1** — Automated enforcement over manual compliance - **FLOW-001 F-02 T3** — Pipeline gates as admission control ## Contents | File | What It Shows | CERG Controls Mapped | |------|--------------|---------------------| | [`dish-baseline-opa.rego`](./dish-baseline-opa.rego) | DISH secure configuration baseline as OPA/Rego policies for Linux password policy and Windows audit policy | `CERG-STD-CFG-001` §4, §5 | | [`arch-review-gate.yml`](./arch-review-gate.yml) | Architecture review gate as a GitHub Actions workflow — blocks PRs missing required artifacts | `PRC-AR-001`, `FLOW-001 F-02` | | [`admission-control.yml`](./admission-control.yml) | Change management admission control as a GitHub Actions workflow — enforces evidence + approval gates | `FLOW-001 F-01`, `RMF-001 §9.7` | ## How to Use ### Prerequisites - **OPA / Rego**: [`openpolicyagent/opa`](https://www.openpolicyagent.org/docs/latest/) (CLI or deployed as sidecar) - **GitHub Actions**: A GitHub repository with Actions enabled - **Alternative engines**: The Rego policies work with [Kyverno](https://kyverno.io/) (via Kyverno JSON mode) and [Conftest](https://www.conftest.dev/) ### Quick Start (OPA) ```bash # Evaluate all DISH policies against a configuration input opa eval --data dish-baseline-opa.rego --input input.json "data.dish.auth" # Test with a specific rule opa eval --data dish-baseline-opa.rego --input input.json "data.dish.linux.password.min_length" ``` ### Quick Start (Conftest) ```bash # Evaluate DISH policies against a YAML config conftest test --policy tools/policy-as-code/dish-baseline-opa.rego config.yaml ``` ## CERG Control-to-Policy Mapping Each policy rule references the CERG control baseline (CB-001) and standard it implements: | Rego Rule | CERG Control / Standard | Adversarial Goal | |-----------|------------------------|-------------------| | `dish.linux.password.min_length` | CB-001 AC-7 / STD-CFG-001 §5.1 | Prevent brute-force / weak-password login | | `dish.linux.password.complexity` | CB-001 IA-5(1) / STD-CFG-001 §5.1 | Enforce password composition | | `dish.linux.password.expiry` | CB-001 IA-5 / STD-CFG-001 §5.1 | Limit credential lifetime | | `dish.linux.account.lockout` | CB-001 AC-7 / STD-CFG-001 §5.1 | Throttle repeated auth failures | | `dish.windows.audit.account_login` | CB-001 AU-3 / STD-CFG-001 §5.2 | Log authentication events | | `dish.windows.audit.account_management` | CB-001 AU-3 / STD-CFG-001 §5.2 | Log account create/modify/delete | | `dish.windows.audit.object_access` | CB-001 AU-3 / STD-CFG-001 §5.2 | Log resource access attempts | | `dish.arch_review.requires_record` | PRC-AR-001 §4 / FLOW-001 F-02 T3 | Every deployment needs a disposition | | `dish.arch_review.requires_threat_model` | PRC-AR-001 §5 / FLOW-001 F-02 T4 | High-risk changes need threat model | | `dish.admission.requires_approval` | RMF-001 §9.7 / FLOW-001 F-01 | Changes need risk-acceptance or exception | | `dish.admission.evidence_complete` | CB-001 §9 / AUD-001 | Evidence must be current | ## Adding New Policies 1. Add the Rego rule with a unique name under the `dish` package 2. Include a comment mapping to the CERG control ID and adversarial goal 3. Add the mapping to the table above 4. Verify with `opa eval` or `conftest test` ## References - [Open Policy Agent — Policy Language](https://www.openpolicyagent.org/docs/latest/policy-language/) - [Conftest — Rego for configuration files](https://www.conftest.dev/) - [CERG STD-CFG-001 — DISH Baseline Standard](../../standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md) - [CERG PRC-AR-001 — Architecture Review Procedure](../../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - [CERG FLOW-001 — Cross-Pillar Operational Flows](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md) --- # 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, pick your path below. If you are still unsure where to begin, use these four helpers before diving into the full library: - [Framework System Map](governance/CERG-GOV-FRM-002_Framework_System_Map.md) - how the documents, pillars, records, evidence, and improvement loops fit together. - [Adoption Decision Tree and Dependency Matrix](governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) - which path and overlays apply, plus what must be adopted together. - [Role-Based Implementation Checklists](governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) - what the CISO, Governance, Risk, and Engineering leads do first. - [Record Catalog](governance/CERG-GOV-CAT-002_Record_Catalog.md) - the records and minimum evidence that prove the program is operating. - [Day in the Life examples](examples/day-in-the-life/README.md) - 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](governance/CERG-GOV-IMP-007_Role_Reader_Paths.md) - 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 | If you need to... | Use | |---|---| | Pick the right adoption path in the first hour | This START-HERE page | | Understand the narrative rollout model | [IMP-001 Implementation and Adaptation Guide](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) | | Avoid unsafe tailoring and authority collapse | [IMP-002 Adoption Safety Guide](governance/CERG-GOV-IMP-002_Adoption_Safety_Guide.md) | | Run CERG with 2-8 people | [IMP-003 Small Team Adoption Path](governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) | | Decide Lite / Standard / Regulated and dependencies | [IMP-005 Decision Tree and Dependency Matrix](governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md) | | Convert reading into action | [IMP-006 Role-Based Implementation Checklists](governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) | | Onboard a specific role quickly | [IMP-007 Role Reader Paths](governance/CERG-GOV-IMP-007_Role_Reader_Paths.md) | --- ## 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](governance/CERG-POL-001_Cybersecurity_Policy.md).** This is the spine. Nothing is authoritative until an Executive Sponsor signs this. 2. **Read the [CERG Framework](governance/CERG-GOV-FRM-001_CERG_Framework.md)** — the three-pillar model. You'll consolidate roles heavily; that's expected. 3. **Read the [Small Team Adoption Path](governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md).** This is your primary guide. It covers the CERG Lite package, 5-person operating rhythm, role consolidation map, first 10 records, and spreadsheet schemas. 4. **Read the [Role-Based Implementation Checklists](governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md).** Use the small-team consolidated checklist if one person holds multiple roles. 5. **Read the [Implementation Guide](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md)** §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](governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md).** Set your headcount, sector, and regulators. Do NOT leave the default values. 8. **Start the Risk Register.** Open [the template](templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md). Create your first entry. It can be simple. 9. **Create the first records from the [Record Catalog](governance/CERG-GOV-CAT-002_Record_Catalog.md).** 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](procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) 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](examples/day-in-the-life/story-8-cerg-lite-maria.md) 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](governance/CERG-GOV-FRM-001_CERG_Framework.md).** Map your existing team to the three pillars. Identify gaps. 2. **Read the [Implementation Guide](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md)** §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](governance/CERG-GOV-FRM-001_CERG_Framework.md).** Understand the three-pillar model. 2. **Read the [Implementation Guide](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md)** §4-5. 3. **Adopt the MVC spine.** 4. **Identify your regulatory overlay.** Open the relevant operational package: - NERC-CIP → [PLN-CIP-001](plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md) - CMMC / CUI → [PLN-CUI-001](plans/CERG-PLN-CUI-001_CUI_CMMC_Operational_Package.md) - SOX ITGC → [PLN-SOX-001](plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) - ISO 27001 → [PLN-ISO-001](plans/CERG-PLN-ISO-001_ISO_IEC_27001_Operational_Package.md) 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](governance/CERG-GOV-CMX-001_Compliance_Matrix.md).** 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. ### Schedule your first stakeholder survey at month 2 After one full cadence cycle (approximately 60 days), administer the [Stakeholder Perception Survey](templates/CERG-TMPL-GOV-001_Stakeholder_Perception_Survey.md). 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](governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md). The survey is paired with monthly [Service Responsiveness metrics](governance/CERG-GOV-MTR-001_Metrics_Dashboard_and_Reporting.md) (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](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md) §9 (Common Adoption Pitfalls). 2. Check your org profile in [VAR-001](governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) — 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/](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](governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md). 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](README.md)** · **[Full catalog](governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md)** · **[Implementation Guide](governance/CERG-GOV-IMP-001_Implementation_and_Adaptation_Guide.md)** --- # Security ## Reporting security issues If you find a vulnerability or security concern **in the CERG framework itself** (not in an organization that uses it), please report it responsibly: 1. **Do not** open a public GitHub issue for sensitive security findings. 2. Open a [GitHub Security Advisory](https://github.com/m0dernz/CERG/security/advisories/new) or contact the maintainers directly. 3. Allow reasonable time for a response before public disclosure. ## What this covers This policy covers security issues in the CERG repository — broken access controls in the CI pipeline, exposed credentials, or vulnerabilities in the build/deploy tooling. For security issues in an **organization that uses CERG**, contact that organization's security team. CERG is a framework; implementation security is the adopter's responsibility. --- # Story 10: The new CISO's first 90 days This story is for the CISO, the incoming security leader, or the executive sponsor trying to understand what good adoption looks like at the program level. It is a narrative arc, not a single event. It walks day 1 through day 90 of a new CISO inheriting a fragmented program and bringing it onto CERG Standard. For the underlying checklists that anchor this arc, see [CERG-GOV-IMP-006 §3](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md#3-ciso-or-security-lead-checklist). For the consolidation and pacing logic, see [CERG-GOV-IMP-005](../../governance/CERG-GOV-IMP-005_Adoption_Decision_Tree_and_Dependency_Matrix.md). ## Setting Meridian Analytics is a 180-person B2B SaaS company selling a customer data platform to mid-market and enterprise customers. The platform processes customer behavioral data, integrates with major CRMs and marketing tools, and runs as a multi-tenant cloud service. Meridian holds a SOC 2 Type II report that is up for renewal in six months. Three enterprise customers have audits queued in the next 90 days. The previous CISO left two months ago. Since then, the CEO Jordan has been "covering it" with help from an outside vCISO who works four hours a week. There is a folder of policy documents from 2022 that have not been updated. There is a spreadsheet called "security risks" with 14 rows, none of which have owners. There is a vulnerability scanner running weekly against the production cloud tenant, but findings go into an email thread that no one closes. There is no risk register. There is no evidence library. There is no decision log. There is no documented owner for anything. Priya Anand starts on a Monday. She has held CISO roles at two smaller SaaS companies and has been a deputy CISO at a larger one. She has read CERG before, ran a CERG Lite adoption at her last company, and has chosen Meridian specifically because the board has committed to a real program. This is the story of her first 90 days. ## Day 1-7: Arrival and the first 48 hours Priya arrives at 9 a.m. on Monday. Her first meeting is with Jordan at 9:30. By 10 a.m. she has: - Confirmed Jordan will be the Executive Sponsor (per IMP-006 §3.1, first row). - Asked for the names of the Engineering, Risk, and Governance interim owners. Jordan names Tomás (Engineering Manager, has been running the production cloud), Sara (Director of Trust, has been running SOC 2 and customer audits), and himself as Governance until Priya hires. - Asked for the vCISO's notes. There are none worth keeping. - Scheduled a Tuesday afternoon meeting with Tomás, Sara, and the Head of Sales (because the enterprise audits will land first). By Tuesday at 5 p.m., Priya has filled in [CERG-GOV-VAR-001](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) with Meridian's profile: 180 people, B2B SaaS, SOC 2 + customer-driven regulatory scope, cloud-only, no OT, no CUI. She has picked CERG Standard as the adoption path (IMP-005 §3) because Meridian has an existing engineering team and existing customer audits. She has created the [Role Assignment Map](../../governance/CERG-GOV-VAR-001_Organization_Adaptation_Profile.md) per IMP-003 §5 Record 2. She has approved a shared Google Drive as the temporary evidence store (per IMP-006 §3.1, last row) because Meridian does not yet have a GRC platform. By Friday she has the first 10 records seeded (per IMP-003 §5). The most important is Record 4: the initial top 10 risks. She writes those herself over Wednesday and Thursday. The list looks like this: | # | Risk | Owner | Treatment | |---|------|-------|-----------| | 1 | SOC 2 Type II renewal in 6 months with no evidence library | Sara | Build evidence library by month 2 | | 2 | Three enterprise customer audits queued with no response template | Sara | Build audit response template by month 1 | | 3 | Vulnerability scanner findings not being closed | Tomás | Triage this week, fix process within 30 days | | 4 | No documented access review cadence | Tomás | Implement quarterly cadence by month 2 | | 5 | Vendor risk assessments not performed on three critical SaaS dependencies | Sara | Complete assessments by month 3 | | 6 | No incident response plan or IR owner | Priya | Name IR owner, adopt IR Plan by month 1 | | 7 | Board has not received a security update in 4 months | Priya | First board update at next board meeting | | 8 | No documented data classification | Sara | Adopt DG standard by month 2 | | 9 | Engineering security reviews happening informally | Tomás | Adopt Architecture Review procedure by month 2 | | 10 | No metrics dashboard | Priya | First metrics report by month 2 | This list becomes Priya's first 90 days. It is the risk register's seed content. ## Day 8-30: First monthly review By the second Monday, the rhythm starts. The team adopts the IMP-003 weekly 1-hour cadence for a Standard team of Meridian's size (4 people: Priya, Tomás, Sara, plus an Engineering security engineer Devin who joins in week 2). Week 2: Priya runs the first weekly meeting. Tomás walks the vulnerability scanner backlog. There are 23 findings, 2 Critical, 5 High. The Criticals are both on the production API tier. Tomás opens Change Records for both and schedules maintenance windows. By Friday both are remediated. The weekly cadence absorbed a Critical without a single ad hoc meeting. Week 3: Sara delivers the audit response template. The template maps a customer audit request to the relevant CERG artifact, identifies the evidence owner, and sets a 10-business-day response clock. This becomes the basis for the three queued audits. Week 4: Priya signs the [Cybersecurity Policy](../../governance/CERG-POL-001_Cybersecurity_Policy.md). It is the first authoritative artifact Meridian has had in two years. The board ratifies it at the next board meeting (which happens to be in week 4). End of month 1 deliverables: - Approved Cybersecurity Policy - First 10 risks in the register with owners - Risk appetite defaults approved (Priya proposed, board ratified) - Cyber Oversight Group formed (Priya chairs, Tomás and Sara attend, vCISO joins as observer) - First exposure backlog reviewed (the 23 scanner findings are now 6 open, all triaged) - Exception and risk acceptance authority mapped to RMF-001: Business Owners accept consequence, Priya approves High/Critical where required, and the Executive Sponsor / board are named for Critical or board-notified items. - 30-day improvement backlog seeded Priya logs every decision in the Decision Log per IMP-002 §4. The log is a simple spreadsheet. It has 11 entries at the end of month 1. ## Day 31-60: First quarterly review prep and first audit Week 5 starts with the first exposure cycle closing out. The 6 open findings from month 1 are down to 2, both Medium, both with planned remediation windows. The scanner schedule moves from weekly to biweekly because the backlog is now stable. Week 6: Priya runs the first formal audit response. An enterprise customer sends a 47-question security questionnaire with a 10-business-day clock. Sara uses the audit response template. The questionnaire maps to 12 CERG artifacts (Policy, Operating Model, RMF, Access Standard, Logging Standard, TPRM Procedure, and others). Sara pulls each from the evidence library, attaches the relevant evidence, and routes the response through Priya for sign-off. The response goes out on day 8 with 2 questions marked "evidence pending - response by day 12." The customer accepts the response without follow-up. Week 7-8: Sara runs the first three vendor risk assessments on critical SaaS dependencies. The vendor assessments use [CERG-PRC-TPRM-001](../../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) and [CERG-TMPL-TPRM-001](../../templates/CERG-TMPL-TPRM-001_Vendor_Security_Questionnaire_and_Assessment_Template.md). Two vendors pass on first assessment. One vendor returns incomplete answers and is given a 30-day remediation window with an Exception Record. End of month 2 deliverables: - First metrics dashboard. Three metrics: open Critical/High findings, exceptions expiring in 30 days, vendor assessments current. All three are green. - First board update. Priya presents the metrics dashboard, the top 10 risks, and the SOC 2 readiness status to the board. The board approves the next quarter's hiring plan: one additional Engineering security engineer and one Risk analyst. - First risk acceptance package. Tomás and Sara identify one Medium-risk decision (deferring a configuration baseline update until next quarter), Risk recommends the disposition, and the affected Business Owner accepts the consequence under the RMF authority path. Priya reviews the package for visibility and escalation readiness. The package has a named owner, an expiration date, and a remediation plan. ## Day 61-90: First audit lands, first exception, first quarterly review Week 9: A SOC 2 readiness assessment (pre-audit gap analysis by an external firm) lands. The firm identifies 12 gaps across 8 control families. Each gap becomes a Finding Record. Each Finding Record has an owner (Sara or Tomás), a remediation deadline, and an evidence plan. None of the 12 gaps are Critical SLA. All are Medium or Low with 90-day windows. The quarterly SOC 2 audit is in 5 months; this is the work that closes the gaps. Week 10: An enterprise customer's auditor requests live evidence of a quarterly access review for a Meridian system. Meridian has not been running quarterly access reviews (Risk #4 from day 7). Tomás runs an out-of-cycle review to satisfy the auditor. The review identifies 4 stale privileged accounts and 1 contractor account whose engagement ended 6 weeks ago. Engineering removes all 5. Sara records the Exception Record with a 60-day expiration, Priya reviews it as CISO, and the Business Owner confirms the next scheduled quarterly review will happen on time. The auditor accepts the response. Week 11-12: Priya runs the first quarterly review per IMP-003's quarterly half-day cadence. The review covers: - Control evidence refresh (3 control families: Access, Logging, Asset Management) - Lessons learned from the SOC 2 readiness findings and the customer audit - Open high risks review - Expired exceptions review - Improvement backlog review The quarterly review produces 5 new entries in the Program Improvement Register. None of them are "patch faster." They are systemic improvements: implement automated access review tooling, integrate vulnerability scanner with ticketing, define the Security Reviewer role in the Architecture Review procedure, add board pack insert for quarterly metrics, formalize the vCISO engagement scope. End of month 3 deliverables (matches IMP-006 §3.3): - First metrics dashboard reviewed by the CISO and approved for ongoing use. - Control implementation snapshot reviewed. Of the 22 CERG control intents in [CB-001](../../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md), Meridian now has authoritative evidence for 14 and is working evidence plans for the remaining 8. - Adoption expansion decision. Priya recommends expanding to the CERG Regulated overlay for [CERG-PLN-SOX-001](../../plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md) readiness, and the board approves the scope and funding, even though Meridian is not yet SOX-relevant, because the next enterprise customer audit will require it. - Open high risks reviewed. 2 of the original 10 are closed. 8 remain, all with owners and dates. - Expired exceptions reviewed. The one exception from week 10 has a renewal decision: extend 60 days because the automated access review tool will not be live for another 60 days. - Resourcing decisions approved by the board / Executive Sponsor. One Engineering security engineer and one Risk analyst hired, starting in month 4. ## What this story shows The first 90 days of a CERG Standard adoption do not look like a "project." They look like a rhythm: - Weekly 1-hour cadence absorbing Criticals without ad hoc meetings - Monthly 2-hour cadence absorbing regulatory and audit work - Quarterly half-day cadence producing systemic improvement The CISO does not deliver the program. The CISO convenes it. The CISO's job in the first 90 days is to: 1. Get the Executive Sponsor named and the Role Assignment Map populated (week 1). 2. Seed the first 10 records so the program has something to operate on (week 2-3). 3. Sign the Cybersecurity Policy (week 4). 4. Run the weekly cadence every week without fail (weeks 2-12). 5. Run the first monthly review (week 4). 6. Run the first quarterly review (week 12). 7. Surface one Decision Log entry per material decision. 8. Produce one metrics dashboard for the board before the board asks. By day 90, Meridian has 5 authoritative CERG artifacts (Policy, RMF, Operating Model, Risk Register, Document Catalog), 3 standards adopted (Access, Logging, Asset Management), 4 procedures in operation (Risk Register, TPRM, Architecture Review, Access Management Runbook), 12 records in the evidence library, 23 Decision Log entries, and one quarterly metrics report. The team has remediated 21 findings, opened 1 exception, filed 1 business-owned risk acceptance package, and passed one customer audit without follow-up. The SOC 2 Type II renewal in month 7 is now a finishing exercise, not a panic. ## What this story does not cover - **A real incident.** The first 90 days did not include a declared incident. If one had, it would have triggered F-06 and the standing IR team. See Story 6 for the third-party incident pattern and the IR handoff. - **A major regulator-driven control change.** The first 90 days did not include an external regulatory obligation. When the SOC 2 framework updated or a new customer required NIS2 alignment, Story 9's F-01 pattern would apply. - **CERG Lite.** Meridian is a Standard team. See Story 8 for the small-team pattern. For the CISO checklist that anchors this arc, see [CERG-GOV-IMP-006 §3](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md#3-ciso-or-security-lead-checklist). For the First 90-Day Completion Criteria, see [CERG-GOV-IMP-006 §8](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md#8-first-90-day-completion-criteria). For the role assignment map pattern, see [CERG-GOV-IMP-003 §4](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md#4-role-consolidation-map). For the Decision Log requirement, see [CERG-GOV-IMP-002 §4](../../governance/CERG-GOV-IMP-002_Adoption_Safety_Guide.md#4-the-decision-log). --- # Story 8: CERG Lite - Maria and the Tuesday scanner report This story is for the CERG Lite team: 2-8 people running the Minimum Viable CERG (MVC) spine. Every other story in this directory assumes a Standard or Regulated team. Read [CERG-GOV-IMP-003](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) and [CERG-GOV-IMP-006](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) before this story. ## Situation Northwind Logistics is a 60-person regional distribution company. Last quarter the CEO told the IT Lead, Maria, that she "also owns security now" after the previous security contractor walked off mid-engagement. Maria has two people on her team: Devin (help desk and endpoint) and Priya (network and cloud). None of the three has held a dedicated security role before. Six weeks ago Maria adopted the MVC. The [Cybersecurity Policy](../../governance/CERG-POL-001_Cybersecurity_Policy.md) is signed by the Executive Sponsor (the COO). Maria is CISO + Governance + Risk Register consolidated. Devin is Engineering Lead. Priya is Risk + Exposure Management + Vendor Risk consolidated. The first 10 records exist (per IMP-003 §5): profile, role assignment map, asset extract, top 10 risks, exposure backlog, exception register, evidence index, control snapshot, regulatory applicability, and 30-day improvement backlog. The first weekly 1-hour cadence meeting ran last Friday. It is Tuesday at 8:07 a.m. The vulnerability scanner has finished its weekly run against the production subnet, the staging cloud tenant, and the four external IPs. Priya opens the export. There are 47 findings. Two are rated Critical. ## CERG flow pattern Primary flow: [F-04 Finding to Remediation, Exception, or Residual Risk](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#12-flow-f-04--finding-to-remediation-exception-or-residual-risk) Supporting procedures and standards: - [Small Team Adoption Path](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md) - the operating rhythm and role consolidation map for a 3-person team. - [Role-Based Implementation Checklists](../../governance/CERG-GOV-IMP-006_Role_Based_Implementation_Checklists.md) - what each consolidated role does in week 1 through month 6. - [Exposure Management Procedure](../../procedures/CERG-PRC-VM-001_Exposure_Management_Procedure.md) - the observe, validate, classify, treat, verify flow Priya runs. - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - how findings become risks, exceptions, or risk acceptances when treatment cannot meet the required clock. - [Adoption Safety Guide](../../governance/CERG-GOV-IMP-002_Adoption_Safety_Guide.md) - role safety and decision log requirements for consolidated roles. - [Risk Management Framework](../../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) - canonical risk scoring and Business Owner / Executive Sponsor acceptance authority. - [Evidence Quality Standard](../../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) - what "evidence" means on a spreadsheet in a small team. - [Third Party and Supply Chain Risk Procedure](../../procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md) - vendor escalation, evidence requests, and alternate-service decisions. ### How the three pillars collapse onto three people | Pillar | Consolidated role at Northwind | Primary responsibilities today | |---|---|---| | Governance | Maria (also CISO) | Decision log, exception routing, evidence index, executive sponsor liaison | | Risk | Priya | Triage the 47 findings, severity calls, SLA tracking, risk register updates | | Engineering | Devin | Patch planning, change windows, asset ownership confirmation | The collapse is intentional and recorded in the [Decision Log](../../governance/CERG-GOV-IMP-002_Adoption_Safety_Guide.md#4-the-decision-log) per IMP-002 §4. Maria is the only person who signs exceptions. Priya owns the scanner schedule and the risk register. Devin owns the change record. There is no fourth person to delegate to. ## Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | Priya imports the 47 findings into the exposure backlog spreadsheet and tags each row with asset, reachability, source severity, and PRC-VM classification clock. | Priya (Risk) | Exposure backlog (EVD rows) | | 2 | Priya validates reachability and asset ownership for the two Critical findings. One is on the customer portal web server; the other is on a legacy SFTP endpoint that hosts a vendor integration. | Priya (Risk) | Triage notes in Finding Record | | 3 | Priya checks public exploit and KEV status. Both have public exploit code; the Internet-facing portal is classified as **Material Risk — PPR**. The vendor SFTP endpoint is treated as a Third-Party Finding with potential Critical residual risk until the vendor proves containment. | Priya (Risk) | Classification notes; PRC-VM SLA clock | | 4 | Devin confirms the customer portal web server is in his asset inventory and that the application owner (Operations Director) is named. The SFTP endpoint is vendor-owned, so Devin identifies the integration path, credentials, logs, and whether Northwind can pause transfers safely. | Devin (Engineering) | Asset Record update; integration map; vendor question logged | | 5 | Devin opens an emergency Change Record for the customer portal patch. He coordinates a same-day maintenance window with the Operations Director because PRC-VM's PPR clock is 48 hours for Internet-facing exposure. | Devin (Engineering) | Change Record | | 6 | For the SFTP endpoint, Priya opens a Third-Party Finding, sends the vendor the CVE details, requests evidence of containment and patch timing, and references the contract SLA. Devin disables nonessential transfers, rotates credentials, and prepares an alternate encrypted transfer path for sensitive reports. | Priya (Risk) + Devin (Engineering) | Third-Party Finding; containment evidence; vendor evidence request | | 7 | Maria reviews both Criticals immediately, not at the next weekly meeting. She can approve emergency containment and exception routing as CISO/Governance, but she cannot accept the vendor residual business risk alone. If the business must keep using the SFTP path before vendor remediation, Maria prepares a Risk Acceptance Request for the COO Executive Sponsor under RMF-001 §9.7. | Maria (Governance / CISO) | Decision Log entry; Risk Acceptance Request if continued use is required | | 8 | The COO chooses the safer business path: pause sensitive SFTP transfers and use the alternate encrypted path until the vendor patches. Because the risky path is not used, no Critical risk acceptance is needed; the open item remains a Third-Party Finding with treatment tracking. | COO Executive Sponsor + Maria | Decision Log entry; business decision; alternate transfer evidence | | 9 | After the maintenance window, Devin uploads patch output, the change ticket closure, and a service-validation screenshot. Priya rescans the portal and confirms closure. The portal Finding Record moves to Closed. | Devin (Engineering) + Priya (Risk) | Closed Finding Record | | 10 | Priya leaves the remaining 45 findings in the exposure backlog with PRC-VM clocks running. She flags the 11 High findings for the biweekly exposure review. | Priya (Risk) | Updated exposure backlog | | 11 | Maria updates the evidence index with the Closed Finding for the portal, the Third-Party Finding for the SFTP endpoint, the vendor evidence request, and the COO decision to use the alternate path. | Maria (Governance) | Evidence index entries | ### Narrative At 8:07 a.m. Priya's email pings with the scanner export. She has been doing this every Tuesday for six weeks and has the spreadsheet template down. By 8:30 a.m. the two Critical findings are tagged, validated against the asset inventory, and routed. The portal finding goes to Devin and is classified as Material Risk — PPR because it is Internet-facing with public exploit code. The SFTP finding goes back to Priya because the asset is vendor-owned, but Priya does not treat vendor ownership as a reason to slow down. Devin sees the portal Change Record in his queue at 8:45 a.m. He calls the Operations Director directly - the CERG escalation rule says a PPR exposure bypasses the normal change review queue. The Director approves a 2 p.m. maintenance window and reschedules a customer email blast so users hit the maintenance banner, not a blank page. Devin also applies a temporary WAF rule on the vulnerable path while the patch is prepared. Maria does not wait for the weekly 1-hour meeting. She opens a 15-minute emergency risk huddle with Priya, Devin, and the COO. Priya explains that the vendor SFTP issue is not something Maria can simply accept as a security exception: if Northwind keeps sending sensitive reports over the exposed path, the COO must accept the business consequence under RMF-001 §9.7, with Maria approving as CISO. Devin offers a safer path: pause sensitive SFTP transfers, rotate credentials, monitor for anomalous SFTP traffic, and use an alternate encrypted transfer method until the vendor patches. The COO chooses the safer path, so no Critical residual-risk acceptance is needed. Maria adds one Decision Log entry: "Vendor SFTP Critical exposure: sensitive transfers paused; alternate encrypted path approved by COO; vendor patch evidence due before SFTP resumes." Priya opens the Third-Party Finding, sends the vendor the CVE and evidence request, and records the contract SLA. This is still lightweight, but it is not informal. At 2:15 p.m. the maintenance window opens. Devin deploys the portal patch, validates the service, captures the validation screenshot, and closes the change ticket. Priya rescans at 3 p.m. The portal PPR exposure is closed. The remaining exposure backlog carries the 45 other findings into the biweekly exposure review. By the end of Tuesday, the team has produced: - 1 closed Finding Record (portal Material Risk — PPR) - 1 open Third-Party Finding (SFTP Critical, vendor remediation pending) - 1 closed Change Record (portal patch) - 1 Decision Log entry (Maria) recording the COO-approved alternate transfer path - 1 vendor evidence request and contract-SLA follow-up - 4 evidence index rows (portal closure, SFTP finding, vendor evidence request, COO decision) - 11 High findings flagged for biweekly review The team did not create a new committee or a heavyweight exception package, but it did interrupt the normal rhythm for a real Critical decision. Priya's scanner triage stayed spreadsheet-light. Devin's engineering work was bounded by the emergency change window. Maria's governance work was a short emergency huddle, a Decision Log entry, and the discipline to involve the COO when business consequence could not be accepted by security. ### Operating under the 5-person rhythm The MVC spine did not break under pressure, but it also did not pretend every decision can wait for the weekly cadence. The emergency huddle protected the PPR clock and the vendor-risk decision without creating a standing committee. The Decision Log made Maria's CISO/Governance decision and the COO's business decision auditable. The exposure backlog spreadsheet gave Priya a place to capture every finding without opening a ticket for each one. The collapse of the three pillars onto three people is the central design constraint of CERG Lite, not a workaround. Maria is doing CISO, Governance, and Risk Register work in one head. Devin is doing Engineering and Identity work in one head. Priya is doing Risk, Exposure Management, Threat Intel (read-only), and Vendor Risk in one head. The MVC spine fits because the consolidated roles each get one seat at the weekly meeting, and the records are designed to be one-row-per-event in a spreadsheet. If Northwind grows to 8 people in the next year, the team will deconsolidate. Maria will keep CISO and Governance. Priya will keep Risk and Exposure Management. They will add a dedicated Identity Engineer, a dedicated Compliance person, and two more Engineering roles. The records do not change. The RACI in [OM-001](../../governance/CERG-GOV-OM-001_CERG_Operating_Model.md) does not change. The cadence expands from weekly 1-hour to weekly 2-hour with sub-pillar owners. That deconsolidation is the documented growth path in IMP-003 §4. ## Operational outputs - 1 closed Finding Record for the customer portal Material Risk — PPR exposure. - 1 open Third-Party Finding for the SFTP Critical CVE, with vendor remediation and evidence due dates. - 1 closed Change Record linked to the portal patch. - 1 Decision Log entry recording Maria's CISO/Governance decision and the COO's business decision to use the alternate transfer path. - 4 evidence index rows added (portal closure, SFTP finding, vendor evidence request, COO decision). - 11 High findings flagged for the biweekly exposure review; remaining 34 findings left in the backlog with PRC-VM clocks running. ## What this story does not cover - **Internal IR declaration.** Northwind's IR owner is a contracted MSSP. If the portal or SFTP evidence showed active compromise, Maria would call the MSSP / Incident Commander and F-06 would take over. This story covers exposure treatment before incident declaration. See Story 6 for the third-party incident pattern and IR handoff. - **Audit response.** Northwind is not yet regulated. When their largest customer requests a SOC 2 attestation in six months, Story 3 will be the right reference. - **AI tooling.** Northwind is not yet piloting AI. When the Operations Director asks about an AI assistant for the customer service team, Story 7 will be the right reference. For the 5-person operating rhythm used in this story, see [CERG-GOV-IMP-003 §3](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md#3-operating-rhythm-for-a-5-person-team). For the role consolidation map, see [CERG-GOV-IMP-003 §4](../../governance/CERG-GOV-IMP-003_Small_Team_Adoption_Path.md#4-role-consolidation-map). --- # Story 9: F-01 Control Intent - when the regulator changes the rule This story is for any team that needs to convert an external regulatory change into operating CERG work. None of the other stories in this directory show [Flow F-01](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#9-flow-f-01--control-intent-to-implementation) (Control Intent to Implementation) in motion. F-01 is the flow that turns governance-originated change into implementable technical work and risk-validated outcomes. ## Situation Halberd Mutual is a 220-person European insurance carrier. Halberd adopted CERG Standard in 2024. The CERG Operating Model is in place, the MVC spine is running, all core standards are adopted, and Halberd holds ISO 27001:2013 certification with a planned transition to ISO 27001:2022 already in flight. On a Tuesday morning in late October, the CISO Lena opens an email from the General Counsel. The firm's home country has transposed the EU NIS2 Directive into national law. The transposition text names Halberd as an "important entity" in the financial services sector. Compliance deadlines start in 90 days for board-level accountability, 180 days for the operational measures, and 365 days for full evidence readiness. NIS2 obligations cut across Halberd's existing CERG work: incident reporting timelines (24-hour early warning, 72-hour notification, 30-day final report), supply-chain security controls, encryption and cryptography requirements, business continuity and crisis management, vulnerability handling, and board-level cybersecurity accountability. None of these are new categories for CERG. What is new is the binding legal clock and the named executive accountability. The work has to move fast. The CISO's question is: how does CERG absorb a regulatory change without breaking the program? ## CERG flow pattern Primary flow: [F-01 Control Intent to Implementation](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#9-flow-f-01--control-intent-to-implementation) Supporting procedures and standards: - [Risk Management Framework](../../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md) - for the gap analysis that justifies the F-01 record. - [Unified Control Baseline](../../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) - to map NIS2 obligations onto existing CB controls. - [Compliance Matrix](../../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) - to verify alignment with ISO 27001:2022, NIST CSF 2.0, and DORA simultaneously. - [Risk Register and Exception Process](../../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md) - for obligations Halberd cannot meet by the deadline. - [Cybersecurity Policy](../../governance/CERG-POL-001_Cybersecurity_Policy.md) - the parent policy that may need a clarifying paragraph for board accountability. - [Architecture Review and Project Intake Procedure](../../procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md) - for any technical changes that result. - [Evidence Quality Standard](../../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md) - for the audit package that goes to the regulator. - [Program Improvement Register](../../governance/CERG-GOV-IMPREG-001_Program_Improvement_Register.md) - for tracking and reporting the rollout. ### Why F-01, not F-02 or F-04 The temptation is to treat NIS2 as a project (F-02) or a finding (F-04). Neither fits. F-02 is for new systems or services entering production. F-04 is for specific vulnerabilities or audit findings. NIS2 is a control intent change at the program level: new rules that affect existing controls across many systems, with an external authority and a clock. F-01 is the right flow when the trigger is: - Policy changed (here: the regulator added requirements) - Standard changed (consequence) - Control baseline changed (consequence) - Regulatory requirement added (direct trigger) This story walks through the first two triggers. ## Walkthrough | Step | What happens | Primary owner | Record or evidence | |------|--------------|---------------|--------------------| | 1 | The CISO convenes a one-hour "regulatory change" session with the General Counsel, the Risk Pillar Leader (Marco), the Governance Pillar Leader (Yusra), and the Engineering Pillar Leader (Aisha). They map NIS2 obligations onto CERG artifacts. | CISO | Decision Log entry; gap analysis spreadsheet | | 2 | Yusra opens one Control Change Record per NIS2 obligation cluster (incident reporting, supply-chain, cryptography, continuity, vulnerability handling, board accountability). Six Control Change Records in total. | Governance Pillar Leader | 6 Control Change Records (CCR-NIS2-001 through CCR-NIS2-006) | | 3 | For each Control Change Record, Yusra defines the conformance scope: which environments, which asset classes, which existing controls apply, which are missing. | Governance Pillar Leader | Conformance Scope Statement per CCR | | 4 | Aisha produces the implementation design: which existing CERG standards need a new clause, which procedures need a step, which templates need new fields. | Engineering Pillar Leader | Implementation design package per CCR | | 5 | Marco defines validation criteria before rollout: how Risk will test that the new obligation is met. For incident reporting, the validation is a tabletop that walks the 24-hour / 72-hour / 30-day clocks end to end. | Risk Pillar Leader | Validation plan per CCR | | 6 | Yusra approves the evidence plan and assigns implementation deadlines. The 90-day obligation lands on CCR-NIS2-006 (board accountability). The 180-day obligations land on CCRs 001-004. The 365-day obligations land on the evidence-readiness track. | Governance Pillar Leader | Approved evidence plan per CCR | | 7 | Aisha and the Engineering pillar execute rollout per CCR. Each implementation produces evidence: updated standards, updated procedures, new templates, training records, board materials. | Engineering Pillar Leader | Implementation evidence per CCR | | 8 | Marco validates effectiveness per CCR. For each closure, Marco produces a Control Test Worksheet using [CERG-TMPL-AUD-001](../../templates/CERG-TMPL-AUD-001_Control_Evidence_and_Test_Worksheet.md). | Risk Pillar Leader | Control Test Worksheets | | 9 | For obligations Halberd cannot meet by the deadline, the Business Owner (CEO, in this case, because the obligation is board-level) signs a Risk Acceptance Memo with a documented remediation plan and a named review date. | CEO + CISO | Risk Acceptance Memo per missed obligation | | 10 | Yusra updates the metrics dashboard with NIS2 implementation status and links the audit package. The dashboard now has a regulator-facing overlay that the board reads monthly. | Governance Pillar Leader | Updated Reporting Metric Record | ### Narrative Lena opens the General Counsel's email at 9:14 a.m. By 9:30 a.m. she has scheduled a one-hour session for 11:00 a.m. with Marco, Yusra, and Aisha. She also loops in the CEO's chief of staff so the board-level accountability conversation has executive context. At 11:00 a.m. the four sit down with the transposition text, a printout of the existing [Unified Control Baseline](../../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md), and the [Compliance Matrix](../../governance/CERG-GOV-CMX-001_Compliance_Matrix.md) cross-reference page. They walk each NIS2 article and find: - Incident reporting timelines → CB-001 §6 already has the concept; specific 24/72/30 clocks are new. - Supply-chain security → CB-001 §9 covers TPRM; NIS2 adds explicit subcontractor flow-down requirements that the existing CERG-PRC-TPRM-001 does not enforce. - Cryptography → existing CERG-STD-CR-001 covers algorithm and key management; NIS2 adds explicit requirements for state-of-the-art cryptography that need a clarifying sentence. - Business continuity → existing CERG-PLN-BC-001 covers DR; NIS2 adds explicit crisis-management obligations that link crisis to incident declaration. - Vulnerability handling → existing CERG-PRC-VM-001 covers exposure management; NIS2 adds explicit coordination requirements with the regulator. - Board accountability → existing CERG-POL-001 names the CISO; NIS2 requires named board-level sign-off and documented cybersecurity training for board members. By noon the gap analysis is complete. Marco logs a Decision Log entry per IMP-002 §4: "NIS2 identified as in-scope. Six Control Change Records opened. Existing CERG work absorbs 80 percent of obligations. Three obligations need new clauses in existing standards. One obligation needs a board training program." Yusra opens six Control Change Records before end of day. Each has the source reason, affected environments, affected asset classes, implementation deadline (mapped to the regulatory clock), required evidence, and reporting metric target. CCR-NIS2-006 (board accountability) gets the 90-day deadline. CCR-NIS2-001 through 004 (operational measures) get the 180-day deadline. CCR-NIS2-005 (full evidence readiness) gets the 365-day deadline. Over the next two weeks, Aisha drafts implementation designs. The supply-chain gap requires a new clause in CERG-PRC-TPRM-001 requiring explicit flow-down language in vendor contracts. The cryptography gap requires a one-paragraph addendum to CERG-STD-CR-001 §3 defining "state-of-the-art" with reference to NIST and BSI guidance. The board accountability gap requires a board cybersecurity training program documented in CERG-GOV-TRN-001 and a board-pack insert prepared by Yusra. Marco's validation plan for the incident reporting CCR is the most elaborate. He schedules a tabletop at day 100 that walks a real incident scenario through the 24-hour early warning, 72-hour notification, and 30-day final report. The tabletop is run by the standing IR team (Halberd has an internal IR function, not an external one) with CISO and General Counsel observing. The tabletop produces a control test result and a list of process gaps that go into the Program Improvement Register. By day 175, CCR-NIS2-001 through 004 are validated and closed. The board accountability CCR closes on day 88, three days before the deadline. The full evidence-readiness CCR closes on day 340 with the audit package ready for regulator review. For two obligations Halberd cannot fully meet by the deadline, the CEO signs a Risk Acceptance Memo with a remediation plan and a 90-day review date. The memos are time-bound, named-owned, and visible in reporting. They are not "exceptions hidden in email." They are exceptions with ownership and clocks. ### The key idea F-01 exists so that when an external authority changes the rules, the program has one flow to absorb the change without scattering the work across ad hoc projects. The flow produces: - One Control Change Record per obligation cluster (not one per control, not one per system). - One Conformance Scope Statement per CCR (what is in scope, what is out). - One Implementation Design per CCR (what changes in which standards, procedures, templates). - One Validation Plan per CCR (how Risk will test). - One Evidence Plan per CCR (what proves the obligation is met). - One Closure per CCR or one Risk Acceptance Memo if the obligation cannot be met by the deadline. The board never sees a "NIS2 project." The board sees the monthly regulatory-overlay line on the metrics dashboard. The dashboard is fed by the six CCRs. The CCRs are fed by the gap analysis. The gap analysis is fed by the regulatory text. The chain is traceable end to end in the evidence library. ## Operational outputs - 6 Control Change Records opened with conformance scope, implementation deadline, evidence plan, and reporting metric target. - 6 Implementation Design packages (updates to existing standards, procedures, and templates). - 6 Validation Plans and 6 Control Test Worksheets. - 1 tabletop exercise for the incident reporting CCR with named gaps fed to the Improvement Register. - 2 Risk Acceptance Memos for obligations that miss the regulatory deadline, with remediation plans and 90-day review dates. - 1 audit package with regulator-facing evidence indexed per NIS2 article. - 1 monthly regulatory-overlay line on the board metrics dashboard, traceable end to end to the source obligations. ## What this story does not cover - **Internal IR declaration.** The tabletop here is for validation, not for a real incident. See Story 6 for that. - **Audit response.** This story assumes a forward-looking regulatory obligation, not an auditor's request. See Story 3 for that. - **CERG Lite.** Halberd is a Standard team. See Story 8 for the small-team pattern. For the F-01 SLAs and decision logic, see [CERG-GOV-FLOW-001 §9](../../governance/CERG-GOV-FLOW-001_Cross-Pillar_Operational_Flows.md#9-flow-f-01--control-intent-to-implementation). For the gap-analysis pattern that justifies opening a CCR, see [CERG-GOV-RMF-001](../../governance/CERG-GOV-RMF-001_Risk_Management_Framework.md). For the audit-ready evidence model, see [CERG-GOV-AUD-001](../../governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md). ---