Summary: When Quest Diagnostics disclosed unauthorized access to its lab-ordering platform in October 2026, the number of affected patients was still under investigation. This article walks security leaders through what it takes to scope a data incident with evidence: locating sensitive data, reconstructing access, separating facts from assumptions and testing the process before a real incident.
On October 21, Quest Diagnostics discovered that someone had gained unauthorized access to Quanum Lab Services Manager, the platform some of its clients use to place test orders and look up results. The next day, the company disclosed the incident in a filing with the Securities and Exchange Commission. It said it believed certain patient records had been accessed, but the number of affected patients and the specific records involved were still under investigation.
That is a completely normal place to be a day after discovery. Incident response takes time, and early disclosures are supposed to be careful about what they claim. This is not a critique of Quest. It is an invitation to look inward, because every security leader will eventually face the same question from legal, from the board and from regulators: which customers were affected?
The honest answer depends less on how quickly your team works during the incident and more on the evidence you put in place before it. If you cannot connect access activity to the sensitive information involved, scoping a breach turns into an exercise in estimation, and estimates tend to grow in the direction of caution.
Why scoping a data incident is so hard
Most organizations have plenty of logs. The problem is that logs describe events, while the people making notification decisions need answers about data. A firewall log can tell you that an IP address connected to a server. An authentication log can tell you that an account signed in. Neither one tells you whether that account read a table full of lab results, a reference table of supply codes or nothing at all.
When that gap cannot be closed, teams fall back on the broadest defensible assumption. If an attacker had a foothold in a system, everyone whose data lived in that system becomes potentially affected. That conclusion is safe, but it is expensive. It can mean notifying far more people than necessary, widening regulatory exposure and straining relationships with customers whose records were never touched.
Closing the gap comes down to four disciplines, and each one is far easier to build ahead of time than to improvise in the middle of a response.
Locate the sensitive information first
You cannot scope an incident around data you have not found. The first question in any investigation is what sensitive information lived in the compromised environment, and that question is much easier to answer when classification has already been done.
Good data classification goes beyond tagging a column as PII. It tells you which categories of data exist, such as health information, payment data, government identifiers and contact details. It tells you where they sit, which business owner is accountable for them and where copies have traveled. That last point matters more than most teams expect. Production data gets cloned into analytics environments, exported to vendors and staged for testing, so a breach in one place may involve records that also live in three others.
When classification is current, an investigator can look at a compromised system and say with confidence which data categories were at risk. When it is stale or incomplete, the team spends the first critical days of an incident rediscovering its own data estate.
Reconstruct the access
Knowing what data was present is half the picture. The other half is knowing what actually happened to it, which means connecting identities, queries, objects and timestamps into a sequence someone can follow.
Database activity monitoring is built for this kind of reconstruction. It records which identity ran which query, against which tables or columns, at what time and how many rows came back. Paired with application logs, it lets investigators trace a session from login through to the specific records touched. If a compromised service account queried a results table, you want to know whether it pulled ten rows or ten million, and whether those rows belonged to one client or every client.
There is a catch, and it is worth facing before an incident rather than during one. Monitoring only helps where it is deployed and where its records are retained. Teams should know which databases and platforms are covered, how long activity records are kept, whether service accounts and shared credentials can be tied back to a real actor and where the blind spots are. A coverage gap you discover in the middle of an investigation is far harder to explain than one you documented and addressed in advance.
Separate facts from assumptions
Early in an investigation, three very different statements tend to blur together. The first is that someone had permission to access the data. The second is that someone actually accessed it. The third is that the data was confirmed to have left the environment.
Each one carries different implications. A compromised account with broad permissions creates potential exposure across everything it could reach. Observed access narrows that to the records the account actually queried. Confirmed extraction narrows it further and often changes the legal and communications strategy entirely.
Healthcare offers a useful illustration. Under HIPAA, an impermissible use or disclosure of protected health information is presumed to be a breach unless the organization can demonstrate a low probability that the information was compromised. That determination rests on a risk assessment that considers, among other factors, whether the information was actually acquired or viewed. The standard rewards evidence. An organization that can show precisely what was touched has more room to make accurate, defensible decisions than one that can only point to what was reachable.
Keeping these categories distinct in incident documentation helps security, legal and leadership have the same conversation. It also makes it easier to refine conclusions as new evidence arrives, rather than walking back a statement that blended fact and assumption.
Test the investigation before you need it
Most tabletop exercises focus on containment: who gets called, who isolates which systems and who speaks to the press. Those are important. Fewer exercises ask the question that dominates the days after containment, which is who was affected and how you know.
Try running a tabletop built around that question. Choose a realistic scenario, such as a compromised credential with read access to a customer database, and ask the team to answer three things. Which customers could be affected? What evidence supports that conclusion? What remains unknown, and why?
The answers tend to be revealing. A team might find that classification does not yet cover a recently migrated platform, that activity records roll off sooner than an investigation would need, or that a shared service account makes attribution impossible. Each of those findings is far cheaper to fix in a conference room than in a live incident with a disclosure clock running.
Building incident scoping into your data security program
The most useful shift is to treat incident scoping as a requirement of your data security program rather than a task that begins after something goes wrong. Classification and activity monitoring are often justified by compliance, but their value becomes most obvious when someone asks which customers were affected and expects a specific, supportable answer.
That is the work ALTR’s data classification and database activity monitoring are designed to support. Knowing where sensitive data lives, and keeping a reliable record of who accessed it, gives security, legal and leadership teams the evidence to make incident decisions on facts rather than worst-case assumptions.
The question will come eventually. The organizations best prepared to answer it are the ones that decided, well in advance, what evidence they would need.