/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

Purpose

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`](../sota-privacy-compliance/SKILL.md) (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`](../sota-privacy-compliance/SKILL.md) — personal-data lifecycle, GDPR/CCPA/HIPAA/PCI, SOC 2 & ISO 27001 audit-ready engineering, breach clocks, data residency
• [`sota-devsecops`](../sota-devsecops/SKILL.md) — the actual pipeline: SLSA/provenance, SBOM tooling, signing, dependency scanning (SSDF's PS/PW practices live here)
• [`sota-secrets-management`](../sota-secrets-management/SKILL.md) — key management, KMS envelope encryption, rotation (the FIPS 140-3 validated-module requirement is this skill's [rules/02](rules/02-nist-800-53-171-cmmc-fedramp.md) §4)
• [`sota-identity-access`](../sota-identity-access/SKILL.md) — NIST 800-63 assurance levels, MFA, RBAC/ABAC (the IA/AC control families)
• [`sota-detection-engineering`](../sota-detection-engineering/SKILL.md) — detective controls, NIST 800-61 incident response (the DE/RS/RC functions)
• [`sota-network-security`](../sota-network-security/SKILL.md) — segmentation depth, zero-trust, egress control (SC family, 62443 conduits)
• [`sota-sandboxing`](../sota-sandboxing/SKILL.md) / [`sota-kubernetes`](../sota-kubernetes/SKILL.md) / [`sota-cloud-infrastructure`](../sota-cloud-infrastructure/SKILL.md) — the CM/SC hardening controls in practice
• [`sota-threat-modeling`](../sota-threat-modeling/SKILL.md) — 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/02-nist-800-53-171-cmmc-fedramp.md), [rules/05](rules/05-iec-62443-ot-ics.md)). 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](