A renewal questionnaire arrives, and you get to question 31, which asks: "Can you show who accessed your most sensitive files in the last 90 days?"
You open the logs. Your identity provider shows who signed in. Your cloud storage shows which folders were opened and which files were downloaded, by account, from the main tenant. Your SIEM has the network side.
What you cannot produce is a straight answer to the question as written: which people opened which sensitive files, from which devices and locations, and what happened when someone who should not have tried.
The logs are not wrong. They answer a different question: what happened on the system. The question on the form is about the file.
That gap is the subject of this post: what a file access audit log has to record, who asks for it, and what it takes to produce one you can hand to someone outside your team.
📁 Can You Prove Who Opened Your Most Sensitive Files?
System logs show who signed in. File-level evidence shows who opened which file, from where, and whether the attempt was allowed. See the per-file access log on your own files in a free two-week pilot.
What Insurers, Auditors, and Boards Actually Ask
Each audience wants evidence, and each wants a different kind.
Insurers: Underwriting guidance published for 2026 renewals consistently names three controls as the baseline: multi-factor authentication, endpoint detection and response, and tested, immutable backups. It also reports a shift in how underwriters ask. A plain "yes" no longer closes the question. They want to know where a control is enforced, since when, and with what exceptions, and they ask for reports from the tools themselves.
To be accurate about this: a standard insurance questionnaire does not usually ask for per-file access logs by name. What it asks for is evidence. File-level evidence is what you need when the question gets specific, after an incident, or when an underwriter or a customer asks what a compromised account could actually reach.
External auditors: Auditors test whether a control exists and whether it operated. They ask for records, not assurances. A log that shows who accessed a sensitive file and when is a record. A policy that says access is restricted is not.
Customer security reviews: Enterprise buyers send questionnaires that ask how you protect their files and how you would know if someone else opened them. A credible answer is a log, not a promise.
Boards: Directors ask a simpler version: if we were breached tomorrow, how fast could we say what was touched? That is a question about scope, and scope is determined by whether you can see activity at the file.
In every case, the person asking is looking for the same thing: a record that ties a named identity to a named file at a stated time with a stated outcome.
System Logs Versus File Logs
Many organizations already keep substantial logs. The difference is what each one records.
| Log source | What it tells you | What it does not tell you |
|---|---|---|
| Identity provider | Who signed in, from where, with what authentication | What they opened afterward |
| Cloud storage activity | Which folders and files were accessed or downloaded inside that platform | What happened to a copy once it left the platform |
| SIEM and network logs | Traffic and events across systems | The contents or identity of a specific file |
| File-level access log | Which identity tried to open which file, from which device and location, and whether access was granted or refused | Activity on files that are not protected by the control |
The first three are system logs. They were built to monitor infrastructure and sessions, and they do it well. The fourth is built around the file, and the file is the unit an insurer, auditor, or customer is asking about.
The cost of that gap is measurable. IBM puts the average time to identify and contain a breach at 247 days, and the global average cost at $4.99 million. A large part of that time is spent working out what was actually accessed. When the log is built around the file, that question has an answer. When it is built around the system, it has an estimate.
What a File Access Log Must Record
Security logging guidance is consistent about the contents of a useful audit record. NIST's audit record control (AU-3 in SP 800-53) calls for records that establish what type of event occurred, when it occurred, where it occurred, the source of the event, the outcome, and the identity of the individuals or subjects involved. NIST SP 800-92 gives the same shape for log management generally.
Applied to files, that means each record should carry:
- Identity: which person or account made the request, so a human can be named.
- File: which file, specifically, not just which folder or share.
- Action: what was attempted, including opens and decryption requests.
- Time: a reliable timestamp.
- Device and location: where the attempt came from.
- Outcome: granted or refused.
- Policy: which access rule produced that outcome.
Two details matter more than they look.
Refused attempts are the most useful rows: A log that records only successes shows you what happened. A log that records refusals shows you what the control did. An auditor who sees that an unauthorized identity tried and failed has evidence the control operated, not just that it existed.
The log has to be about the file, not the session: A session record says an account was active for an hour. It does not say which files were opened in that hour.
A caution about overclaiming. Whether a log is tamper-resistant, how long it is retained, and how it can be exported into your SIEM are all separate questions with separate answers for each product. Ask each vendor directly rather than assuming. Our own answers are covered in a pilot, and we will not describe a log as tamper-proof or immutable unless we can show it.
Evidence by Audience
| Audience | Typical question | The evidence that answers it |
|---|---|---|
| Insurer | Where is the control enforced, and since when? | Reports from the tool showing scope and dates |
| External auditor | Show that access to this data was restricted and monitored | A record of attempts, including refusals, by identity and time |
| Customer security review | How would you know if someone else opened our file? | A per-file access record for that customer's files |
| Board | If we were breached, what would we know, and how fast? | A demonstrated ability to scope activity to specific files |
Notice that none of these asks for more logs. They ask for logs that answer their question.
What to Look for in Audit Logging Tools
If you are evaluating tools that produce audit evidence, ask these questions.
- Is the record tied to the file or to the session? Ask for an example record and read the fields.
- Does it record refused attempts and the reason? A log of successes only is half a log.
- Does it identify a person, or only an account or IP address? Auditors want someone to ask.
- Does it cover files after they leave your environment? A log that stops at your tenant boundary does not cover the file you forwarded.
- How is log integrity handled? Ask how entries are protected from alteration and what the vendor will and will not claim.
- How can you export it, and for how long is it retained? Ask for specifics, not a feature list.
- Can you show a log for one file, end to end, on request? This is the demonstration an auditor or customer will actually ask for.
How Per-File Encryption Produces the Evidence
This is where the architecture matters, and it is a point about mechanism, not marketing.
When each file has its own key, opening the file requires a request. That request is an access decision: who is asking, from which device, from where, at what time, under which policy. Every decision is an event, and every event can be recorded against that file.
That is why per-file protection generates file-level evidence as a consequence rather than a separate feature. The log is not reconstructed afterward from system traces. It is the by-product of the control doing its job.
Control that travels with the data also means the record travels with it. A file forwarded to an outside party still requires a decision when someone tries to open it. The attempt is logged whether it succeeds or is refused. Theodosian records the identity, device, location, time, and policy outcome for every access request on protected files, while continuously logging access risks and exposure posture across unencrypted data during discovery scans.
The threat changed shape. Attackers arrive with valid credentials, and to every system log that sees only the session, a valid login looks routine. A record built around the file is the one that can show the difference.
The Honest Limits
Theodosian generates per-file access logs for all protected files, wherever they travel, and maps access risk across unmanaged cloud files discovered during continuous scans. However, we believe in being explicit about what the control does and does not do:
- In-Use Content Restrictions: It controls who can open and decrypt a file and under what context; it does not prevent an authorized user from physically copying text or printing content once an unencrypted application display view is rendered (full Digital Rights Management/DRM restrictions are on our roadmap).
- Databases vs. Unstructured Files: It governs and protects unstructured files (e.g., documents, spreadsheets, PDFs, code), not relational databases.
- Holistic Defense: A file access audit log provides definitive proof of file exposure; it works alongside—and does not replace—foundational security controls like multi-factor authentication (MFA), endpoint detection and response (EDR), and immutable backups.
What This Means for Your Program
Most security programs have the logging they need for operations and the logging they need for compliance, and assume the two are the same. They are not. Operational logs help you run the system. Evidence logs help you prove, to someone who was not in the room, that a specific control did a specific thing.
You are probably paying for the first and being asked for the second. The question is whether you can produce it for the files that matter, which is a smaller set than you think. Start there. Pick the files an insurer, an auditor, or a board member would ask about first, and make sure each one can answer for itself.
📁 See the Evidence on Your Own Files
We run a free two-week pilot on a defined set of your most sensitive files. At the end, you have the per-file access log from your own environment, including refused attempts, to put in front of an auditor, insurer, or customer.
FAQs: File-Level Audit Logs and Evidence
Will Theodosian's audit log satisfy our cyber insurance questionnaire?
Questionnaires typically focus on multi-factor authentication, endpoint detection, and backups, and Theodosian does not replace those. What the per-file log gives you is evidence for the harder follow-up: which files an identity could reach, and what happened when someone tried. We do not claim the log satisfies any particular insurer's form. In a pilot, you can show your broker the log from your own files and ask what they would credit.
What does the per-file log actually record?
Each attempt to open a protected file is recorded against that file: the identity, the device, the location, the time, and whether access was granted or refused. That maps to the elements security logging guidance calls for in an audit record. You see a real record from your own environment in the pilot, not a sample.
Does it record refused attempts?
Yes. A refused attempt is an access decision like any other and is logged. For an auditor, those entries are often the most useful, because they show the control operated and not just that it existed.
Can we show an auditor or customer the log for a single file?
Yes. The record is tied to the file, so you can pull the history for one file and walk someone through it. In a pilot, we run that exercise on a file you choose: protect it, share it outside, try to open it from an unapproved device, and show the log.
What happens in a breach? Can the log tell us which files were reached?
For the files Theodosian protects, the record shows which identities attempted to open them, and with what result, so scoping is a lookup, not a forensic project. Stolen copies of protected files are inaccessible without an authorized request. For files that are not protected, the log has nothing to report, which is why we suggest starting with the files an insurer or board would ask about first.
How long does it take to get to a working log on our files?
Deployment takes days or even less, depending on the setup you need and the number of files you wish to protect, not quarters, and there is no data migration. A standard pilot runs two weeks on a defined set of files you choose. You leave with the per-file access log from your own environment and a clear answer to the question on the form.
Related Reading:
The File Security Evidence Package: What CMMC, ITAR, and DoD Auditors Will Ask For
What Does AI Data Governance Require at the File Layer?
What Stops an Attacker Who Has Valid Credentials From Accessing Your Files?
What Your Breach Response Looks Like When Files Are Per-File Encrypted
🔍 Contractor Access Audit: Contractors hold copies your system logs never see. Use our Contractor Offboarding File Security Checklist to find out which files are still out there.
🤖 AI Access Audit: Files pasted into AI tools leave no file-level record. Use our Shadow AI Risk Assessment Checklist to map where that happens.