If you sell into U.S. healthcare — security tooling, EHR or practice-management software, managed services, backup and recovery, encryption, identity and access management, or HIPAA compliance tooling — your customers and prospects are legally required to publish detailed disclosures every time they suffer a protected-health-information breach affecting 500 or more individuals. Those disclosures live in the HHS Office for Civil Rights (OCR) breach portal, informally known as the "Wall of Shame," and they are one of the few public datasets in healthcare that consistently names third-party vendors and technical infrastructure alongside the covered entity.
This sits next to customer-fda-510k-submission-and-ce-marking-technical-file-product-mentions-extraction-workflow-from-public-medical-device-regulatory-disclosures and customer-nist-csf-attestation-and-cmmc-certification-product-mentions-extraction-workflow-from-public-defense-supply-chain-compliance-archives in the broader healthcare-and-security public-disclosure family. Form 510(k) captures medical device submissions; CMMC and NIST CSF capture defense supply chain posture; HHS OCR breach notifications capture what actually went wrong, who was affected, and — in the long-form narrative descriptions and downstream Resolution Agreements — which vendors were in the path of the incident.
What the HHS OCR breach notification portal is and what it discloses
The HITECH Act (2009) amended HIPAA to require covered entities — health plans, healthcare clearinghouses, and most healthcare providers — and their business associates to notify the Secretary of HHS of any breach of unsecured protected health information. For breaches affecting 500 or more individuals, HHS publishes the notification on its public portal at ocrportal.hhs.gov/ocr/breach/breach_report.jsf within a short window after notification. Smaller breaches (under 500 affected) are submitted to HHS annually but are not published on the public portal.
The portal exposes each breach as a structured record with the following fields:
- Name of Covered Entity — the breached organization (hospital, clinic, payer, dental practice, etc.).
- State — primary state of operation.
- Covered Entity Type — Healthcare Provider, Health Plan, Healthcare Clearing House, or Business Associate.
- Individuals Affected — count.
- Breach Submission Date — when the covered entity reported to HHS.
- Type of Breach — Hacking/IT Incident, Theft, Loss, Improper Disposal, Unauthorized Access/Disclosure, Other, or combinations.
- Location of Breached Information — Network Server, Email, Electronic Medical Record, Laptop, Desktop Computer, Other Portable Electronic Device, Paper/Films, or combinations.
- Web Description — a narrative paragraph, written by the covered entity or its counsel, describing what happened. This is the highest-value field for product mention extraction.
Records remain on the portal in two states: "Cases Currently Under Investigation" (recent breaches, typically the last 24 months) and "Archived Cases" (older, resolved breaches). The portal supports search by entity name, state, breach type, and date range. The full archive is downloadable as a CSV that updates as new breaches are posted, which makes it suitable for scripted ingestion without HTML scraping.
Where customer product mentions appear in HHS OCR disclosures
The product mention value is concentrated in two places. Knowing exactly where to look is the difference between a workflow that produces useful sales evidence and one that drowns in regulator-mandated boilerplate.
The Web Description narrative field
The Web Description is a free-text narrative — typically 2 to 6 sentences — describing the breach. In Hacking/IT Incident breaches (now the majority of large breaches), this narrative routinely names:
- Third-party software vendors when the breach originated in a vendor's product (e.g., file transfer software, managed file transfer products, EHR add-ons, telehealth platforms).
- Cloud and hosting providers when the breach involved a misconfigured cloud bucket, exposed database, or hosted service.
- Specific malware family or threat actor names — useful for security vendors who can correlate to specific defensive products.
- Incident response or forensics firms the covered entity engaged after the breach, when the entity chooses to name them.
- Notification and credit monitoring vendors offered to affected individuals.
The narratives are written for regulators and patients, not for vendors, so the density of named third parties varies. The 2023 MOVEit Transfer vulnerability and the 2024 Change Healthcare ransomware incident both produced waves of breach notifications where the vendor was named directly in the narrative — making these incidents goldmines for customer-of vendor mapping during the months that followed.
The downstream Resolution Agreement and Corrective Action Plan
For a small but high-value subset of breaches, HHS OCR investigation results in a Resolution Agreement and Corrective Action Plan (RA/CAP), published separately at hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements. These documents are far more detailed than the portal entries. They typically include:
- Named technical controls the covered entity agreed to deploy or improve (encryption, multi-factor authentication, log monitoring, access controls).
- The category of product (the documents rarely name a specific vendor, but the control category is explicit enough that vendor mapping is straightforward).
- Audit and assessment requirements that frequently obligate the covered entity to engage a qualified third-party assessor.
For security tooling vendors, RA/CAPs are the strongest signal that a covered entity is mandated to procure in your category. The lag from breach to RA/CAP is typically 18 to 36 months, but the procurement window opens immediately on RA/CAP publication.
The extraction workflow
The workflow we recommend has five stages. Each is mechanical enough to automate, but the first run on a new entity-type segment is usually worth doing manually to calibrate the vendor lookup table for that segment.
Stage 1: Pull the portal CSV and Resolution Agreement index
The breach portal exposes its full record set as a CSV download. Pull this on a scheduled cadence — weekly is reasonable, daily is over-investment unless you have a fast-follow sales motion. Cache each pull with the fetch date so you can compute deltas (new breaches added, status transitions from "Under Investigation" to "Archived").
The Resolution Agreement page is a static HTML index. A simple HTML parse extracts the entity name, year, and link to the PDF agreement. Cache these PDFs locally with a deterministic filename ({entity}_{ra_date}_ra.pdf).
Stage 2: Filter to your target segment
Most B2B vendors should not try to extract mentions from every breach. Filter the CSV before extraction by:
- Covered Entity Type — if you sell to payers, filter to Health Plan; if you sell to providers, filter to Healthcare Provider; if you sell to vendors serving healthcare, filter to Business Associate.
- Individuals Affected — small breaches under your customer ICP size threshold are not worth the extraction labor.
- Breach Type — Hacking/IT Incident narratives are denser in vendor mentions than Theft or Loss narratives. Improper Disposal narratives are denser in physical destruction vendor mentions.
- Location of Breached Information — if you sell email security, filter to "Email"; if you sell EHR-adjacent products, filter to "Electronic Medical Record" or "Network Server."
Stage 3: Narrative extraction
For the Web Description field, two extraction approaches work, and a hybrid gives the best precision/recall.
Approach A — Vendor lookup table. Maintain a list of vendors in your competitive category and their common name variants. Run case-insensitive substring match against the Web Description and capture the entire narrative as context for any hit. This catches known vendors cheaply but misses unknown ones.
Approach B — Named entity recognition. Run an NER model over each Web Description to extract organization names, then filter against a stop-word list of healthcare entities, regulators, law firms, and the covered entity's own name. This surfaces previously-unknown vendor mentions for human review.
For Resolution Agreement PDFs, the structure is more predictable — the Corrective Action Plan section is a numbered list of obligations. A simple section parser extracts each numbered obligation as a separate evidence record, with the obligation language as the source citation.
Stage 4: Cross-reference to entity master data
The covered entity name in the OCR portal is sometimes idiosyncratic (DBA names, legal entity variants, hospital system children). Cross-reference each entity name against a healthcare entity master like the CMS NPI registry or a commercial healthcare-entity database to get a stable identifier, parent-system mapping, and address-level metadata. This is the step that converts "Some Regional Health" in a breach record into "subsidiary of TopParentHealthSystem, 1200 beds, Medicare-participating" for sales targeting.
Stage 5: Validation and use
Every extracted mention should carry source metadata: HHS OCR case identifier (when available), breach submission date, covered entity name and state, the full Web Description as evidence text, and the link back to the public portal record. For Resolution Agreement mentions, include the RA date, the obligation number, and the obligation text verbatim.
Mentions used in sales motions should always be cited with the source link and submission date. The OCR portal is a public record, and citing the source directly is both the most credible and the most legally defensible way to reference a breach in customer-facing material.
See testimonial-attribution-with-public-data-sources for the broader practice of attributing customer mentions to verifiable public sources, and how-to-collect-product-mentions-from-public-regulatory-filings for the cross-regulator framework this HHS OCR workflow plugs into.
What HHS OCR disclosures are not useful for
Three categories of customer signal that HHS OCR breach data does not reliably contain:
Day-to-day operational vendor stack. The portal only surfaces vendors that were in the path of an incident. A healthcare entity that has not suffered a 500+ breach is invisible to this data source entirely. For ICP-wide vendor stack mapping, this is not a substitute for procurement-record sources or ad spend signals.
Specific product version, license, or contract terms. Narratives identify vendors at the brand level, not the SKU or contract level. Pricing intelligence and competitive displacement signals are not available here.
Win/loss intelligence on which vendor replaced which. Resolution Agreements obligate the covered entity to adopt controls but rarely name the specific vendor selected to provide those controls. The procurement that follows an RA/CAP is observable only through other channels (FOIA, public RFPs for state entities, vendor press releases).
The corollary: HHS OCR is most useful for vendors selling security, identity, encryption, backup, incident response, EHR-adjacent, MFT, and HIPAA-attestation tooling into the healthcare segment. For these vendors, the workflow above produces credible incident-driven customer evidence at the cadence at which breaches are publicly disclosed, with the entity, the affected count, and frequently the relevant vendor named in the public record.
The cadence and the freshness window
The portal updates as HHS receives notifications, which means new records appear continuously throughout the year. There is no fiscal-year batch like Form ADV or Form 10-K — the freshness is event-driven. Weekly CSV pulls are the right cadence for most workflows. For incident-response and forensic vendors operating in a fast-follow motion, daily pulls are justifiable.
Resolution Agreements publish on an irregular cadence — usually a handful per quarter, sometimes more during enforcement-priority years. A monthly check of the Resolution Agreement index is sufficient.
The freshness window for a given breach record is the gap between breach occurrence and portal publication, which is typically 60 to 120 days (the 60-day HITECH notification deadline plus HHS processing time). The narrative itself is finalized at submission and does not update later, so the data extracted from a record once is stable.
Final thoughts
The HHS OCR breach notification portal is the most reliable public source of customer evidence in the U.S. healthcare market for vendors whose products sit anywhere near the path of a PHI incident. The mandatory nature of the disclosure under HITECH, the structured CSV access, and the narrative field that frequently names third parties combine to produce a customer signal that does not require any outreach to the covered entity to access.
The work to build the extraction pipeline is real but tractable: weekly CSV pull plus narrative extraction plus Resolution Agreement parsing plus entity master cross-reference plus source-metadata-stamped output. Once built, the pipeline runs continuously and surfaces fresh evidence whenever a new 500+ breach is posted. Pair it with customer-fda-510k-submission-and-ce-marking-technical-file-product-mentions-extraction-workflow-from-public-medical-device-regulatory-disclosures for the device-side view of healthcare regulatory disclosure and you have a near-complete public-record picture of vendor presence in any U.S. healthcare entity whose footprint touches the regulator's view.