SaaS audit logs: define, protect and test the evidence

Start a SaaS audit logging review with the actions your team needs to reconstruct: a permission change, an export request, or an administrator changing a customer setting. For each action, write down what evidence a reviewer should be able to retrieve. Then examine collection, access and retention separately. Use the workflow below as a proposed engineering checklist, adapted to your product and its actual obligations.

Define the questions before the storage

Choose one workflow for the first review. For an export, ask who requested it, which account and dataset were involved, whether authorization succeeded, and whether the export completed. Specify the expected record for a denied request as well as a successful one. Keep a list of events that your current implementation does not capture.

The OWASP Logging Cheat Sheet recommends recording the time, location, actor and nature of an event, with details suited to its purpose. It also distinguishes application events from infrastructure logs. Use that guidance to inspect the application code that knows the action and outcome.

Write a small event contract

A proposed starting contract could include the following fields. These names are suggestions for your application, not a required industry schema:

• event_id and schema_version: identify the record and its interpretation.
• tenant_ref and actor_ref: identify the account and responsible user or service.
• action, object_ref and outcome: describe the attempted operation and its result.
• request_ref: connect related records from the workflow.

For each field, document who supplies it, its permitted values and what happens when it is missing. Have the application owner review a sample export alongside the event definition. Label sample records as synthetic when demonstrating the format.

Keep event time and collection time distinct

The OpenTelemetry Logs Data Model distinguishes the source event timestamp from the time the collection system observed it. It also defines optional trace and span identifiers for related request processing.

If your system collects delayed events, preserve both available timestamps and document which one an exported report sorts by. Treat correlation fields as links for investigation; do not use their presence as a substitute for checking that the expected business events were recorded.

Choose what stays out

OWASP's exclusion guidance identifies access tokens, passwords, connection strings and sensitive personal data as information that should generally be removed or specially protected rather than logged directly. Build an explicit field allowlist and review it before enabling production collection. Keep raw request bodies out of the proposed contract unless a separately reviewed need justifies them.

Specify the archive's actual protection

If you use Amazon S3 Object Lock, record the protected object version and retention configuration. AWS documents that locking an existing version does not prevent creation of a new version. Governance mode also permits authorized bypass under specified conditions.

For that design, ask the reviewer to retrieve the protected version, not simply whichever version is currently visible under the object name. Keep storage protection and event completeness as separate review questions: a retained file still needs to be compared with the events your application was supposed to produce.

Test failure and retrieval

OWASP's verification guidance includes logging failures and access controls. For your acceptance test, use synthetic accounts to exercise a successful action, a denied action and a collector outage. Check the resulting records, tenant isolation, secret filtering and the documented recovery behavior.

Finish the review with a reproducible evidence package: the event contract, sample records, test procedure, observed results, archive settings and unresolved gaps. Assign an owner to each gap and repeat the relevant checks after changes to the workflow or logging configuration.