/sota-security-compliance

name: sota-security-compliance
description: >-
  State-of-the-art security & compliance engineering (2026) for the
  cybersecurity control frameworks and product-security regulations that drive
  architecture, code, and CI gates — not the organizational policy binder. Use
  when work must satisfy or be audited against NIST CSF 2.0, SP 800-53, SP
  800-171 / CMMC, the Secure Software Development Framework (SSDF, SP 800-218),
  FedRAMP, the EU Cyber Resilience Act (CRA), or ISA/IEC 62443
  (OT/ICS/embedded). Covers control-framework-as-code crosswalks (control →
  engineering mechanism → evidence), CUI boundaries, FIPS-validated crypto,
  SBOM + coordinated vulnerability disclosure + security-update obligations,
  secure-SDLC gates, and OT zones/conduits & security levels. Complements
  sota-privacy-compliance (personal data, GDPR, SOC 2, ISO 27001). Trigger
  keywords: compliance, NIST, CSF, 800-53, 800-171, CMMC, CUI, SSDF, FedRAMP,
  CRA, Cyber Resilience Act, SBOM, VEX, CVD, IEC 62443, OT security, ICS,
  security levels, zones and conduits, FIPS 140.

SOTA Security & Compliance Engineering

The engineering half of cybersecurity regulation: how to make a control framework a property of the codebase, pipeline, and infrastructure rather than a binder of policy documents. A control that lives in a schema, an IAM policy, a CI gate, or a signed SBOM survives staff turnover and an assessor's sampling; a control that lives in a wiki page does not.

This skill is the **security/regulation counterpart** to `sota-privacy-compliance` (which owns personal-data lifecycle, GDPR, SOC 2, ISO 27001). It owns the cybersecurity *control frameworks* and *product-security regulations* — NIST CSF 2.0, SP 800-53, SP 800-171 / CMMC, SSDF (SP 800-218), FedRAMP, the EU Cyber Resilience Act, and ISA/IEC 62443 for OT.

> **This is engineering guidance, not legal, certification, or assessment advice.** > Framework versions, regulation dates, and conformity routes move — every date > and version below was verified against a primary source (NIST CSRC, EUR-Lex, the > Federal Register, ISA/IEC) as of **July 2026** and each rules file cites it. > Re-verify before you rely on a deadline, and route scoping/attestation decisions > (is this system in CUI scope? which CMMC level? is our product "important" under > the CRA?) to your assessor, sponsor, or counsel. This skill tells you how to > build the machinery those decisions require.

The boundary — what this skill does and does not own

Every framework here mixes **engineering controls** with **organizational controls**. This skill owns only the first; it names the second and routes it out, so you neither skip it nor pretend code can satisfy it.

| In scope (drives code / architecture / gates) | Out of scope (org/governance — note & route out) | |---|---| | System/authorization boundary definition, segmentation, zones & conduits | Security-awareness training programs, phishing simulations | | FIPS-validated crypto selection; encryption at rest/in transit | Personnel screening, background checks, HR onboarding | | Audit-log families, retention, tamper-evidence | Physical & environmental security (badges, data-center access) | | SBOM generation, coordinated vuln disclosure, signed update channels | Risk-committee structure, CISO/DPO roles, board reporting | | Secure-SDLC gates (SAST/DAST/provenance) as CI checks | Written policy authorship, management review cadence | | Control-as-code mappings + machine-generated evidence | Legal interpretation, contract clauses, insurance |

When a framework requirement is organizational, the finding is *"owned by GRC/HR/ legal — here is the engineering hook (an event, an export, an enforcement point) that makes it auditable,"* not silence and not a code change that pretends to cover it.

**Related skills — reference, do not duplicate:**

• `sota-privacy-compliance` — personal-data lifecycle, GDPR/CCPA/HIPAA/PCI, SOC 2 & ISO 27001 audit-ready engineering, breach clocks, data residency
• `sota-devsecops` — the actual pipeline: SLSA/provenance, SBOM tooling, signing, dependency scanning (SSDF's PS/PW practices live here)
• `sota-secrets-management` — key management, FIPS-validated KMS, rotation
• `sota-identity-access` — NIST 800-63 assurance levels, MFA, RBAC/ABAC (the IA/AC control families)
• `sota-detection-engineering` — detective controls, NIST 800-61 incident response (the DE/RS/RC functions)
• `sota-network-security` — segmentation depth, zero-trust, egress control (SC family, 62443 conduits)
• `sota-sandboxing` / `sota-kubernetes` / `sota-cloud-infrastructure` — the CM/SC hardening controls in practice
• `sota-threat-modeling` — the risk analysis that sets 62443 target Security Levels and DPIA/PIA scope

BUILD mode

When designing or implementing a system that must satisfy a framework:

1. **Scope the boundary first.** Before controls, decide what is *in* the assessed system — the authorization boundary (FedRAMP), CUI enclave (800-171/CMMC), or zone (62443). A tight, honest boundary is the cheapest control decision you will make; a flat network drags the whole estate into scope (rules/02, rules/05). 2. **Pick the framework spine, then crosswalk down.** Use NIST CSF 2.0 as the organizing map, then bind each outcome to a concrete mechanism from an existing sota-* skill and record it as code (rules/01). Do not re-implement encryption, RBAC, or logging here — reference where they already live. 3. **Encode controls as gates, not prose.** Encryption-required, FIPS-crypto-only, boundary-egress-deny, SBOM-present, no-known-exploitable-vulns-at-release become policy-as-code and CI checks that fail the build (rules/01 §evidence, rules/03). 4. **Build product-security obligations in from day one** where the CRA/62443 apply: SBOM in CI, a coordinated-vulnerability-disclosure intake, a signed update channel, and a defined support period are architecture, not paperwork — brutal to retrofit (rules/