File access log

Download tracking is the slice that covers fetches. The access log is the whole sequence an auditor asks for when the question is "who could see this, and who did."

NIST SP 800-53's audit family (AU-2, AU-3) asks an organization to decide which events are logged and what each record contains. SP 800-92 covers how those logs are kept and reviewed. For a transfer, a useful row has the time in a stated zone, the actor, the action, the object key, the result, and a byte count where the action moved bytes. A row that says "file accessed" with no actor and no result fails AU-3's intent.

A partner claims a Thursday payroll file never arrived. The MFT log shows an SFTP STOR at 01:17 UTC, 1,204,883,221 bytes, result success, key id `vendor-prod-3`. The partner's server log shows no session from that source IP. The two logs disagree, and the disagreement is the finding: either the job wrote somewhere else, or the partner is searching the wrong host. Without the sender's row, the argument is a memory of a green checkmark. A second case is a revoked link. The log should show the revoke actor at 10:20 and a denied GET at 11:00. A log that only stores successes cannot prove the revoke was enforced.

Access logs are not the file. They live in a different store, with their own retention. A 30-day log and a seven-year retention rule on the file is a gap the first audit will find. They also contain addresses and names. Access to the log is its own permission. A shared support login that can read every transfer row is a second copy of the sensitive metadata, and SP 800-92 treats unprotected logs as a failed control even when the files were encrypted.

Managed file transfer products sell this record. A bucket access log can too, if someone actually enabled it and shipped it off the bucket. The feature that is off generates no row.