Quest Diagnostics took a key system used to manage medical test results offline on Thursday after discovering unauthorized access. The company published a statement and an FAQ about the cyberattack, warning customers that they believe some patient data within the system was accessed. The New Jersey-based company says it serves half of the doctors and hospitals in the U.S. and one in three American adults each year.
What happened
The affected system handles medical test results, which places it in the path of routine clinical work rather than at the edge of the estate. Quest discovered unauthorized access and took the system down the same day. Access to the system has been paused while Quest investigates the attack.
The company published a statement and an FAQ about the cyberattack, warning customers that they “believe some patient data” within the system was accessed.
Quest said it is working with law enforcement to resolve the incident and is investigating what patient data was affected by the attack. The scope of the exposure has not been stated.
How it was done
The quoted reporting does not describe an initial access route, a vulnerability or a technique. It says only that unauthorized access was discovered and that the system was taken offline in response. No party has been confirmed as responsible, and the investigation into which patient data was affected is still running. Treat any further detail as unknown for now.
What to check
If your organisation runs or integrates with a clinical results system, these checks are worth running this week.
Map which systems hold patient records
Build or refresh an inventory of applications that store or transit patient identifiers, results or report documents. Include reporting replicas, data warehouses, message queues and file drops, not just the primary application. A gap looks like a results feed landing in storage no one owns.
Review who can read bulk results
Pull the role assignments for any account that can query or export more than one patient at a time, including service accounts and support roles. In a typical identity provider, export group membership and compare it against the current staff list. Accounts for departed staff or shared logins with export rights are a bad result.
Confirm you can detect bulk reads
Check that database and application logs record read and export events, not only writes and logins. Run a query for the largest result sets returned per account over the last ninety days and see whether anything stands out. If read activity is not logged at all, that is the finding.
Test that you can take the system offline
Write down the exact steps to isolate the results platform, who approves it and how clinicians would be told. Walk it through on paper with the operations and clinical teams. If the only way to stop access is a full data centre action, the plan needs work.
Check interface and partner connections
List every inbound and outbound integration, including HL7 interfaces, SFTP endpoints and API clients. Verify each one has a named owner, scoped credentials and an expiry date. Shared static credentials with no rotation record are the weak point.
Verify log retention matches investigation needs
Confirm authentication, access and network logs for these systems are retained long enough to reconstruct months of activity. Check the retention setting in your log platform rather than trusting the policy document. Thirty days of retention will not support a long lookback.