Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / HIPAA vs GDPR: Key Differences & Dual Compliance Guide

HIPAA vs GDPR: Key Differences & Dual Compliance Guide

HIPAA and GDPR are the two most consequential data protection frameworks any healthcare or technology organisation is likely to encounter. They share a common purpose, protecting sensitive personal data, but they differ significantly in scope, enforcement mechanisms, and compliance obligations.

For organisations operating across the Atlantic, understanding where they align, where they clash, and how to satisfy both simultaneously is not optional. It is a legal necessity.

HIPAA vs GDPR

What Is HIPAA?

The Health Insurance Portability and Accountability Act was enacted by the U.S. Congress in 1996. Its original purpose was to modernise the flow of healthcare information and ensure the portability of health insurance coverage. Over time, it became primarily known for its data protection requirements, administered by the U.S. Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR).

HIPAA is built around three core rules.

  • The Privacy Rule governs how Protected Health Information (PHI) may be used and disclosed.
  • The Security Rule sets standards for safeguarding electronic PHI (ePHI).
  • The Breach Notification Rule establishes mandatory reporting timelines when PHI is compromised.

Who Needs to Be HIPAA Compliant?

HIPAA applies to covered entities, healthcare providers, health plans, and healthcare clearinghouses, and to their business associates: any third-party organisation that handles PHI on their behalf. If you build software that processes patient data for a U.S. hospital, you are a business associate. If you store medical records in the cloud for an insurance company, you are a business associate. A Business Associate Agreement (BAA) is the formal contract that governs this relationship.

What Types of Data Does HIPAA Protect?

HIPAA protects Protected Health Information (PHI): any individually identifiable information relating to a person’s past, present, or future physical or mental health condition, the provision of healthcare, or the payment for healthcare.

This includes names, dates of birth, Social Security numbers, medical record numbers, and any data that could be used to identify a patient in connection with their health. Electronic PHI, the subset stored or transmitted digitally, is subject to the Security Rule’s additional technical requirements.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

What Is GDPR?

The General Data Protection Regulation came into force across the European Union on 25 May 2018, replacing the 1995 Data Protection Directive. It is the world’s most comprehensive data privacy law, and its extraterritorial reach means it extends well beyond Europe’s borders. The GDPR is enforced by national Data Protection Authorities (DPAs) and coordinated at the European level by the European Data Protection Board (EDPB). Unlike HIPAA, GDPR is not sector-specific. It applies to any organisation processing the personal data of EU residents, regardless of industry.

Who Needs to Be GDPR Compliant?

Any organisation that processes the personal data of individuals located in the European Union, regardless of where the organisation is based. A U.S. hospital treating European patients, a SaaS company offering services to German users, or a health app collecting data from French residents all fall within GDPR’s scope. The regulation applies to both data controllers (organisations that determine how and why data is processed) and data processors (third parties that process data on a controller’s behalf).

What Types of Data Does GDPR Protect?

GDPR protects all personal data: any information relating to an identified or identifiable natural person. Health data is explicitly designated a special category under GDPR Article 9, commanding heightened protection alongside biometric data, genetic data, racial or ethnic origin, religious beliefs, and sexual orientation.

HIPAA vs GDPR: Key Differences at a Glance

FeatureHIPAAGDPR
JurisdictionUnited States onlyEU + extraterritorial reach
SectorHealthcare onlyAll sectors
Regulatory bodyHHS / OCRNational DPAs / EDPB
Data coveredPHI onlyAll personal data
Consent modelTreatment-based exceptionsExplicit consent required
Breach notification60 days (proposed: 72 hours)72 hours
Max fine$1.9M per violation category/year€20M or 4% of global turnover
DPO requiredNoSometimes
Right to erasureLimitedYes

Scope and Geographic Reach

HIPAA’s reach is defined by entity type: it applies to covered entities and business associates operating within the United States. Whether a patient holds EU citizenship is irrelevant to HIPAA jurisdiction. What matters is whether the organisation providing care or processing health data operates within the U.S. healthcare system.

GDPR’s reach is defined by the location of the data subject, not the organisation. Article 3 of the GDPR gives it explicit extraterritorial effect. If your organisation targets or monitors EU residents, GDPR applies, regardless of where you are headquartered, where your servers are located, or what industry you operate in.

Types of Data Protected: Personal Data vs Protected Health Information (PHI)

This is the sharpest structural difference between the two frameworks. HIPAA is focused exclusively on health data in the context of healthcare delivery or payment. GDPR covers all personal data, from email addresses and IP addresses to medical records and genetic profiles.

Health data under GDPR is a subset of the broader personal data category, not the totality of it. An organisation that is fully HIPAA-compliant may still be in violation of GDPR if it mishandles employee data, marketing data, or website analytics.

Legal Basis for Data Processing

GDPR requires organisations to identify a valid legal basis before processing any personal data. For health data, that typically means explicit consent or one of the specific derogations in Article 9(2), such as processing necessary for medical diagnosis or the provision of healthcare. This is a meaningful threshold; pre-ticked boxes, bundled consent, or vague terms of service do not meet GDPR’s standard.

HIPAA takes a different approach. It permits covered entities to use and disclose PHI for treatment, payment, and healthcare operations without obtaining patient consent. Authorisation is required only in specific circumstances, such as disclosures for marketing purposes or release of psychotherapy notes.

Important: GDPR’s explicit consent requirement creates real friction for U.S. healthcare organisations treating EU patients. A hospital cannot rely on its standard HIPAA-compliant intake forms to satisfy GDPR. The legal bases must be documented separately, and consent forms must meet the GDPR’s granularity requirements.

Regulatory Authority and Enforcement

HHS OCR is the primary HIPAA enforcer in the United States. OCR investigates complaints, conducts compliance reviews, and imposes civil monetary penalties. In serious cases, the Department of Justice (DOJ) handles criminal enforcement.

Under GDPR, enforcement sits with each EU member state’s national DPA. Ireland’s Data Protection Commission (DPC), France’s CNIL, and Germany’s BfDI are among the most active. The EDPB coordinates cross-border enforcement and issues binding guidelines, but individual DPAs investigate organisations and impose fines.

Consent Requirements

Under GDPR, consent must be freely given, specific, informed, and unambiguous. For special category data, including health data, it must be explicit. Individuals can withdraw consent at any time, and organisations must be able to demonstrate that it was validly obtained. Silence, pre-ticked boxes, or inactivity do not count.

HIPAA permits treatment, payment, and operations processing without patient consent. Authorisation is required for specific disclosures outside these standard permissions.

Data Breach Notification Requirements

Under current HIPAA rules, covered entities must notify affected individuals and HHS within 60 calendar days of discovering a breach. For breaches affecting 500 or more individuals in a state, media notification is also required. The HIPAA Breach Notification Rule permits smaller breaches to be reported on an annual basis. Importantly, the 2025 proposed HIPAA Security Rule overhaul would reduce this to 72 hours for large breaches, aligning HIPAA’s timeline with GDPR.

GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a breach, where that breach is likely to result in a risk to individuals’ rights. If the breach poses a high risk to those individuals, affected data subjects must also be notified directly, without undue delay.

Worth Knowing: GDPR’s 72-Hour Breach Notification Rule

Under GDPR, if you cannot provide all details within 72 hours, you can submit the notification in phases, but the clock does not pause while you investigate. Initial notification is required, with supplemental information to follow. Many organisations discover a breach and wait to notify until the investigation is complete; this approach routinely results in regulatory scrutiny.

Penalties and Fines

HIPAA penalties are tiered by culpability, ranging from $100 to $50,000 per violation, with a maximum annual cap of $1.9 million per violation category (updated for inflation in 2023). Criminal penalties, pursued by the DOJ, can reach $250,000 and 10 years’ imprisonment.

GDPR fines operate on a two-tier structure. Less severe violations carry fines up to €10 million or 2% of global annual turnover, whichever is higher. Violations of core principles, lawfulness of processing, data subject rights, transfers to third countries can trigger fines up to €20 million or 4% of global annual turnover. By early 2026, cumulative GDPR fines had exceeded €7.1 billion since the regulation came into force.

Data Protection Officer (DPO) Requirements

HIPAA does not require a Data Protection Officer. Covered entities are expected to designate a Privacy Officer and a Security Officer, but these are internal roles without the formal independence that GDPR mandates.

Under GDPR Article 37, certain organisations must appoint a DPO: public authorities, organisations engaged in large-scale systematic monitoring of individuals, and organisations processing special category data on a large scale. For healthcare SaaS vendors processing EU patient data at scale, this threshold is frequently met.

Privacy Rights and Data Subject Access

GDPR grants data subjects a comprehensive set of rights: access, rectification, erasure, restriction of processing, data portability, and the right to object. These must be responded to within one month in most cases, with a limited extension to three months for complex requests.

HIPAA grants patients the right to access their own PHI, request corrections, and receive an accounting of disclosures. These are meaningful rights, but narrower than GDPR’s framework. HIPAA does not, for instance, grant patients data portability in the GDPR sense, nor does it provide a general right to object to processing.

The Right to Be Forgotten: GDPR vs HIPAA

This is where the two frameworks create a genuine compliance conflict. Under GDPR Article 17, individuals can request erasure of their personal data under certain conditions. A European patient treated by a U.S. provider might, in principle, request deletion of all records relating to their treatment.

HIPAA, however, requires covered entities to retain medical records for at least six years from the date of creation or last use, whichever is later. Deleting records on request could place an organisation in HIPAA violation, even if refusing to delete them constitutes a GDPR violation.

Insider Note: Organisations caught between GDPR erasure requests and HIPAA retention requirements should document their legal basis for retaining the records and respond to the GDPR request explaining why erasure cannot be fulfilled. GDPR Article 17(3) includes an explicit carve-out for legal obligations requiring retention; this is the mechanism to rely on, but the documentation must be in place before the request arrives.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Similarities Between HIPAA and GDPR

Shared Data Protection Goals

Both HIPAA and GDPR exist to protect individuals from the misuse, exposure, or unauthorised access to sensitive personal data. They take different routes, one sector-specific and prescriptive, the other broad and principles-based, but the destination is the same: organisations must treat personal data with care, limit access to those who need it, respond to failures transparently, and maintain accountability for their data practices.

Access Controls and Security Measures

Both frameworks require appropriate technical and organisational safeguards. The HIPAA Security Rule requires covered entities to implement physical, technical, and administrative controls for ePHI. GDPR Article 32 requires “appropriate” technical and organisational measures, which in practice means access controls, authentication, encryption, and regular security testing. Neither regulation prescribes a specific technical architecture; both expect organisations to assess risk and implement proportionate controls.

Risk Assessment Requirements

Both HIPAA and GDPR require formal risk assessments. The HIPAA Security Rule requires covered entities to conduct an accurate and thorough assessment of risks and vulnerabilities to ePHI. GDPR’s Data Protection Impact Assessment (DPIA) requirement, triggered for high-risk processing activities, follows the same logic. Before deploying a new healthcare application processing EU patient data, a DPIA is not a best practice, it is mandatory.

Encryption and Data Security Standards

Neither regulation originally mandated encryption as an absolute requirement. Both framed it as a control appropriate to the risk. The 2025 proposed HIPAA Security Rule update would make encryption required for ePHI in transit and at rest, eliminating the previous “addressable” flexibility. GDPR Article 32 cites encryption explicitly as an example of an appropriate security measure. The direction of travel under both frameworks is toward encryption as a baseline expectation.

GDPR vs HIPAA Compliance Requirements Explained

HIPAA Compliance Requirements Overview

HIPAA compliance centres on three rules.

  • The Privacy Rule governs permissible uses and disclosures of PHI, minimum necessary standards, and patient rights.
  • The Security Rule establishes technical, physical, and administrative safeguards for ePHI.
  • The Breach Notification Rule governs timelines and procedures when PHI is compromised.

Organisations demonstrate compliance through documented policies and procedures, regular risk assessments, employee training, access controls, audit logging, and Business Associate Agreements with all third parties handling PHI. There is no formal HIPAA certification; compliance is demonstrated through documentation and internal controls, which OCR evaluates during investigations and compliance reviews.

GDPR Compliance Requirements Overview

GDPR compliance requires organisations to: identify a lawful basis for each processing activity; maintain Records of Processing Activities (RoPA); implement data subject rights mechanisms across all relevant systems; appoint a DPO where required; complete DPIAs for high-risk processing; execute Data Processing Agreements (DPAs) with all processors; establish breach notification workflows; and address cross-border data transfer obligations using an approved mechanism such as Standard Contractual Clauses (SCCs) or the EU-U.S. Data Privacy Framework (DPF).

 

Can an Organization Be Subject to Both HIPAA and GDPR?

Yes, and this situation is increasingly common.

When Dual Compliance Is Required

A U.S. hospital actively marketing telemedicine services to patients in Europe triggers both regimes. A health-tech SaaS company selling software to EU hospitals and U.S. clinics must satisfy both. A global pharmaceutical company running clinical trials across the United States and the EU falls under both. The key question is: does the organisation handle PHI from U.S. covered entities, and does it also process personal data of EU residents?

Challenges of Achieving Dual Compliance

The most significant friction points are consent, retention, and the right to erasure. GDPR demands explicit consent as the legal basis for health data processing in many contexts; HIPAA permits processing without consent for treatment and operations. GDPR grants the right to erasure; HIPAA mandates six-year retention. GDPR requires 72-hour breach notification; HIPAA currently allows 60 days (though the proposed rule would close this gap). Each of these conflicts requires deliberate resolution, not a single document that attempts to satisfy both simultaneously.

Tips for Meeting Both HIPAA and GDPR Requirements

Use GDPR’s stricter requirements as the floor wherever the standards diverge. Implement 72-hour breach notification regardless of which framework technically applies. Treat all patient data as requiring explicit consent, even where HIPAA permits treatment-based exceptions. Use both a BAA and a DPA with processors handling data subject to both frameworks; these are different agreements serving different legal purposes. Document the retention justification clearly for any records that cannot be erased on GDPR request, invoking HIPAA’s retention obligation as the legal basis under GDPR Article 17(3).

Pro Tip: Map your Data Flows

Map your data flows against both frameworks simultaneously, rather than sequentially. A single data inventory annotated against HIPAA's PHI definition and GDPR's personal data categories will surface the exact points of overlap and conflict, and it is far easier to build controls around those collision points upfront than to retrofit them after a dual-framework audit.

HIPAA vs GDPR: Cloud and Healthcare IT Considerations

Cloud Provider Requirements Under GDPR

Under GDPR, cloud providers acting as data processors must execute a Data Processing Agreement with their clients. The DPA must specify the nature and purpose of processing, the categories of data and data subjects involved, the duration of processing, and the obligations and rights of the controller. Cloud providers must also support data subject rights requests and notify controllers of breaches without undue delay. For data stored or processed outside the EU, the appropriate transfer mechanism, SCCs, the DPF, or Binding Corporate Rules, must be in place.

Cloud Provider Requirements Under HIPAA

Under HIPAA, a cloud service provider storing or processing ePHI is a business associate, regardless of whether it can actually view or access that data. The covered entity or business associate must execute a BAA with the cloud provider. The Security Rule’s requirements apply in full: access controls, transmission security, audit controls, and integrity controls. AWS, Microsoft Azure, and Google Cloud all offer HIPAA-eligible service tiers with associated BAA templates.

Business Associate Agreements vs GDPR Data Processing Agreements

A BAA and a DPA serve analogous purposes, establishing terms under which a third party handles protected data, but they are distinct documents with different legal requirements. A BAA is tailored to HIPAA: it governs permissible uses and disclosures of PHI, requires appropriate safeguards, and mandates breach reporting. A DPA is tailored to GDPR Article 28: it covers processing instructions, security measures, sub-processor management, support for data subject rights, and audit rights. For organisations subject to both frameworks, both agreements are required with every relevant processor.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

2025–2026 Regulatory Updates: What Has Changed?

Recent HIPAA Security Rule Updates

In January 2025, HHS published a comprehensive Notice of Proposed Rulemaking to overhaul the HIPAA Security Rule, the first major update since 2013. The proposals would eliminate the distinction between “required” and “addressable” implementation specifications, making every specification mandatory. Encryption of ePHI at rest and in transit would become explicitly required, as would multi-factor authentication (MFA) for all systems involving ePHI. Covered entities would also need to maintain a written technology asset inventory and network map, updated at least annually.

The proposed rule would reduce the breach notification timeline for large breaches (500 or more individuals) from 60 days to 72 hours. The OCR confirmed finalization remains on its regulatory agenda for mid-2026, with a 240-day compliance period following final publication. Healthcare IT teams should treat the proposed changes as directionally final and begin gap assessments now.

Recent GDPR Enforcement Developments

GDPR enforcement has accelerated substantially since 2023. By early 2026, cumulative fines exceeded €7.1 billion. In 2025 alone, regulators issued approximately €1.2 billion in fines. Ireland’s DPC fined TikTok €530 million for unlawfully transferring EU user data to China. France’s CNIL issued a €325 million fine against Google across its entities. The EDPB’s 2025 coordinated enforcement action focused on the right to erasure, with 32 supervisory authorities participating and over 760 controllers investigated.

The EDPB has also clarified that large language models and AI systems rarely meet GDPR’s standards for anonymisation, placing any AI tool processing EU patient data squarely within scope. The EU AI Act’s August 2026 compliance deadline for high-risk AI systems introduces an additional compliance layer for healthcare AI vendors already navigating GDPR obligations.

Worth Knowing: The 2025 HIPAA Security Rule NPRM

The 2025 HIPAA Security Rule NPRM also proposes requirements for business continuity and disaster recovery planning, including annual testing of contingency plans. For healthcare IT teams, this significantly raises the bar for operational resilience.

In Summary

HIPAA and GDPR approach data protection from different angles. HIPAA is narrowly focused on the healthcare sector, U.S. jurisdiction, and specific entity types, with detailed prescriptions for PHI safeguards. GDPR is broadly focused, with a near-universal jurisdictional reach, all personal data, with principles-based obligations designed to scale across industries and technologies.

Where they overlap, as they do for any organisation handling health data on both sides of the Atlantic, GDPR’s requirements tend to be stricter in most dimensions. The practical path to dual compliance is not to find a single framework that satisfies both, but to understand their differences precisely enough to address each on its own terms, and to build controls that can satisfy both simultaneously where the standards permit.

Frequently Asked Questions (FAQ) About HIPAA vs GDPR

Is GDPR Stricter Than HIPAA?

In most respects, yes. GDPR’s maximum fine, up to 4% of global annual turnover, significantly exceeds HIPAA’s $1.9 million annual cap per violation category. GDPR’s consent requirements are more demanding, its data subject rights framework is broader, and its scope extends across all sectors and industries. HIPAA is more prescriptive in its specific technical requirements for healthcare entities, but GDPR’s overall compliance burden is typically greater for organisations subject to both frameworks.

No. HIPAA applies to covered entities and business associates operating within the United States. The nationality of the patient is irrelevant to HIPAA jurisdiction. A French citizen receiving treatment at a New York hospital has their health data protected by HIPAA, but that fact does not trigger GDPR for the hospital; only the organisation’s deliberate conduct toward EU residents in the EU context would do that.

Yes, if it actively offers services to or monitors EU residents. A hospital marketing telemedicine services in Europe, maintaining a website in European languages, or accepting payments in euros is likely within GDPR’s extraterritorial scope under Article 3. Any organisation with deliberate commercial activity directed at EU residents should assess GDPR applicability carefully.

HIPAA is sector-specific (healthcare) and jurisdiction-specific (United States). GDPR is sector-agnostic and applies wherever EU residents’ personal data is processed. HIPAA protects only PHI; GDPR protects all personal data, with health data as a special category commanding heightened protection. GDPR’s scope is broader by design.

Current HIPAA rules require notification within 60 calendar days of discovering a breach, with media notification for large-scale incidents. The proposed 2025 HIPAA Security Rule update would require large breaches to be reported to HHS within 72 hours. GDPR requires supervisory authority notification within 72 hours of becoming aware of a breach, with no minimum size threshold, and requires direct notification to affected individuals when the breach poses a high risk to their rights.

The penalties stack. A U.S. healthcare organisation suffering a breach that affects both U.S. patients and EU residents could face HIPAA civil monetary penalties from OCR and GDPR fines from the relevant DPA simultaneously. These are independent enforcement actions, pursued by separate authorities under separate legal frameworks. There is no mechanism for offsetting one penalty against the other.

SaaS companies are business associates under HIPAA if they handle ePHI on behalf of covered entities, regardless of how the service is branded or whether the company identifies as a healthcare company. They are data processors under GDPR if they process personal data on behalf of EU data controllers. In both cases, the appropriate agreement (BAA for HIPAA, DPA for GDPR) is required, and appropriate security controls must be in place. SaaS companies serving healthcare clients globally will routinely need to satisfy both frameworks simultaneously.

No. They share a common value, protecting individuals’ sensitive data, but differ fundamentally in scope, legal mechanisms, enforcement, and the rights they confer. HIPAA compliance does not constitute GDPR compliance, and GDPR compliance does not exempt an organisation from HIPAA requirements. For organisations operating under both frameworks, the only compliant path is to address each on its own terms while identifying practical efficiencies where they genuinely overlap.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly. What Agentic AI Actually Changes Traditional AI systems, even generative ones, are advisory. They produce an output such as a summary, a prediction, a draft email, or a classification, and a human remains the last checkpoint before anything happens in the real world. Agentic AI removes that checkpoint. An agentic system doesn’t just produce an answer. It pursues a goal. It decides which tools to call and in what order, then executes those actions directly against live systems: submitting a purchase order, modifying a database record, sending an external communication, or orchestrating a set of sub-agents to complete a broader workflow. Agentic autonomy is the degree to which a system can plan and execute actions without a human explicitly authorizing each step. It’s a spectrum rather than a binary. At one end, the AI drafts and a human approves every action. At the other, the AI operates within broad guardrails and only escalates exceptions. The further an organization moves along that spectrum, the less its exposure looks like software risk and the more it looks like delegated authority risk, the kind normally reserved for employees, contractors, and automated financial systems. Why Existing Risk Registers Miss Agentic AI Risks Most enterprise risk registers were built on a reasonably safe assumption: a human initiates consequential actions, and the technology around that human behaves deterministically. Agentic AI breaks both halves of that assumption at once. A few specific gaps show up quickly when organizations try to map agentic deployments onto existing categories. Operational risk registers assume process failures come from human error or system outages, not from a system independently choosing an unanticipated path to a stated goal. Cybersecurity risk registers are built around unauthorized external access, while an agent problem usually involves an authorized system taking unauthorized internal actions with its own legitimate credentials. Model risk frameworks, borrowed largely from financial services, evaluate output accuracy rather than action consequences, which matters most when those actions can’t be reversed. And third-party risk assessments treat vendors as static entities, not as autonomous agents that might invoke other vendors’ agents on your behalf. See our guide to the NIST AI Risk Management Framework for how output-focused frameworks are structured. The result is a governance blind spot. An organization can be compliant against its AI policy, its cybersecurity policy, and its vendor risk policy, and still have nobody accountable for the specific risk of a system initiating a harmful sequence of actions before anyone notices. Defining Agentic Autonomy Risk Agentic Autonomy Risk is the risk that an AI system, operating with delegated decision-making and execution authority, takes actions that are harmful, non-compliant, or misaligned with organizational intent before adequate human oversight can intervene. Those actions might happen independently or in coordination with other agents. It deserves standing as a named category alongside cybersecurity, operational, legal, financial, and third-party risk because the loss event itself is different. The harm is a completed action in a live system, and it may be difficult or impossible to reverse. The accountability structure is different too: when an orchestrating agent delegates to sub-agents, responsibility for the outcome gets distributed in ways existing ownership models don’t cleanly capture. So is the detection window. Traditional controls assume a human is positioned to catch an error before it compounds, but an agent can execute dozens of dependent actions faster than any human review cycle. 7 Agentic AI Risk Scenarios to Put on Your Register 1. Unauthorized autonomous decision-making. An agent takes an action within its technical permissions but outside its intended business mandate. It adjusts pricing, approves a refund, or modifies a customer record, and no policy ever explicitly authorized that scenario. 2. Goal misalignment. The agent optimizes for a literal interpretation of its objective in a way that diverges from actual business intent, particularly under ambiguous or adversarial inputs. 3. Multi-agent interactions and cascading failures. One agent’s flawed output becomes another agent’s trusted input. A single error can propagate across a chain of agents faster than anyone can detect it, amplifying the original mistake instead of containing it. 4. Excessive tool or system permissions. Agents get provisioned with broad, standing access “to be safe” rather than scoped, least-privilege access tied to specific tasks. A productivity tool quietly becomes a privilege-escalation path. 5. Regulatory non-compliance. Autonomous actions trigger obligations under data protection, financial services, employment, or sector-specific regulation, and they execute without the compliance review a human-initiated process would normally receive. 6. Explainability and accountability gaps. An autonomous action causes harm and the organization can’t clearly reconstruct why the agent chose that path, or establish whether the business owner, the AI governance function, or the vendor is accountable for the outcome. 7. Autonomous third-party actions. A vendor’s agent, integrated into your environment, takes action on your behalf, or your agent acts against a

A SOC 2 penetration test costs between $1,000 and $30,000 for most companies. A typical SaaS scope, meaning one web application, its API layer, and the cloud infrastructure behind it, usually lands between $2,000 and $20,000. Early-stage startups with a narrow scope can get an auditor-accepted test for $1,000 to $8,000, while enterprises with multiple products and hybrid infrastructure regularly spend $20,000 to $50,000 or more. The spread is wide because “penetration test” covers everything from an automated scan with a cover page to weeks of manual testing by senior engineers. Auditors know the difference, and so do the enterprise customers who asked for your SOC 2 report in the first place. This guide breaks down what drives the price, where the hidden costs sit, and how to buy a test that holds up in fieldwork without overpaying for it. What Is SOC 2 Penetration Testing?​ A SOC 2 penetration test is a simulated attack on your systems, performed by a qualified security professional, scoped to the environment covered by your SOC 2 report. The tester tries to exploit real weaknesses the way an attacker would: broken access controls, injection flaws, misconfigured cloud services, exposed credentials. The output is a report your auditor reads as evidence that your security controls work in practice, not only on paper. That last part matters. A pentest bought for SOC 2 has a second audience beyond your security team. If the report doesn’t map findings to your audit scope, document its methodology, and show remediation, it fails the job you bought it for. We cover the full deliverable in our guide to what a SOC 2-ready VAPT report includes. How Penetration Testing Fits Into SOC 2 Compliance​ SOC 2 is built on the AICPA’s Trust Services Criteria, and the Security category (the Common Criteria) applies to every report. Penetration testing is the standard way to satisfy CC7.1, which expects you to detect and monitor for new vulnerabilities, and it supports CC4.1, which covers ongoing evaluations of whether controls actually function. The AICPA’s points of focus explicitly mention vulnerability scanning and penetration testing as examples of how companies meet these criteria. In practice, the test slots into your audit timeline as an evidence item. Your auditor will ask for the report, check the test date against the audit period, and review how you handled the findings. Remediation is often scrutinized harder than the test itself, because it shows whether your vulnerability management process runs or merely exists. Is Penetration Testing Required for SOC 2?​ Strictly speaking, no. The Trust Services Criteria never use the word “mandatory” about penetration testing. You could theoretically satisfy CC7.1 with vulnerability scanning and strong monitoring alone. In reality, almost every auditor expects one, and skipping it invites two problems. First, your auditor may push back during fieldwork or add exceptions to the report. Second, the enterprise buyers reviewing your SOC 2 report increasingly look for pentest evidence specifically, and a report without it raises questions during procurement. Treat the test as effectively required and budget for it from the start of your SOC 2 compliance checklist. How Much Does SOC 2 Penetration Testing Cost? Typical Price Range for SOC 2 Pen Testing Most companies pay $1,000 to $30,000, with the median engagement for a SaaS business sitting around $12,000 to $15,000. Compliance-focused tests at the lower end of the market start around $1,000 to $5,000. Deep manual testing from established firms runs $10,000 to $30,000. Anything quoted below roughly $3,000 is almost certainly automated scanning packaged as a pentest, which auditors are getting better at spotting. Cost by Company Size (Startup, SMB, Enterprise) Company size is a proxy, not the driver. A 15-person company with three products and a legacy on-prem component will pay more than a 200-person company with one tightly scoped SaaS platform. Testers price effort, and effort follows scope. Cost by Test Type (Network, Web App, API, Cloud, Internal/External) Most SOC 2 engagements bundle two or three of these. The common package for a cloud-native SaaS company is web app plus API plus cloud configuration, which is why the $1,000 to $20,000 band comes up so often. Companies with office networks and internal systems in their audit scope add internal network testing, and the price climbs accordingly. Factors That Influence SOC 2 Penetration Testing Cost Scope and Number of Assets Tested Scope is the single biggest cost driver. Every additional application, API endpoint group, cloud account, or network segment adds testing hours. A pentest priced without a scoping call is a pentest priced on guesswork, and the guess usually favors the vendor. Complexity of Application or Infrastructure​ A simple CRUD app with two user roles tests quickly. A multi-tenant platform with role hierarchies, workflow engines, file processing, and third-party integrations takes far longer, because each of those features creates attack surface a tester has to work through manually. Authentication tiers matter especially: every distinct role needs testing for privilege escalation and cross-tenant data access. Testing Methodology (Black Box, Grey Box, White Box) Black box testing gives the tester nothing but a URL, grey box adds credentials and documentation, and white box adds source code and architecture diagrams. Grey box is the default for SOC 2 and usually the best value, since the tester spends time exploiting rather than discovering. White box costs more upfront but finds deeper issues. Black box sounds rigorous but often wastes paid hours on reconnaissance an attacker would run for free. Depth of Testing and Manual vs. Automated Approaches Automated scanning finds known vulnerability patterns. Manual testing finds business logic flaws, chained exploits, and authorization gaps that no scanner catches, and it’s the part auditors and security-literate customers actually value. The ratio of manual work to automation is the honest explanation for most price differences between two quotes covering the same scope. Tester Credentials and Firm Reputation Senior testers holding OSCP, GPEN, or CREST credentials bill higher rates, and firms with recognized methodologies charge a premium for the credibility their letterhead carries

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That