CIPSEA — Confidential Information Protection and Statistical Efficiency Act¶

Statute: 44 U.S.C. §§ 3561–3583 (CIPSEA 2018, as amended by Title III of the Foundations for Evidence-Based Policymaking Act, Pub. L. 115-435; original enactment Title V of the E-Government Act of 2002, Pub. L. 107-347) Operative interpretive guidance: 72 Fed. Reg. 33362 (June 15, 2007) — OMB Implementation Guidance for CIPSEA, FR Doc. E7-11542 Default categorization: FIPS-199 Moderate (per OMB 2007 guidance § V) → FedRAMP Moderate floor on Azure Companion playbook: CIPSEA Operational Playbook — the 14-step "can I do this in Azure and how" checklist Microsoft Azure CIPSEA documentation: none exists publicly. CIPSEA is not a named Microsoft compliance offering. Compliance is built by composing existing FedRAMP / FISMA controls with agency-administered governance.

Summary¶

CIPSEA is the principal federal statute protecting statistical data collected from respondents under a pledge of confidentiality. It applies to all federal agencies that collect such data — not only the 16 recognized statistical agencies and units — and it imposes a Class E felony (up to 5 years in prison and a fine of up to $250,000 per violation) on any officer, employee, or agent who knowingly and willfully discloses CIPSEA-protected information in identifiable form (44 U.S.C. § 3572).

For an Azure architect, four facts are load-bearing:

1. The criminal penalty attaches to individuals, including cloud operator personnel who are "designated agents." Agent designation is per-individual, not corporate.
2. OMB's recommended default FIPS-199 categorization is Moderate, which effectively requires FedRAMP Moderate (or higher) for any cloud service in the boundary.
3. Roughly 70% of CIPSEA's technical requirements are already covered by the FedRAMP Moderate baseline that CSA-in-a-Box implements via NIST 800-53 Rev. 5. The remaining ~30% are governance gaps (agent agreements, SDL review, CIPSEA-flavored incident response, OMB annual reporting).
4. Non-statistical agencies (EPA, USGS, NOAA in our examples) can acquire CIPSEA-protected data but cannot designate cloud-operator agents under CIPSEA alone. They must rely on separate statutory authority or scope the boundary so no operator agent is needed.

CSA-in-a-Box's role is to ship the technical control set that satisfies the FedRAMP-derived 70% out of the box and to provide the operational playbook and templates that close the governance 30%.

The three core CIPSEA protections¶

CIPSEA establishes three protections that information acquired under a CIPSEA pledge enjoys (44 U.S.C. § 3572; OMB 2007 guidance § II–IV):

1. Exclusively statistical use. Data may not be used for any non-statistical purpose — administrative, regulatory, enforcement, investigative, or in any action against any individual or entity. An agency that pledged CIPSEA at collection cannot later repurpose the data for an enforcement action; doing so is itself a violation.

2. Confidentiality. The data may not be disclosed in identifiable form to anyone outside the statistical agency or its designated agents.

3. Designation of agents. Extension of the protection to non-employees (contractors, researchers, cloud operators, federal employees of other agencies) is permitted only via a written designation that imposes the same obligations and the same criminal penalty.

The 16 recognized statistical agencies and units¶

CIPSEA 2018 (the Evidence Act re-codification) recognizes 16 statistical agencies and units (44 U.S.C. § 3562). Thirteen are designated Principal Statistical Agencies (PSAs); three are additional Recognized Units.

This list directly intersects several CSA-in-a-Box end-to-end examples: NASS / ERS / NAHMS at USDA, Census + BEA at Commerce, SOI at Treasury. EPA and NOAA are not recognized statistical agencies but can still acquire data under a CIPSEA pledge — see non-statistical agencies, below.

When data is CIPSEA-protected¶

Per 44 U.S.C. § 3572(b) and the 2007 OMB guidance, data is CIPSEA-protected when all four of the following are true:

1. It is acquired by a Federal agency,
2. From a respondent (individual, household, or organization),
3. Under a pledge of confidentiality,
4. For exclusively statistical purposes.

Statistical purpose (§ 3561) means the description, estimation, or analysis of the characteristics of groups, without identifying the individuals or organizations that comprise such groups. Statistical activities include collection, compilation, processing, analysis, and dissemination of data and analytical results for statistical purposes.

When CIPSEA stops protecting data¶

CIPSEA protects information in identifiable form. Once data has been processed through a Statistical Disclosure Limitation (SDL) review and a Disclosure Review Board (DRB) determines the released product cannot identify any respondent, the released aggregates are no longer CIPSEA-protected for purposes of further dissemination. The underlying microdata remains CIPSEA-protected indefinitely.

Modern complication: traditional SDL methods (cell suppression, swapping, top-coding) have been shown inadequate against database-reconstruction attacks at scale. The Census Bureau's 2020 modernization papers document the move to formal differential-privacy methods. Other PSAs (BLS, BTS, NCHS) continue to use traditional SDL. Both pathways are operationally legitimate.

What disqualifies data from CIPSEA¶

If at the time of collection the agency intends or pledges any non-statistical use (regulatory, administrative, enforcement, investigatory), the data is not CIPSEA-protected — and it cannot be retrofitted onto data that was collected under a non-statistical pledge. This means a single ingest stream cannot serve both regulatory and statistical purposes if a CIPSEA pledge is on the form.

Interaction with other confidentiality statutes¶

CIPSEA operates alongside several other confidentiality regimes. The more restrictive regime always governs the data element in question.

Cloud / Azure-specific requirements¶

Azure Government vs Azure Commercial¶

There is no statute or OMB guidance that mandates Azure Government for CIPSEA workloads. What constrains the choice in practice:

• The OMB 2007 guidance does not explicitly require US-only data residency, but the agent-personnel restrictions effectively impose a US-residency posture on any system the agents touch. NCHS, for example, restricts agent telework to the 50 states + DC.
• The recommended FIPS-199 Moderate categorization is satisfied by both Azure Commercial and Azure Government per Microsoft's formal FedRAMP authorizations: see Microsoft Azure FedRAMP compliance offering (FedRAMP High authorization for Azure and Azure Government) and the per-service FedRAMP scope tables in Microsoft Service Trust Portal. DoD IL2 / IL4 / IL5 authorizations for Azure Government are documented at Microsoft Azure DoD compliance offering.
• In practice every PSA cloud strategy publicly documented uses a government-cloud or FedRAMP High posture for CIPSEA data, even though the statute permits Moderate. Reasons: cohabitation with FTI workloads (which require IL5 / FedRAMP High); personnel screening and citizenship requirements that Azure Government can satisfy via screened-US-persons-only operations; reduced supply-chain risk under EO 14028 / EO 14110.

CSA-in-a-Box recommendation: default the reference architecture to Azure Government for CIPSEA workloads. Document that Azure Commercial (US regions only) is statutorily permissible for pure CIPSEA-only data with no FTI commingling and where the agency's risk acceptance allows it. Pin all storage and compute to US regions via Azure Policy allowed-locations.

Encryption, KMS, audit logging — what CIPSEA adds beyond NIST baseline¶

CIPSEA itself does not specify encryption algorithms or HSM requirements; these inherit from NIST 800-53 Rev. 5 Moderate baseline (SC-12, SC-13, SC-28, AU-2, AU-3, AU-12) which CSA-in-a-Box already implements. What CIPSEA does impose beyond stock NIST baseline:

• Agent access logging — every access to identifiable CIPSEA data must be auditable to the named individual agent. This pushes toward customer-managed keys (CMK) with key access logging, identity-bound access via Microsoft Entra ID Privileged Identity Management, and immutable audit log retention. Azure Key Vault Managed HSM with diagnostic logs to Microsoft Sentinel / Log Analytics with immutability policies is the natural pattern.
• Confidential Computing (Azure Confidential VMs, SGX, SEV-SNP) is not required by CIPSEA but is an emerging best practice for re-identification-attack defense, particularly for DRB environments where the protected data must be processed without exposure to the cloud operator. Recommended where the threat model includes the cloud provider as an adversary — and the standard pattern for non-statistical agencies that cannot designate cloud-operator agents.

Non-statistical agencies acquiring CIPSEA-protected data¶

EPA, USGS, NOAA, and any other non-statistical federal agency can acquire data under a CIPSEA pledge — but they cannot designate cloud-operator agents under CIPSEA alone (per OMB 2007 guidance § VI; § 3573 powers attach only to recognized statistical agencies and units).

Two operational paths for a non-statistical agency:

• Agency-employee-only access. Restrict logical access to identifiable CIPSEA data to agency employees only; no cloud-operator agent designation. Operationally hard in IaaS — every break-glass operator action by Microsoft personnel breaks the model.
• Customer-managed encryption + Confidential Computing. Render the data unreadable to the cloud operator at all times, removing the operator from the access chain. CMK in Azure Key Vault Managed HSM with no Microsoft access path; processing in Confidential VMs / SGX enclaves with attestation. This is the scalable Azure pattern.

This is the most genuinely unsettled area of CIPSEA cloud architecture. CSA-in-a-Box's reference implementation for EPA / NOAA examples uses path 2 (CMK + Confidential Computing) by default for any data that may be CIPSEA-protected.

Control crosswalk — CIPSEA → NIST 800-53 Rev. 5 → CSA-in-a-Box¶

There is no formal publicly available CIPSEA-to-NIST 800-53 Rev. 5 crosswalk. The mapping below is derived from the CIPSEA statute, the 2007 OMB guidance, and PSA implementation reports (notably NCHS 2024 and BLS). It identifies which CIPSEA requirements CSA-in-a-Box already satisfies via its FedRAMP Moderate / NIST 800-53 baseline, and where the residual governance gaps are.

Pattern: roughly 70% of CIPSEA technical requirements are inherited directly from the FedRAMP Moderate baseline. The remaining 30% are governance/process gaps (agent agreements, SDL review, CIPSEA-flavored incident response, OMB annual reporting). The operational playbook covers the gap.

Existing public agency practice¶

The richest publicly available CIPSEA implementation patterns come from PSAs that have published their compliance posture:

• Census Bureau — Federal Statistical Research Data Centers (FSRDC): 37 physical centers nationwide, all backed by Census Bureau VDI hosted at the Bowie, MD Computer Center, recently extended to remote access from approved home worksites with annual video inspection. The FSRDC architecture is the gold-standard physical pattern that any CSA-in-a-Box virtual-enclave reference architecture should map to.
• Census Bureau — OCIO Cloud Services PIA (FY23, SAOP-approved): centralized framework using FedRAMP-authorized CSPs. Publicly named providers include AWS GovCloud (used for the 2020 Census decennial data collection) and Google Cloud. Microsoft Azure is not listed in the public PIA; Azure IaaS use for CIPSEA data at Census is not publicly documented.
• BLS — CIPSEA Implementation Reports: documents approximately 1,506 designated agents working under approximately 38 contracts with private vendors. Useful concrete data point: agent designation is operationally feasible at scale, but it requires per-individual paperwork, training, and oath — not a corporate blanket.
• NCHS — Annual OMB CIPSEA Report CY 2024: the most operationally detailed PSA disclosure publicly available. Documents a "CIPSEA Compliant System" approval process (NCHS ISSO + NCHS Confidentiality Officer + CDC CISO + CDC CIO), telework restricted to 50 states + DC, open Wi-Fi prohibited, annual recertification. This is the best public template for how a federal-statistical PSA actually operationalizes CIPSEA in a modern hybrid-cloud environment.

Known unsettled areas¶

A handful of CIPSEA cloud-architecture questions do not have settled public answers as of this page's preparation. Address with your agency Confidentiality Officer and Microsoft Federal account team rather than treating as solved:

• Whether Microsoft will sign per-individual CIPSEA agent agreements for Azure Government operators. No public documentation either confirms or denies this. The IRS Pub. 1075 precedent (where Microsoft signs a Safeguards Agreement and provides screened-US-persons-only operator personnel for FTI tenants) suggests a path, but CIPSEA-specific arrangements would need to be negotiated.
• Whether FedRAMP Moderate is sufficient or High is effectively required. Statute says Moderate by default; PSA practice trends toward High when commingled with FTI or when re-identification consequences are severe.
• How CIPSEA interacts with EO 14117 (preventing access to bulk sensitive personal data by countries of concern). EO 14117 (Feb 2024) and the DOJ implementing rule create new restrictions on bulk data transactions. CIPSEA-protected data is plausibly "sensitive personal data" within EO 14117's scope. No public guidance has yet aligned the two regimes.
• Whether OMB will issue refreshed CIPSEA implementation guidance to replace the 2007 document. Anticipated by some PSA implementation reports but not announced as of preparation date.

Next steps¶

• Read the operational playbook for the 14-step "can I host this in Azure and how" checklist.
• If your workload also touches FTI, defer to IRS Pub. 1075 — it is more restrictive than CIPSEA on cloud and effectively governs.
• For non-statistical-agency CIPSEA acquisitions (EPA / USGS / NOAA examples), see the Customer-managed encryption + Confidential Computing pattern above.
• Verify your control posture against the NIST 800-53 r5 mapping — that's where most CIPSEA technical controls actually live.

References¶

Statute and regulation:

• 44 U.S.C. §§ 3561–3583 — CIPSEA 2018
• Pub. L. 107-347 — E-Government Act of 2002 (CIPSEA original)
• Pub. L. 115-435 — Foundations for Evidence-Based Policymaking Act of 2018
• 72 Fed. Reg. 33362 (June 15, 2007) — OMB Implementation Guidance for CIPSEA, FR Doc. E7-11542
• OMB M-23-04 — Standard Application Process
• 88 Fed. Reg. 56353 (Aug. 18, 2023) — Fundamental Responsibilities of Recognized Statistical Agencies and Units

Agency implementation reports:

• BLS CIPSEA Implementation Reports
• NCHS Annual OMB CIPSEA Report CY 2024
• NCES CIPSEA Report
• BTS Confidentiality Policy
• ERS CIPSEA Training
• EIA 2016 CIPSEA Report
• Census Bureau OCIO Cloud Services PIA (FY23)
• Census FSRDC program

Background and cross-reference:

• Wikipedia — CIPSEA
• CRS Report R48161 — The Federal Statistical System: An Overview
• National Academies — CIPSEA at 15 Years
• Abowd et al. — The Modernization of Statistical Disclosure Limitation at the Census Bureau
• Statistical Policy Working Paper 22 — SDL Report (FCSM)
• Azure Government for Federal

Last updated: 2026-05-04 Review cadence: Annual (target: 2027-05-04) Owner: csa-inabox platform team