Control template: NIST Cybersecurity Framework 2.0

Status: Stable · Version: nist-csf-2/v1.0.0

A bundle of CALM control snippets covering the architecturally enforceable subset of the NIST Cybersecurity Framework 2.0 (NIST CSWP 29, February 2024). You copy these into your *.calm.json files on the nodes that are in scope for your firm's cybersecurity program.

Who NIST CSF applies to

CSF is voluntary but widely adopted by: - US federal agencies (mandated for FCEB agencies under OMB) - US federal contractors (often required via FAR / DFARS clauses) - Critical-infrastructure operators (energy, water, healthcare, finance) - State + local governments adopting it as a baseline - Enterprises using CSF as their primary cybersecurity framework (often instead of ISO 27001 in US-heavy markets) - Smaller firms using CSF as a "common language" with auditors, insurers, and customers

CSF 2.0 (Feb 2024) replaced CSF 1.1 and added the new Govern (GV) function alongside the existing Identify / Protect / Detect / Respond / Recover.

What this template covers

CSF 2.0 has 6 Functions, each broken into Categories and Subcategories. The architectural surface is concentrated in Protect (PR) and Detect (DE), with some Identify and Recover overlap.

CSF 2.0 Function	Architectural surface	Control alias
PR — Protect	Access control (RBAC)	`csf-access-control`
PR — Protect	Data security (encryption at rest + in transit)	`csf-data-security`

2 architectural controls covering the most-tested CSF surfaces. Governance subcategories (organizational context, risk strategy, roles + responsibilities) live in your CSF program documentation, not your CALM.

The "CSF-in-scope" pattern

A node is CSF-in-scope if it participates in your firm's cybersecurity program. Most production-touching nodes qualify. Tag those nodes:

{
  "unique-id": "core-platform",
  "node-type": "service",
  "name": "Core Platform",
  "metadata": {
    "csf-in-scope": true,
    "csf-tier": "tier-3-repeatable",
    "data-classification": "internal"
  }
}

CSF Tier (1 Partial → 2 Risk Informed → 3 Repeatable → 4 Adaptive) indicates the maturity level the firm has selected. This template's defaults assume Tier 2/3.

Infrastructure verification. ArchRails now verifies the following controls against your infrastructure at PR review time and during code generation (AWS): csf-data-security.

Control snippets

Copy each block under the controls key of the node it applies to.

PR — Access control (`csf-access-control`)

Per-node.

"csf-access-control": {
  "description": "NIST CSF 2.0 PR.AA-05 — access permissions, entitlements, and authorizations defined in a policy, managed, enforced, and reviewed.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/nist-csf-2/access-control",
      "config": {
        "control-id": "csf-access-control",
        "principle": "least-privilege",
        "allowed-roles": ["read-only", "operator", "admin"],
        "review-frequency": "quarterly",
        "privileged-access-jit-or-pam": true
      }
    }
  ]
}

PR — Data security (`csf-data-security`)

Per-node.

"csf-data-security": {
  "description": "NIST CSF 2.0 PR.DS — data-at-rest and data-in-transit protected. Maps to SP 800-53 SC-13 + SC-28.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/nist-csf-2/data-security",
      "config": {
        "control-id": "csf-data-security",
        "at-rest-algorithm": "AES-256-GCM",
        "in-transit-minimum-tls": ["1.2", "1.3"],
        "key-management": "hsm-or-kms-cmk",
        "key-rotation-days": 365
      }
    }
  ]
}

What the engine actually enforces

There is no CSF-specific cross-cutter — the engine has no "if csf-in-scope: true, require these controls" sweep. Enforcement is graph-driven: you attach a control where you want it enforced; the absence of an attach is opt-out by silence.

For the 2 CSF 2.0 controls above, here is the honest split:

Enforced via attestation (constraint engine)

Every snippet's config block is read by the constraint engine: presence / exact / enum / set_required / set_forbidden shapes are inferred from what you authored, and the agent's declared_pattern must satisfy them. This applies to TLS-version sets, allowed-role sets, key-rotation cadence, and the access-control principle.

Enforced via sensitivity-gated validators (separate path)

When a node declares data-classification as pii / phi / pci / confidential / restricted, a set of always-on architectural validators fires on changes to that node's code — independent of which CSF controls you've authored. These cover:

Secret detection — substantive enforcement against credentials inadvertently committed
Weak crypto — deprecated algorithms on sensitive-classified nodes (substantive enforcement for the PR.DS data-at-rest intent)
Authorization — sensitive nodes must have an authz layer (substantive enforcement for the PR.AA-05 access-control intent)
Edge protocol — plaintext protocols on edges touching sensitive-classified nodes (substantive enforcement for CSF PR.DS data-in-transit intent)
Sensitive fixture detection — real-looking sensitive literals committed to governed files
Retention — required retention windows on sensitive data stores

And the diff-walking AR-REL-008 validator fires on any outbound call from a CSF-scoped node to an external host that the node's allowed_connects doesn't declare — substantive enforcement for the supply-chain and data-security intents.

All checks are deterministic — pure function over your CALM JSON. The same constraint engine handles PCI DSS, GDPR, SOC 2, HIPAA, MiFID II, ISO 27001:2022, NYDFS Part 500, and any controls you author yourself.

Versioning

This is nist-csf-2/v1.0.0 — the first stable cut. Each surviving control has per-validator firing tests + cross-language coverage across 11 Tier A languages (Python, Java, C#, TypeScript, Go, Kotlin, Scala, Rust, Ruby, Swift, PHP). Future bumps: v1.x.y for additive controls and substantive validator coverage; v2.0.0 for breaking changes (control retired, semantics changed). Updates as authoritative guidance or enforcement priorities materially shift.

Out of scope for this template

Governance subcategories (GV.OC organizational context, GV.RM risk management strategy, GV.RR roles + responsibilities, GV.OV oversight) — process / organizational, not architectural.
CSF Profiles — Current vs. Target profile gap analysis is a program methodology, not architectural.
CSF Tiers — tier selection is an organizational maturity decision; the template surfaces the tier in metadata.csf-tier but doesn't enforce tier-specific control variants.
Underlying SP 800-53 controls in full — CSF subcategories map to 800-53 control families; deep 800-53 implementation testing is a separate (federal-specific) activity. If you need full SP 800-53 enforcement (FedRAMP, FISMA), that's its own template family.
Specific federal mandates (CMMC for DoD contractors, FedRAMP for cloud services to federal agencies) — separate frameworks with overlapping but distinct controls. Potential sub-templates.

For those surfaces, pair this template with your CSF program documentation.