DOCUMENT CATALOG AND NAMING CONVENTION

Authoritative Inventory · ID Scheme · Roadmap

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
2. Naming Convention
3. Document Types
4. Authority and Status Lifecycle
5. Authoritative Catalog (V1)
6. Cross-Reference Rules
7. Artifact Roadmap (V1.x → V2)
8. Document Control

1. Purpose and Scope

CERG-POL-001 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-<TYPE>-<DOMAIN>-<NNN>

Where:

Files are named <DocumentID>_<Short_Title>.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)

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

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, SOX). When in doubt, prefer PRC and add templates as appendices.

4. Authority and Status Lifecycle

Approval authority follows CERG-POL-001 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:

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.

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.

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:

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:

Evidence Retention After Retirement

Retired documents are not deleted. They are retained in the repository for the following purposes and durations:

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

5.2 Framework, Operating Model, and Cross-Cutting Instruments

5.3 Standards

5.4 Procedures

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 §9. The -002 ID is preserved to avoid renumbering existing references. The -001 slot is reserved for future use.

5.5 Plans / Operational Packages

5.6 Templates

| CERG-TMPL-SAAS-001 | SaaS Evidence Collection Checklist | Governance Pillar Leader | Approved | | CERG-TMPL-SBOM-001 | 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)

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.

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

Revision History

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

Source: governance/CERG-GOV-CAT-001_Document_Catalog_and_Naming_Convention.md · Download .md · View on GitHub