SYSTEM CONTROL PROFILE TEMPLATE

Per-System Control Implementation · Evidence · Validation · Review State

Table of Contents

1. Purpose and Use
2. Template Instructions
3. YAML Structure
4. Fill-In Template
5. Review and Approval
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.
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.
5. Link each control entry to evidence that is independently verifiable under CERG-GOV-AUD-001.
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.

3. YAML Structure

Minimum structure:

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.

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

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

Revision History

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

Source: templates/CERG-TMPL-SCP-001_System_Control_Profile_Template.md · Download .md · View on GitHub