Audit Obligations

Reference#

The Frameworks#

Four bodies of guidance apply to a business application that holds personal data or touches payments. They agree far more than they differ, so an implementation built to their union satisfies each one without a separate program per framework.

NIST SP 800-53, AU Family#

The AU controls split auditing into six questions. They are the most complete public statement of the problem.

AU-3 is the field list that the other frameworks restate. AU-2 is the control most projects skip, because a selection nobody writes down produces no document to check.

ISO/IEC 27001:2022, Annex A 8.15#

Control A.8.15 requires logs of user activities, exceptions, faults, and security events. It requires protection from tampering and unauthorized access. It also requires analysis, which makes an unread trail a finding rather than a control.

PCI DSS 4.0, Requirement 10#

Requirement 10.2.2 names the fields for each event: user identification, event type, date and time, success or failure indication, origination, and affected resource identity.

Requirement 10.2.1 names the events: individual access to cardholder data, actions by administrative accounts, access to the audit records, invalid logical access attempts, and changes to authentication credentials.

A trail that records successes only fails exactly two obligations: the success-or-failure field and the invalid-attempt event.

OWASP Logging Cheat Sheet#

The OWASP guidance adds the developer-facing half. Record authentication successes and failures, authorization failures, higher-risk actions, sensitive data access, and data import or export.

It also states the exclusions. Never record passwords, session identifiers, access tokens, encryption keys, database connection strings, payment card data, or sensitive personal data.

GDPR#

The General Data Protection Regulation both requires the trail and constrains what it holds. Reading it as only a constraint produces a thin trail, and reading it as only a mandate produces an erasure problem.

The resolution is the record shape. A trail retained on a legal-obligation or legitimate-interest basis stays lawful, and a supervisory authority accepts it. A trail that copies names, addresses, message bodies, or state snapshots into an append-only store conflicts with Article 17, and no retention policy resolves that conflict.

litespec/ext/audit#exclude-personal-data-beyond-actor-identity and litespec/ext/audit#exclude-state-snapshots prevent that conflict at design time. litespec/ext/audit#remove-the-identity-mapping-on-erasure then satisfies an erasure request by removing the mapping from actor identifier to person. The record keeps its evidential value and the person stops being identifiable from it.

Two consequences follow for a project. Record the lawful basis and the retention period of each audited category in the adoption decision. Include the trail in the records of processing activities, because the trail is itself a processing activity.

Schema Alignment#

The record shape follows a model that three sources describe in the same terms: an initiator performs an action on a target and produces an outcome at a time and from a place.

Following that model at design time needs no extra work. It lets a project map the trail onto a security platform later without remodeling the store.

Obligation to Provision Map#

Notes#

The sources behind every table above:

• NIST SP 800-53 Rev. 5
• ISO/IEC 27001:2022
• PCI DSS
• OWASP Logging Cheat Sheet
• DMTF Cloud Auditing Data Federation
• Open Cybersecurity Schema Framework
• Erasure rights against audit retention