Every framework document, policy, standard, procedure, operational package, template, workforce artifact, and adoption guide. Each page is rendered from markdown — download the source any time.
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.
DOCThe six phases map directly to the NIST RMF, with CERG pillar ownership assigned at each step:
Every flow in this document follows a consistent structure. When implementing a flow, use these conventions to ensure completeness.
DOCPrimary Pillar: Engineering Regulations: NERC-CIP · [CMMC](https://dodcio.defense.gov/CMMC/) · · NIST
DOCRisk 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.
DOCThe monthly operating review uses a standard agenda:
DOCThis 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.
DOCThe division of labor is deliberate and must stay clean.
DOCCERG'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?"
DOCA traceability gap exists when any of the following is true:
DOCIt 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).
DOCIt 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.
DOCIt 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.
DOCCERG procedures create records. Records become evidence. Evidence supports metrics, oversight, audits, and risk decisions.
DOCIt 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.
DOCPurpose: Track known STY-001 and governance compliance gaps across the CERG corpus. Owner: Governance Pillar Leader (Document Control)
DOCIt applies to every new or revised CERG policy, governance instrument, standard, procedure, plan, template, and operational package.
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.
DOCThis 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.
DOCCERG is modular, but it is not arbitrary. Some artifacts can be deferred safely. Others must travel together because they form an operating loop.
DOCCERG 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.
DOCIntent: Maintain an authoritative asset inventory. [CMX-001 §1](CERG-GOV-CMX-001_Compliance_Matrix.md)
DOCThis 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.
DOCThis 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.
DOCCERG 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.
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)
DOCIt 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.
DOCCERG-adopting organizations engage contractors for legitimate reasons:
DOC1. 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.
DOC2. 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.
DOCIt 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.
DOCCybersecurity teams have a single-point-of-failure problem that is worse than most knowledge-work functions for three reasons:
DOCIt applies to every CERG team member. Certifications are role-dependent; the training philosophy, cross-training expectation, and budget guidelines are universal.
DOCMost 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:
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.
DOCThis 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.
DOCCERG 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.
DOCThis 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).
DOCThis document adds the top-down layer. It does two things:
DOCFor 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.
DOCCERG is intentionally complete. That completeness can make the first hour difficult for a new reader. This document is the map.
DOCCERG is intentionally complete. That completeness can make the first hour difficult for a new reader. This document is the antidote.
DOCThis 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.
DOCMost cybersecurity work, outside of Security Awareness and Incident Response, falls naturally into one of three activities:
The organization recognizes the following identity classes. Controls in this standard apply to all classes; specific provisions are noted where they differ.
DOCCERG governs three categories of AI use. The requirements differ by category.
DOCIt 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.
DOCIt 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.
DOCThe three CERG pillars operate in CUI environments with the same structure as elsewhere, with adaptations for contractual compliance evidence.
DOCThis standard closes that gap. It applies to every in-scope asset that has data, configuration, or workload state worth recovering.
DOCThis 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.
DOCThe organization's email domains, including domains that are owned but not used to send mail, are configured with the three standard email authentication mechanisms.
DOCIt 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.
DOCThe 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.
DOCThe 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.
DOCOnboarding follows a fixed checklist. The output is a SIEM Onboarding Record per environment.
DOCThe 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.
DOCDISH 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.
DOCSix principles govern secure development in CERG.
The runbook covers every identity in the environment: human (employee, contractor), machine (system, service, agent), and vendor / third-party.
DOCWhen adversarial validation is conducted by an external firm rather than internal staff, the following requirements apply.
DOCCERG engagement with a project follows five phases. Not every project hits every phase, Section 4 names the carve-outs.
DOCThe Evidence Librarian maintains the evidence library. The exact platform may vary by adopting organization, but the structure is fixed.
DOCThis procedure establishes CERG's exposure management program — the discipline of understanding which weaknesses actually threaten the organization, not which ones a scanner reports.
DOCThis 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.
DOCPrinciple 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:
DOCThe 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.
DOCA 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.
DOCCERG uses a 5-tier vendor model that maps to the typical enterprise model. Business rating sets the baseline; CERG adjusts only via Section 4.
DOCThis 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.
DOCThis 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.
CERG does not replace Enterprise BCP. CERG supplies the cyber, risk, evidence, and control integrity layer that BCP needs.
DOCIt applies to every system, person, and process within the CUI boundary, and to every CUI subcontractor receiving CUI from the organization.
DOCThe 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.
DOCThis 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.
DOCIt 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).
DOCThis 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.
DOCSOX 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.
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)
DOC1. [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)
DOC1. [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)
DOC1. [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)
DOC1. [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)
DOCThis 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.
DOC1. [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)
DOC1. [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)
DOCEvery risk register entry has a single sentence, the Risk Statement, in this form:
DOC1. [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)
DOCStandardizes SBOM evidence collection for vendor-delivered software and internally-built artifacts. Supports CIP-013, CMMC SR.L2, EO 14028, and SOX ITGC evidence requirements.
DOC1. [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)
DOC1. [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)
DOCThe 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.
DOCThis 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.
DOC1. [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)
Incident Response (JF-ADJUNCT) — Respond to and investigate cybersecurity incidents.
DOCExecutive Leadership (JF-EXEC) — Set strategy, approve risk, report to board, lead the function.
DOCGovernance & Compliance (JF-GOVCOMP) — Own policy, compliance posture, risk register, and evidence; translate regulation into action.
DOCRisk Operations (JF-RISKOPS) — Maintain continuous visibility into organizational exposure; test controls; drive remediation.
DOCSecurity Engineering (JF-SECENG) — Design and build secure systems, platforms, and infrastructure.
DOCUse the workforce documents in this order:
DOCThis 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:
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
DOCJob 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)
name: Validation / CI error about: Report a CI validation failure or catalog error title: "[VALIDATION] <brief description>" labels: bug, validation assignees: ''
DOCThis guide gives humans and AI assistants a safe way to start CERG adoption without turning the full repository into an overwhelming rewrite project.
DOCname: Document improvement about: Suggest a change to an existing CERG document title: "[IMPROVE] <document ID or name>" labels: improvement assignees: ''
DOCname: New document proposal about: Propose a new CERG document (standard, procedure, template, etc.) title: "[NEW] <proposed document title>" labels: new-document assignees: ''
DOCThis guide is for people who are not GitHub users, do not write code, or just want to use CERG without learning developer workflows first.
DOCAn operating model for teams that need security to actually run.
DOCSample 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).
DOCThese 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.
DOCThis is a sample organization profile for a regulated electrical utility adopting CERG. It is provided as a reference example, not the default.
DOCCERG 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.
DOCCopy this prompt into an AI assistant when starting a small-team CERG adoption.
DOCThis 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).
DOCThis 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.
DOCWe pledge to act and interact in ways that contribute to an open, welcoming, diverse, and inclusive community.
DOCCERG is open source (CC BY 4.0) and contributions are welcome. This document explains how to contribute effectively.
DOCThis 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:
DOCYou just found CERG. You have a repo full of Markdown. What do you actually do on Monday morning?
DOCIf you find a vulnerability or security concern in the CERG framework itself (not in an organization that uses it), please report it responsibly:
DOCPriya arrives at 9 a.m. on Monday. Her first meeting is with Jordan at 9:30. By 10 a.m. she has:
DOCIt 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.
DOCThe work has to move fast. The CISO's question is: how does CERG absorb a regulatory change without breaking the program?