Supply Chain Compromise Incident Response Checklist for Advance Directive Platforms

A compromised vendor can affect more than platform availability. It may expose, alter, or make unavailable advance directive information that people and care teams rely on. Use this checklist to coordinate the response, investigate what happened, protect access to reliable directive information, and assess any notification duties.

First determine each organization’s role and which laws and contracts apply. A platform’s handling of directive information does not, by itself, establish that every record is protected health information (PHI) under HIPAA. If HIPAA applies, the Security Rule requires regulated entities to respond to and document security incidents; the Breach Notification Rule applies to breaches of unsecured PHI. HHS cybersecurity guidance and the HHS Breach Notification Rule explain those requirements.

How should teams declare and coordinate a vendor compromise response?

Activate your incident response plan when credible information suggests that a vendor’s systems, accounts, software, or services may be compromised and could affect your platform. Treat an unconfirmed alert as a reason to investigate, not as proof that information was accessed or that a reportable breach occurred.

• Appoint an incident lead and establish a response group that includes security, engineering, privacy, legal, clinical or care operations, communications, and vendor management. Assign clear decision-making and escalation roles.
• Set up a secure coordination channel that does not depend on the potentially affected vendor’s systems. Share information on a need-to-know basis and protect sensitive incident details.
• Open a decision and action log. Record who made each decision, when it was made, the evidence available, the action taken, and any follow-up owner.
• Define the initial scope and priorities. Identify connected services, affected environments, possible access paths, and risks to the confidentiality, integrity, or availability of directive information. Prioritize immediate safety and continuity needs.
• Preserve evidence before making changes when feasible and safe. Coordinate containment with responders so routine actions do not erase useful logs or forensic data.

Track a single vendor incident timeline from the earliest known alert through containment, investigation, remediation, and recovery. Include the vendor’s reported discovery time, your organization’s discovery time, system and data impacts, status updates, and any changes to the vendor’s account of events. HIPAA-regulated organizations must have procedures to respond to, mitigate, and document known security incidents. 45 C.F.R. § 164.308

What information should advance directive platforms request from affected vendors?

Request a written incident briefing through the contact and escalation process in your contract or business associate agreement (BAA). Ask for facts, supporting evidence where available, and a clear distinction between confirmed findings, estimates, and unanswered questions.

• Timeline: when the incident began, when it was detected, when the vendor notified you, key investigative milestones, containment times, and when the vendor expects its next update.
• Scope: affected products, environments, accounts, systems, regions, data stores, backups, integrations, and subcontractors or other downstream service providers.
• Information involved: whether directive documents, user or representative details, access credentials, audit records, or related metadata may have been accessed, copied, changed, deleted, or made unavailable; request affected date ranges and an estimated population when known.
• Technical findings: suspected entry path, attacker activity, relevant indicators of compromise (IOCs), persistence mechanisms, evidence of access or exfiltration, and the limits of the vendor’s investigation.
• Containment and remediation: actions taken, outstanding risks, credential and key resets, vulnerability fixes, system rebuilds, backup restoration, and controls added to prevent recurrence.
• Evidence and follow-up: available logs, forensic reports, affected service versions, investigation contacts, and a schedule for updated findings and final reporting.

Ask the vendor to preserve relevant logs and evidence, and agree on a secure method for sharing sensitive findings. A HIPAA business associate must report security incidents involving ePHI to its covered entity or business associate customer; the BAA can establish the report’s format, level of detail, and timing, subject to applicable breach-notification rules. HHS guidance on business associate incident reporting

How can teams assess exposure of advance directive data and contain affected systems?

Map the flow of directive information through the vendor, platform, interfaces, backups, exports, support tools, and downstream providers. Compare that map with vendor findings and your own logs. Do not assume that the absence of confirmed exfiltration proves that no one accessed or altered data.

• Determine what may be exposed. Identify record types, affected individuals, date ranges, identifiers, and whether documents were readable or encrypted with keys that remained secure.
• Review access and activity records. Check for unusual logins, downloads, searches, API calls, privilege changes, bulk exports, failed access attempts, or changes to directive records. Preserve copies of relevant records.
• Check integrity as well as confidentiality. Compare affected directives with trusted copies, version histories, signatures or validation records, and update timestamps. Flag any record whose current status or accuracy cannot be confirmed.
• Contain affected connections. As appropriate, suspend integrations, block compromised access paths, revoke or rotate exposed tokens and credentials, terminate active sessions, and limit vendor access while the investigation proceeds.
• Protect unaffected services. Segment systems, review connected accounts and permissions, and increase monitoring for related activity. Preserve evidence before rebuilding or deleting systems when feasible.

Document the reasoning behind containment decisions and coordinate changes with the incident lead and relevant system owners. For HIPAA-regulated systems, the Security Rule addresses access controls, audit controls, and protection against improper alteration or destruction of ePHI. 45 C.F.R. § 164.312

What downtime procedures protect access to critical directive information?

Activate your downtime procedures if a vendor disruption, containment action, or investigation prevents authorized users from reliably accessing current directives. Define in advance who can activate the procedures, which roles need access, and how staff will find the approved source of information.

• Use a verified fallback source. Maintain an appropriately protected, recoverable copy or export of critical information and identify when it was last synchronized. Mark its currency clearly so users do not mistake an older version for the latest directive.
• Provide controlled emergency access. Limit access to authorized users, use a secure retrieval process, and keep an access log where feasible. Avoid sharing directive files through personal email, unsecured messaging, or unmanaged devices.
• Keep an approved alternative available. Depending on the organization’s procedures, this may include a secured read-only repository or controlled paper copies for emergency use. Protect copies from unauthorized access and follow retention and disposal rules.
• Give staff a clear verification path. Explain how to check a document’s identity, version, and effective date, and whom to contact if records conflict or appear incomplete.
• Reconcile changes after restoration. Track updates made during downtime and reconcile them against the trusted system of record once the service is available and validated.

Test whether the fallback process works in practice, including retrieval, user authentication, and restoration from backups. HIPAA’s Security Rule includes contingency planning and retrievable copies of ePHI; HHS also recommends testing restorations to verify backup integrity and recovery capability. 45 C.F.R. § 164.308 and HHS ransomware guidance

Which legal, privacy, and regulatory notification obligations should teams assess?

Make a documented protected health information breach assessment with privacy and legal advisors. First determine which information and organizations are covered by applicable law, then assess whether the incident involved unauthorized access, use, disclosure, alteration, or destruction and whether the information was secured as required by the relevant rule.

For HIPAA, an impermissible use or disclosure of PHI is generally presumed to be a breach unless the covered entity or business associate demonstrates a low probability that the PHI was compromised through a risk assessment. HHS identifies four required factors: the nature and extent of the PHI, including identifiers; the unauthorized person; whether the PHI was actually acquired or viewed; and the extent to which risk was mitigated. HHS breach assessment guidance

If HIPAA applies, assess the notification rules for unsecured PHI, the contract or BAA, and other potentially applicable requirements. HHS states that covered entities must notify affected individuals without unreasonable delay and no later than 60 days after discovery; other reporting duties depend on factors including the number of individuals affected. A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 days, while the BAA may require faster reporting. Do not treat those outer limits as a reason to delay action. HHS notification requirements and HHS guidance on BAA reporting

Also assess state privacy and breach-notification laws, applicable advance directive or health-record requirements, contractual notice duties, and any other federal rules relevant to the platform’s role. If the platform or a connected service is not covered by HIPAA, determine whether the FTC Health Breach Notification Rule applies to it as a vendor of personal health records, related entity, or service provider. Coverage depends on the organization and service, so do not assume that HIPAA applies—or that it does not. FTC guidance on the Health Breach Notification Rule

Maintain the assessment, decision rationale, notification drafts, approvals, delivery records, and documentation supporting a determination that notification was not required. HHS describes the organization’s burden to document whether required notices were made or why a breach was not reportable. HHS administrative requirements

How should teams validate vendor remediation before restoring connections?

Do not restore a vendor connection solely because the vendor reports that the incident is resolved. Set documented restoration criteria based on the incident’s scope, the data and services involved, and the risk of reintroducing compromised access or software.

• Confirm the threat is addressed. Request evidence that affected systems have been contained, compromised accounts and secrets have been reset, identified vulnerabilities have been corrected, and suspected persistence mechanisms have been removed.
• Verify clean recovery. Confirm that restored systems and data came from trusted sources, that relevant security controls are active, and that directive records can be checked for completeness and unauthorized changes.
• Test the connection safely. Validate authentication, permissions, data transfer, monitoring, and expected application behavior in a controlled environment before resuming normal data flows.
• Require appropriate approvals. Have security, privacy, engineering, operations, and vendor management review the evidence and approve restoration according to the response plan.
• Restore in stages. Begin with limited access or data flows where practical, monitor closely for renewed suspicious activity, and keep a rollback or disconnect option available.

Record what evidence supports reconnection, what residual risks remain, who approved the decision, and what monitoring will continue. Keep the vendor under heightened review until agreed recovery conditions are met.

What should an incident review document and improve?

After immediate response and stabilization, hold a review with the teams involved and relevant vendor contacts. Focus on evidence-based findings and improvements, not blame. HHS recommends post-incident analysis of regulatory, contractual, and other obligations, along with lessons learned to improve future response. HHS post-incident guidance

• Document the incident: the vendor incident timeline, detection and escalation, affected services, data and users, relevant IOCs, evidence collected, containment steps, recovery actions, and known uncertainties.
• Record key decisions: the rationale for disabling or restoring connections, access revocation, downtime procedures, breach assessment conclusions, and notifications made or determined unnecessary.
• Assess the response: identify what worked, where information or authority was unclear, whether the vendor met contractual reporting expectations, and whether critical directive information remained accessible and reliable.
• Improve third-party risk management: update vendor inventories, security requirements, incident contacts, subcontractor visibility, evidence-sharing expectations, and escalation timelines in accordance with organizational policy and applicable contracts.
• Test the changes: update response and downtime plans, assign owners and deadlines, and exercise the revised process with the vendor and relevant internal teams.

Keep incident records and supporting evidence in an appropriately restricted repository and follow applicable retention requirements. Use the review to make specific improvements to vendor oversight, access controls, data integrity checks, and service continuity.

FAQs.

What should an advance directive platform request from a compromised vendor?

Request a written timeline, affected systems and data, possible access or alteration, relevant IOCs, known attacker activity, subcontractor involvement, containment and remediation steps, supporting logs or forensic findings, and a schedule for updates. Ask the vendor to separate confirmed facts from estimates and unknowns, preserve evidence, and follow the incident-reporting terms in the contract or BAA.

How can teams determine whether directive information was accessed or altered?

Compare vendor findings with platform and integration logs, access records, export activity, version histories, timestamps, and trusted copies of the directives. Check for unusual accounts, access patterns, bulk downloads, or modifications, and document gaps in available evidence. If HIPAA applies, assess the incident under the relevant breach rules; a lack of confirmed access alone does not establish that no compromise occurred.

How can critical directive information remain accessible during service disruption?

Use tested downtime procedures and a protected fallback copy with a clearly marked synchronization time. Restrict emergency access to authorized users, provide a method to verify each document’s version and effective date, and track changes made during the outage for later reconciliation. The fallback should support continuity without making outdated or unverified records appear current.

When should vendor connections be restored after a compromise?

Restore connections only after the response team reviews evidence that the threat has been contained and remediated, affected credentials and secrets have been addressed, restored data has been checked for integrity, and the connection passes controlled testing. Document approval, residual risks, heightened monitoring, and a rollback plan. The incident review should then carry forward improvements to coordination, vendor oversight, containment, and access to reliable directive information.