Your team published aggregate statistics on a public-facing website. The dashboard shows enrollment counts, demographic breakdowns, and service utilization rates. No names or Social Security numbers appear on screen, just summary tables and charts.
Three years later, you find out that the underlying data structure contained full beneficiary records, accessible to anyone who knew how to query the page source or export the data feed.
This scenario happened at the District of Columbia Department of Health Care Finance (DHCF). Nearly 400,000 Medicaid and DC Healthcare Alliance beneficiaries were notified in July that their personal information had been exposed on the agency's website since 2023. The breach notification to the US Department of Health and Human Services (HHS) confirmed that Medicaid IDs, provider names, dates of birth, race, gender, ethnicity, and ward information were accessible to unauthorized users, even though none of this appeared in the visible interface.
These incidents persist because organizations operate under faulty assumptions about web publication, what "de-identified" means technically, and where data governance responsibility ends. Here are six myths that lead to accidental public exposure.
Myth 1: If the UI doesn't display PII, the data is protected
Reality: Display logic and data structure are separate layers. A reporting interface might show only aggregate counts, while the API endpoint, JSON feed, or embedded data object contains row-level records. Modern web applications often load full datasets client-side and filter them in the browser, meaning the complete data arrives on the user's machine before any masking occurs.
In the DHCF incident, reports showed "only summary information about groups of people, such as enrollment counts and other statistics" on screen, yet the underlying data remained accessible. This pattern appears in business intelligence tools, JavaScript charting libraries, and custom dashboards where developers prioritize performance over security.
Your pre-publication checklist must include inspecting network traffic in browser developer tools, examining the page source for embedded JSON, testing the API endpoints directly, and verifying that server-side filtering occurs before data leaves your infrastructure. If your front-end developer can access the raw data to build the visualization, so can anyone else.
Myth 2: We ran a de-identification process, so we're compliant
Reality: De-identification is a legal standard, not a technical checkbox. Removing direct identifiers like names and Social Security numbers doesn't automatically render a dataset non-identifiable, especially when you retain dates of birth, geographic indicators, and demographic attributes in combination.
The DHCF dataset excluded Social Security numbers, names, and financial information, yet still contained Medicaid IDs, provider names, dates of birth, race, gender, ethnicity, and ward. Depending on how these fields combine, re-identification risk may remain substantial. A Medicaid ID is itself a persistent identifier. A date of birth plus ward plus provider name can narrow to a very small population.
GDPR Recital 26 clarifies that information should be considered identifiable if the data subject can be identified "directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person." Your de-identification assessment must include combinatorial analysis, not just a field-by-field review.
Myth 3: Our web team handles publication; data governance doesn't need to review
Reality: Data governance owns the data lifecycle through publication. The boundary between "internal" and "external" isn't the firewall, it's the point at which data becomes accessible to an uncontrolled audience. Publication to a public website is a transfer event that requires the same rigor as sharing data with a third-party processor.
DHCF's incident notice acknowledged that "underlying personal information that supported these reports may have been reachable by unauthorized users between 2023 and July 2026." This suggests a gap between what the business unit intended to publish and what the technical implementation actually exposed, a gap that data governance procedures should close.
Before any dataset reaches a web server, your governance workflow should include a data classification review, a minimum necessary determination, technical controls validation (server-side filtering, access logging, rate limiting), and a publication approval from someone who understands both the regulatory requirements and the technical architecture. The web team implements; governance approves.
Myth 4: We'll catch problems during our annual audit
Reality: Annual audits detect last year's mistakes. The DHCF data remained accessible from 2023 until discovery in July 2026, likely more than two years of exposure. Annual reviews operate on a cycle that doesn't align with the speed of web publishing or the frequency of site updates.
Effective monitoring requires continuous controls: automated scans of public endpoints for unexpected data elements, logging and alerting on unusual download patterns, quarterly reviews of all active web publications with data governance sign-off, and anomaly detection on data egress volumes. If your web analytics show a user downloading 50,000 rows from a "summary statistics" page, that's a signal worth investigating immediately.
ISO/IEC 29134 recommends that privacy impact assessments be updated "when there is a change to the nature, scope, context or purposes of the processing." Web publication counts as a scope change. Treat each new public dataset as a trigger for review, not something to batch into next year's audit cycle.
Myth 5: Transparency requires publishing detailed data
Reality: Transparency is about meaningful information, not maximum data. DHCF's stated intent was to "display only summary information about groups of people, such as enrollment counts and other statistics." That goal doesn't require exposing record-level details, it requires thoughtful aggregation and clear presentation.
You can publish enrollment trends, demographic distributions, and service utilization patterns without transmitting a single beneficiary record. The technique: aggregate server-side, suppress cells below minimum thresholds (typically 5-10 records), and transmit only the summary statistics needed to render the visualization. If your dashboard shows "127 enrollees in Ward 3, ages 25-34," the web server should send exactly that string, not 127 database rows.
Balancing transparency with privacy means asking what question the public needs answered, then publishing the minimum data required to answer it. If you can't articulate the public interest served by a specific data element, don't publish it.
Myth 6: No evidence of misuse means no harm
Reality: Breach notification obligations trigger on exposure, not exploitation. DHCF noted it "has no reason to believe anyone looked at or used any of this information in the wrong way," yet still notified 399,086 individuals and filed with HHS. This is correct: once personal data becomes accessible to unauthorized parties, the breach has occurred.
The absence of detected misuse doesn't eliminate risk. Exposed data can be harvested silently, stored for future exploitation, or combined with other datasets to enable fraud years later. Your notification decision should rest on what was accessible, not on whether you can prove someone accessed it. Most web servers don't log every data element viewed, only page requests and download events. If the data was technically reachable, assume it may have been reached.
What to do instead
Build a pre-publication protocol that treats web publication as a high-risk data transfer. Before any dataset reaches a public server:
Classify the source data. Identify all personal data elements, direct and indirect identifiers, and special category data. If the source contains PII, document the legal basis for public disclosure and the specific public interest served.
Aggregate before extraction. Run your summary queries in the database and extract only the aggregated results. Don't extract record-level data with the intention of aggregating it client-side.
Test the entire stack. Inspect network traffic, examine page source, query API endpoints directly, and attempt to export or download data using the tools available to any site visitor. If you can reach record-level data, so can others.
Implement server-side filtering. Never rely on JavaScript or CSS to hide data. All filtering, masking, and aggregation must occur on the server before transmission.
Log and monitor access. Enable detailed logging on all public data endpoints, set alerts for high-volume downloads or unusual query patterns, and review logs monthly for anomalies.
Schedule quarterly reviews. Inventory all active web publications containing any derived or aggregated data, verify that data governance approved each one, and confirm that the technical controls remain effective.
The DHCF incident wasn't the result of hacking, it was the result of assumptions. Your publication controls should assume that anything technically accessible will eventually be accessed, that "summary data" implementations can leak record-level details, and that the gap between intent and implementation is where breaches happen.
