If you run security or compliance for a healthcare organization, the recent run of breach notifications is less a reason to panic than a reason to look carefully at one specific layer of your stack. Two separate incidents — at a New Jersey health insurer and a Texas home-health management company — have now put personal information for more than a quarter of a million patients into the wrong hands. They are not connected to each other. That is precisely what makes them worth studying together: two unrelated organizations, two different failure paths, the same underlying weakness.
This post walks through what happened, where these breaches fit in the broader 2026 healthcare landscape, and — most usefully — what a HIPAA-regulated team can actually do about the layer where this damage keeps happening. The goal here is calm, practical clarity, not alarm. The systemic issues are real, but they are also addressable with controls most teams can put in place without rebuilding everything they already have.
What Happened: Two Breaches, 250,000+ Patients
According to SecurityWeek’s reporting on data breaches at the New Jersey and Texas healthcare firms, two unrelated organizations disclosed incidents that, combined, affected well over 250,000 people.
Clover Health Investments, a New Jersey-based health insurer, notified a large group of individuals that their personal information had been compromised. For a payer, the data at stake is rarely limited to a name and an email. It typically spans the full span of what makes healthcare data so attractive to attackers: identifiers, coverage and member details, and the kind of information that supports both identity theft and medical fraud.
AngMar Management Services, a Texas-based company that provides management services to home-health and hospice agencies, disclosed a separate incident affecting its own population of patients and individuals. Home-health and hospice contexts tend to involve especially sensitive records — the information is detailed, it concerns people in vulnerable circumstances, and it moves between multiple parties (the agency, the management company, and various downstream systems).
The two incidents share no common cause in the reporting. One is an insurer; the other is a management-services firm serving care providers. What they share is the outcome: attackers reached the data that these organizations are legally and ethically obligated to protect, and large numbers of patients now carry the long tail of that exposure.
That shared outcome, across two unrelated organizations, is the signal worth paying attention to. When different companies with different architectures and different threat models keep producing the same result — patient data leaving the building — the problem is usually not any single organization’s negligence. It is a structural weakness in how the industry tends to secure the data tier.
The Broader Healthcare Breach Landscape in 2026
These two incidents are not outliers. They are two data points in a year that has been difficult for healthcare security as a whole.
The HIPAA Journal’s H1 2026 healthcare data breach report documents the scale plainly: 397 data breaches reported in the first half of the year, with more than 19 million individuals affected. Healthcare remains one of the most consistently targeted sectors, and the reasons are not mysterious.
A few structural factors keep healthcare in the crosshairs:
- The data is uniquely valuable. A health record is a bundle of identity, financial, and medical information that does not expire the way a credit card number does. You can reissue a card. You cannot reissue a patient’s medical history.
- The ecosystem is fragmented. Care involves providers, payers, management-services firms, billing vendors, labs, and software platforms — each a potential path to the same underlying data. AngMar’s role as a management-services company is a reminder that the organization holding the data is often not the one that originally collected it.
- Legacy systems and rapid cloud migration coexist. Many healthcare organizations run a mix of older on-premises systems and newer cloud workloads, and the seams between them are where visibility tends to break down.
- Attackers have industrialized the playbook. Credential theft, lateral movement toward the database, and bulk exfiltration or encryption is a repeatable pattern now, not a bespoke operation.
Nineteen million people in six months is a number large enough to feel abstract. The useful way to read it is not as a crisis to react to, but as confirmation of where the effort should go. The breaches cluster around the same layer again and again, which means the defense can cluster there too.
Why the Data Tier Is the Weakest Link
Here is the pattern that connects nearly every one of these incidents, including the two in the SecurityWeek report. The attacker’s objective is the data. Everything else — the phished credential, the exposed service, the misconfigured bucket — is just a route to the database where the patient records live.
Most healthcare security programs have invested heavily in the outer layers, and that investment is not wrong. Posture management catches misconfigurations. Vulnerability scanning finds unpatched systems. Data discovery tools can even tell you where your sensitive data sits. This last category — often called DSPM — has become popular precisely because knowing where the protected health information lives feels like the foundational step.
And it is a useful step. But it exposes a gap that is easy to miss: DSPM tells you where the data is. It does not watch who touches it.
Think about what that means in practice. You can have a perfect inventory of every database holding patient records, every column that contains a Social Security number or a diagnosis code, every table that would trigger a breach-notification obligation if it leaked. And still have no answer to the question that actually matters after an incident: who ran which query against that table, and what did they see?
That question lives at the data tier, and it is the question native tooling tends not to answer. Cloud audit logs like CloudTrail capture API-level events — someone modified the database instance, changed a parameter group, took a snapshot. They do not capture the SQL that runs inside the database. A support engineer connecting to a production database and running SELECT * FROM patients does not show up as a cloud API event. It shows up nowhere, unless something has been deliberately placed in that path to see it.
This is the heart of the matter. The outer layers are well-tended; the data tier, where the actual loss happens, is frequently the one layer with no behavioral visibility at all. Database Activity Monitoring exists specifically to close that gap — to answer “who queried what, and what did they see” at the layer where the records live.
Standing Database Access: The Hidden HIPAA Risk
If the data tier is the weakest link, standing access to it is the single thread most likely to pull the whole thing apart.
Consider how database access typically works at a healthcare organization. There is an application credential the service uses. There are also, almost always, human access paths — engineers who need to debug a production issue, DBAs who maintain the systems, support staff investigating a ticket, and very often third-party vendors who were given access during an integration and never had it revoked. Each of those paths frequently relies on a standing credential: a database password that exists permanently, is often shared, and sits in a config file, a password manager, or someone’s memory.
Standing credentials are the breach vector in a large share of these incidents. The reason is simple. A permanent, shared password is a target that never moves and never expires. If it is phished, leaked in a prior breach, or lifted from a compromised laptop, the attacker inherits exactly the access the legitimate holder had — and because the credential is shared, the resulting activity cannot even be reliably attributed to a specific person after the fact.
For a HIPAA-regulated organization, this is doubly costly. It is both the thing most likely to cause the breach and the thing most likely to fail an audit. The HIPAA framework’s expectations around access control and audit controls are fundamentally about knowing — and being able to prove — exactly who had access to protected health information and what they did with it. A shared, standing database password undermines both halves of that at once. You cannot enforce least privilege with a credential everyone shares, and you cannot produce clean attribution from a login that could have been anyone.
The vendor dimension deserves special mention, because AngMar’s situation — a management-services firm sitting between care agencies and their data — is exactly the kind of multi-party arrangement where standing vendor access tends to accumulate quietly. Every integration, every contractor, every “temporary” grant that outlived its purpose adds another permanent key to a lock that guards patient records.
The alternative is not to lock everyone out. People genuinely need to access these systems to do their jobs. The alternative is to make that access temporary, individually attributed, and keyless — which is exactly what just-in-time access is built to do.
What HIPAA Security Teams Should Do Right Now
None of this requires a rip-and-replace. The most effective moves are targeted at the data tier and the access paths into it. Here is a practical order of priority.
1. Inventory every path into your databases
Not just the application credentials — the human and vendor paths too. Who can reach the databases holding PHI? Through what credential? Is that credential shared? When was it last rotated? Most teams are surprised by how long this list is once they actually write it down. Standing vendor access, in particular, has a way of outliving the project that created it.
2. Eliminate shared, standing database passwords
This is the highest-leverage single change. Replace permanent shared credentials with access that is granted on request, tied to a named identity, and expires automatically. Database Just-in-Time access provides keyless, time-boxed, identity-stamped connections — no shared password to steal, and a clean record of who had access when.
3. Extend JIT to the cloud infrastructure layer too
Database access is one path; the cloud console and infrastructure APIs are another. Cloud JIT applies the same zero-standing-privilege model to AWS, Azure, and GCP access, so an attacker who phishes a credential does not inherit permanent reach into your environment.
4. Add query-level visibility and masking at the data tier
Even authorized access should not mean unrestricted visibility. Dynamic masking means a support engineer debugging a billing issue sees the records they need without the raw Social Security numbers or full diagnosis details they do not. And query-level logging means that after any incident, you can answer the question auditors and investigators will ask first.
5. Map your controls to HIPAA and keep evidence audit-ready
CSPM with HIPAA mapping turns the posture of your cloud environment into continuous, exportable evidence — so an audit is a report you generate, not a scramble you survive.
6. Correlate identity and posture, not just findings
Isolated misconfigurations rarely tell the real story. CIEM connects identities to the entitlements and resources they can actually reach, which is how you spot the over-permissioned account or forgotten vendor role before an attacker does.
How DAM + JIT + CSPM Close the Healthcare Security Gap
The three controls above are strongest together, because each closes a different part of the same path an attacker takes toward patient data. Here is how they fit at Cloudanix specifically.
DAM: control over what people actually see
The core pain Database Activity Monitoring addresses is blunt: you gave someone database access, but you have no control over what data they see. An application role or a human login that can reach the patients table can, by default, read every column in it.
Cloudanix DAM runs as a secure query proxy inside the customer’s own ECS — meaning the data never leaves your cloud environment, which matters a great deal for HIPAA and for any organization careful about where PHI travels. On top of that proxy, it provides:
- Dynamic PII masking with eight configurable strategies, so sensitive columns are masked at query time based on who is asking. The engineer sees the shape of the data without the raw identifiers.
- Destructive-query prevention, so a mistaken or malicious
DELETEorDROPagainst production is stopped before it runs — not mourned afterward. - Query-level audit logging, so every statement is attributable to an identity and available as evidence. This is the record that answers “who touched the patient records, and what did they see.”
Cloudanix DAM supports PostgreSQL, MySQL, and MSSQL. The unattributed figure the team cites — roughly a 90% reduction in breach risk at the data tier — reflects what happens when access stops meaning unrestricted visibility.
JIT: remove the standing credential entirely
The breach vector in so many of these incidents is the permanent, shared database password or vendor credential. Database JIT removes it. Access becomes keyless, identity-stamped, and time-boxed — granted when needed, gone when the window closes, and attributable to a real person throughout. There is no shared password to phish, leak, or inherit. Cloud JIT extends the same discipline to the infrastructure layer, so neither the data tier nor the control plane carries standing access.
CSPM: continuous HIPAA evidence
Cloudanix CSPM runs more than 1,000 checks and maps them to compliance frameworks including HIPAA, turning your cloud posture into audit-ready evidence you can export on demand. Instead of assembling proof during an audit, you maintain it continuously — and you see posture drift the moment it happens rather than at the next assessment.
Brought together under Cloudanix CNAPP+, these are not three separate tools bolted on. They are one view of the same path an attacker would take, with the data tier — the part most programs leave least watched — treated as a first-class concern rather than an afterthought.
Building a Data-First Security Posture for Regulated Environments
The through-line of 2026’s healthcare breaches is that the industry has gotten good at securing the perimeter and the posture, and is still catching up on the layer where the loss actually occurs. A data-first posture simply reorders the priorities to match where the damage happens.
In practice, a data-first posture for a HIPAA-regulated environment rests on four commitments:
- No standing access to systems holding PHI. Every connection — human, vendor, or otherwise — is temporary and individually attributed. The permanent shared credential is gone.
- Authorized access does not mean unrestricted visibility. Masking and least privilege apply at the query layer, so people see what their role needs and nothing more.
- Every touch of the data tier is recorded and attributable. The question “who queried the patient table and what did they see” has an answer, always, available before an incident forces you to find one.
- Compliance is a continuous state, not an annual event. Posture is mapped to HIPAA and kept audit-ready, so evidence is generated, not reconstructed.
The reassuring part is that this is a finite, well-understood set of controls, not an open-ended project. The two breaches in the SecurityWeek report, and the 397 incidents behind the H1 2026 numbers, point at the same place. That focus is a gift, in a way — it tells you exactly where the next hour of effort will do the most good.
Healthcare organizations are entrusted with some of the most sensitive data anyone holds, under some of the most demanding obligations. The teams protecting that data are doing hard, consequential work. The point of a data-first posture is not to add weight to that work, but to aim it — at the one layer where, year after year, the records keep walking out the door.
Where to Start
If you take one thing from this: look at who has standing access to your databases holding PHI, and start closing those paths. If you want to see how Database Activity Monitoring, Database and Cloud JIT, and HIPAA-mapped CSPM fit your environment, talk to the Cloudanix team — we will walk through your data tier with you and show where the gaps are, calmly and concretely.
People Also Read
- A Practical Guide to Achieving HIPAA Compliance in AWS
- Why Your Developers Shouldn’t See Raw Production PII — and How to Prevent It
- Database Activity Monitoring Explained: What It Is and How It Differs From Native DB Logging
- Securing Databases Behind ECS: The Data Tier Blind Spot in Cloud Security
- Elevate Your Security With IAM Just-in-Time (JIT) Access
