Healthcare DSPM rollouts have an unusual property: the discovery phase produces numbers that nobody on the customer side is happy to hear, but everyone is grateful to know. This deployment was no exception. The clinical-systems lead's reaction in the week-two readout, almost verbatim, was: "I would have bet a month's salary the answer was under three thousand. The answer is eleven." The "eleven" was thousand-scale sensitive data assets discovered across the estate. Three-thousand-two-hundred of them lived in places nobody on the IT side had on a list.
The case study below covers a six-week pilot across all fourteen hospitals, which then transitioned into a steady-state operating model. The pilot's deliverables were a complete sensitive-data inventory, a closed set of over-permissioning remediation tickets, a DPDP-readiness re-audit pack, and a HIPAA breach 72-hour workflow that had been exercised end-to-end against simulated incidents.
Before Netgraph
The network had grown by acquisition. Three of the fourteen hospitals had been added in the previous four years, each arriving with its own EMR, its own staff directory, its own legacy file shares, and its own approach to data classification — which in two of three cases was "we don't". Six distinct EMR systems were in production across the estate, two of them on-premises, three in single-tenant private cloud, one in a shared public-cloud environment.
The security posture, to the team's credit, was not absent. There was a SIEM (a Type C small-vendor product), an EDR rolled out to roughly 80% of endpoints, and a patch scanner that ran weekly against the server estate. Where the posture collapsed was data. Nobody could answer, with evidence, where patient records lived, who had read access to them, or whether that access matched the staff member's clinical role. The compliance team had compensated by writing policy. There were eighteen pages of policy. None of it was enforced because none of it was measurable.
Three concrete failure modes drove the engagement.
- Two patient-data exposure incidents in 18 months. Both were small in absolute terms — one was a file-share with broken inheritance that exposed about 1,800 patient records to staff outside the relevant department, and the second was a clinical-research bucket that had been left world-readable for six days after a misconfigured infrastructure-as-code change. Neither was malicious. Both were the kind of thing a DSPM with a live graph would have flagged within minutes. Both required disclosure under emerging DPDP guidance and triggered uncomfortable conversations with the medical directors of the affected hospitals.
- A failed DPDP readiness audit. An external assessor had been engaged to dry-run the network against the DPDP framework six months before the project. The report came back with twenty-seven findings; nineteen were directly about data classification, access control, and breach-response readiness. Two were classed as "critical, must remediate before going live". The compliance team did not have the tooling to remediate at scale; their existing approach was a quarterly manual access review per hospital, which produced 14 spreadsheets and an action list that nobody had bandwidth to act on.
- HIPAA breach 72-hour readiness was untested. The network's US-resident research collaborations brought HIPAA into scope for a meaningful subset of data. The breach-notification clock under HIPAA is 60 days from discovery for notifications, but the network's internal target was a 72-hour readiness window from incident detection to a complete impact assessment — the artifact that determines whether the breach is reportable. That workflow had never been exercised against a real or simulated incident. The IR runbook was 14 pages of well-meaning prose and zero tested automation.
The trigger for the project was the DPDP re-audit deadline. The board had agreed to a nine-month window to remediate the original report's findings. The compliance team had used four of those nine months building a programme around manual remediation and concluded, in month five, that it was not going to land. Netgraph was brought in for what was originally scoped as a DSPM proof-of-concept and ended up replacing the SIEM and EDR consolidation roadmap as well.
Why Netgraph
The hospital network looked at three DSPM vendors plus Netgraph. The other three were specialist DSPM products — good at the discovery and classification step, but each requiring a separate platform for SIEM, EDR, and incident response. Netgraph was the only platform on the shortlist where DSPM was a module on the same substrate as everything else.
Four reasons drove the choice.
- DSPM as a graph module, not a silo. A sensitive-data asset is a node. The identities with access are nodes. The devices those identities sign in from are nodes. The patch state of those devices is an attribute on the device nodes. The EMR application is a node. The result is that the question "who can read patient records, from what device, in what patch state, in which department, with what clinical justification" is a single graph traversal — not a join across four products. The DSPM head's note from the evaluation: "This is the first product that doesn't ask me to email the EDR team to find out whether the laptop accessing patient data is patched."
- DPDP and HIPAA evidence packs out of the box. Netgraph ships with control mappings for DPDP and HIPAA pre-loaded against its detection and policy library. The evidence pack for a DPDP-readiness audit is a graph projection, not a quarter-end spreadsheet exercise. The compliance team verified this in the second week by re-generating the failed audit's twenty-seven findings against the graph and seeing them produce live status flags with link-outs to remediation tickets.
- India-resident operations and clear DPDP residency posture. All sensitive-data scan results, all metadata, all model invocations stay in Indian data centres. The DPDP "significant data fiduciary" residency expectations are met structurally. The other three shortlisted DSPM vendors had to write residency commitments by hand; Netgraph showed them on the storage layout.
- Path to consolidate SIEM and EDR onto the same graph. The Type C SIEM was nearing renewal. The EDR was a perfectly acceptable point product but the team did not enjoy operating it as a separate console. Picking Netgraph for DSPM gave the network a credible roadmap to retire two more products in the following twelve months — not as a forced consolidation, but as a natural one because the data was already on the same substrate.
The deciding meeting was not a feature comparison. It was the question, asked by the chief medical information officer: "If a research-bucket misconfiguration like the one we had last year happens again, how fast do we know, and what do you show the medical director?" Netgraph's answer was a live walkthrough on the demo environment that ended with the impact graph — patients affected, departments affected, identities with access, devices touched — generated in roughly two minutes. The competing DSPM vendors answered the same question in language. That was the point at which the room made up its mind.
Implementation
The pilot was scoped at six weeks for the full fourteen-hospital footprint. We split the work into four phases that overlapped deliberately — the discovery output from phase 1 was needed as input to phase 2, but the IR-workflow design in phase 3 could begin against synthetic data while discovery completed.
| Phase | Weeks | Scope | Exit criteria |
|---|---|---|---|
| 1 — Discovery and classification | 0 to 2 | Connectors stood up for six EMR systems, on-premises file shares, two cloud object stores, the imaging archive, and the clinical-research environment. Healthcare classifier pack loaded (MRN, DOB, diagnoses, lab results, imaging metadata, insurance identifiers). Scan executed across the estate. | Complete sensitive-data inventory; classification confidence above 95% on a 500-record audit sample reviewed by the data-protection officer. |
| 2 — Identity and access graph | 1 to 3 | Staff directory federated into the graph. Clinical-role-to-data-type matrix loaded as policy. Access edges from identities to sensitive-data nodes computed and overlaid. Device posture from the EDR joined onto identity sign-in edges. | Every sensitive-data node has at least one identity edge or is flagged as orphan. Every identity edge has a clinical-role policy classification (in-scope, out-of-scope, or "requires justification"). |
| 3 — Remediation and IR workflow | 2 to 5 | Over-permissioning tickets generated per hospital, batched by department and routed to local IT leads. HIPAA and DPDP breach-response workflows configured. BAS scenarios authored for two healthcare-specific data-exposure patterns (file-share misconfiguration; research-bucket exposure). | 80% of over-permissioning tickets closed or accepted-with-justification. HIPAA 72-hour breach workflow dry-run end-to-end on a BAS-generated incident. |
| 4 — Re-audit and operating handover | 5 to 6 | DPDP-readiness evidence pack generated. External re-audit conducted against the original twenty-seven findings. Operating handover to the DPO and the SOC team. Quarterly access-review automated. | Re-audit clears. Operating runbook signed off. First automated quarterly access review scheduled and dry-run. |
The discovery phase produced the headline of the engagement. Eleven thousand four hundred sensitive-data assets were identified across the estate. Of those, 3,200 were in locations that did not appear on the IT team's existing list of patient-data systems. The breakdown of the previously-unknown 3,200 is itself instructive:
- ~1,400 in clinical user file shares. Patient summaries, lab exports, and consultation notes saved to personal departmental shares for convenience. Most were duplicates of records that also lived properly in the EMR, but the duplicates were not access-controlled to the same standard.
- ~900 in the research environment. De-identification had been done on most research datasets, but a subset of older datasets retained MRNs in joined-but-archived tables. The research team had simply lost track of them.
- ~600 in legacy backup mounts. Backup snapshots from a hospital integrated two years prior were still accessible on a network share. The hospital's own systems had been decommissioned. Nobody had decommissioned the backups.
- ~300 in cloud object storage. Mostly imaging exports for second-opinion workflows. The buckets had been used for one-off transfers and not cleaned up.
None of this was a security failure of the kind that makes headlines. All of it was a data-hygiene failure of the kind that fails DPDP audits and turns small misconfigurations into reportable breaches. Finding it was the whole point.
The identity-and-access graph in phase 2 produced the second uncomfortable number. Of 22,000 staff identities, 7,800 had at least one access edge to patient data. Of those 7,800, the graph flagged 3,114 as "access not consistent with clinical role" — meaning either the role didn't normally require patient-data access (e.g. facilities, vendor accounts, administrative interns) or the access was scoped far wider than the role's documented data-class boundary. After remediation through phase 3, that number dropped to 502, of which 487 were accepted-with-justification (e.g. cross-departmental medical leads, audit roles, named clinical research staff) and 15 were flagged for ongoing monitoring. The remaining 84% reduction in over-permissioning came largely from removing legacy group memberships that had accumulated over years of staff movements.
Phase 3's BAS exercises were the work nobody had previously had time to do. The team authored two healthcare-specific exposure scenarios — a file-share inheritance break and a public-bucket misconfiguration — and replayed them against the live graph. The first scenario produced a detection in 41 seconds; the second in 18 seconds. The 72-hour HIPAA workflow then generated a complete impact assessment — patients affected, data classes involved, regulatory clocks, notification templates — in 6 minutes 30 seconds against the simulated incident. The IR lead's reaction, paraphrased: "Six and a half minutes of compute did what would have been a three-day project for my team."
Outcomes
The numbers below cover the six-week pilot through to a four-week steady-state measurement window. The "before" column is sourced from the failed DPDP readiness audit, the pre-existing SIEM/EDR baselines, and the manual quarterly access-review reports from the four quarters preceding the engagement.
| Metric | Before | After | Change |
|---|---|---|---|
| Sensitive-data assets on inventory | ~8,200 (estimate) | 11,400 (discovered) | +39% (and now exhaustive) |
| Previously-unknown sensitive-data assets | n/a | 3,200 | New visibility |
| Identities with patient-data access | 7,800 | 7,800 (unchanged) | Same denominator |
| Over-permissioned identities | 3,114 | 502 (487 justified, 15 monitored) | −84% |
| Orphan sensitive-data assets (no clear owner) | Unknown | 118 → 0 after cleanup | Resolved |
| DPDP readiness audit findings | 27 (2 critical) | 0 (re-audit cleared) | −100% |
| HIPAA 72-hour breach workflow | Untested, manual | Dry-run end-to-end in 6.5 min on BAS incident | New capability |
| Quarterly access review | 14 manual spreadsheets, ~3 weeks | Automated, evidence-pack export | Operational |
| Patient-data exposure incidents (12-month rolling) | 2 in prior 18 months | 0 since cutover | To-date only; reported here as observation, not steady-state claim |
| Time-to-impact-graph on simulated exposure | n/a (manual, days) | ~2 minutes | New capability |
One number deserves to be explicitly not claimed. We do not claim that the patient-data-exposure incident count has gone to zero on the basis of three months of post-cutover observation. We claim that none have been detected in that window, that the BAS workflow can reproduce both of the historical incident patterns and would now flag them within sixty seconds, and that the DPDP and HIPAA workflows would handle them within their respective clocks. Three months is not enough data to claim a long-run rate change. The structural risk reduction — measured by over-permissioning, discovery completeness, and workflow readiness — is the right summary.
We spent five years writing policy nobody could enforce. In six weeks we have a graph that enforces it, evidence that proves it, and a workflow that handles a breach in minutes instead of a working week. The patients we serve do not know any of this. They should not have to.
Key results
- 11,400 sensitive-data assets discovered across 14 hospitals — 3,200 of them in locations the IT team did not previously know existed.
- Over-permissioned access to patient data cut by 84%, from 3,114 identities to 502 (of which 487 are documented exceptions).
- DPDP readiness re-audit cleared in a single cycle; all 27 original findings closed, including both critical findings.
- HIPAA 72-hour breach workflow stood up and dry-run end-to-end against a BAS-generated incident in 6 minutes 30 seconds — first time the network has ever exercised the workflow.
- Quarterly access reviews moved from 14 hand-built spreadsheets and three weeks of effort to an automated evidence-pack export.
- Roadmap for SIEM and EDR consolidation onto the same graph has been signed off; two further products earmarked for retirement in the next twelve months.
What's next
Three workstreams are queued for the second half of 2026.
SIEM and EDR consolidation onto the graph. The Type C SIEM's renewal falls in Q3. The plan is to migrate detection content onto Netgraph's graph-pattern engine and retire the SIEM. The EDR will remain as the on-endpoint sensor; its telemetry already flows to the graph. The savings projection is comparable to the BFSI deployment summarised in our other case study work — high double-digit percentage reduction in run-rate — but the more important effect is that incident triage and DSPM live on the same console.
Imaging and laboratory device graph. Medical-imaging modalities and laboratory analysers are not in scope of the current DSPM rollout because they are not "data stores" in the conventional sense. They are, however, sources of sensitive data that travel through the estate. The next phase models these devices as first-class nodes — with patch state, vendor maintenance windows, and data-flow edges to the imaging archive — so that imaging-device misconfigurations get the same graph-level visibility as file-share misconfigurations do today.
Cross-hospital detection-pack sharing. The network has agreed in principle to publish anonymised detection content back to the wider Netgraph community — patterns specific to healthcare data exposure, EMR-export abuse, and clinical-research misconfiguration. This is the same model the BFSI deployment is exploring; the healthcare and BFSI peer groups will not share content with each other, but each group benefits from shared content within its own peer set.
The underlying point: healthcare DSPM is not a tooling problem. It is a data-hygiene problem with a tooling enabler. The tooling, when it is graph-native, makes the hygiene legible. The hygiene is then a programme that organisations actually run, rather than a policy document that lives in a binder. None of this required a different SOC team; it required a different substrate underneath the SOC team.
Sample case study. Composite of representative deployments; customer details anonymised.