HIPAA, GLBA, FedRAMP Moderate/High, and SOC 2 show up in federal AI procurement conversations in predictable rooms: HIPAA in health agency deals and any conversation where PHI is in scope, GLBA when the buyer is a financial regulator or a contractor to one, FedRAMP in virtually every federal civilian cloud deployment, SOC 2 as the baseline due diligence ask before an ATO process completes. Each regime operates on different logic — different triggers, different architecture constraints, different evidence requirements. An AE who can name those differences precisely, in the buyer's language, earns a different kind of credibility than one who treats them as interchangeable compliance checkboxes.
Regime Profiles
HIPAA
What it is. A federal statute governing the use and disclosure of protected health information.
What it does. The Privacy Rule and Security Rule together require covered entities (health plans, healthcare clearinghouses, most healthcare providers) and their business associates to implement administrative, physical, and technical safeguards for PHI. For AI systems, whether the system processes, stores, or transmits PHI at any point in its workflow — including during model training — is the threshold question. A vendor that processes PHI on behalf of a covered entity is a business associate and must sign a BAA before any PHI enters the system.
Who's behind it. HHS Office for Civil Rights enforces the Privacy and Security Rules. The HITECH Act (2009) extended direct liability to business associates and increased civil monetary penalties. OCR's enforcement authority covers both intentional violations and failures to implement required safeguards.
What makes it distinct. Applicability is triggered by data type, not deployment environment. An AI system running on commercial cloud infrastructure is subject to HIPAA if it touches PHI, regardless of where it runs or who built it. A FedRAMP-authorized AI system that processes PHI is subject to both regimes simultaneously: FedRAMP authorization does not satisfy HIPAA's BAA requirement, and a BAA does not satisfy FedRAMP's authorization boundary requirement.
GLBA
What it is. A federal statute requiring financial institutions to protect the security and confidentiality of customer financial information.
What it does. The Safeguards Rule — enforced by the FTC for non-bank financial institutions and by prudential regulators for banks — requires a written information security program (WISP), a documented risk assessment, specific technical controls including encryption and MFA, and an annual penetration test for entities above the 5,000-customer-record threshold. The FTC's amended Safeguards Rule, effective June 2023, added prescriptive technical requirements that directly affect AI system design: encryption at rest and in transit, MFA for any individual accessing customer information, and a designated "qualified individual" responsible for overseeing the information security program.
Who's behind it. The FTC enforces for non-bank financial institutions. The OCC, FDIC, Federal Reserve, and NCUA enforce for their respective regulated entities under the Interagency Guidelines Establishing Information Security Standards, which parallel the Safeguards Rule requirements.
What makes it distinct. Applicability is triggered by business activity — specifically, being "significantly engaged" in financial activities as defined under the Bank Holding Company Act. This catches more entities than people expect. Fintech vendors, federal contractors that process financial aid data, and some insurance-adjacent technology providers have all found themselves in GLBA scope after assuming they were outside it. Unlike HIPAA, there is no standard contractual instrument equivalent to the BAA: GLBA compliance is documented through the WISP and risk assessment, not through a bilateral agreement with each customer.
FedRAMP Moderate / High
What it is. A government-wide program that standardizes security assessment, authorization, and continuous monitoring for cloud products used by federal agencies.
What it does. Requires cloud service providers to meet NIST SP 800-53 Rev. 5 control baselines — approximately 325 controls at Moderate impact level and approximately 421 at High — undergo third-party assessment by an accredited 3PAO, and receive an Authority to Operate from an agency or the Joint Authorization Board. Continuous monitoring requirements persist after authorization: monthly vulnerability scans, annual penetration tests, and significant change notifications when the system architecture changes materially.
Who's behind it. GSA's FedRAMP Program Management Office administers the program. The JAB, composed of the CIOs of DoD, DHS, and GSA, issues the highest-tier authorizations (P-ATOs). Agency ATOs are issued by individual agency authorizing officials and are portable to other agencies through the "use" process.
What makes it distinct. Applicability is triggered by deployment environment, not data type. Any cloud service used by a federal agency requires FedRAMP authorization. There is no data-type carve-out: an AI system processing only publicly available information still requires FedRAMP authorization if it is deployed in a federal environment. OMB Memorandum M-23-22 (September 2023) reinforced that agencies must use FedRAMP-authorized services for cloud deployments, with limited exceptions requiring documented justification from the agency CIO. The Moderate/High distinction matters for AI deployments: systems that process data classified as High impact — including certain law enforcement, financial, and health data — require High authorization, which carries substantially more demanding control requirements and a smaller pool of authorized vendors.
SOC 2
What it is. An audit framework developed by the AICPA that evaluates a service organization's controls against the Trust Services Criteria.
What it does. Produces an audit report — not a certification — assessing controls across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type I reports assess whether controls are suitably designed at a point in time. Type II reports assess whether controls operated effectively over a defined period, typically 6 to 12 months. The auditor issues an opinion; the report is provided to customers under NDA.
Who's behind it. The AICPA sets the Trust Services Criteria. Licensed CPA firms conduct the audits. No government body issues, validates, or requires SOC 2 reports. There is no registry of SOC 2-compliant vendors analogous to the FedRAMP Marketplace.
What makes it distinct. Nothing triggers it. SOC 2 is entirely voluntary. Agencies request SOC 2 Type II reports as a procurement signal; vendors provide them as evidence of baseline security hygiene. For AI systems, the AICPA has not issued AI-specific Trust Services Criteria as of mid-2026. What "processing integrity" means for a model that produces probabilistic outputs, how "availability" applies to a model that degrades under distribution shift, and how "confidentiality" governs training data — these are genuinely unsettled questions that current SOC 2 engagements do not systematically address. A SOC 2 report that does not specifically test AI-relevant controls is not evidence of AI-specific security posture, regardless of what the vendor's marketing materials say.
Comparison Strategy
This section uses trait-led analysis: each of the four fixed dimensions is examined across all four regimes in sequence. The alternative, scenario mapping, would be more narrative but would bury the reference utility this piece needs to serve. An AE in a live conversation needs to locate "what evidence does FedRAMP require" without reconstructing it from a deployment scenario. Trait-led analysis preserves parallel structure and supports that use case directly.
Dimension 1: What Triggers Applicability
HIPAA: Data type. PHI is the trigger — individually identifiable health information held or transmitted by a covered entity or business associate. An AI system that never touches PHI is outside HIPAA scope regardless of who deploys it or where it runs.
GLBA: Business activity. Being "significantly engaged" in financial activities under the Bank Holding Company Act. The FTC's amended Safeguards Rule applies to non-bank financial institutions with more than 5,000 customer records — a threshold that catches vendors who don't self-identify as financial institutions.
FedRAMP: Deployment environment. Any cloud service used by a federal agency requires FedRAMP authorization. The trigger is the customer, not the data type or the vendor's industry.
SOC 2: Nothing. No statute, no threshold, no trigger. Agencies request it; vendors provide it or decline to. No legal trigger exists — and that is the most operationally important fact about SOC 2 in a procurement conversation.
Dimension 2: What Architecture Decisions It Constrains
HIPAA: Encryption at rest and in transit for PHI (45 CFR §164.312). Audit logging of PHI access. Access controls limiting PHI access to authorized users. If the model was trained on PHI, training data handling is subject to HIPAA. If the model outputs PHI — summarizing a patient record, for example — output handling is subject to HIPAA. HHS OCR's 2024 guidance on AI and HIPAA clarified that de-identification of training data must meet the Expert Determination or Safe Harbor standards under 45 CFR §164.514, and that statistical re-identification risk from model outputs is an active enforcement concern.
GLBA: Encryption of customer information in transit and at rest. MFA for any individual accessing customer information. A written incident response plan. The Safeguards Rule's requirement for a "qualified individual" overseeing the information security program creates accountability questions when AI systems make autonomous decisions about customer data access. The OCC's model risk management guidance (OCC Bulletin 2011-12, updated 2021) adds validation and documentation requirements for models used in financial decisions — requirements that apply to AI models used by bank-regulated entities.
FedRAMP: The most architecturally prescriptive of the four. FIPS 140-3 validated cryptographic modules are required. NIST SP 800-53 Rev. 5 controls govern network segmentation, logging and monitoring, incident response, and supply chain risk management. The authorization boundary must include all components: model training infrastructure, inference endpoints, and any third-party APIs the model calls. The FedRAMP PMO's 2025 advisory on AI workloads clarified that model weights stored in cloud infrastructure are in-scope for the authorization boundary, a determination that directly affects how vendors architect model storage and access controls.
SOC 2: No prescriptive architecture requirements. The Trust Services Criteria describe outcomes, not specific controls. This flexibility is why SOC 2 is easier to obtain than FedRAMP but less meaningful as a procurement signal for federal buyers. The current criteria do not address probabilistic model outputs, model drift, or training data governance. Agency security leads who ask about AI-specific controls are asking questions that SOC 2 reports, as currently structured, are not designed to answer.
Dimension 3: What Evidence It Requires
HIPAA: A signed BAA with every business associate that handles PHI. A risk analysis (45 CFR §164.308(a)(1)) documenting identified risks and implemented safeguards. Audit logs demonstrating access controls are functioning. HHS OCR expects the risk analysis to address AI-specific risks, including re-identification risk from model outputs. Enforcement actions since 2023 have cited inadequate risk analysis — not the absence of a BAA — as the primary finding in AI-adjacent HIPAA investigations.
GLBA: A written information security program approved by the board or a senior officer. A risk assessment documenting reasonably foreseeable risks to customer information. Annual penetration testing and vulnerability assessments for covered entities above the 5,000-record threshold. The WISP must address how AI systems that process customer financial information are governed, including access controls, audit logging, and the accountability structure for automated decisions.
FedRAMP: A System Security Plan documenting all required controls. A Security Assessment Report from an accredited 3PAO. A Plan of Action and Milestones tracking open findings. Continuous monitoring deliverables: monthly vulnerability scans, annual penetration tests, significant change notifications. The ATO letter from the authorizing official. Any significant change to the AI system — new model version, new training data, architectural change — requires a significant change request that may trigger re-assessment of affected controls.
SOC 2: A SOC 2 Type II report from a licensed CPA firm covering a defined period. The report includes the auditor's opinion, a description of the system, the criteria tested, and any exceptions noted. Buyers should ask whether the engagement specifically tested controls relevant to AI workloads. A report that covers general IT controls without addressing model governance, training data handling, or inference logging is not evidence of AI-specific security posture — and a vendor who presents it as such is overstating what the report demonstrates.
Dimension 4: Practical Procurement Bar for Federal AI Deployments
HIPAA: BAA in place before any PHI touches the system, plus a completed risk analysis that addresses AI-specific risks. Agencies increasingly request the risk analysis as part of procurement due diligence, not just the BAA. A vendor that offers a BAA but cannot produce a risk analysis addressing AI-specific PHI risks is not meeting the practical bar that HHS OCR's current enforcement posture implies.
GLBA: Documentation of the WISP and evidence of required annual assessments. Unlike HIPAA, there is no standard contractual instrument — vendors should expect agency-specific data handling questionnaires. Financial regulators that are themselves GLBA-regulated entities (OCC, FDIC, CFPB) will apply their own interpretations of the Safeguards Rule to vendor assessments, and those interpretations vary.
FedRAMP: The hard bar. An AI system deployed in a federal environment must have a FedRAMP authorization or be in-process with a documented path to authorization. OMB M-23-22 eliminated most "equivalent" alternatives. The most common gap in AI vendor FedRAMP posture as of mid-2026: the AI vendor holds a FedRAMP authorization for their platform but relies on a third-party foundation model API that is not itself FedRAMP authorized and is not within the vendor's authorization boundary. This gap is not theoretical — it surfaces in 3PAO assessments and has delayed ATOs.
SOC 2: The baseline ask, not the ceiling. A SOC 2 Type II report is a first-pass procurement signal, not a government-recognized authorization. A SOC 2 report without a FedRAMP authorization is not sufficient for federal cloud deployment. SOC 2 carries weight as evidence of baseline security hygiene during the pre-ATO period, or for on-premise deployments that don't meet the threshold for FedRAMP applicability.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "We're HIPAA compliant." | "We have a signed BAA and a completed risk analysis that addresses AI-specific PHI risks — I can share both." | HIPAA compliance is not a certification; the BAA and risk analysis are the actual evidence, and buyers know the difference. |
| "We're working toward FedRAMP." | "We have an active FedRAMP In Process designation with [Agency] as our sponsoring agency, targeting Moderate authorization by [quarter]." | "Working toward" is unverifiable; In Process status, sponsoring agency, and target level are all checkable against the FedRAMP Marketplace. |
| "Our AI doesn't store PHI." | "Our system is designed so that PHI is not persisted beyond the transaction, and our BAA covers transient processing — our risk analysis documents the controls." | "Doesn't store" doesn't address in-memory processing, model training, or inference logging, which are where OCR's current focus sits. |
| "We're SOC 2 certified." | "We have a SOC 2 Type II report covering [period] — I can share it and walk through what the auditors specifically tested." | SOC 2 is not a certification; calling it one signals you don't understand the framework, which is exactly what a CISO will test. |
| "We're GLBA compliant." | "We maintain a written information security program that meets the FTC Safeguards Rule requirements, and I can provide our most recent risk assessment." | GLBA compliance is not a certification and has no central registry; the WISP and risk assessment are the evidence. |
| "FedRAMP Moderate covers this deployment." | "This deployment falls within our FedRAMP Moderate authorization boundary — here's the specific component in our SSP." | "Covers this" is unverifiable without the SSP reference; agency security leads will ask for the boundary documentation. |
| "Our SOC 2 covers AI." | "Our SOC 2 engagement included testing of [specific controls] — I want to be direct that the AICPA hasn't issued AI-specific criteria yet, so I can walk through what the report does and doesn't address." | The AICPA has not issued AI-specific Trust Services Criteria; claiming SOC 2 covers AI is a credibility risk with any buyer who has read the criteria. |
| "We're FedRAMP High." | "We hold a FedRAMP High ATO for [specific service] — I can confirm whether the AI components you're evaluating are within that boundary." | FedRAMP High for one service doesn't mean all services or components are authorized; boundary specificity is what matters. |
| "Our third-party model API is covered." | "The foundation model API we use is [FedRAMP authorized / within our authorization boundary] — here's the documentation from our SSP." | Third-party API coverage is the most common gap in AI vendor FedRAMP posture; leaving it unaddressed invites the question at the worst moment. |
| "GLBA probably doesn't apply here." | "Let me confirm the applicability question with our compliance team — GLBA's scope under the amended Safeguards Rule is broader than it looks, and I want to give you an accurate answer." | AEs frequently dismiss GLBA applicability incorrectly; the amended Safeguards Rule's 5,000-record threshold catches entities that don't self-identify as financial institutions. |
| "Our SOC 2 is current." | "Our SOC 2 Type II report covers [specific period] — if you need coverage through [date], I can discuss our audit schedule." | "Current" is meaningless without the period; Type II coverage gaps matter to buyers who are doing point-in-time due diligence. |
| "We can get you a BAA." | "We have a standard BAA that our legal team has reviewed against current HHS OCR guidance — I can get that to you today, and we should schedule time to walk through our risk analysis as well." | A BAA offer without the risk analysis is incomplete; OCR's enforcement posture since 2023 makes the risk analysis the substantive document. |
Okta Concept Mapping: BAAs and Federated Trust
Business Associate Agreements map structurally to federated trust relationships in IDAM. In federation, when you extend trust to a third party, the IdP issues tokens that are technically constrained — the relying party can only do what the token permits, and the federation agreement is enforced by the protocol itself. A BAA works similarly in concept: it's a contractual extension of trust to a business associate, defining what they can do with PHI. The break point is enforcement mechanism. Federated trust is technically enforced: the IdP won't issue tokens to parties outside the federation, and token scope is cryptographically bounded. A BAA is contractually enforced but technically unverified — an AI vendor with a BAA can technically access PHI beyond the scope of the agreement, and HHS OCR won't know until an audit or a breach. When a CISO asks whether your BAA "covers" a particular AI use case, the accurate answer is that the BAA defines permitted scope contractually, but the technical controls documented in your risk analysis are what actually enforce it. Lead with the risk analysis, not just the BAA.

