The Question at Hand
A breach involving 153 million driver's licenses has reignited a debate in privacy circles: should large datasets of personal information fall under regulatory frameworks as strict as HIPAA? The incident at IDScan.net, which provides ID verification services for companies like Hertz and FedEx, exposes a regulatory gap. These firms aggregate massive volumes of identity documents but operate without the prescriptive security mandates that govern healthcare data. Four class-action lawsuits have been filed, and the FBI is investigating. The legal question is thornier: do we need sector-specific rules for identity brokers, or should we strengthen horizontal frameworks like GDPR?
The Case for HIPAA-Style Regulation
Proponents of a HIPAA-equivalent framework argue that identity verification brokers handle data as sensitive as medical records but face far lighter obligations. HIPAA imposes specific appropriate technical and organisational measures, breach notification timelines, business associate agreements, and enforcement mechanisms. A driver's license contains your full name, address, date of birth, physical characteristics, and a government-issued identifier. Combine that with geolocation data from cannabis dispensaries or rental car returns, and you've got a profile ripe for identity theft or stalking.
The argument gains weight when you consider scale. IDScan.net reportedly processes IDs for hundreds of businesses. When a healthcare entity suffers a breach, HHS can impose civil monetary penalties and mandate corrective action plans. But when an ID verification broker loses 153 million records? The enforcement landscape is fragmented. State breach notification laws apply, but they vary wildly. The FTC can pursue unfair or deceptive practices under Section 5, but that's reactive, not prescriptive.
A HIPAA-style regime would establish baseline security requirements: encryption at rest and in transit, access controls, audit logging, and regular risk assessments. It would mandate business associate agreements so that companies using ID verification services can't outsource accountability. And it would create a single supervisory authority with clear enforcement powers, rather than forcing victims to navigate a patchwork of state attorneys general and class-action litigation.
The practical benefit? Your contracts team would know exactly what to require in processor agreements. Your audit checklist would have regulatory teeth. And when a processor fails, you'd have a clear path to demonstrate you met your obligations as a controller.
The Case for Strengthening Horizontal Frameworks
Critics of sector-specific regulation argue we're solving yesterday's problem. GDPR already imposes strict obligations on any organization processing personal data at scale. Article 32 requires appropriate technical and organizational measures based on risk. Article 28 mandates processor agreements with specific security commitments. Article 33 requires breach notification within 72 hours. The issue isn't regulatory gaps but enforcement gaps and jurisdictional reach.
Creating a HIPAA equivalent for ID brokers would fragment the compliance landscape further. You'd have different rules for health data, financial data, biometric data, and identity data. Each sector would develop its own interpretation of "reasonable security," its own breach thresholds, its own documentation requirements. Your processor due diligence would multiply: you'd need separate assessment frameworks for each regulatory regime your processors touch.
The horizontal approach also addresses the root problem more directly. IDScan.net isn't just an ID broker; it's a processor for hundreds of controllers. Under GDPR Article 28(3), you're required to ensure your processor provides sufficient guarantees to implement appropriate technical and organizational measures. If you're a cannabis dispensary or car rental company using IDScan.net, you should already be conducting processor assessments, reviewing security certifications, and auditing data retention policies.
Strengthening GDPR enforcement would create incentives without adding regulatory complexity. Supervisory authorities could issue binding decisions requiring specific security measures for high-risk processing. They could impose administrative fines on processors that fail to meet Article 32 obligations. And they could coordinate cross-border enforcement when breaches affect multiple jurisdictions, which HIPAA's US-centric framework can't do.
Where Practitioners Actually Land
Most DPOs I've spoken with want something in between. They recognize that GDPR's risk-based approach is conceptually sound but operationally vague. What constitutes "appropriate" measures when you're processing 153 million identity documents? Article 32 lists encryption and pseudonymization but doesn't mandate them. You're left interpreting supervisory authority guidance and hoping your interpretation survives a post-breach investigation.
The practical challenge isn't choosing between HIPAA and GDPR. It's that neither framework adequately addresses the concentration risk when third-party processors aggregate data from hundreds of controllers. Your legitimate interests assessment or Article 6(1)(b) necessity analysis focuses on your processing, not your processor's cumulative exposure. Your processor agreement requires security measures, but you can't audit a processor's entire infrastructure. And when a breach happens, you're notifying your supervisory authority about your data subjects while 499 other controllers are doing the same.
What practitioners need isn't necessarily new regulation. It's clearer guidance on what "appropriate measures" means for high-volume processors, standardized processor certification schemes that controllers can rely on, and supervisory authority coordination so enforcement doesn't fall through jurisdictional cracks.
Our Take
The IDScan.net incident doesn't prove we need a HIPAA equivalent; it proves we need better enforcement of existing obligations. GDPR Article 28(1) already requires you to use only processors that provide sufficient guarantees. Article 32 already requires security measures appropriate to the risk. The problem is that "sufficient guarantees" has become a checkbox exercise: ISO 27001 certification, a standard processor agreement, maybe a SOC 2 report if you're thorough.
If supervisory authorities started imposing fines on controllers for inadequate processor due diligence, you'd see rapid change. If they required annual third-party audits for processors handling more than 10 million records, the market would respond. And if they coordinated enforcement across borders, processors couldn't hide behind jurisdictional complexity.
That said, there's a case for sector-specific guidance. The EDPB could issue an opinion on security measures for identity verification processors, similar to its guidance on video surveillance or social media. That would give you concrete benchmarks without fragmenting the regulatory landscape.
Don't wait for regulation to clarify. Ask your ID verification vendors: How long do you retain images? Who has access? What encryption standards do you use? How often are you audited? If they can't answer, find a processor who can. The lawsuits will clarify liability, but your job is to prevent being in that position.
