MON-002 Log Integrity and Protection
Description
Audit logs are stored in a tamper-resistant or write-once store, separate from the systems being logged. Unauthorised access to, modification of or deletion of logs is prevented and alerted. Audit records and the tools that read them are protected by a cryptographic mechanism: records are signed or hashed on write and the values are verifiable independently of the system that produced them. Log integrity can be demonstrated to auditors.
Rationale
Logs that can be tampered with are worthless as evidence, and separating log storage keeps a compromised production system from erasing the record of its own compromise. Storage controls and cryptographic protection answer different attacks: immutable storage stops deletion by someone who reached the store, while signing stops undetected alteration before the record ever arrived, including by whoever operates the store. Covering the audit tools as well as the records closes the case where the reader is changed rather than the data.
Applicability (9 profiles)
Framework Mappings (16)
| LOG-02 | Audit Logs Protection | full |
| LOG-04 | Audit Logs Access and Accountability | full |
| LOG-10 | Audit Records Protection | full |
| LOG-02 | Audit Logs Protection | full |
| LOG-04 | Audit Logs Access and Accountability | full |
| LOG-10 | Audit Records Protection | full |
| HIPAA-164.312.b | Audit Controls | informative |
| HIPAA-164.312.c.2 | Mechanism to Authenticate Electronic Protected Health Information | informative |
| NIS2-CIR-3.2 | Monitoring and Logging | informative |
| AU-10 | Non-repudiation | informative |
| AU-5 | Response to Audit Logging Process Failures | informative |
| AU-9 | Protection of Audit Information | full |
| AU-9(2) | Protection of Audit Information | Store on Separate Physical Systems or Components | full |
| AU-9(3) | Protection of Audit Information | Cryptographic Protection | full |
| AU-9(4) | Protection of Audit Information | Access by Subset of Privileged Users | informative |
| ASI10 | Rogue Agents | informative |
Evidence (3)
Log storage configuration showing audit logs are written to a tamper-resistant or write-once store, separate from the systems generating the logs, with access controls restricting modification and deletion.
Example: AWS S3 Object Lock configuration for log buckets (WORM/Compliance mode), AWS CloudTrail log file validation settings, or equivalent immutable log storage configuration showing bucket policy, access controls, and object lock settings
Test: Read the log storage configuration. Verify: (1) the log store sits in a separate account, project or resource from the systems being logged, (2) write-once retention is enabled on the store for the retention period the schedule sets, (3) log file integrity validation is enabled where the platform offers it, (4) permission to modify or delete log objects is restricted to a named privileged role, (5) an attempt to delete a log object using a standard service account is denied.
Alert or access log entries showing detection of unauthorised access attempts to the log store.
Example: SIEM alert or AWS CloudWatch alarm triggered by unauthorised attempts to access or modify the centralised log bucket, with alert configuration and sample alert event visible
Test: Query the SIEM or alerting platform for alerts on log store access in the last 90 days. Verify: (1) an alert is configured for any modification or deletion attempt against the log store; (2) alert configuration covers all log storage locations; (3) any triggered alerts have a documented review and response.
Output of an integrity verification run over a sample of stored audit records and over the audit tooling itself.
Example: log-integrity-verify-2026-08-25.json
Test: Run or request the integrity verification output. Verify: (1) the run covers records from every log source in scope rather than one representative source, (2) every sampled record's signature or hash validates, (3) a record altered in a controlled test fails validation, (4) the audit tools themselves carry a verified signature or hash, (5) the verification key or anchor is held outside the system that produced the records, (6) the run is scheduled rather than performed only for an audit.
Questions (2)
Are audit logs stored in a tamper-resistant or write-once store?
Log storage should be in a separate account, project, or cloud resource from the systems generating logs. Object Lock (Compliance mode) or equivalent immutability should be enforced.
Which mechanisms are used to protect audit log integrity?
Options run from the most commonly held to the least. Storage controls and cryptographic protection answer different attacks: immutable storage stops deletion by someone who reached the store, signing stops undetected alteration before the record arrived, including by whoever runs the store. Covering the tools closes the case where the reader is changed rather than the data.