CareCloud Breach: What Healthcare Practices Should Review

An electronic health record system can feel like one part of a medical practice’s technology. In reality, it may connect patient records, scheduling, billing, insurance information, clinical documentation, and payment workflows.

That concentration makes healthcare technology vendors valuable targets.

CareCloud, a provider of electronic health records, practice-management, billing, and related healthcare technology, has reported a breach affecting 3,756,469 people. The newly confirmed total makes this more than a story about one software company. It is a reminder that healthcare organizations need to understand what information their vendors hold, how those systems connect to daily care, and what happens when a vendor is compromised.

Quick Answer: What should healthcare organizations do about the CareCloud breach?

Healthcare organizations should first determine whether they use CareCloud directly or through a related service, integration, billing provider, or technology partner.

If they are potentially affected, they should obtain written information from the vendor, identify the systems and patient populations involved, review connected accounts and integrations, preserve relevant documentation, and confirm that downtime and patient-notification responsibilities are understood.

Organizations that do not use CareCloud can still apply the lesson by reviewing their most important EHR, billing, cloud, and practice-management vendors.

What happened in the CareCloud breach?

CareCloud detected a network disruption in its CareCloud Health division on March 16, 2026. The disruption affected functionality and data access in one of the company’s six electronic health record environments for approximately eight hours.

CareCloud restored the affected environment that evening.

Its later investigation found that an unauthorized third party had accessed one of its Amazon Web Services environments between March 10 and March 16. CareCloud reported that the attacker claimed to have removed data from databases in that environment.

On March 24, CareCloud determined that the incident was material because of the sensitivity of the potentially affected information and the possible consequences for patients, customers, operations, regulatory matters, and the company’s reputation. It filed a cybersecurity disclosure with the Securities and Exchange Commission on March 27.

The company completed its review of the affected data on June 24. Breach notifications followed in July, and the Department of Health and Human Services breach portal now lists 3,756,469 affected individuals.

What information may have been involved?

The information varies by person. CareCloud’s regulatory notices say the affected data may include a person’s name together with one or more of the following:

Home address
Date of birth
Social Security number
Driver’s-license or other government identification number
Financial-account information
Credit or debit card information
Medical information
Health-insurance information

An individual notification letter should identify the categories associated with that person.

This combination is particularly sensitive because it can support several forms of misuse. Medical and insurance information may be used to make phishing messages more convincing, while identity and financial details may increase the risk of fraud or account impersonation.

CareCloud has said it found no evidence of additional unauthorized activity in the affected environment after March 16. That does not establish whether stolen information will be misused later.

What remains unknown?

Several important questions have not been answered publicly:

How the attacker first entered the CareCloud environment
Whether stolen or compromised credentials were involved
Whether a vulnerability was exploited
Who conducted the attack
Whether the incident involved ransomware or an extortion payment
Which CareCloud customers were affected
Whether the federal total may change again

No known criminal group has publicly taken responsibility for the incident.

There is also no public evidence that Amazon Web Services itself was breached. The confirmed facts concern unauthorized access to an AWS environment operated by CareCloud.

Why this matters to healthcare organizations

Smaller healthcare organizations often rely on outside vendors for systems they could not reasonably build or manage internally. That includes electronic health records, billing, prescription services, patient communications, imaging, backups, payment processing, and cloud applications.

This is normal and often necessary. It also creates dependencies that must be understood before something goes wrong.

The lesson is especially relevant to:

Independent medical and dental practices with limited internal IT staff
Hospice and home-health providers whose employees need remote access
Assisted-living and senior-living organizations using several clinical and administrative platforms
Outpatient clinics that depend on hosted records, scheduling, and billing
Organizations working with outside billing companies or managed service providers

A healthcare organization may not operate a vendor’s cloud environment, but it still needs enough information to manage its own access, integrations, documentation, communications, and continuity planning.

Five questions to ask about an EHR or healthcare-technology vendor

1. What data does the vendor hold?

Document the types of information shared with the vendor.

This may include patient demographics, clinical notes, insurance information, billing records, payment details, employee information, scanned documents, and system logs.

The organization should also know whether the vendor retains information after a patient relationship ends or after a contract is terminated.

2. Which systems connect to the vendor?

An EHR rarely stands alone. It may connect to:

Microsoft 365
Patient portals
Billing and payment platforms
Laboratories
Imaging systems
Pharmacies and prescribing services
Insurance and claims systems
Medical devices
Document repositories
Third-party reporting tools

Maintain a current integration list that identifies the system owner, purpose, connection method, responsible vendor, and procedure for disabling access.

3. Who can access the platform?

Review users, administrators, service accounts, vendor-support identities, and integration credentials.

Remove accounts that are no longer required. Verify that multifactor authentication is enabled where available, administrative access is limited, and shared accounts are avoided.

Vendor access should also be reviewed. A support account that is rarely used may still have broad access to patient and operational information.

4. What happens if the system becomes unavailable?

CareCloud reported an approximately eight-hour disruption to the affected EHR environment. Even a shorter interruption can create problems during a busy clinic day.

A practical downtime plan should explain:

How staff verify patient identity
Where appointments and contact information can be accessed
How clinical notes are recorded temporarily
How medication and allergy information is handled
How orders, referrals, and prescriptions are managed
Who can authorize urgent technical changes
How temporary records are entered after service returns
How staff and patients receive reliable updates

The procedure must be usable by the people delivering care—not only by the IT team.

5. What will the vendor provide after an incident?

The organization should know who its vendor contact is and what information will be requested after a security event.

Useful written answers include:

Whether the organization was affected
Which systems and dates are involved
What information was accessed
Which patients or employees may be affected
Whether integrations or credentials must be changed
What containment and remediation occurred
What monitoring the vendor is offering
Who is responsible for notifications
When the next update will be provided

A vague statement that an incident is “under investigation” may be appropriate at first, but it should not be the final documentation.

What should an affected CareCloud customer do?

A CareCloud customer should avoid making assumptions based only on public reporting. Its own vendor notice and contractual relationship will determine the appropriate response.

A reasonable technical and operational review should include these steps:

Obtain written confirmation of impact. Ask whether the organization, its systems, or its patients are included in the reported breach.
Identify the affected population and data. Determine which patients, employees, locations, and information categories are involved.
Review connected access. Examine administrator accounts, service accounts, integrations, remote-access methods, application secrets, and support identities.
Coordinate required assessments. Leadership should involve the appropriate privacy, legal, insurance, clinical, and technical personnel. Vault does not provide legal determinations.
Preserve documentation. Retain notices, vendor communications, decisions, system records, investigation notes, and completed actions.
Prepare staff for impersonation attempts. Attackers may use real medical, insurance, or billing details to make fraudulent messages sound legitimate.
Review continuity procedures. Confirm that staff know what to do if the EHR, billing system, portal, or connected application becomes unavailable.

Do not rotate credentials or disconnect an integration without understanding its clinical and business impact. Technical changes should follow a documented sequence that protects patient care.

Applying Protect, Operate, Recover, and Grow

Protect

Use multifactor authentication wherever supported.
Separate administrative accounts from everyday user accounts.
Apply least privilege to staff, vendor, and integration access.
Remove inactive accounts promptly.
Protect exported reports and locally stored patient files.

Operate

Maintain an inventory of healthcare applications and vendors.
Document data types, system owners, integrations, and support contacts.
Review privileged and vendor access regularly.
Track vendor notices, updates, and unresolved security questions.
Confirm where sensitive downloads and scheduled reports are stored.

Recover

Maintain usable EHR and communications downtime procedures.
Document how integrations and compromised accounts can be isolated.
Preserve vendor communications and technical records.
Test how temporary clinical records will be reconciled after restoration.
Confirm that backup and recovery plans cover systems the organization controls.

Grow

Include vendor dependencies in technology planning.
Replace unsupported systems and undocumented integrations.
Use contract renewals to request clearer security, notification, and recovery terms.
Prioritize improvements based on care-continuity risk.
Use a Technology Health Assessment to establish a practical baseline.

The bottom line

The CareCloud breach did not begin inside 3.75 million individual medical practices. It occurred inside a widely used healthcare-technology environment where information from many people was concentrated.

That is the central lesson.

Healthcare organizations cannot directly manage every vendor’s security. They can control which vendors they use, what access they grant, what information they retain locally, how well their dependencies are documented, and whether staff are prepared to continue care during a disruption.

Start with three questions:

Which vendors hold our most sensitive information?
Which daily services would stop if one of those vendors became unavailable?
Do we have current, written procedures for responding?

Frequently asked questions

What is CareCloud?

CareCloud provides electronic health records, practice-management, revenue-cycle, billing, and other technology services to healthcare organizations. It handles patient and operational information for providers across the United States.

How many people were affected by the CareCloud breach?

The HHS Office for Civil Rights breach portal lists 3,756,469 affected individuals. The entry remains under investigation, so organizations should use their direct CareCloud notices for organization-specific information.

When did the CareCloud breach happen?

CareCloud’s investigation found unauthorized access to an AWS environment between March 10 and March 16, 2026. The company detected a network disruption on March 16.

What information was involved?

Depending on the person, the information may include names, addresses, dates of birth, Social Security numbers, government identification, financial information, payment-card information, medical information, and health-insurance information.

Was Amazon Web Services breached?

There is no public evidence that AWS itself was breached. The incident involved unauthorized access to an AWS environment operated by CareCloud.

Does every CareCloud customer need to notify patients?

Not necessarily. A healthcare organization should obtain written, organization-specific information from CareCloud and coordinate with its appropriate privacy and legal resources. Public reporting alone does not determine an organization’s notification obligations.

What should a practice do if it does not use CareCloud?

Use the incident as a reason to review other EHR, billing, cloud, and healthcare-technology vendors. Document what data they hold, who can access their platforms, what systems connect to them, and how the organization would operate during an outage.

Strengthen your healthcare technology readiness

Vault Technologies helps healthcare organizations improve the reliability, security, and documentation of the technology supporting patient care.

Our work includes managed IT, endpoint and Microsoft environment administration, access and configuration reviews, network and systems support, backup and recovery planning, technology assessments, and audit-ready technical documentation.

Our nurse-led perspective keeps the focus on a practical goal: technology should support patient care, not interrupt it.

Request a complimentary Technology Health Assessment to review vendor dependencies, access controls, documentation, endpoint management, and recovery readiness.

The assessment provides a practical baseline and prioritized next steps. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents.

Authoritative sources

HHS Office for Civil Rights Breach Portal — CareCloud entry submitted July 24, 2026; federal total verified August 24, 2026.
CareCloud Form 8-K filed with the SEC — March 27, 2026.
CareCloud consumer breach notice published by the California Attorney General — July 2026.
CareCloud notification filed with Massachusetts — July 2026.
TechCrunch independent reporting — August 19, 2026.

< Older Post

Newer Post >

The First 60 Minutes of a Healthcare IT Outage

By michael • September 7, 2026

When a healthcare system stops wo rking, the first question is not always, “How do we fix the computer?” The first questions are: Can employees continue caring for patients safely? Which services are affected? Who is coordinating the response? Could this be a cybersecurity incident? What information must be preserved? How will staff receive reliable instructions? A short outage can affect scheduling, medication information, clinical documentation, laboratory orders, referrals, billing, communications, and access to patient records. The first hour should be organized around care continuity, controlled technical response, clear communication, and accurate documentation. Quick Answer: What should a healthcare organization do during the first hour of an IT outage? Confirm the scope, protect urgent patient-care functions, appoint one response leader, contact the approved IT or vendor representative, activate the appropriate downtime procedures, preserve relevant information, and issue one clear internal update. Do not let every employee troubleshoot independently. Avoid unnecessary reboots, password changes, software removal, or disconnected equipment until someone has determined whether the event is an ordinary failure, vendor outage, network problem, or possible security incident. This guide is a practical starting point. Each organization should adapt it to its systems, clinical responsibilities, staffing, vendors, contracts, and emergency procedures. Before using this guide If the disruption creates an immediate threat to life or patient safety, follow the organization’s emergency clinical procedures and contact emergency services when appropriate. Technology troubleshooting must not delay urgent care. An IT outage does not automatically mean a cyberattack. Possible causes include: Internet or power failure Vendor service disruption Equipment malfunction Expired certificate or license Failed update Authentication problem Network configuration error Accidental change Malicious activity Treat the cause as unknown until it is reasonably established. Minutes 0–10: Recognize, protect, and report 1. Confirm what employees are seeing Ask for observable facts: Which system is unavailable? When was the problem first noticed? Is it affecting one user, one location, or everyone? Is the internet working? Are telephones working? Are users receiving an error message? Are files missing or renamed? Did anyone receive a suspicious prompt, email, call, or login request? Did a vendor announce an outage? Are medical devices or medication workflows affected? Record the exact wording of error messages when possible. A photograph may be useful if it does not expose patient information. Avoid declaring the event “ransomware,” “a breach,” or “just an internet problem” without evidence. 2. Protect immediate patient-care functions The clinical or operational leader should determine whether staff can safely continue normal work. Check critical functions such as: Patient identification Current medications and allergies Urgent orders and results Prescription handling Clinical documentation Scheduling and patient contact Laboratory and imaging workflows Communication between care teams Access to emergency information If required information is unavailable, activate the applicable clinical escalation or emergency procedure. 3. Report through the approved support channel Employees should contact the organization’s established IT representative, managed service provider, internal support contact, or affected vendor. Use a known telephone number or support portal. Do not rely on contact information supplied in an unexpected email, text message, pop-up, or telephone call. The initial report should include: Reporter’s name and callback number Affected location System or device Time first noticed Number of affected users Patient-care impact Exact symptoms Actions already taken Suspicious activity, if any Minutes 10–20: Establish control 4. Appoint one incident coordinator One person should coordinate the organization’s response. Depending on the organization, this may be: Practice administrator Executive director Clinical supervisor Privacy or security representative Internal IT lead Designated continuity coordinator This person does not need to repair the system. The role is to coordinate decisions, communications, priorities, and documentation. Identify backups in case the primary coordinator is unavailable. 5. Open an incident record Start a written record immediately. Paper may be necessary if normal systems are unavailable. Record: Date and time Person reporting Systems and locations affected Known operational impact People contacted Instructions received Decisions made Temporary procedures activated Changes performed Time of each update Unanswered questions Separate confirmed facts from assumptions. A clean timeline is valuable for technical recovery, leadership review, insurance coordination, vendor follow-up, and any later privacy or legal assessment. 6. Establish a trusted communication method Choose one approved method for staff updates. Possible options include: Telephone tree Approved text-notification system Alternate email service Printed instructions In-person unit or department briefings Predefined emergency communication platform Do not discuss patient details in an unapproved communication channel. Employees should know: Where updates will come from Who is authorized to issue instructions When the next update is expected Where questions should be directed Which temporary procedures are active Minutes 20–30: Stabilize and preserve 7. Prevent uncontrolled troubleshooting Ask employees to stop taking independent corrective actions unless directed by the response lead or technical representative. Uncoordinated actions may: Erase useful evidence Spread malicious activity Interrupt working systems Complicate restoration Create conflicting configuration changes Delay diagnosis Disconnect equipment needed for patient care Do not broadly instruct employees to unplug everything. Isolation decisions should consider both technical risk and clinical impact. 8. Preserve relevant information Where safe and practical, retain: Error messages Alert emails Suspicious messages or telephone details Login notifications Screenshots without unnecessary patient information Device names Usernames involved IP or network information supplied by IT Vendor notices Support-ticket numbers Times of observed events Names of people who performed technical actions Do not forward suspicious attachments or links to coworkers. Use the organization’s approved reporting method. 9. Determine whether specialized escalation is needed Technical personnel should assess whether signs point to: A local device failure Network or internet outage Microsoft 365 or identity disruption EHR or vendor outage Account compromise Malware or ransomware Unauthorized administrative change Data loss Power or facility problem If malicious activity is suspected, activate the organization’s security-incident process. Appropriate leadership, cyber-insurance, privacy, legal, law-enforcement, or regulatory contacts may need to become involved based on the facts and established procedures. Vault can support operational coordination and technical incident management, but legal determinations, breach-notification decisions, forensic investigations, and law-enforcement matters require the appropriate qualified resources. Minutes 30–45: Activate downtime operations 10. Move staff to approved temporary procedures A healthcare downtime plan should identify how essential work continues when normal systems are unavailable. Procedures may cover: Patient check-in Identity verification Appointment lists Medication and allergy information Clinical notes Orders and referrals Prescription requests Laboratory and imaging work Billing and payment collection Patient communications Care-team handoffs Home-health schedules Hospice coordination Assisted-living or senior-care documentation Use approved forms and procedures. Improvised notes on loose paper can create privacy, accuracy, and reconciliation problems. 11. Identify the most critical systems Not every system should receive equal restoration priority. Consider: Immediate patient-safety functions Clinical communications Identity and access services EHR and medication-related systems Network and internet connectivity Laboratory, imaging, and prescribing connections Scheduling and patient communications Billing and administrative services The correct order depends on the organization. HHS contingency-planning guidance addresses application and data criticality analysis—determining which applications and information are most important to patient care and business operations so recovery can be prioritized appropriately. 12. Coordinate with affected vendors If a hosted platform or external service may be involved, contact the vendor through a verified channel. Ask: Is there a confirmed service disruption? Which products, locations, or customers are affected? When did the disruption begin? Is the event operational or security-related? Are customer actions required? Should credentials or integrations be changed? Is there a temporary workaround? When is the next update? What ticket or incident number should be recorded? Do not accept “everything is fine” or “we are investigating” as the final record. Request written follow-up as facts become available. Minutes 45–60: Brief leadership and set the next checkpoint 13. Prepare a short situation report The response coordinator should provide leadership with a concise update: What happened: Confirmed symptoms and start time What is affected: Systems, locations, and users Patient-care impact: Current clinical and operational consequences What is working: Available systems and workarounds What has been done: Contacts, containment, and downtime actions What remains unknown: Cause, duration, data impact, or restoration time What is needed: Decisions, resources, or external support Next update: Specific time or triggering event Avoid filling gaps with guesses. 14. Confirm responsibility for the next phase Before the first hour ends, assign owners for: Technical diagnosis Clinical operations Staff communications Vendor coordination Incident documentation Leadership updates Privacy and legal escalation, if needed Insurance notification, if applicable Recovery validation Reconciliation of temporary records One person may hold several roles in a small organization, but the responsibilities should still be named. 15. Set a firm update schedule Even if there is no resolution, staff should receive updates at predictable intervals. A useful message answers: Is the system still unavailable? Are current downtime procedures unchanged? Has the affected scope changed? Is there a new safety or security instruction? When will the next update arrive? Silence encourages rumors and independent troubleshooting—two commodities rarely in short supply during an outage. What employees should not do Unless specifically directed by an authorized responder, employees should not: Repeatedly restart computers or network equipment Delete suspicious messages Run unapproved cleanup tools Install software Change settings Reset passwords across the organization Use personal email or consumer file-sharing services Photograph patient information Post outage details on social media Contact unverified “support” numbers Reconnect isolated equipment Discard temporary clinical records after service returns A password reset may be appropriate in some incidents, but indiscriminate resets can disrupt response work and may not revoke an attacker’s existing session. Why this matters to healthcare organizations Independent medical and dental practices A small practice may have only one administrator and one outside technology provider. A one-page first-hour checklist can prevent the response from depending entirely on one person’s memory. Hospice and home-health providers Employees may be dispersed across homes and care locations. The plan must explain how schedules, patient contacts, documentation, and clinical escalation continue when cloud or mobile systems fail. Assisted-living and senior-living organizations Technology outages may cross shifts and affect medication-related workflows, documentation, communication, and resident support. Handoffs must include the outage status and temporary procedures. Outpatient clinics An EHR, internet, identity, or telephone disruption can affect nearly every patient encounter. Front-desk, clinical, administrative, and technical personnel need coordinated instructions. Small healthcare organizations Smaller organizations may not have separate security, privacy, legal, clinical-operations, and IT teams. That makes clearly assigned roles more important, not less. Build the first-hour kit before an outage Keep a protected printed or offline kit containing: One-page first-hour checklist Incident-record form Current IT and vendor contacts Leadership call tree Cyber-insurance contact and policy number Approved downtime forms Critical-system priority list System and application owners Alternate communication instructions Emergency-access procedure Locations of backups and recovery documentation Instructions for reconciling temporary records Date the kit was last reviewed and tested Do not place passwords, recovery keys, or sensitive configuration details in an openly accessible binder. Protect, Operate, Recover, and Grow Protect Maintain MFA and individual accounts. Separate administrative access from ordinary work. Keep systems patched and supported. Protect backups from routine user access. Monitor critical systems and vendor services. Train employees to report unusual activity quickly. Operate Maintain current support contacts. Document system dependencies. Rank applications by clinical and operational importance. Keep approved downtime forms accessible. Define response authority and communication channels. Review vendor notification procedures. Recover Validate systems before returning them to normal use. Confirm that restored information is complete and usable. Reconcile paper or temporary records. Preserve the incident timeline and vendor communications. Monitor for recurring errors or suspicious activity. Communicate clearly when normal operations resume. Grow Conduct a short after-action review. Record what worked and what failed. Assign owners and deadlines for improvements. Update the downtime plan and contact list. Test the revised procedure. Include continuity gaps in technology planning and budgeting. The bottom line The first hour of a healthcare IT outage should not be improvised. A strong response protects patient care, establishes one decision structure, brings in verified technical support, preserves useful information, activates documented downtime workflows, and keeps employees informed. Prepare four things now: A named response coordinator A verified contact list A one-page first-hour checklist Usable clinical downtime procedures The technology may still fail. The organization’s ability to respond does not have to fail with it. Frequently asked questions What is the first action during a healthcare IT outage? etermine whether patient care is immediately affected, then report the outage through the approved technical-support channel. Urgent clinical and safety procedures take priority over routine troubleshooting. Does every IT outage indicate a cyberattack? No. Outages can result from equipment, power, internet, software, configuration, identity, or vendor failures. Treat the cause as unknown until it is reasonably established. Should employees unplug computers during a suspected cyber incident? Not automatically. Disconnecting a device may sometimes be appropriate, but it can also affect patient care or remove useful technical information. Employees should follow the approved incident procedure or directions from an authorized responder. Should a healthcare practice call its cyber-insurance carrier? Follow the policy’s notification requirements and the organization’s incident procedure. Some policies require early contact or approval before engaging certain vendors. Keep the current policy number and contact instructions in the protected response kit. What should be documented during an outage? Record times, symptoms, affected systems, patient-care impact, people contacted, instructions received, actions taken, temporary procedures, vendor statements, decisions, and unresolved questions. When can staff return to normal systems? Return only after the responsible technical and operational leaders confirm that the systems are available, safe to use, and ready for clinical operations. Temporary records must then be reconciled through an approved process. How often should a healthcare downtime plan be tested? Use a risk-based schedule and test often enough to keep contacts, roles, forms, and procedures workable. Testing should also occur after significant system, vendor, staffing, or workflow changes and after an actual disruption. Strengthen your healthcare technology readiness Vault Technologies helps healthcare organizations document critical systems, organize vendor dependencies, improve Microsoft 365 and endpoint administration, develop practical downtime procedures, plan backup and recovery, and strengthen incident-management readiness. Our nurse-led perspective keeps the response focused on the essential outcome: maintaining safe, reliable patient care while technology is restored. Request a complimentary Technology Health Assessment to establish a practical baseline across systems, access controls, vendor dependencies, documentation, backup planning, and care-continuity readiness. The assessment is a planning tool. It is not a legal opinion, compliance certification, penetration test, forensic investigation, or guarantee against cyber incidents. Authoritative sources NIST — SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management , published April 3, 2025. NIST — Announcement of revised incident-response guidance , published April 3, 2025. HHS — Summary of the HIPAA Security Rule , updated August 7, 2026. HHS — HIPAA Security Series: Administrative Safeguards , published May 2005 and revised March 2007. HHS 405(d) — Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients , 2023 edition. HHS 405(d) — Patient Safety , published June 28, 2023.