To determine whether your client project data was accessed, you must examine audit logs, review cloud provider records, and conduct a forensic assessment of your systems—not simply assume access occurred. The difference between an attempted breach and actual data access is critical: many jurisdictions only trigger mandatory breach notification requirements if you can affirmatively demonstrate that unauthorized persons actually accessed and acquired sensitive information. Checking access starts by knowing where your data lives and what automated logging mechanisms are already capturing activity without your intervention.
The 2026 Instructure Canvas breach provides a stark example of the distinction. When the ShinyHunters ransomware group compromised over 9,000 schools, Instructure had to verify which of the 275 million affected individuals’ records were actually accessed versus merely exposed. The company relied on automated cloud audit logs and forensic investigation to determine the scope. Your approach should be similar: begin with what your infrastructure automatically records, then layer in targeted investigation if those logs are incomplete.
Table of Contents
- What Audit Logs Reveal About Data Access
- Forensic Assessment Standards and Their Limitations
- File Server and Application-Level Monitoring
- Documentation and Retention Requirements for Access Records
- Warning Signs of Data Access and Investigation Triggers
- Third-Party Verification and Regulatory Disclosure Processes
- Building Ongoing Access Monitoring as Prevention
- Conclusion
What Audit Logs Reveal About Data Access
Cloud platforms automatically capture data access without requiring you to enable any special monitoring. Google Cloud Platform, AWS CloudTrail, and Azure Activity Log record every administrative action and data retrieval event—including the timestamp, identity of the accessor, the method called, and the specific resource affected. If your client data lives in Cloud SQL, Bigtable, Firestore, or similar services, these logs already exist. The challenge is not whether access occurred, but whether anyone reviewed the logs.
The limitation here is significant: automatic logs capture *what happened* but not always *intent*. A system administrator accessing database records for legitimate operational purposes produces the same audit trail entry as someone exfiltrating data. You must correlate audit logs with other indicators—unusual access patterns, downloads from off-hours, or access from unfamiliar IP ranges—to distinguish routine operations from suspicious behavior. Tools like Datadog, Elastic, and Splunk now offer machine learning–driven anomaly detection that flags mass reads, unusual write patterns, or access outside expected windows. This layering of detection can catch what raw logs alone miss.
Forensic Assessment Standards and Their Limitations
A forensic assessment is the formal method regulators and courts recognize for determining actual data access. The assessment examines your logs, backup records, and system configurations to reconstruct what happened during a suspected breach window. Many state breach notification laws explicitly require this harm-based threshold analysis: you must document a reasonable conclusion that personal data was actually accessed and acquired by an unauthorized person, not merely that your system was breached. If your forensic work shows that attackers only gained access to a non-sensitive server and never reached customer data, you may legally avoid breach notification—but only if you retain written documentation of your findings. The critical limitation is that forensic work is time-consuming and expensive.
A major incident can require hiring external security firms at $50,000 to $500,000 per engagement, depending on complexity and scope. Additionally, if your logging infrastructure is poor or you lack baseline data about normal activity, forensic investigators have little to work with. The Medtronic unauthorized access incident in 2026, which involved claims of up to 9 million compromised records, required months of investigation before the scope could be verified. The company had to document not only that access occurred but the exact categories of data affected. In your case, if your audit logging is sparse, your forensic assessment becomes speculative, and regulators will be skeptical.
File Server and Application-Level Monitoring
While cloud audit logs are automatic, file server access often requires dedicated monitoring tools. Tools like Lepide, Netwrix, and Varonis monitor who accessed which files, when, and what they did with them—capturing both successful access and failed attempts. Varonis distinguishes itself by providing insider risk context: it doesn’t just log “user A accessed folder B,” but correlates that access with behavioral baselines and known threat patterns. This deeper intelligence can reveal whether someone was browsing normally or conducting a systematic data exfiltration. The tradeoff is that these file auditing tools generate enormous amounts of data.
A single file server can produce gigabytes of logs daily. You need the infrastructure to store, index, and query those logs—or you’re back to not knowing what happened. The Flickr third-party email incident on February 5, 2026, illustrates another access verification challenge: the breach occurred not in Flickr’s systems but in a third-party email service provider’s infrastructure. Flickr had to verify data access through disclosure from that vendor, not through its own logs. This means your monitoring is only as complete as your supply chain—if your data passes through third-party services, you depend on their logging and their willingness to disclose.
Documentation and Retention Requirements for Access Records
Every state in the U.S. has enacted data breach notification laws, and many require you to retain your access verification documentation for at least three years. This isn’t optional: if a regulator or plaintiff’s attorney asks how you determined whether data was accessed, you must produce your written risk assessments, log analyses, and forensic reports. States like California, New York, and Massachusetts are particularly strict. You’re essentially required to document your conclusions with evidence, not memories or verbal explanations.
The practical challenge is that three-year retention of voluminous logs is expensive. A database accessed daily by hundreds of users generates petabytes of audit data. You must decide what to retain: real-time logs (expensive but complete), sampled logs (cheaper but gaps), or summarized reports (leanest but least defensible if questions arise later). A comparison: one Fortune 500 company keeps full CloudTrail logs in cold storage at approximately $2,000 per month, whereas others keep only 90 days of hot logs and rely on forensic tools to reconstruct historical activity. Neither approach is wrong, but your choice affects both your breach investigation capability and your compliance posture if someone later disputes your access determinations.
Warning Signs of Data Access and Investigation Triggers
Certain red flags warrant immediate investigation regardless of your audit logs. Ransom notes, threats from attackers, or public disclosure of your data on underground forums are unambiguous signals of access. But more subtle indicators matter too: unusual database query patterns visible in your monitoring tools, unexpected traffic spikes to your storage systems, or unusual login attempts from anomalous locations. The Canvas and Medtronic breaches both began with third-party notification—researchers discovered the compromised data being distributed—which forced investigation backward.
A critical limitation: by the time you detect access through your own monitoring, attackers may have already been present for months. The average dwell time in data breaches is now measured in days to weeks before detection, meaning that initial access may have left no obvious forensic trace. This is why machine learning anomaly detection, despite its cost and false-positive burden, is increasingly necessary. It’s not foolproof—no detection system is—but it dramatically shortens the window between access and discovery, reducing the volume of data that could be exfiltrated.
Third-Party Verification and Regulatory Disclosure Processes
If your investigation concludes that data was accessed, you’re obligated to disclose to affected individuals and regulators in most cases. The HHS breach portal, state attorneys general, and credit reporting agencies all maintain public records of verified breaches. You cannot simply declare a breach—you must support it with evidence. The Canvas breach disclosure had to specify which schools were affected, what data types were compromised, and on what dates access occurred.
This verification process forces rigor into your investigation that you might otherwise skip. A practical example: when you file a breach notification with your state attorney general, they may request copies of your forensic report, audit logs, and remediation actions. If your documentation is sloppy or conclusions are unsupported, they may demand further investigation or impose penalties. This downstream accountability often becomes the motivation for organizations to conduct thorough initial investigations.
Building Ongoing Access Monitoring as Prevention
The highest-value organizations don’t wait for a breach to investigate access. They implement continuous monitoring from the start—automated logging, anomaly detection, and quarterly access reviews. The cost is significant upfront but spreads over time. If you implement Varonis or a similar tool now and it flags suspicious access in month three, you catch the problem while damage is limited.
If you wait until a breach is disclosed publicly, your forensic investigation is reactive and far more expensive. Looking forward, access verification will become faster and more precise as AI-driven detection improves. Tools like Datadog and Splunk are already offering predictive capabilities that estimate likelihood of compromise before data is confirmed missing. Organizations that embrace continuous monitoring now will have far simpler answers to the question of whether data was accessed—because they’ll know immediately rather than scrambling retroactively.
Conclusion
Checking whether your client data was accessed requires three parallel activities: reviewing automated audit logs from your cloud infrastructure, conducting formal forensic analysis if logs are incomplete or suspicious, and documenting your findings for regulatory and legal purposes. You cannot rely on a single source of truth. Cloud audit logs are automatic but insufficient; forensic assessment is rigorous but expensive; file-level monitoring is precise but generates data overload.
All three together form a defensible picture of what happened. The legal standard is straightforward but demanding: you must affirmatively determine that unauthorized persons accessed and acquired data, not merely that they breached your perimeter. Start with the logs you already have, hire forensic expertise if needed, and retain documentation for at least three years. The organizations that respond most effectively to breach questions are those that answered them in advance, before external pressure forced the investigation.