NIST SP 800-53 — Security and Privacy Controls for Information Systems

Scope: the unified catalogue of security and privacy controls referenced by FISMA, FedRAMP, DoD ICD 503, and many state RAMPs. Currently at Revision 5 (with annual errata).

The annotation is compliance: [NIST_800_53]. It almost always travels with FISMA, the statute that requires the controls:

compliance: [FISMA, NIST_800_53]

FedRAMP is not a class here. It is the authorization program that selects a baseline from this catalogue and has a 3PAO assess it — a fact about who signed off on your service, not about what the data is. The regulatory vocabulary is closed (axon-T1214) and holds sources of obligation: statutes and control standards. Declare FISMA + NIST_800_53, and record the baseline where your assessment programme records it. See Regulatory classes for the full list.

This page focuses on the AXON-enforceable subset — the families where the language has direct grammar, runtime, or evidence support. The full 800-53 catalogue has 20 families; AXON substantively enforces 8 of them.

Family-by-family map

AC — Access Control

Control	What it requires	AXON enforcement
AC-2 — account management	Lifecycle of system accounts	OIDC layer (v2.0.0); audit row on every account event
AC-3 — access enforcement	Authorisation per policy	Runtime — every emission to a NIST-tagged endpoint is checked against requires: capabilities
AC-4 — information flow	Authorised flows only	Compile time — a flow that lowers a tagged type to an untagged endpoint is rejected
AC-5 — separation of duties	Tasks split across roles	mandate excludes_requester: true — see SOX page
AC-6 — least privilege	No wildcard caps	Compile time — wildcard requires: on NIST-tagged endpoints rejected

AU — Audit and Accountability

Control	What it requires	AXON enforcement
AU-2 — audit events	Catalogue of auditable events	Runtime — closed category: enum, always-on
AU-3 — audit record content	What each row contains	Runtime — (actor, action, target, timestamp, source_ip, decision) always present
AU-6 — audit review + analysis	Regular review	Operational; AXON exports via axon-enterprise diagnostics gate
AU-9 — protection of audit info	Tamper-evidence	Runtime — hash-linked + signed chain (v1.19.1 FIPS-friendly)
AU-10 — non-repudiation	Originator binding	Runtime — actor subject is the OIDC-verified identity, not a service principal
AU-12 — audit generation	Selectable events	Compile time — categories closed; runtime always emits

SC — System and Communications Protection

Control	What it requires	AXON enforcement
SC-7 — boundary protection	Network egress controls	Compile time — tool with network effect requires explicit transfer_boundary: on NIST endpoints
SC-8 — transmission integrity/confidentiality	In-flight protection	Runtime — wss:// + TLS 1.2+ required
SC-12, SC-13 — crypto key mgmt	FIPS-validated modules	Runtime — selects FIPS 140-3 validated configuration when tagged
SC-23 — session authenticity	Session-level binding	Compile time — socket requires protocol: (a typed session); runtime verifies duality
SC-28 — protection of info at rest	At-rest encryption	Compile time — NIST-tagged axonstore requires encryption: at_rest

SI — System and Information Integrity

Control	What it requires	AXON enforcement
SI-4 — system monitoring	Continuous monitoring	Runtime — v2.0.0 observability layer
SI-7 — software/firmware/info integrity	Detection of unauthorised changes	Runtime — hash-linked audit chain
SI-10 — info input validation	Validate inputs	Compile time — v2.0.0 D4 body schema validation activates on NIST-tagged endpoints with refined types
SI-15 — info output filtering	Validate outputs	Compile time — v2.0.0 D5 output schema validation

IR — Incident Response

Control	AXON enforcement
IR-4 — incident handling	Structured incident records flow to the compliance event store
IR-5 — incident monitoring	The v2.0.0 observability layer surfaces incident metrics
IR-6 — incident reporting	Records are consumable by US-CERT-equivalent tooling
IR-8 — incident response plan	Operational

CM — Configuration Management

Control	AXON enforcement
CM-2 — baseline configuration	The AXON source IS the baseline; declared in version control
CM-3 — configuration change control	Configuration changes emit system:config_change audit rows
CM-5 — access restrictions for change	Endpoints that mutate config require elevated capabilities
CM-7 — least functionality	Operational
CM-8 — system component inventory	Operational

CP — Contingency Planning

Control	AXON enforcement
CP-9 — system backup integrity	The audit-chain hash is a self-verifying integrity proof of the data plane
CP-10 — system recovery + reconstitution	The hash chain + audit-log restore allow point-in-time reconstitution

IA — Identification and Authentication

Control	AXON enforcement
IA-2 — identification + authentication (org users)	Runtime — OIDC layer, MFA enforced per the v2.0.0 policy
IA-5 — authenticator management	Operational
IA-8 — identification + authentication (non-org users)	OIDC federation; tenant-isolated principal namespace

Families AXON does NOT enforce substantively

These families are organizational, physical, or operational; AXON has no language surface for them. They are documented in the SSP and audited externally:

• AT — Awareness and Training
• CA — Assessment, Authorization, and Monitoring
• MA — Maintenance
• MP — Media Protection
• PE — Physical and Environmental Protection
• PL — Planning
• PM — Program Management
• PS — Personnel Security
• PT — PII Processing and Transparency (partially — see GDPR / Privacy resources)
• RA — Risk Assessment
• SA — System and Services Acquisition
• SR — Supply Chain Risk Management

Common patterns

Pattern 1 — Moderate-baseline audit-trail evidence

flow GenerateNIST_AU_Evidence(month: Month) -> EvidencePackage {
    step Collect {
        given: month
        retrieve: AuditLog where tag = "NIST_800_53" AND month
        output: List<AuditRow>
    }
    step Sign {
        given: Collect.output
        ask: "Sign the bundle + emit chain-head proof"
        output: EvidencePackage
    }
    return Sign.output
}

Pattern 2 — AC-6 least-privilege binding

mandate StrictLeastPrivilege
    requires: capability("case.read")    # specific, not wildcard
    on_breach: raise

axonendpoint CaseLookup {
    flow: CaseLookupFlow
    method: GET
    route: "/v1/cases/{case_id}"
    compliance: [NIST_800_53]
    mandate: StrictLeastPrivilege
}

Pattern 3 — SC-7 explicit egress boundary

tool ExternalLookup {
    provider: external_search
    effects: <network>
    transfer_boundary: ISA_2024_017      # required on NIST endpoints
}

When NOT to use NIST 800-53

• Pure commercial customers with no government nexus. SOC2 + framework-specific tags are usually enough.
• NIST 800-171 systems (federal contractor data). Use the shorter 800-171 catalogue instead; AXON's nist_800_171 resource is planned.
• Non-US frameworks. ENS (Spain), IRAP (Australia), CSE (Canada) have separate catalogues; some map to 800-53 + an addendum.

For the per-baseline selection of which 800-53 controls apply, see axon://compliance/fedramp (Low/Moderate/High).