Sota Security Compliance

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.

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/04, rules/05).
5. Emit evidence as a byproduct. Every control's enforcing system should produce its own proof (a CI log, a signed attestation, an IaC diff, a KSI feed). If proving a control needs a screenshot, the control runs only at screenshot time (rules/01).
6. Know your regime before architecture freezes (rules/02–05): CUI → 800-171/ CMMC + FIPS crypto + boundary; US-gov cloud → FedRAMP + 800-53 baseline; EU-market product → CRA; OT/industrial/embedded → 62443.

AUDIT mode

When reviewing a codebase/infrastructure against a framework:

Process: (1) Establish the applicable framework(s) and the assessed boundary (rules/02 §scope). (2) Obtain or build the control crosswalk — control → claimed mechanism → evidence source (rules/01). (3) For each control, verify the mechanism actually enforces it and the evidence is machine-generated, not asserted — test the gate, read the policy-as-code, sample the log. (4) Separate engineering findings from organizational ones (the boundary table above) so each lands with the right owner. (5) Map findings to the framework's control IDs so they are traceable to an assessor's language.

Severity conventions:

Finding format:

[SEVERITY] <title>
Location: <file:line / pipeline stage / IaC resource / boundary component>
Framework: <CSF 2.0 Subcat / 800-53 control / 800-171 req / SSDF task / CRA Annex I / 62443 FR — as applicable>
Owner: <engineering | GRC/org — per the boundary table>
Issue: <control missing / claimed-not-enforced / evidence-not-generated>
Impact: <assessment failure, contract loss, CRA non-conformity, incident exposure>
Fix: <concrete engineering remediation, or the hook if org-owned>
Evidence: <how you verified — the gate you ran, the log you sampled, the policy you read>

Group findings by control family/function, not by file — that is how assessors and sponsors read them.

Rules index

Top 10 non-negotiables

1. Scope the boundary before the controls. The assessed system's edge — authorization boundary, CUI enclave, or 62443 zone — is decided, drawn, and enforced by segmentation before control work starts. A flat network makes the whole estate in scope and every control 10× more expensive.
2. One control set, many frameworks. Build the mechanism once and crosswalk it; CSF, 800-53, 800-171, SOC 2, ISO 27001, and CRA overwhelmingly ask for the same engineering. Per-framework silos duplicate work and drift.
3. A control is the mechanism, not the policy. Every control maps to a running system that enforces it. "We have a policy" with no enforcing mechanism is a finding, not a control.
4. Evidence is a byproduct or it is theater. Each control's enforcing system produces its own proof — CI log, signed attestation, IaC history, KSI feed. Screenshots pasted before fieldwork are the smell of a control that runs only then.
5. FIPS-validated crypto where the regime demands it. CUI, FedRAMP, and many OT contexts require validated modules (FIPS 140-3), not merely "encryption." A home-rolled or non-validated cipher protecting CUI is a critical finding.
6. Ship no known exploitable vulnerabilities. Under the CRA (and as basic hygiene) release gates block known-exploitable vulns; a monitored SLA drives remediation within the support period. "We'll patch it later" is a non-conformity, not a backlog item.
7. SBOM, CVD, and a signed update channel are architecture. For any product under the CRA/62443, generate an SBOM in CI, publish a coordinated-vulnerability- disclosure intake, and sign updates over a maintained channel — designed in, not bolted on at audit time.
8. Secure-SDLC practices are gates, not intentions. SSDF PW/PS practices — threat modeling, SAST/DAST, provenance, protected repos, signing — are CI checks that fail the build. A signed attestation whose practices aren't enforced is the finding assessors hunt.
9. Reporting clocks are wired into on-call, not lawyers. Where a regime imposes a 24h/72h reporting clock (CRA, NIS2, DORA), detection and the reporting workflow are engineered and rehearsed; a clock that depends on someone noticing is already breached.
10. Separate engineering findings from organizational ones. Every control lands with the owner who can fix it. Blaming code for a training gap — or asking GRC to fix a missing CI gate — wastes both and leaves the real control unbuilt.