Compliance, Certification & Governance

An AI data center earns nothing until someone is allowed to put a regulated workload on it. The chapters before this one decide whether the machine is secure; this one decides whether it is sellable — whether a bank, a hospital network, a defense prime, an EU regulator, or a sovereign-AI program can lawfully place its data and its models inside your walls. Compliance is the layer that converts an engineering artifact into a commercial one, and it does so by imposing constraints that reach all the way back to siting, staffing, and the wiring of your audit logs. The recurring error is to treat it as a post-commissioning paperwork exercise. The framework portfolio you target is an upstream decision — as upstream as the workload archetype in Chapter 1.1 — because it dictates where data may reside, who may administer the silicon, and what evidence you must be generating continuously from the day the first GPU is energized.

What follows is the compliance and governance map. The four framework layers come first — the commercial-trust baseline, the new AI-governance layer, the federal stack, and the sector regimes — with exactly how they differ in what they certify and what they cost. NERC CIP appears here as a portfolio member, with a pointer to its canonical engineering home. Then the case for compliance-as-code (OSCAL, FedRAMP's Key Security Indicators, continuous control monitoring) as the only model that survives at AI-factory scale, and the control crosswalk that lets one body of evidence satisfy many frameworks. The three that are genuinely hard at the physical layer close the chapter: audit logging at fleet scale, data residency and sovereignty, and the sector-specific overlays that customers bring with them.

A common mistake is to imagine compliance as a ladder — SOC 2, then ISO, then FedRAMP, each a higher rung. It is not a ladder; it is four orthogonal layers, and a serious AI campus needs a chosen subset of each, driven by the union of its target customers' mandates. The layers are: the commercial-trust baseline that every B2B buyer expects; the AI-governance layer that is brand new and rising fast; the federal/government stack that gates public-sector revenue; and the sector regimes that ride along with regulated tenants. Each certifies a different thing, and confusing them is how operators over-spend on a stamp no customer asked for while missing the one that would have unlocked the contract.

SOC 2 (AICPA) is an attestation, not a certification: an independent auditor opines on whether controls against the common criteria for Security and any additional Trust Services categories scoped into the engagement operated effectively. A Type II label alone does not establish availability, processing integrity, confidentiality, or privacy coverage; buyers must inspect the report's scope and system boundary. ISO/IEC 27001 is a true certification against a normative information-security-management-system (ISMS) standard, issued by an accredited body, valid three years with annual surveillance audits — the global lingua franca, expected by European and Asian buyers. They overlap heavily in substance but differ in form: SOC 2 produces a detailed report a customer reads; ISO 27001 produces a certificate a customer trusts. Most operators serving a global market carry both, and the crosswalk between them is the first place compliance-as-code pays off.

The layer that did not exist three years ago is AI governance. ISO/IEC 42001:2023 — the world's first certifiable AI-management-system standard — moved through 2025 and into 2026 from novelty to procurement requirement: by mid-2026 the question "are you ISO 42001 certified or implementing it?" is a routine line item in EU enterprise AI-vendor RFPs and increasingly common in North American ones. The EU AI Act is the regulatory teeth: GPAI-model obligations became applicable 2 August 2025 and the Commission’s enforcement powers over GPAI providers applied from 2 August 2026 — Article 101 caps those fines at €15 million or 3% of worldwide annual turnover, whichever is higher, alongside model-recall powers; the €35 million / 7% ceiling is Article 99's, for prohibited practices, and does not attach to GPAI supervision — but the 2026 simplification ("digital omnibus") package, politically agreed in May 2026 and approved by the Council on 29 June 2026, deferred the high-risk-system obligations: stand-alone (Annex III) systems comply from 2 December 2027, and AI embedded in regulated products from 2 August 2028 (European Commission; Council of the EU, 2026). Determine whether the operator is an infrastructure host, model provider or system provider/deployer before assigning AI Act duties. Contracts can flow down logging and traceability work; ISO 42001 certification and infrastructure hosting alone establish neither the legal role nor conformity.

Use current editions for the assertion being bought. TIA-942-C, released in May 2024, is a data-centre infrastructure standard, including physical-security considerations; it does not certify weight confidentiality. ISO/IEC 27001:2022 with Amendment 1:2024 governs the scoped information-security management system. The amendment addresses climate-action considerations, not a new AI security level. Keep the AI-management-system and AI Act role assessments separate. The AI Act, Articles 111(3) and 113, consolidated 27 July 2026, distinguishes GPAI obligations from 2 August 2025, Commission enforcement from 2 August 2026, and the 2 August 2027 transition for pre-existing models. High-risk-system duties use their own 2 December 2027 or 2 August 2028 date; Articles 99 and 101 have different sanctions and regulated conduct.

The US federal layer is where compliance stops being a report and becomes a machine-readable, continuously-validated obligation — and 2025–2026 is precisely the inflection. FedRAMP 20x is the modernization of the federal cloud-authorization program, and it inverts the old model. The 20x Phase 2 pilot used 56 Low and 61 Moderate Key Security Indicators (KSIs). Those are historical pilot counts. Under the 2026 20x rules SDR-CSO-FRR and SDR-CSX-KSI, providers supply human-readable and JSON Security Decision Records, including KSI explanations, verification and validation. Automation supplies repeatable evidence; human explanations and independent assessment remain. Under the Consolidated Rules for 2026, the 2026 Rev5 SDR-CSO-FRR rule also requires a Security Decision Record in human-readable and JSON formats for Classes B-D: obtain from 1 January 2027, maintain from 1 August 2027; the grace period ends at the first independent assessment started after 1 August 2027. The 20x record rule lists obtain from 4 July 2026, maintain from 1 January 2027, and grace ending at the first assessment started after that January date. If you intend to serve federal AI workloads, compliance-as-code is no longer a sophistication choice — it is the entry condition.

CMMC (Cybersecurity Maturity Model Certification) governs defense-industrial-base contractors handling Controlled Unclassified Information. The long rulemaking finally closed: the 48 CFR final rule (DFARS Case 2019-D041) published 10 September 2025, and Phase 1 of the rollout began on that rule's 10 November 2025 effective date; the Phase 2 third-party-certification requirement — which would have made CMMC Level 2 mandatory for CUI-handling contracts from 10 November 2026 — was suspended on 13 July 2026 pending a 60-day review. Phase 1 self-assessment obligations remain in force; the Level 3 and full-implementation milestones are paused with it (DoD/DoW, 2025–2026). For an AI campus chasing defense workloads, CMMC Level 2 means implementing the 110 NIST SP 800-171 Rev 2 requirements across systems that process, store, or transmit CUI and preserving evidence for the applicable assessment. US-person access restrictions come from contract terms or export controls, while physical separation is one way to scope the CUI environment rather than a Level 2 mandate; those choices ripple into staffing, network segmentation (Chapter 11.7), and tenant isolation (Chapter 11.6).

Read the rightmost column as the real cost. The audit fee is only one part of the design burden each framework imposes — and the burdens are not additive in a friendly way. A campus targeting the full portfolio inherits the union of every applicable constraint: the 110 NIST SP 800-171 Rev 2 requirements assessed by CMMC Level 2, machine-readable continuous evidence from FedRAMP, GDPR transfer mechanisms such as adequacy decisions, SCCs, or BCRs, DORA operational-resilience duties for financial workloads, and a formal ISMS from ISO 27001. Better to identify the binding portfolio your target book of business actually requires, then reuse evidence through a crosswalk that checks each requirement’s scope and sufficiency, rather than chasing every stamp or running parallel programs that each re-collect the same logs.

NERC CIP — the Critical Infrastructure Protection standards — is the one framework on this list whose engineering substance lives elsewhere in the guide, and we are careful here to place it rather than re-derive it. The full treatment of substation ownership, transmission interconnection, and the CIP registration analysis prompted when an AI campus becomes a transmission-connected load or operates on-site generation is the canonical material of Chapter 4.3. Its place in the compliance portfolio is the point here: multi-hundred-megawatt campuses are grid actors for planning, because synchronized load loss materially affects reliability — a shift NERC made explicit after multi-hundred-megawatt load-loss events (the 2024 Virginia event saw six successive 230 kV line faults over 82 seconds, roughly 1,500 MW of total coincident load reduction, and a ~1,260 MW sustained step at the third voltage depression, one of the load-loss events that informed NERC's rare May 2026 Level 3 alert). CIP obligations, though, attach to a registered function and in-scope BES cyber systems, not to campus MW. Only where the operator performs a registered function and has in-scope BES Cyber Systems do CIP's cyber-physical asset-inventory, access-control, and incident-reporting obligations become mandatory and audited — a distinct, sometimes-surprising line item in the governance budget. The grid-interactive engineering that prompts that analysis is in Chapter 4.10.

At AI-factory scale, manual evidence alone becomes difficult to keep current. A point-in-time audit that samples controls once a year cannot describe a fleet of tens of thousands of accelerators whose firmware, configuration, and tenancy change weekly. The federal program saw this first, which is why FedRAMP 20x is built on continuous validation with automated and human evidence, alongside independent assessment — and why OSCAL (the NIST Open Security Controls Assessment Language) is the connective tissue. OSCAL expresses controls, implementations, and assessment results in machine-readable JSON/XML/YAML, so implementations and assessments share a structured format; the format itself neither collects evidence nor proves a control. The decision an operator faces is whether to adopt this model from day one or to bolt it on later. It is nominally reversible — you can retrofit — but the retrofit is punishing: every control, every telemetry source, and every audit-log pipeline that was wired for human consumption must be re-instrumented for machine consumption, and the institutional habit of essay-writing is hard to unlearn.

The mechanism that makes this tractable is the control crosswalk: a single mapping from one body of collected evidence to the requirements it can support. A control that proves "all administrative access is MFA-gated and logged" can support a SOC 2 CC6 criterion, an ISO 27001 Annex A control, a FedRAMP KSI, and a CMMC SP 800-171 requirement simultaneously, but each still needs its own scope, period, exceptions and assessor sufficiency decision. Collect it once, in OSCAL, and the crosswalk fans it out to every report. Run separate programs and you collect it four times, with four chances to drift out of sync. The crosswalk is where compliance-as-code converts from a federal obligation into a cost-saving discipline for the entire portfolio.

The newest demand on the compliance program is that hardware provenance is now auditable. Federal authorizers and serious enterprise buyers no longer accept "we bought it from a reputable vendor"; they want the evidence chain — and you cannot reconstruct it after commissioning. The OCP S.A.F.E. program is the emerging standard here: an Open Compute Project framework under which device vendors commission an accredited Security Review Provider (ten approved SRPs on the program’s provider list as of 16 September 2026 — Atredis Partners, IOActive, and NCC Group among the first) to produce a standardized short-form firmware-security audit that travels with the device on the OCP Marketplace. The value to an operator is de-duplication: instead of every buyer re-auditing the same BMC firmware, the conformance review is performed once and consumed many times — and from 2026-10-01 a S.A.F.E. review must itemize its S.O.L.I.D. requirement gaps in the long-form report, so coverage against the per-product-type requirements is visible to the operator inheriting the review rather than implied by the endorsement.

The decision for an operator is whether to make these artifacts first-class in the compliance program or to treat them as security trivia. Get it wrong and the bill arrives late and large: a federal authorizer or a sovereign-AI customer asks for the firmware provenance chain, the SBOM, and the root-of-trust attestation history for the accelerators, and an operator who did not capture them at receiving and burn-in (Chapter 13.8) cannot produce them. The provenance must be captured as the hardware enters the building, bound to a hardware root of trust, and carried in the same OSCAL evidence store as everything else — because by 2026 it is no longer a security nicety, it is a line item in the authorization package.

Every framework on the list demands an audit trail, and at AI-factory scale the audit trail is itself an engineering problem. The naive read of "log everything" is unaffordable and unsearchable: a 100,000-GPU campus generates control-plane, data-plane, OOB-management, physical-access, and environmental telemetry at a volume that overwhelms a conventional SIEM. The decision is what to log immutably, how long to retain it, and where it may physically reside — and the last is set by a tenant's contract or export-control overlay and, for EU personal data, GDPR transfer mechanisms. A US-federal contract may require logs retained and queryable on US soil; where personal-data logs subject to GDPR are transferred to a third country, an applicable Chapter V route is needed; contractual location/access restrictions apply separately; defense CUI logs stay inside the contractually defined CUI scope and any export-controlled access boundary. The single-pane SIEM fantasy fractures along the same jurisdictional lines the rest of the campus does.

The required property is retention and integrity appropriate to the applicable obligation: audit records protected against unauthorized alteration and deletion, with detectable changes and preserved originals where the regime permits an audit-trail method, because in an insider-threat or incident scenario the logs are the evidence (Chapter 11.9). Write-once storage, cryptographic chaining, and out-of-band collection to an enclave the production operators cannot reach are candidate mechanisms; a hash chain alone detects changes but does not prevent deletion. The forward link is that these same audit logs are the raw material for detection and incident response — the security-operations treatment is Chapter 11.12, and the unified incident-command model that consumes them is in Chapter 14.11.

Residency and sovereignty are where compliance reaches back and rewrites the site plan. Sovereignty has three distinct meanings that diverge, and most operators conflate them. Physical residency means the data is stored and processed within a defined jurisdiction; it is the easiest to satisfy and the weakest guarantee. Operational sovereignty means the people and systems that administer the data are also within the jurisdiction — no foreign-national administrator, no remote operations center in another country, no support engineer who can pull data across a border. Control-of-stack sovereignty is the strongest: no foreign vendor, government, or court can compel access to the data, regardless of where it physically sits — which can fail even when physical residency holds, if the hardware, software, or operator is subject to a foreign jurisdiction's extraterritorial reach. Empirical study of hundreds of nominally-sovereign non-US data centers found that physical residency routinely coexists with deep stack-level dependencies that defeat the sovereignty the customer thought they bought.

The consequence is a fork at siting and procurement. A customer buying physical residency can be served from a leased hall in-region. A customer buying operational sovereignty forces you to staff the campus with in-jurisdiction personnel and route all administration through in-region operations — which can collide with the US-person access restrictions a defense contract or export-controlled data imposes if you are trying to serve both books from one site. A customer buying control-of-stack sovereignty may reject your hardware vendor, your hypervisor, or your remote-management path entirely. Export controls compound this: the 2025 AI Diffusion Rule was rescinded before its compliance date in May 2025; as of August 2026, BIS country, end-user, and end-use controls govern whether the same accelerators are routine in one jurisdiction and license-gated or denied in another. Sovereign-AI demand — national programs that require the entire stack be domestically controlled — is a fast-growing slice of the market, and it is the one segment where compliance, not engineering, is the binding constraint.

The sector regimes ride along with the tenant and overlay the baseline. HIPAA (US healthcare) requires a Business Associate Agreement when the provider acts as a business associate; the current Security Rule makes encryption an addressable implementation specification for e-PHI. PCI DSS (payment-card data) uses the validation method set by the compliance-accepting entity, and eligible service providers can use SAQ D instead of a QSA-led ROC. DORA (EU financial sector) subjects an ICT provider to direct ESA oversight only after designation as critical, while financial-entity contracts impose applicable operational-resilience and third-party-risk requirements on other providers. NIS2 can attach to an operator’s own covered service: Implementing Regulation (EU) 2024/2690 names data-centre service providers among the covered digital-infrastructure entities, so determine entity/service definitions, size and exceptions under Directive Articles 2–3, and jurisdiction under Article 26 before assigning management accountability, supplier requirements, and an incident-notification path to a national authority (the response process is Chapter 11.12). FINRA/SEC records rules require either compliant WORM storage or an electronic recordkeeping system meeting the audit-trail alternative that amended Rule 17a-4 introduced (87 FR 66412; effective 3 January 2023, compliance date 3 May 2023) — pick the mechanism the tenant's regime actually calls for instead of forcing WORM media by reflex. The operator carries these duties only when its service meets a regime's applicability test or a tenant contract flows them down, adding encryption, retention, or BCP/DR constraints (Chapter 12.3) that the facility must already satisfy when the regulated tenant arrives. The disciplined operator maps the sector overlays its target tenants will bring before commissioning, so each service is built to its applicable overlay rather than retrofitted to it.

The same governance failures recur, because each comes from treating compliance as downstream paperwork rather than an upstream design constraint:

• Certification theater — collecting stamps no customer required. Pursuing a framework because a competitor has it, while the actual binding portfolio for your book of business goes unmet. The fix is to derive the portfolio from the union of target-customer mandates, not from a marketing checklist.
• Manual evidence at machine scale. Running a spreadsheet-and-screenshot compliance program against a fleet whose state changes weekly. It passes the first audit, drifts immediately, and collapses the moment continuous monitoring becomes mandatory under FedRAMP 20x.
• Residency as an afterthought. Selling "sovereign" capacity that satisfies physical residency while the remote-management path, the backup site, or the vendor support channel quietly defeats operational or control-of-stack sovereignty — discovered by the customer's auditor, not yours.
• Unowned shared-responsibility seams. Leasing capacity without a written control-ownership matrix, so the OOB-logging or firmware-attestation control belongs to no one until an authorizer asks who owns it.
• Provenance you cannot reconstruct. Skipping firmware-security audits, SBOMs, and root-of-trust attestation capture at receiving — then being unable to produce the evidence chain when a federal or sovereign customer demands it.

Sell the service after its legal entity, data classes, jurisdictions and control owners map to the obligations that apply. Reuse an artifact when it answers the same scoped requirement; obtain separate evidence when it does not. Overpromising certification or residency adds contract exposure without creating the missing control.