Audit logs are evidence. If an attacker can delete or modify them, the logs lose their value. If a disgruntled employee can clear their own activity, accountability disappears. AU.L2-3.3.8 requires you to protect logs as the security assets they are.
Protection has multiple dimensions. First, access control. Only authorized security and audit personnel should be able to read logs. System administrators who can see logs should not be able to modify them. Second, tamper evidence. You should know if someone has tried to modify or delete logs. Third, retention. Logs are protected for their entire retention period. This complements AU.L2-3.3.1 (log collection). If you collect logs but don’t protect them, they’re worthless as evidence.
What the assessor is actually evaluating
The assessor will test your log protection in three ways. First: “Who can read these logs?” They want a specific answer. “The security team” is vague. “The SIEM administrator and the security manager, with IT director approval required to grant others access” is what they want to hear.
Second: “Who can modify or delete logs?” The answer should be “No one. The SIEM system writes them, and only the SIEM has write access. Everyone else has read-only access, and audit logs specifically cannot be deleted, only archived by the SIEM after retention expires.” If a system administrator or auditor can modify or delete logs, this practice fails.
Third: “How do you know if someone has tried to modify logs?” They want evidence of tamper detection. This might be file integrity monitoring on log files, hashing of log entries, immutable log storage, or monitoring of access control changes on the log store. The specific mechanism matters less than the existence of detection.
What a realistic SSP definition looks like
Access controls:
- Read access is granted only to [specify roles: security team members, audit staff, IT director] on a need-to-know basis
- Write access is restricted to the automated logging systems and SIEM platform only
- Delete access is completely restricted; logs are retained for [X months] and archived or deleted only through automated processes
- All access to logs is logged and monitored as part of our regular audit review
Integrity protection:
- Log files are protected with file integrity monitoring to detect unauthorized modifications
- Logs are stored in [read-only storage / immutable storage] after a brief buffer period to prevent modification
- Log entries are [cryptographically hashed / digitally signed] to detect tampering
- [If applicable: Logs are replicated to a second, physically separate location to ensure availability and detect deletion attempts]
Encryption:
- Logs in transit to the SIEM are encrypted using [protocol: TLS 1.2 or higher]
- Logs at rest are encrypted using [algorithm: AES-256]
Retention and disposal:
- Logs are retained for a minimum of [X months]
- After retention expires, logs are [securely deleted / archived to long-term storage] using [deletion method]
- Deletion is logged and audited"
Specificity matters. Named people, clear restrictions, and concrete protection mechanisms all demonstrate that you’ve thought this through.
How to present your evidence
- Access control lists showing who can read and modify logs
- File integrity monitoring configuration or immutable storage settings
- Access logs showing who accessed logs and when
- Encryption configuration for logs in transit and at rest
Gather four categories of evidence:
Access control documentation. A document or screenshot showing who has access to logs. This might be a SIEM user roles list, file permissions on a log directory, or a security control procedures document. Show that read access is limited and write/delete access is restricted.
Configuration protecting log integrity. If you use file integrity monitoring, provide the configuration showing which log files are protected and the monitoring rules. If you use immutable storage, document the storage configuration and retention settings. If you use log signing or hashing, show the mechanism.
Access logs or audit trails. Evidence that access to logs is itself logged. Pull a sample of who accessed logs and when over the past month. This demonstrates that you monitor access and can detect unauthorized attempts.
Encryption configuration. Document how logs are protected in transit and at rest. TLS 1.2+ for transmission and AES-256 for storage are standard. Provide configuration screenshots.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
If you use an MSSP
Your MSSP should protect your logs with at least as much rigor as you would internally. They own the technical implementation of access controls, encryption, and integrity monitoring on your logs. Your role is to verify that their approach meets your requirements and to document the controls they’ve put in place on your behalf.
Your MSSP’s SIEM should implement access controls limiting who can see your logs. You should have a distinct user account to access your data, separate from their other customers’ data. Encryption in transit (TLS) and at rest (AES-256 or equivalent) should be standard. They should use immutable or read-only storage for logs to prevent modification. Access to logs should be logged and monitored.
Request documentation of your MSSP's access controls, log storage architecture, encryption approach, and confirmation that your logs are isolated from other customers. Ask about their integrity monitoring and how they detect unauthorized access or modification. In the assessment room, ask them to walk through their multi-layered protection approach. A good MSSP can explain their controls in detail and provide evidence they're working.
Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.