Ransomware Incident Response Checklist for Therapy Goals Databases

A ransomware attack on a therapy goals database can disrupt care and put sensitive patient information at risk. Use this checklist to coordinate a safe response, preserve evidence, maintain access to essential care information, and assess your legal obligations.

Follow your organization’s incident response plan and involve qualified security, privacy, legal, and clinical leaders. HIPAA requires covered entities and business associates to respond to security incidents and maintain contingency plans, but the right technical steps depend on the incident and your environment.

How to contain ransomware affecting a therapy goals database

• Activate your incident response plan. Notify your designated incident lead, IT or security team, privacy officer, leadership, and clinical operations lead using contact methods that do not rely on potentially compromised systems.
• Isolate affected devices and services. Disconnect compromised database servers, workstations, and network shares from wired and wireless networks. If multiple systems or network segments are affected, qualified administrators may need to isolate a broader segment at the network level.
• Protect connected systems. Disable access to affected file shares, remote connections, and backup destinations where appropriate. Do not reconnect systems or restore access until responders have assessed the risk of reinfection.
• Preserve the option to collect evidence. Avoid immediately powering down or rebooting affected devices if responders can isolate them from the network. Powering down can destroy volatile evidence, but if a device cannot be isolated and ransomware is spreading, stopping the spread may take priority.
• Use approved out-of-band communications. Coordinate response steps by phone or another trusted method if email, chat, or identity systems may be compromised.
• Record initial decisions. Note the discovery time, observed symptoms, systems affected, containment steps, decision-makers, and any impact on therapy or patient safety.

CISA’s StopRansomware Guide recommends isolating affected systems and powering them down only when network isolation is not possible, noting that shutdown may erase evidence in volatile memory. HHS also advises regulated entities to contain incidents and take appropriate steps to protect the confidentiality, integrity, and availability of electronic protected health information.

How to preserve forensic evidence and incident records

Preserve information that can help determine how attackers entered, what systems they accessed, whether data was copied, and whether malicious access remains. Do not assume that encrypted records are the only affected data: attackers may access or exfiltrate information before deploying ransomware.

• Preserve security, database, identity, endpoint, firewall, VPN, email, and cloud-service logs. Export them to a secure location the attackers cannot alter.
• Have qualified responders decide whether volatile memory acquisition is appropriate before rebooting or shutting down live systems. Collecting memory can change a system, so responders should consider the value of the evidence, operational risks, and containment needs.
• When appropriate, create forensic disk imaging using a sound forensic process. Keep original evidence protected, work from copies where feasible, and document who collected, handled, transferred, and analyzed each item.
• Preserve ransom notes, suspicious messages, file samples, relevant backups, cloud snapshots, and records of security alerts. Avoid opening suspicious files on ordinary workstations.
• Keep a time-stamped incident record that identifies actions taken, the people responsible, systems and data involved, findings, recovery decisions, and any changes in the assessment.

NIST’s Guide to Integrating Forensic Techniques into Incident Response explains that volatile system data can be lost when a computer is powered down and recommends documenting forensic actions and handling evidence carefully. HHS likewise identifies logs and other artifacts as useful evidence and recommends documenting the systems affected, response activities, recovery outcomes, root cause, and forensic data collected.

How to maintain therapy goals access and patient care during downtime

Prioritize patient safety and continuity of care while keeping compromised systems isolated. Follow your organization’s approved downtime procedures and have clinical leadership determine which therapy goals or treatment details staff need to deliver safe, timely care.

• Use approved downtime forms or another authorized, secure source for essential care information, such as current goals, precautions, relevant progress notes, and follow-up needs.
• Give access only to personnel who need the information for their duties. Store paper records securely, track their use, and return or reconcile them according to your downtime procedures.
• Use an approved alternate system only after security and privacy leads confirm that it is suitable for the information and the incident. Do not move patient information to personal email, consumer file-sharing services, or unapproved devices.
• Maintain a record of care provided during downtime so it can be reconciled with the official patient record once the database is safe to use.
• Communicate clearly with clinicians about what information is unavailable, how to access approved alternatives, and whom to contact about urgent care decisions.

The HIPAA Security Rule’s contingency planning requirements include procedures for continuing operations during emergencies and restoring data. Your organization’s contingency plan requirements under 45 CFR § 164.308 should guide downtime and recovery planning. Apply those procedures in a way that safeguards patient information and supports care.

Who to notify and how to coordinate the response

Assign a response lead to coordinate technical containment, clinical continuity, privacy and legal analysis, communications, and recovery. Keep an up-to-date contact list for internal teams and external partners so notification does not depend on systems that may be affected.

• Internal teams: notify IT or security, privacy, legal, leadership, clinical operations, records management, and communications teams as applicable.
• Technology and response partners: contact relevant cloud, database, managed security, and backup providers. Review business associate agreements and contracts for security incident reporting and cooperation terms.
• Government and law enforcement: consider contacting appropriate federal or state authorities, such as CISA or the FBI, with incident details that can support response and investigation. Coordinate disclosures with your privacy and legal leads.
• Patients and care teams: communicate service disruptions and safe access procedures through approved channels. Do not make unverified claims about whether patient information was exposed.
• Insurers and other required parties: notify your cyber insurer and any other parties required by your policies or contracts, following applicable reporting timelines.

HHS recommends that incident procedures identify response-team members, communication methods, external contacts, evidence-handling processes, and incident reporting steps. Keep communications factual, restricted to people who need them, and consistent with the ongoing investigation.

How to assess protected health information exposure and notification duties

Therapy goals records may contain protected health information (PHI), including patient identifiers and information about treatment. A ransomware infection is a security incident; whether it is also a reportable breach depends on the facts and applicable requirements. HHS says that when ransomware encrypts electronic PHI, a breach is presumed unless the organization can demonstrate a low probability that the PHI was compromised through a documented risk assessment, or establish that an exception applies.

For a protected health information breach assessment, evaluate at least:

• The nature and extent of the PHI involved, including identifiers and the likelihood of identifying individuals.
• Who accessed or received the information and whether that person or group could reasonably use it.
• Whether the PHI was actually viewed, acquired, or retained, using available forensic evidence and system records.
• What steps were taken to reduce the risk that the information was used or disclosed.

Also investigate whether attackers accessed systems, exfiltrated data, altered records, or disrupted the availability or integrity of patient information. Consider the effect of the incident on care and patient safety. Encryption of PHI by your organization may affect whether the information is “unsecured PHI,” but assess how the encryption was implemented and whether keys or unencrypted data were accessible.

Under the federal HIPAA Breach Notification Rule, covered entities generally must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured PHI. For breaches affecting 500 or more individuals, the covered entity must also notify HHS without unreasonable delay and within that period; additional media notice may be required when 500 or more residents of a state or jurisdiction are affected. For breaches affecting fewer than 500 individuals, HHS reporting is due no later than 60 days after the end of the calendar year in which the breach was discovered. Business associates must notify the covered entity under the applicable rule and agreement. Other federal or state laws and contractual obligations may also apply.

Do not wait for a complete technical investigation before involving your privacy and legal teams. The reporting clock can start when the incident is first known, and the applicable deadline is an outer limit, not permission to delay. See HHS’s Ransomware and HIPAA Fact Sheet, the HHS Breach Notification Rule guidance, and the rule for notification to individuals under 45 CFR § 164.404.

How to eradicate ransomware and safely restore verified backups

Do not restore the database simply because a backup is available. First determine the scope and likely entry point of the attack, remove malicious access, and ensure the recovery environment is not connected to compromised systems or credentials.

• Identify and address the initial compromise, persistence mechanisms, and vulnerabilities that allowed the attack. Rebuild or reimage affected systems using trusted media or known-clean sources where appropriate.
• Reset credentials and revoke compromised sessions or tokens. Apply current patches and security controls before reconnecting systems.
• Select a backup from a point before the compromise, where feasible. Confirm that backup systems and credentials were not affected and that the backup is free of ransomware or other malicious changes.
• Test the backup in an isolated environment. Check database integrity, record completeness, access controls, application compatibility, and whether restoration will overwrite newer legitimate information.
• Validate restored therapy goals and other critical records with authorized clinical and technical staff before returning the database to production.
• Reconnect in stages, monitor for suspicious activity, and keep a rollback plan. Preserve the original backup and relevant recovery records.

HHS recommends verifying backup integrity and periodically testing restoration. Its guidance also identifies reimaging from clean backups, rebuilding systems from trusted sources, applying updates, and resetting passwords as possible recovery measures. Make verified backup restoration a controlled process, not a shortcut around eradication and validation.

How to document lessons learned and strengthen contingency plans

After containment and recovery, review the response with technical, privacy, legal, and clinical leaders. Record the timeline, affected systems and data, decisions made, containment and mitigation actions, evidence collected, recovery results, breach analysis, notifications, and unresolved risks.

Use the review to identify practical improvements: update incident contacts, clarify isolation and downtime steps, strengthen access controls, improve log retention, review vendor reporting arrangements, and test the backup and recovery process. Practice scenarios involving therapy goals database outages so staff know how to access approved downtime information and reconcile care records afterward.

HIPAA requires regulated entities to maintain security incident procedures and contingency plans; HHS recommends documenting incidents and using the record to improve future response. In short, coordinate containment, preserve evidence, protect care continuity, assess exposure carefully, restore only verified data, and use the lessons learned to strengthen your next response.

FAQs

Should affected database systems be powered down or isolated from the network?

When possible, isolate affected systems from wired and wireless networks rather than immediately powering them down. Isolation helps limit spread while preserving volatile evidence. If a system cannot be disconnected and ransomware is continuing to spread, powering it down may be necessary; have incident responders weigh containment needs against evidence preservation.

How can therapy goals records remain available during ransomware downtime?

Use your organization’s approved downtime procedures, such as secure forms or an authorized alternate system, and make only the information needed for safe care available to authorized staff. Track care delivered and reconcile it with the official database after a secure restoration. Do not use personal email or unapproved storage to share patient records.

How do we determine whether protected health information was accessed or disclosed?

Review database and application audit trails, identity and endpoint logs, network activity, cloud records, and forensic evidence to determine what systems and records were accessed, whether information was copied, and who may have received it. Document the assessment using the HIPAA breach factors and involve privacy and legal leads. Ransomware involving PHI may trigger a presumption of breach unless the organization can demonstrate a low probability of compromise or establish an applicable exception.

What must be verified before restoring a therapy goals database from backup?

Confirm that the backup predates the compromise where feasible, that the backup environment and credentials were not affected, and that a test restoration is clean and complete. Validate database integrity, record accuracy, application function, and access controls in an isolated environment. Have authorized clinical and technical staff confirm the restored information is safe and suitable for use before reconnecting the database.