Compliance vs. Security in Healthcare 2026

2. Why Compliance Has Not Stopped the Bleeding

Healthcare organizations that suffer major breaches are rarely non-compliant. Most have completed HIPAA risk assessments, signed Business Associate Agreements, implemented access controls, and adopted cloud platforms with security certifications. The breaches happen anyway, and they are rarely limited in scale.

2.1 What HIPAA Requires and What It Does Not

HIPAA's Security Rule requires covered entities and business associates to implement reasonable safeguards for electronic PHI (protected health information). The rule is intentionally flexible, allowing organizations to choose measures appropriate to their size and risk profile. That flexibility creates gaps (HHS, 45 CFR Part 164):

• HIPAA does not mandate end-to-end encryption. Encryption is classified as an “addressable” specification, meaning organizations can satisfy it by documenting why they chose not to encrypt and implementing an alternative measure.
• HIPAA allows broad administrative and service-account access to PHI. There is no requirement that access be cryptographically enforced or that decryption keys be separated from infrastructure credentials.
• HIPAA does not restrict decryption inside applications. Once data reaches an authorized system, it can exist in plaintext across memory, logs, caches, and temporary storage.
• HIPAA does not protect PHI after sharing beyond requiring a Business Associate Agreement, which is a contractual control, not a technical one. A BAA cannot prevent a third party from storing or mishandling plaintext data.
• HIPAA does not require tamper-evident, cryptographic audit trails. Organizations may rely on system logs that can be altered, deleted, or incomplete.

The result: an organization can pass a HIPAA audit and still have PHI sitting in plaintext across dozens of systems, vendor environments, and shared workflows. This is not a theoretical risk. It is how every major breach described in Section 1 occurred.

2.2 The Expanding Attack Surface

A modern healthcare organization may share PHI with EHR vendors, billing and coding platforms, clearinghouses, insurance payers, telehealth systems, analytics tools, AI platforms, cloud providers, Health Information Exchanges, and numerous consultants, auditors, and service providers. Each connection is a point where PHI may be decrypted, cached, logged, or exposed. The average hospital works with more than 1,300 vendors (Ponemon Institute).

HIPAA's framework of BAAs and organizational policies was not designed to enforce technical protections across this kind of sprawl.

3. Why Cloud Adoption Has Not Solved the Problem

Cloud platforms like AWS, Azure, and Google Cloud provide strong infrastructure security: physical data centers, hardware isolation, availability, and baseline compliance certifications. But cloud security operates under a shared responsibility model. The provider secures the infrastructure, the customer is responsible for securing the data, applications, and access controls running on that infrastructure (AWS Shared Responsibility Model; Azure Shared Responsibility).

This distinction is frequently misunderstood. Migrating to AWS does not mean PHI is encrypted end-to-end, that administrators cannot access plaintext data, or that policies travel with data after sharing. Cloud encryption at rest and in transit protects data while stored on disk and while moving over a network. Both protections end the moment an application processes the data.

Healthcare breaches most often result from credential compromise, misconfiguration, third-party attacks, insider threats, and ransomware (Verizon DBIR, 2024). In every one of these scenarios, the cloud infrastructure performs exactly as designed. The breach occurs because PHI is accessible at the application layer to anyone with sufficient credentials or access.

4. Why Traditional Encryption Falls Short

Encryption at rest protects data stored on disk, but it remains transparent to the systems that use it. When data is accessed, it is automatically decrypted for any authorized service or user. This means that any entity with sufficient access, including a compromised administrator, insider, or breached service, can still query and read sensitive records in plaintext. In practice, encryption at rest primarily addresses the risk of physical theft of storage media, a threat that has largely been reduced by modern cloud infrastructure.

Encryption in transit (TLS/SSL) secures data as it moves between systems, protecting it from interception over the network. However, data is decrypted at each endpoint along the path, including servers, load balancers, API gateways, and applications, before it is processed or forwarded. TLS protects the connection, not the data itself. Once inside the system boundary, sensitive information is exposed again at each processing point.

Consumer end-to-end encryption, the model used by Signal, protects messages between sender and recipient. But healthcare requires multi-party access across physicians, specialists, billing teams, payers, and labs. Access requirements change over time and must be revocable. Consumer E2EE does not support revocation after delivery, centralized audit trails, or policy-based access controls for time, device, role, or geography.

Healthcare needs an encryption model that provides genuine end-to-end protection while supporting the complex, multi-party, policy-driven workflows the industry requires.

4.4 Tokenization and De-Identification Are Not Data Security

Beyond traditional encryption approaches, many healthcare organizations rely on tokenization and de-identification to reduce risk when sharing data across systems and organizations.

Platforms such as Datavant enable data to be linked, analyzed, and exchanged without directly exposing patient identifiers. These approaches provide significant value, particularly in life sciences, research, and clinical trial environments where identity resolution and longitudinal analysis are required.

However, tokenization is not a substitute for data security.

Tokenization replaces sensitive fields with tokens while maintaining a mapping that allows the original data to be re-associated when needed. In practice, this means that either the original data exists in identifiable form within the system, or the tokenized data can be re-identified through controlled processes. At some point in the workflow, the data must be available in plaintext.

This creates several limitations:

• No protection at the point of use: Systems that process or analyze data often require access to original values, exposing PHI in memory, logs, or downstream applications.
• Re-identification pathways introduce risk: Any system capable of resolving tokens back to identity becomes a high-value target.
• Limited control across systems: Tokenization does not enforce cryptographic access controls across vendors, applications, or infrastructure.
• No persistent protection after sharing: Once data is re-identified or combined with other datasets, control is effectively lost.

Tokenization is highly effective for specific use cases, particularly in research and data collaboration where identity abstraction is required. It is not designed to enforce continuous protection of PHI across operational healthcare workflows.

Data-layer encryption addresses a different problem. Instead of removing identifiers, it protects the data itself. PHI remains encrypted across storage, transit, processing, and sharing, and is only decrypted when explicitly authorized. There is no persistent plaintext exposure, no reliance on re-identification pathways, and no loss of control after data is shared. These approaches are complementary, not interchangeable. Tokenization enables data utility. Data-layer encryption ensures data security.

Tokenization assumes that systems, users, and intermediaries can be trusted to handle sensitive data appropriately. Data-layer encryption assumes that any system, user, or vendor may be compromised, and enforces protection accordingly.

5. What Data-Layer Security Actually Means

Traditional security asks: “Is this system secure?” Data-layer security asks: “Is this data secure, regardless of what system it is on?”

Data-layer security is a fundamentally different architecture. Instead of building walls around data or locking the rooms where data is stored, data-layer security locks the data itself. The protection travels with the data. It does not matter if the system is compromised, the administrator is malicious, or the vendor is breached. Without correct cryptographic authorization, the data is unreadable.

Effective data-layer security for healthcare must: encrypt data at the source before it touches any network or third-party system; maintain encryption across storage, transit, processing, and sharing; prevent intermediary access to plaintext without explicit cryptographic authorization; enforce access policies that travel with the data across organizations; support revocable, dynamic access control even after sharing; provide tamper-evident audit trails with cryptographic integrity; integrate into existing workflows without requiring operational changes; and scale across providers, vendors, payers, and analytics platforms.

6. Data-Layer Security as Zero Trust Architecture

The federal and enterprise cybersecurity conversation has moved decisively toward Zero Trust Architecture. NIST Special Publication 800-207 defines Zero Trust as an approach that assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location. CISA's Zero Trust Maturity Model identifies five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Of these, the Data pillar is arguably the most important and the least mature across healthcare.

Most organizations pursuing Zero Trust focus on identity verification and network segmentation. These are necessary but incomplete. A Zero Trust architecture that does not address the data layer leaves the most valuable asset unprotected. If an attacker bypasses identity controls, compromises credentials, or exploits a trusted insider's access, every record in plaintext is exposed.

Data-layer encryption is the data-centric Zero Trust implementation healthcare requires. It enforces the principle that no entity, whether a user, service, application, or administrator, is trusted with access to plaintext data without explicit, cryptographic, policy-driven authorization at the point of decryption. This maps directly to the most advanced tier of CISA's Zero Trust Maturity Model for the Data pillar:

• Every access request is authenticated and authorized cryptographically, not by network position or inherited credentials.
• Access decisions are continuous and dynamic. Policies can enforce time windows, device posture, geographic restrictions, and MFA requirements at the moment of decryption, not just at login.
• Access is revocable in real time. When trust is withdrawn, whether because a vendor contract expires, an employee changes roles, or a breach is detected, decryption capability is removed immediately across the entire ecosystem.
• Audit trails are tamper-evident and independent of the systems storing or processing PHI, ensuring that even compromised infrastructure cannot hide access events.

For healthcare organizations pursuing Zero Trust maturity, or responding to federal mandates such as Executive Order 14028 and its successors, data-layer encryption provides the component that network-centric and identity-centric tools cannot deliver on their own.

7. How Seald Healthcare Works

Seald Healthcare provides an encrypted data layer purpose-built for healthcare. PHI is encrypted at the source and protection is maintained across every system, vendor, and workflow the data touches.

7.1 End-to-End Encryption for Healthcare

PHI is encrypted at the source and only decrypted by authorized recipients. No intermediary, including Seald Healthcare itself, can access plaintext data. This is persistent, data-layer encryption where the cryptographic keys are independent of the infrastructure.

Unlike consumer end-to-end encryption, Seald Healthcare's model was designed from the ground up for healthcare's multi-party access requirements. A single patient record can be accessible to the treating physician, consulting specialists, the billing team, and the insurance payer, each with different permission levels, all enforced cryptographically.

7.2 Persistent Access Policies

Access policies travel with the data itself. Healthcare organizations can define exactly who can access data, from which devices, during which time windows, under which conditions (geographic, network, or MFA requirements), and for how long.

These policies are cryptographically enforced at the point of decryption, not at the network perimeter. They can be modified or revoked at any time, even after data has been shared. When a vendor's contract expires, access is revoked. When a staff member changes roles, permissions update automatically. When a security incident is detected, access can be suspended across the entire ecosystem in real time.

7.3 AI-Powered Policy Management

Seald Healthcare's AI Studio allows administrators to define access policies in plain English. Instead of configuring complex rule engines or writing security policies in technical syntax, an administrator can write:

“Only allow our clinical staff to decrypt patient records during office hours from managed devices.”

The AI Studio translates natural language into enforceable cryptographic policies. This dramatically reduces the complexity of policy management while eliminating the misconfiguration risk that causes a large percentage of breaches.

7.4 Tamper-Evident Audit Trails

Every access event, whether it is a successful decryption, a denied access attempt, a policy change, a key rotation, or a permission modification, is logged with cryptographic integrity. These logs cannot be altered without detection. They record who accessed data, when, from where, and from which device. They provide evidence-grade records for compliance audits, breach investigations, regulatory inquiries, and legal proceedings. They are maintained independently of the systems storing or processing PHI.

7.5 Developer-First Integration: SDK and API

Seald Healthcare integrates into existing healthcare workflows through a flexible, developer-first model that includes both SDK and API access. The Seald Healthcare SDK can be embedded into EHR systems, patient portals, telehealth platforms, secure messaging applications, file-sharing systems, and custom internal tools. For platforms that require server-side orchestration or third-party data exchange, Seald Healthcare also provides APIs that enable secure data access, policy enforcement, and interoperability across systems. Seald Healthcare supports single sign-on (SSO) with existing identity providers, ensuring authentication aligns with established organizational identity systems.

Integration does not require changes to existing clinical or administrative workflows. Staff continue to use the same systems they use today. Encryption and policy enforcement are applied at the data layer, ensuring that sensitive information remains protected across environments, including AWS, Google Cloud, and Azure.

7.6 Automatic Key Management

Key management is one of the most complex challenges in applied cryptography and a common point of failure in real-world systems. Seald Healthcare abstracts this complexity through a fully managed, policy-driven approach. Encryption keys are issued, rotated, rewrapped, and revoked automatically, without manual intervention. Key management is logically separated from infrastructure access, ensuring that cloud administrators and internal operators cannot access decryption keys. This prevents exposure of sensitive data through privileged access. The key lifecycle follows NIST best practices and is designed for quantum-safe cryptographic migration as post-quantum standards (FIPS 203/204/205) are adopted across the industry (NIST, 2024).

7.7 Group and Role-Based Access

Healthcare is organized around teams, departments, and roles, not individual users. Seald Healthcare supports this structure natively. Permissions can be assigned to care teams, departments, or roles rather than individuals. Access updates automatically as group membership changes. When a physician joins a department, they gain access to that department's encrypted data without manual provisioning. When a nurse transfers to another unit, permissions adjust accordingly. The system supports the complex access patterns healthcare demands: primary care teams, consulting specialists, and administrative staff can each hold different permission levels on the same data.

8. Performance, Latency, and Availability

Healthcare workflows are latency-sensitive. EHR response times, real-time claims adjudication, lab result delivery, and clinical decision support all require near-instantaneous data access. Record-level encryption with policy enforcement at the point of decryption introduces overhead that must be addressed transparently.

8.1 Performance Architecture

Seald Healthcare is engineered to minimize latency impact on clinical and administrative workflows. Our distributed, multi-vendor hybrid cloud architecture maintains a 99.999% uptime SLA, ensuring encryption and decryption services are consistently available when patient data is needed.

Typical key request round-trip latency is under 50 milliseconds, and decryption leverages hardware-accelerated cryptographic modules available on modern CPUs. For high-throughput workloads, bulk data processing is supported via GPU acceleration (CUDA).

8.2 Availability and Business Continuity

In healthcare, system availability is a life-safety requirement. A security platform that prevents providers from accessing patient data during an outage introduces unacceptable clinical risk. Seald Healthcare is designed with this constraint as a core principle.

Our geographically distributed, multi-vendor hybrid cloud architecture, combined with intelligent routing and on-demand backup systems, provides high resiliency and fault tolerance. For enterprise customers, Seald also supports on-premise deployments, including air-gapped environments, enabling additional redundancy, lower latency, and operational control.

8.3 Business Continuity, Key Recovery and Escrow

As part of the architecture described above, Seald Healthcare implements robust key management, recovery, and escrow mechanisms aligned with industry best practices. These systems ensure continuous access to encrypted data under defined policies while maintaining strict security controls. Additional technical details are available upon request.

9. Interoperability: FHIR, TEFCA, and Information Blocking

Healthcare data exchange is increasingly governed by interoperability mandates. The ONC's 21st Century Cures Act information blocking rules require that healthcare providers do not unreasonably restrict the access, exchange, or use of electronic health information. FHIR (Fast Healthcare Interoperability Resources) APIs have become the standard for clinical data exchange, while TEFCA (Trusted Exchange Framework and Common Agreement) is establishing a nationwide framework for health information exchange across networks.

A common concern is whether encrypting protected health information (PHI) at the data layer introduces friction with these requirements. It does not. Data-layer encryption secures the payload while allowing authorized access when required.

When a payer, provider, or health information exchange requests data under interoperability rules, the requesting entity is evaluated against defined access policies. If authorized, the data is decrypted at the destination endpoint. The interoperability obligation is fulfilled without exposing sensitive data beyond what is necessary.

PHI moving through FHIR APIs remains encrypted in transit and at rest across intermediate systems. Only the authorized endpoint receives plaintext. If a FHIR server, HIE node, or TEFCA-qualified network is compromised, the exposed data remains encrypted.

Rather than limiting interoperability, data-layer encryption strengthens it. Interoperability depends on trust. Organizations are more willing to exchange data when they retain control over it. A primary barrier to participation in health information exchanges and FHIR-based integrations is the loss of control once data leaves the organization. Seald Healthcare addresses this by enforcing policy-based access, along with post-share governance and revocation capabilities.

At scale, safe interoperability requires a shift in architecture. Data must remain protected regardless of the systems, networks, or vendors involved. Seald Healthcare enables this model by enforcing persistent, policy-controlled protection of sensitive data across the healthcare ecosystem.

10. What This Looks Like in Practice

Abstract security concepts become more meaningful when applied to real-world healthcare scenarios.

10.1 Vendor Breach

Without data-layer encryption: A revenue cycle management vendor is breached. The vendor has access to plaintext PHI for millions of patients across multiple healthcare organizations. As a result, sensitive patient data is fully exposed. The healthcare organization may not become aware of the breach for weeks and has no ability to limit further exposure. This pattern reflects incidents such as the Change Healthcare cyberattack.

With Seald Healthcare: The same vendor is breached, but all PHI passing through or stored by the vendor is encrypted. The attacker obtains ciphertext, which is unreadable without cryptographic authorization they do not have. The healthcare organization revokes the vendor's decryption permissions in real time. The audit trail shows exactly what data the vendor accessed before the revocation. Patient data remains secure.

10.2 Insider Threat

Without data-layer encryption: A database administrator with broad system access exfiltrates patient records. Traditional access controls cannot prevent individuals with legitimate administrative credentials from querying and extracting sensitive data. The organization may not detect the activity for months, often through an unrelated investigation. In 2024, a former employee at Nuance Communications, a contractor for Geisinger, accessed records of over 1.2 million patients after termination due to delayed credential revocation (HIPAA Journal).

With Seald Healthcare: The administrator can still access the database, but cannot decrypt PHI because decryption keys are managed independently of infrastructure credentials. Data stored in the database remains encrypted. All access attempts are recorded in a tamper-evident audit trail, with real-time alerts enabling immediate detection and response.

10.3 Ransomware Attack

Without data-layer encryption: Attackers exfiltrate PHI before deploying ransomware. Even if the organization successfully restores operations, the stolen data remains permanently exposed. This results in regulatory penalties, class-action litigation, and long-term reputational damage. UnitedHealth Group reported $3.1 billion in costs associated with a single ransomware incident.

With Seald Healthcare: Attackers may still exfiltrate data, but it remains encrypted. Without access to decryption keys, the data is unusable. The organization can demonstrate to regulators and patients that PHI was never exposed in plaintext. Under HIPAA's encryption safe harbor provision, breach notification requirements may not apply, as encrypted data is not classified as “unsecured PHI” under the Breach Notification Rule.

10.4 Tracking Technology Exposure

Without data-layer encryption: Website tracking pixels from Google, Meta, or other advertising platforms inadvertently capture and transmit patient data to third parties. Kaiser Foundation Health Plan exposed 13.4 million member records this way in 2024. The data was sent to advertising companies in plaintext (HIPAA Journal).

With Seald Healthcare: Even if tracking technologies capture data fields, the underlying PHI is encrypted. What gets transmitted is ciphertext. The advertising platform cannot read it. The exposure is neutralized.

11. The Encryption Safe Harbor

The HIPAA Breach Notification Rule (45 CFR Parts 160 and 164, Subparts D and E) requires covered entities and business associates to notify affected individuals, the Department of Health and Human Services (HHS), and in some cases the media when a breach of unsecured PHI occurs. The key distinction is “unsecured.”

HHS defines unsecured PHI as protected health information that has not been rendered unusable, unreadable, or indecipherable to unauthorized individuals. Guidance issued by the Secretary identifies two methods to achieve this standard: encryption consistent with NIST guidelines and destruction. If PHI is encrypted in accordance with NIST standards at the time of a breach, it is not considered unsecured PHI, and breach notification requirements may not apply.

This framework is commonly referred to as the encryption safe harbor, and it has significant financial implications for healthcare organizations.

Without safe harbor protection, a breach triggers a cascade of operational, financial, and legal consequences:

• Individual notification costs: Organizations must notify each affected individual. For large-scale breaches, these costs can reach hundreds of millions of dollars. The Change Healthcare cyberattack, which impacted approximately 192.7 million individuals, illustrates the scale of this burden.
• HHS notification and public disclosure: Breaches affecting more than 500 individuals are published on the HHS breach portal, often referred to as the “Wall of Shame,” where they remain permanently. This drives media attention and long-term reputational impact.
• Media notification: Breaches affecting more than 500 residents within a single jurisdiction require notification to prominent local media outlets.
• Regulatory investigation and penalties: Notification typically triggers investigation by the Office for Civil Rights (OCR), with potential financial penalties.
• Class-action litigation: Public disclosure frequently leads to class-action lawsuits, which have followed nearly every major healthcare breach in recent years.
• Cyber insurance impact: Breach-related claims increase premiums and may exceed coverage limits.
• Patient churn and revenue loss: Breach notifications erode patient trust and can lead to loss of business.

When PHI is encrypted in accordance with NIST standards at the time of a breach, the outcome is materially different. The organization can demonstrate that the data was secured under HIPAA's definition. In many cases, breach notification requirements do not apply. This avoids the downstream consequences associated with notification, including public disclosure, regulatory scrutiny, and litigation risk.

For financial and legal leadership, this is not a theoretical benefit. It is a measurable reduction in risk exposure. The average cost of a healthcare data breach is $7.42 million (IBM, 2025), with a significant portion driven by notification, investigation, and legal expenses that safe harbor protection can mitigate.

Seald Healthcare's encryption architecture is designed to meet the NIST standards specified in HHS guidance. PHI encrypted with Seald Healthcare is rendered unusable, unreadable, and indecipherable to unauthorized individuals, satisfying the requirements for encryption safe harbor.

12. Why This Cannot Wait

Several converging forces are making data-layer security an immediate priority for healthcare organizations.

12.1 Third-Party Risk Is Accelerating

Recent breaches, including the Change Healthcare cyberattack and the MOVEit data breach, demonstrate how vendor compromises can cascade across the healthcare ecosystem. A single breach at a third-party provider can expose data from dozens or even hundreds of organizations.

The average hospital works with more than 1,300 vendors (Ponemon Institute), significantly expanding the attack surface. In 2024, breaches involving business associates accounted for a disproportionate share of compromised records (HIPAA Journal). This risk is increasing as healthcare organizations continue to rely on external vendors for critical functions.

12.2 AI Adoption Is Expanding the Attack Surface

AI adoption across healthcare is rapidly increasing the volume and distribution of sensitive data. Clinical decision support, population health analytics, predictive modeling, and administrative automation all require access to patient information. Each model, pipeline, and data-sharing workflow expands the attack surface. Without data-layer encryption, this expansion directly translates into increased PHI exposure.

Modern AI systems also introduce new categories of security risk. The OWASP Top 10 for Large Language Model applications identifies prompt injection as the most critical vulnerability, observed in a majority of production deployments. Prompt injection enables attackers to manipulate AI systems into disclosing sensitive data, bypassing controls, or executing unintended actions by embedding hidden instructions in inputs such as documents, emails, or structured data.

In healthcare environments, these risks are not theoretical. AI systems that process clinical data can be influenced by malicious inputs, leading to data exposure or compromised outputs. Beyond prompt injection, AI architectures introduce additional leakage vectors. Retrieval-Augmented Generation (RAG) pipelines, which connect models to internal data sources, can expose sensitive information through techniques such as embedding inversion, where original data is reconstructed from vector representations.

Shadow AI further amplifies the risk. Employees increasingly use unauthorized AI tools to improve productivity, often without oversight. Industry research indicates that a significant portion of employees who use AI have submitted company data into external systems, with a meaningful percentage involving sensitive or regulated information. In healthcare, these interactions can directly result in unauthorized disclosure of PHI.

Data-layer encryption fundamentally changes this risk model. When PHI is encrypted before entering AI systems, it remains protected unless explicitly authorized for decryption. AI systems process only the data they are permitted to access. Prompt injection, embedding inversion, and unauthorized AI usage cannot expose data that is not available in plaintext.

As AI adoption accelerates, data-layer encryption becomes essential to ensuring that innovation does not come at the cost of data security. It provides a foundation for safely leveraging AI while maintaining control over sensitive healthcare information.

12.3 Regulatory Enforcement Is Tightening

Regulatory expectations for healthcare cybersecurity are increasing in both scope and enforcement. In December 2024, the Department of Health and Human Services (HHS) published a proposed update to the HIPAA Security Rule that would require organizations to implement controls such as multifactor authentication, encryption for data at rest and in transit, network segmentation, and ongoing security testing. Many of these measures have historically been treated as addressable rather than mandatory (HIPAA Journal; HHS NPRM, 2024).

Enforcement activity is also accelerating. The Office for Civil Rights (OCR) imposed 21 financial penalties in 2025 and has expanded its focus beyond breach response. Its 2026 enforcement priorities include broadening the Risk Analysis Initiative to encompass risk management, requiring organizations to demonstrate not only that risks are identified, but that they are actively mitigated in a timely manner (HIPAA Journal, 2025 Report). State attorneys general are increasing enforcement as well, adding another layer of regulatory pressure at the state level.

12.4 State-Level Privacy Laws Are Expanding Beyond HIPAA

HIPAA provides a federal floor, but a growing number of states are building well above it. Healthcare organizations operating across state lines now face a patchwork of health data privacy laws that impose additional obligations, broader definitions of protected information, and in several cases, private rights of action or aggressive attorney general enforcement that HIPAA itself does not provide.

Washington

Washington's My Health My Data Act, signed into law in April 2023, was the first state law in the country specifically designed to protect consumer health data that falls outside HIPAA's scope. The law applies broadly to any entity that conducts business in Washington or provides products or services targeted to Washington consumers, and it covers health data generated by apps, wearables, and online platforms in addition to traditional clinical data. Critically, any violation of the Act is a per se violation of the Washington Consumer Protection Act, which is enforceable by both the attorney general and through private right of action. Washington's attorney general has been among the most aggressive in the nation on data privacy enforcement, securing a $39.9 million settlement from Google over deceptive location tracking practices rather than joining a less lucrative multistate settlement.

California

California operates under multiple overlapping health data privacy frameworks that go far beyond HIPAA. The Confidentiality of Medical Information Act (CMIA), which predates HIPAA by more than 15 years, applies to a broader set of entities than HIPAA and imposes stricter standards on how medical information can be collected, used, and disclosed. A key difference from HIPAA is CMIA's private right of action, which allows patients to sue for negligent unauthorized disclosures even when there was no intent to cause harm. The California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA) gives consumers a private right of action for data breaches, with statutory damages ranging from $107 to $799 per consumer per incident. The California Attorney General has been active in enforcement, securing a $2.75 million settlement against Disney in 2026 and a $93 million settlement against Google in 2023. In September 2025, Governor Newsom signed AB-45, which strengthens protections for health-related location data, restricts geofencing around healthcare facilities, and provides a limited private right of action for violations. New regulations finalized by the California Privacy Protection Agency took effect January 1, 2026, including requirements for cybersecurity audits by businesses processing significant volumes of sensitive data.

New York

New York passed the Health Information Privacy Act (NYHIPA) through its legislature in January 2025, establishing one of the broadest health data privacy frameworks in the country. The bill defines “regulated health information” expansively to include any data reasonably tied to an individual and related to physical or mental health, including location and payment information. While Governor Hochul vetoed the 2025 version in December 2025, a revised version was reintroduced in the 2026 legislative session with expanded exemptions and modified penalty structures but the same fundamental framework. The New York Attorney General would have exclusive enforcement authority with civil penalties of up to $15,000 per violation. New York also recently amended its data breach notification law (General Business Law 899-aa) to expand the definition of “private information” to include medical and health insurance information and to impose a 30-day notification deadline, one of the shortest in the nation. Whether NYHIPA passes in 2026 or a subsequent session, the trajectory is clear: New York is moving aggressively to regulate health data beyond HIPAA's reach.

New Jersey

The New Jersey Data Privacy Act (NJDPA), effective January 2025, gives the New Jersey Attorney General enforcement authority with penalties of up to $10,000 for initial violations and $20,000 for subsequent offenses, plus investigative costs and attorney's fees under the Consumer Fraud Act. While the NJDPA exempts PHI processed by HIPAA covered entities and business associates, healthcare businesses that process personal data beyond traditional PHI, such as promotional emails to non-patients, consumer-facing wellness services, or telehealth platforms where users sign up directly, are subject to the law's full requirements. The cure period for violations sunsets in July 2026, after which enforcement proceeds without a grace period.

Connecticut, Nevada, Colorado, and Virginia

Connecticut amended its consumer data privacy act to impose transparency requirements and restrictions on consumer health data similar to Washington's My Health My Data Act. Nevada passed its own consumer health data privacy law with provisions modeled on Washington's approach. Colorado's Privacy Act, effective since July 2023, covers health and sensitive data with strict opt-in consent requirements and mandates data protection assessments for high-risk processing activities, with civil penalties reaching $20,000 per violation. Virginia amended its Consumer Protection Act in 2025 to focus on consumer health data privacy related to reproductive and sexual health information.

The Enforcement Reality

State attorneys general, particularly in California, New York, New Jersey, and Washington, have demonstrated a willingness to pursue enforcement actions and support class-action litigation that goes well beyond anything HHS OCR has attempted under HIPAA. The private rights of action available under Washington's My Health My Data Act, California's CMIA and CCPA, and Connecticut's amended privacy law create litigation risk that is independent of federal enforcement. For healthcare organizations operating in multiple states, the compliance burden is substantial and growing. Data-layer encryption provides a technical foundation that satisfies the most stringent requirements across all jurisdictions simultaneously, because data that is cryptographically secured at the source is protected regardless of which state's law applies.

12.5 Cyber Insurance Is Demanding More

Cyber insurers are shifting away from compliance checklists toward requiring demonstrable technical controls as a condition of coverage. Organizations that cannot demonstrate effective data protection measures will face higher premiums, reduced coverage, and exclusions that increase financial exposure in the event of a breach.

12.6 Post-Quantum Cryptography Is Coming

NIST has finalized its first post-quantum cryptographic standards (FIPS 203, 204, and 205), and organizations across industries are beginning to plan for migration or at least they should. Healthcare organizations that have not modernized their cryptographic architecture will face costly and disruptive upgrades as these standards are adopted. Seald Healthcare's architecture is designed to support quantum-safe cryptographic migration, providing strong protection today while enabling a seamless transition as standards evolve (NIST, 2024).

13. Getting Started

Adopting data-layer security does not require replacing existing infrastructure. Seald Healthcare is designed to layer on top of current systems, complementing existing security investments while addressing the gaps left by perimeter-based approaches.

Seald Healthcare supports three integration paths. SDK integration embeds the Seald Healthcare SDK directly into applications, enabling encryption, decryption, key management, and policy enforcement. Gateway deployment encrypts data as it enters or exits environments that cannot be modified at the application level. API-based integration supports custom workflows, including analytics pipelines, interoperability requirements, and specialized use cases.

Implementation is measured in minutes, not months. Organizations can begin by securing high-risk workflows and expand coverage incrementally over time. There is no requirement to encrypt all data at once.

Data-layer security does not replace existing security infrastructure. Firewalls, identity providers, SIEM systems, and endpoint protection remain in place. Seald Healthcare adds a layer of cryptographic protection that these systems do not provide. Even if perimeter controls fail, data encrypted with Seald Healthcare remains unreadable without explicit authorization.

14. Conclusion

Healthcare does not have a compliance problem. It has a data security problem.

The numbers are clear. More than 900 million patient records have been compromised since 2009, including nearly 277 million in 2024 alone. A single breach affected 192.7 million individuals. Healthcare breach costs have exceeded every other industry for 14 consecutive years. Enforcement actions are increasing, litigation is expanding, and third-party risk continues to grow. At the same time, a fragmented landscape of state-level privacy laws is creating new layers of liability that HIPAA was not designed to address. AI adoption is introducing entirely new categories of data exposure.

Compliance frameworks and cloud platforms remain essential. They provide baseline protections, operational discipline, and regulatory alignment. However, they were not designed to secure PHI as it moves across the modern healthcare ecosystem, an environment defined by hundreds of vendors, thousands of integration points, and millions of daily data transactions.

The gap is structural. Perimeter-based security protects systems. Data-layer security protects data. Healthcare requires both.

Closing this gap requires a shift in architecture. Data must be encrypted at the source, governed by persistent policies that travel with it, and protected by tamper-evident audit trails. It must remain secure across systems, networks, and vendors, and be prepared for the transition to quantum-resistant cryptography.

For interoperability to function at national scale through FHIR APIs, TEFCA, and health information exchanges, the data itself must remain protected end-to-end. Without this foundation, the industry is extending nationwide data exchange on the same plaintext architecture that has already resulted in hundreds of millions of compromised records.

Organizations that make this shift will be better positioned to meet evolving regulatory expectations, insurance requirements, and the continued expansion of AI and interoperability. Those that do not will remain dependent on perimeter-based models that have repeatedly failed to protect patient data.

Learn more at www.sealdhealthcare.com or contact info@sealdhealthcare.com.