Audit Obligations

Intent#

This page states the external obligations that the audit extension satisfies. It is informative. The extension page owns every provision.

litespec/ext/audit#record-the-audit-adoption-decision requires an adoption decision. litespec/ext/audit#cover-the-required-audit-categories requires a stated selection of audited categories. Both ask a project to say why it audits what it audits. This page is the source those answers draw on, so a project records a decision rather than a survey.

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. An implementation built to their union satisfies each one without a separate program.

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 an implicit selection needs no document.

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. They are user identification, event type, date and time, success or failure indication, origination, and affected resource identity.

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

The success-or-failure field and the invalid-attempt event are the two obligations that a success-only trail fails.

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 pulls in two directions at once. Reading it as only a constraint produces a thin trail. 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. 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 it 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.

Building to that model costs nothing at design time. 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