QR Code Phishing Incident Response Checklist for Patient Transport Dispatch Software Vendors

A QR code phishing incident can put vendor accounts, dispatch operations, and sensitive information at risk—even when the initial message looks routine. Use this checklist to establish what happened, contain access, verify dispatch activity, and coordinate response with affected customers.

Preserve evidence as you work, restrict access to incident records, and coordinate operational decisions with the customer’s designated security and dispatch contacts. If your organization is a HIPAA business associate, follow the applicable business associate agreement (BAA) as well as relevant legal requirements.

How should vendors triage a QR code phishing incident?

Open an incident as soon as a suspicious QR code is reported. Record when and how it was received, who received it, which device was used, whether the code was scanned, what page appeared, and whether anyone entered credentials, approved a prompt, downloaded an app, or submitted information.

Preserve the original message, image or attachment, headers, relevant timestamps, and user reports. Avoid forwarding the message in a way that could cause others to scan it. Restrict access to evidence that may contain patient or account information, and document investigative actions and outcomes. HHS describes identifying, responding to, mitigating, and documenting security incidents as Security Rule requirements for covered entities and business associates. HHS guidance on security incidents involving ePHI

• Identify the message recipients and any people who scanned the QR code or followed the link.
• Assess whether credentials, multifactor authentication codes, session approvals, or sensitive information were entered.
• Determine whether a file or app was downloaded, a device permission was granted, or a security warning appeared.
• Notify your incident lead, identity and endpoint responders, privacy or legal contacts, and the customer contacts specified in your response plan and BAA.
• Prioritize accounts and systems with access to dispatch, customer administration, integrations, or sensitive information.

Do not assume that scanning alone proves an account or device was compromised—or that no harm occurred. The next steps depend on what the user saw and did, what the device and identity logs show, and whether sensitive information or operations were accessed or changed. The FBI’s QR code scam guidance advises caution with QR codes received through messages.

How can responders safely analyze the QR code and destination URL?

Analyze the code without opening its destination on a production device or using an account that can access customer systems. Preserve the original image or attachment, record its source and file details, and use an approved isolated analysis environment to decode the QR code. Treat the decoded value as untrusted input.

• Record the raw decoded string before changing it. It may be a URL, a shortened link, or another kind of payload.
• For QR code URL decoding, identify the complete hostname and path. Note suspicious look-alike spellings, unexpected subdomains, unusual ports, and encoded characters.
• Perform redirect-chain analysis in a controlled environment that does not contain credentials, patient data, or access to production systems. Record each redirect and the final destination.
• Do not enter credentials, approve an authentication prompt, download files, or submit any information during analysis.
• Retain the original code, decoded value, observed redirects, timestamps, and tool or environment used, following your evidence-handling procedures.

QR-code phishing can direct a person to a malicious site or prompt them to provide information or download software. That is why responders should treat the decoded URL as suspicious until it is assessed and should avoid interacting with it from an ordinary work session. FBI guidance on QR-code scams and CISA phishing guidance

Which accounts and sessions should be contained and reviewed?

Contain accounts when the evidence indicates credentials, session tokens, or authentication approvals may have been exposed, or when unauthorized activity is suspected. Coordinate account actions with the identity team so you can limit access without unnecessarily interrupting critical dispatch operations.

• Reset exposed passwords, block sign-in where appropriate, and require fresh authentication through approved procedures.
• Use session revocation to invalidate available refresh tokens or active sessions. Check the relevant identity provider and application: revoking an identity-provider session may not terminate a session token issued and controlled by a separate application.
• Review identity sign-in logs for unfamiliar devices, IP addresses, locations, applications, authentication methods, unusual timing, and failed or successful attempts around the incident.
• Check for new multifactor authentication methods, app passwords, OAuth consent grants, connected applications, or changes to account recovery details.
• Inspect mailbox forwarding rules, inbox rules, delegated access, and suspicious sent, deleted, or hidden messages.
• Review privileged accounts, service accounts, API credentials, and integrations if the exposed identity could access them; rotate affected secrets when warranted.

Use the sign-in evidence together with user reports and application activity; a location or IP address alone may not establish whether a sign-in was unauthorized. Microsoft’s documentation describes sign-in log details and notes limitations in interpreting location, while its emergency access guidance explains that applications may control their own session tokens. Microsoft Entra sign-in log details and Microsoft guidance on revoking user access

How should affected devices and systems be investigated?

Identify every device used to scan the code or visit the destination, including personal phones used for work. Preserve relevant evidence before making changes that could erase it. If a device appears compromised, isolate it from networks using your established procedures and have qualified responders assess it; do not casually wipe or reset it before evidence is preserved.

Review endpoint and mobile-device-management alerts, browser history, downloads, newly installed apps or profiles, granted permissions, and security-tool detections. Correlate those findings with DNS, web-proxy, firewall, email, cloud, identity, and application logs for the relevant time window. Check whether the device accessed the dispatch platform, customer portals, remote-access tools, or stored credentials.

Investigate vendor-hosted systems and integrations as well as the reported device. Look for unusual administrative actions, API calls, exports, configuration changes, new users, or access from the affected identity. Preserve log sources and timestamps, and document gaps such as missing telemetry or expired retention. HHS guidance calls for assessing risks to ePHI and documenting security measures and relevant systems. HHS guidance on HIPAA risk analysis

How can vendors identify and remove other malicious messages?

Use the original message and available indicators—such as sender details, subject, message identifiers, QR image, decoded URL, and redirect destinations—to search for related messages across vendor and customer mailboxes, where authorized. Look for variations in wording, sender addresses, QR images, shortened URLs, and delivery times rather than relying on one exact match.

• Determine who received each message and whether it was delivered, opened, forwarded, reported, or quarantined.
• Search for related emails, collaboration messages, and other delivery channels used in the campaign.
• Remove or quarantine confirmed malicious messages using approved administrative tools, while preserving copies or metadata needed for investigation.
• Block confirmed malicious senders, domains, and URLs using controls that do not disrupt legitimate dispatch communications.
• Check compromised mailboxes for mailbox forwarding rules, suspicious inbox rules, and unauthorized delegated access.
• Tell staff how to report similar messages and warn recipients not to scan or forward the QR code.

Microsoft’s phishing investigation guidance recommends identifying recipients, assessing user interaction, reviewing sign-in and endpoint activity, checking for forwarding rules, and removing malicious messages. Adapt those steps to the email and security platforms you actually operate. Microsoft phishing investigation playbook

How can responders verify patient transport dispatch changes and protect sensitive data?

Work with the customer’s authorized dispatch lead to identify changes made during the incident window. Review dispatch audit logs and related system records for the actor, timestamp, action, affected trip, and before-and-after values. Examine changes to assignments, pickup and destination details, scheduled times, cancellations, patient or facility details, and user permissions.

Do not treat an email, text, or suspicious QR destination as authoritative confirmation of a dispatch change. Verify questionable changes through an independently established contact method, such as a trusted phone number already on file. If a change could affect a patient’s transport, escalate promptly to the customer’s dispatch lead and follow the customer’s downtime or manual-dispatch procedures.

• Compare dispatch audit logs with relevant identity, application, API, and integration logs.
• Confirm whether changes were authorized with the responsible customer contact, using a trusted channel.
• Identify affected trips and coordinate corrections or re-confirmations with the customer’s dispatch team.
• Restrict access to incident records and share only the information needed for investigation and response.
• Preserve evidence of changes and corrections without altering the underlying audit records.

Document what information may have been viewed, changed, exported, or transmitted, and which customers or individuals may be affected. HHS identifies regular review of information-system activity, including audit logs, as part of the Security Rule’s security management process. HHS HIPAA audit protocol

What recovery, notification, and prevention steps should follow?

Before restoring normal access, confirm that the malicious message or access path is contained, affected credentials and sessions have been addressed, suspicious rules or permissions have been removed, and affected systems have been checked. Validate that dispatch records and integrations are operating as intended with the customer’s authorized team. Monitor for renewed suspicious sign-ins, messages, account changes, or dispatch activity.

Assess healthcare breach notification obligations based on the vendor’s role, the data involved, the evidence, the applicable BAA, and other relevant laws. A software vendor is not automatically a HIPAA business associate in every arrangement; the role depends on the services and relationship. When a business associate discovers a breach of unsecured PHI, HIPAA requires it to notify the covered entity without unreasonable delay and no later than 60 days after discovery, while a BAA may require earlier notice. A security incident may also be reportable under the contract even if it has not been determined to be a breach. HHS guidance on business associate incident reporting

For a suspected impermissible use or disclosure of PHI, the applicable covered entity or business associate should assess whether the event meets the Breach Notification Rule’s definition and whether an exception or documented low-probability-of-compromise assessment applies. Covered entities generally must notify affected individuals without unreasonable delay and no later than 60 days after discovery of a breach of unsecured PHI; additional reporting may apply depending on the circumstances and number affected. The business associate should promptly provide the covered entity with the facts needed for its assessment and follow the BAA and applicable law. HHS Breach Notification Rule guidance

• Preserve an incident timeline, findings, actions taken, affected systems, and customer communications.
• Coordinate customer and individual notices with the responsible privacy or legal teams; do not assume that every QR scan triggers a notification.
• Update detections, email controls, identity protections, and QR-code handling procedures based on the incident findings.
• Brief staff on how to report suspicious QR codes and what to do after scanning one.
• Review the incident response plan and relevant customer contacts, BAAs, and operational continuity procedures.

In short, preserve evidence, safely assess the QR code, contain compromised access, investigate identity and dispatch activity, and coordinate any notifications with the customer and appropriate legal or privacy contacts. A documented response helps protect sensitive data while supporting safe continuity of patient transport operations.

FAQs

What should staff do after scanning a suspicious QR code?

Staff should stop interacting with the destination, avoid entering credentials or approving prompts, and report the message and device to the organization’s security contact promptly. They should say whether they entered information, downloaded an app or file, granted permissions, or approved an authentication request. Responders can then preserve the message, assess the device, and decide whether account containment is needed.

How can responders determine whether credentials were exposed?

Ask the user what information they entered and whether they approved any sign-in or multifactor authentication prompt. Review identity sign-in logs and application activity for suspicious attempts or successful access, and check for new authentication methods, app grants, mailbox changes, and activity in the dispatch platform. Logs can support the investigation, but responders should also consider what telemetry is available and whether sessions or application-issued tokens require separate revocation.

How should vendors verify dispatch changes during an incident?

Review dispatch audit logs and correlate the actor, time, affected trip, and changed values with identity, application, and integration records. Ask the customer’s authorized dispatch lead to confirm questionable changes through a trusted contact method already on file. Escalate changes that could affect patient transport and follow the customer’s downtime or manual-dispatch process.

When may patient or customer notification be required?

Notification depends on the vendor’s legal role, the information involved, whether an event meets the applicable breach definition, the evidence and risk assessment, contractual terms, and other applicable laws. A HIPAA business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery; the BAA may require faster notice. The covered entity is generally responsible for required individual notifications, though it may delegate that work. Consult the applicable BAA and qualified privacy or legal counsel to determine who must notify whom and when.