Immediate Actions Every Practice Should Take When a Billing Company Reports a Security Incident
When a dental or medical billing vendor reports a security incident, such as the 2026 DireWolf ransomware listing tied to eAssist Dental Solutions, practices need to act within hours, not days. Immediate steps include changing every password linked to the vendor portal, enforcing multi-factor authentication across all staff accounts, and revoking access for former employees, contractors, or unused shared logins. Practices should also pull their Business Associate Agreement to confirm notification timelines and liability terms, open a documented incident timeline, and loop in legal counsel and cyber liability insurers early.
On the financial side, accounts receivable needs active triage: claims nearing timely filing deadlines should be prioritized and rerouted manually if the vendor’s system is down, and payment posting should be reconciled to prevent backlogs. Once the immediate response is handled, practices should demand written specifics from the vendor, confirm their own patient notification obligations, and reassess whether the vendor relationship should continue.
Why This Checklist Exists Right Now For Dental Practices
On September 6, 2026, eAssist Dental Solutions, a widely used dental billing and revenue cycle management (RCM) provider, appeared on the dark web leak site operated by the DireWolf ransomware group. The listing was reported by Ransomware.live, and as of this writing, there has been no public confirmation, denial, or statement from eAssist Dental Solutions or its parent company, Henry Schein. Multiple threat intelligence aggregators, including RedPacket Security and BrinzTech, have indexed the posting, but none have independently verified the specifics of what was taken or how the intrusion occurred.
That last point matters more than it sounds like it should. The leak site posting itself does not include details about which systems were affected, what data was involved, the volume of records, or any stated ransom figure. This is fairly typical of how these situations unfold in the early days. A group claims a victim before anyone outside the negotiation room knows the real scope, and the practices downstream of that vendor are left checking their inboxes and wondering if today is the day they find out their patients’ financial and health information is sitting on a criminal marketplace.
DireWolf is not a new player. The group surfaced in May 2025 and by late August 2026 had been linked to well over a hundred claimed victims, with healthcare organizations making up a meaningful share of its targets. It has recently claimed other healthcare victims as well, including hospital systems and organizations like the National Kidney Registry, and it operates using the now-standard double extortion model: steal the data first, encrypt the systems second, then threaten to publish everything if payment doesn’t come through.
What makes an incident like this one particularly relevant to independent practices and small-to-mid-size clinics is the nature of the vendor itself. Billing and RCM companies don’t just process claims. They hold Social Security numbers, dates of birth, insurance member IDs, procedure codes, diagnosis codes, and in many cases full patient demographic files, all consolidated across dozens or hundreds of client practices in one place. A single compromised RCM company like eAssist can turn into a mass-casualty event for every practice that outsourced its billing to them. This is exactly why HIPAA treats a billing company as a business associate rather than a passive one, and it’s exactly why “wait and see” is not an acceptable response when eAssist tells you they’ve had a security incident.
This piece walks through what a practice manager, compliance officer, or physician-owner should actually do in the hours and days after learning that a billing partner has been hit. It’s written as a working checklist, not a theoretical overview, because when this happens to you, you will not have time to read theory. In recent times, a generic vendor is not a necessity, but you should seek a professional Dental RCM services provider.
See How TransDontics Handles Security, Access Control, and Claims Continuity
Part One: Understanding What Kind of Notice You're Dealing With
Before jumping into action items, it’s worth pausing on one distinction that changes everything downstream: has the company confirmed a breach, or has it only acknowledged an “incident” or “event”?
Billing companies, understandably, are cautious with language in the early stages. Legal counsel typically advises against using the word “breach” until forensic investigation confirms that protected health information (PHI) was actually accessed or exfiltrated, not just that a network was compromised. You’ll often see phrasing like “security event,” “unauthorized access to our environment,” or “we are investigating a potential incident.” Don’t let that language soothe you into treating the situation as low priority. Under HIPAA, an unauthorized acquisition, access, use, or disclosure of PHI is presumed to be a breach unless the covered entity or business associate can demonstrate a low probability of compromise through a documented risk assessment. In plain terms: assume the worst has happened to your patient data until you have documented proof otherwise, and act accordingly from the first phone call.
There are generally three notice scenarios a practice will encounter:
Scenario one: the company proactively notifies you. This is the best-case version of a bad situation. It means they’ve identified you as an affected client and are moving through their incident response and notification obligations under your Business Associate Agreement (BAA).
Scenario two: you learn about it from the news or a threat intelligence feed before the vendor contacts you. This is what a lot of eAssist’s clients are likely experiencing right now. The listing on a leak site or a cybersecurity news outlet becomes public before the vendor has finished its internal investigation or completed direct outreach. In this scenario, you are not waiting for a phone call. You are picking up the phone yourself.
Scenario three: you notice unusual account activity, unfamiliar logins, or billing irregularities tied to the vendor’s platform before any notification exists at all. This is the scenario every practice should be building monitoring habits to catch, because it’s often the earliest possible warning sign.
Whichever scenario applies to you, the clock starts now. The checklist below is organized by urgency, starting with what should happen in the first hour and moving outward.
Part Two: The First Hour — Containment and Verification
1. Confirm the source and legitimacy of the notification
Ransomware disclosures create a strange secondary risk: phishing actors love to impersonate breach notifications. If you receive an email, text, or call claiming to be from your billing vendor about a security incident, verify it through a channel you already trust, not through any link or phone number contained in that message. Call your account representative directly using the number on file from before the incident, or log into your vendor portal by typing the URL manually rather than clicking through.
This step feels almost too basic to include, but incident responders across the industry consistently report that a second wave of attacks piggybacks on the confusion of the first. Do not skip verification just because the notification looks official.
2. Change every password tied to the vendor relationship
Once you’ve confirmed the notification is legitimate, or once you’ve confirmed independently through a source like Ransomware.live or a cybersecurity outlet that the vendor has been listed, treat every credential associated with that vendor as compromised. This includes:
- Login credentials for the vendor’s billing or practice management portal
- Any shared or generic staff logins used to access the platform (a common and risky practice in smaller offices)
- API keys or integration credentials if your practice management software connects directly to the vendor’s system
- Email accounts that have ever been used to receive password reset links or account notifications from the vendor
- Any password reused across the vendor’s platform and your internal systems (this is the moment to find out if someone on your team recycled a password, and to fix that immediately)
Password changes should happen from a device you trust, on a network you trust, not from a shared office computer that may itself be compromised if the intrusion touched anything beyond the vendor’s own environment. If your practice management system integrates with the vendor’s platform through a browser extension, desktop application, or locally stored credential, uninstall or disable it until you’ve confirmed it’s safe.
3. Enable or verify multi-factor authentication everywhere it's available
If MFA was optional and your staff hadn’t turned it on, this is the moment to make it mandatory, not just recommended. If MFA was already active, don’t assume that’s enough. Change the underlying password anyway, because MFA protects against unauthorized login attempts, not against a scenario where an attacker already has a valid session token or has compromised the authentication method itself.
Practices that use SMS-based MFA should also consider, at least temporarily, whether to move to an authenticator app instead. SIM-swapping and SMS interception are known techniques used against healthcare targets specifically because so much sensitive infrastructure still relies on text-message codes.
Push notifications for MFA are convenient but come with their own risk during an active incident: “MFA fatigue” attacks, where a threat actor with a stolen password spams approval requests until an exhausted employee taps “approve” by mistake. During the first 24 to 72 hours after a vendor incident, brief your staff specifically on this risk. Tell them plainly: if you get an MFA prompt you didn’t trigger, deny it and report it immediately; don’t just dismiss it and move on.
4. Revoke and re-provision access for departed or unnecessary users
This is the step most practices skip, and it’s often the one that matters most. Pull the full list of staff members, former employees, contractors, and any third parties (billing consultants, IT vendors, temporary staff) who have ever had login access to the compromised vendor’s system.
Ask three questions about every single one:
- Does this person still work here or still need this access?
- Was this account created for a project or a person that no longer applies?
- Is this a shared or generic account that multiple people know the password to?
Revoke anything that doesn’t have a clear, current, active business reason to exist. Then rebuild access from scratch with named, individual accounts, scoped to only what each role actually needs. This is the principle of least privilege, and it is one of the single most effective things a small practice can do to limit the blast radius of a vendor-side compromise, because if the attacker did manage to harvest credentials from the vendor’s environment, an old, forgotten account with broad permissions is exactly the kind of foothold that turns a contained incident into a much bigger one.
Part Three: The First 24 to 72 Hours — Documentation, Legal Review, and Internal Communication
5. Pull and review your Business Associate Agreement immediately
Your BAA with the billing vendor is not a filing-cabinet document anymore. It’s an active operational tool. Pull it and specifically look for:
- Notification timelines. Most BAAs specify how quickly the business associate must notify you of a breach, commonly within a set number of days after discovery. Note the date the vendor discovered the incident (not the date they told you, if those differ) and calculate whether they are within their contractual and regulatory window. Under the HIPAA Breach Notification Rule, business associates generally must notify covered entities without unreasonable delay and no later than 60 days after discovery.
- Responsibility for patient notification. Some BAAs specify that the covered entity (your practice) is responsible for notifying affected patients, even though the breach occurred at the vendor level. Others place that burden on the business associate. Know which applies to you before you need to act on it, because patient notification deadlines under HIPAA are also 60 days from discovery, and that clock is often already ticking by the time you’re reading this checklist.
- Indemnification and liability language. This becomes relevant for your legal counsel and potentially your cyber liability insurer, but you should know now whether the agreement includes cost-sharing provisions for breach response, credit monitoring, legal fees, or regulatory fines.
- Subcontractor and downstream vendor clauses. If your billing vendor uses subcontractors (a clearinghouse, a cloud hosting provider, a collections agency), the BAA should specify how those relationships are governed and whether the vendor is required to have BAAs of its own in place with those parties. This matters because the scope of “who touched our data” is often wider than a single vendor’s own systems.
If you cannot locate a signed BAA, or if the one on file is outdated and doesn’t reflect the current scope of services, flag this to your compliance lead and legal counsel as a separate, serious problem. An out-of-date or missing BAA is itself a HIPAA compliance gap, independent of whatever happened with the vendor’s security.
6. Open a formal incident file and start a timeline
Create a single, centralized record, a shared document, a case management ticket, whatever your practice already uses, and start logging every piece of information as it comes in:
- Date and time you first learned of the incident, and how (vendor notification, news report, internal discovery)
- Every communication received from the vendor, with timestamps and the name of who sent it
- Every internal action taken (password resets, access revocations, staff notifications) with timestamps
- Any patient inquiries or complaints related to the incident
- Legal and compliance consultations, with dates
This isn’t busywork. If your practice is later asked to demonstrate reasonable diligence, whether by a regulator, a patient’s attorney, or your own cyber insurance carrier during a claims process, this timeline becomes your primary evidence that you responded appropriately and promptly. Practices that scramble to reconstruct a timeline after the fact, from memory and scattered emails, consistently end up in a worse position than practices that started documenting on day one.
7. Loop in your practice's legal counsel and cyber liability carrier early
Don’t wait until you’ve confirmed the “worst case” to make these calls. Most cyber liability policies actually require notification to the carrier within a specific window after you become aware of a potential incident, sometimes as short as 24 to 72 hours, and failing to notify promptly can jeopardize coverage even if the eventual claim would otherwise have been valid. Your carrier will also frequently have a panel of breach coach attorneys and forensic firms they want you to use, sometimes as a condition of coverage, so this call early can save you from hiring outside counsel or a forensic firm that your insurer won’t reimburse.
If your practice doesn’t carry cyber liability insurance yet, this incident is the moment to have that conversation as soon as the immediate response work is handled. It is far easier to shop for coverage before an active claim than during one.
8. Brief your staff, once, with a clear and consistent message
Staff will hear about this from patients, from the news, from each other, before you’ve had a chance to control the message if you’re not proactive. Hold a short, mandatory briefing (in person or via a recorded video message if your team is distributed) that covers:
- What is known, and clearly separated from what is not yet known or confirmed
- What staff should say if a patient asks about it (a short, approved script, not improvisation)
- What staff should not say (speculation, blame, confirmation of specifics that haven’t been verified)
- The password and MFA changes they need to make personally, with deadlines
- Who to escalate patient concerns to, so front-desk staff aren’t left fielding legal or clinical questions they’re not equipped to answer
A poorly briefed staff member repeating rumors to a patient, or worse, to a local reporter, can turn a contained vendor incident into a reputational crisis for your practice specifically, even though the fault sits with the vendor.
Part Four: Financial Continuity — Prioritizing Accounts Receivable
9. Identify what's frozen and what's still moving
Within the first day or two, work with the vendor (or, if they’re unresponsive, with your practice management software provider directly) to understand exactly which functions are affected:
- Are new claims submissions paused, delayed, or still processing normally?
- Is payment posting current, or is there a backlog building?
- Are patient statements and collections communications still going out, and should they be paused if account data integrity is in question?
- Is your clearinghouse connection affected, or is the issue isolated to the vendor’s own billing platform?
10. Prioritize claims by filing deadline risk
Payers enforce timely filing limits, and those limits do not extend themselves because your billing vendor had a ransomware incident. Pull a report (from your practice management system if the vendor’s system is inaccessible) of all claims approaching their filing deadline, sorted by days remaining. Anything within 15 to 20 days of a hard deadline needs a manual contingency path, whether that means submitting directly through your clearinghouse, using a backup billing resource, or, in the worst case, submitting on paper.
This is also the moment to document, in writing, any claims that miss deadlines specifically because of the vendor incident. If you later need to appeal a timely filing denial, having a contemporaneous record tying the delay to a documented, publicly reported security incident meaningfully strengthens your appeal position with the payer.
11. Reconcile and protect payment posting
12. Communicate proactively with high-balance or sensitive-account patients
13. Set up short interim reporting
Part Five: The First Two Weeks — Assessment, Notification, and Vendor Accountability
14. Demand specifics from the vendor, in writing
Once the initial chaos settles, your practice is entitled to ask direct questions and to receive direct answers, ideally documented in writing so you have a record:
- What was the root cause of the intrusion?
- What specific data types were involved, and for which date ranges or record sets?
- Has the vendor completed a forensic investigation, and can they share a summary or the full report?
- What remediation steps has the vendor taken, and have those been independently verified (by a third-party forensic firm, not just internal IT)?
- What is the vendor doing differently going forward to prevent recurrence?
A vendor that stonewalls these questions or responds only with vague reassurance is telling you something important about whether this relationship should continue past the current contract term.
15. Determine your own notification obligations
16. Reassess the vendor relationship itself
This is uncomfortable, but necessary. Once the immediate fire is out, your practice needs to have an honest conversation about whether this vendor remains the right partner. Questions worth asking as a team:
- Was this vendor’s security posture something we had visibility into before this happened, or did we take it on faith?
- Does our contract include any security or compliance auditing rights we haven’t been using?
- Are there red flags in how the vendor communicated during the incident — delays, inconsistency, defensiveness — that suggest deeper organizational problems?
- What would switching vendors cost us in disruption versus what staying costs us in risk?
Not every incident should end a vendor relationship. Plenty of well-run organizations get hit by sophisticated ransomware groups despite doing most things right, and switching vendors carries its own operational risk and disruption. But this decision should be made deliberately, with information, not by default because switching felt like too much work in the moment.
Part Six: Building Resilience for Next Time
No practice can fully prevent a vendor from being targeted. What a practice can control is how exposed it is when that happens, and how quickly it can respond. A few structural changes worth putting in place regardless of whether you’re dealing with an active incident right now:
- Build vendor security review into your onboarding and renewal process. Before signing or renewing with any billing vendor, ask for evidence of their security posture: SOC 2 reports, HIPAA risk assessment summaries, incident history, and clear answers on how they handle MFA, encryption, and access controls internally.
- Maintain an internal, current inventory of every system with access to patient financial and health data. You cannot revoke access quickly during a crisis if you don’t already know, at a glance, everywhere that access exists.
- Practice the response, not just the plan. A written incident response plan that’s never been walked through in a tabletop exercise tends to fall apart under real pressure. Even a short, once-a-year internal drill, walking through “what if our billing vendor called us right now and said they’d been breached,” dramatically improves how fast and how calmly a team actually responds when it happens for real.
- Keep BAAs current and actually read them. Set a calendar reminder to review every BAA annually, not just at signing. Vendors change subcontractors, change hosting providers, and change the scope of services they perform, and your agreement should reflect the relationship as it actually exists today.
- Separate patient communication about routine matters from breach-related communication. Have a plan ready, even a template, so that if this happens again, your practice isn’t drafting a patient notification letter from a blank page under deadline pressure.
Closing Thoughts
Incidents like the one affecting eAssist Dental Solutions are a reminder that outsourcing a function like billing doesn’t outsource the responsibility that comes with it. Patients hold your practice accountable for the safety of their information regardless of which vendor’s server it happened to be sitting on when something went wrong. The practices that come through these situations with the least damage, financially, operationally, and reputationally, are consistently the ones that had a plan before they needed one, and that moved through the first hours with discipline rather than panic.
If your practice works with a billing or RCM vendor and you don’t currently have a written incident response checklist specific to that relationship, this is worth treating as a priority this week, not a someday project. The vendors handling your revenue cycle are, by necessity, holding some of the most sensitive information your practice generates. Treat that relationship with the same seriousness you’d apply to any other part of patient care.
