NIST SP 800-171 Revision 2 and CMMC 2.0 Level 2 control AU.L2-3.3.9 require that audit logs be protected so that only authorized, privileged personnel can manage them — meaning collection, retention, access, and deletion of logs must be tightly controlled, monitored, and auditable. This post shows how to implement that requirement across AWS, Azure, and on-prem environments by combining cloud-native protections, SIEM configuration, role-based access controls, immutability options, and detective controls so a small business can meet compliance without unnecessary complexity.
Implementation overview & compliance context
Practice / Requirement / Key Objectives / Implementation Notes
Practice: enforce privileged-only management of logs. Requirement: prevent unauthorized modification, deletion, or manipulation of audit logs and ensure an auditable chain of custody. Key objectives: separation of duties, least privilege for log management, immutable storage where possible, encrypted transit and at-rest storage, and logging of log-management actions. Implementation notes: centralize collection to a SIEM or immutable storage, use specialized log accounts/tenants, apply RBAC and MFA, and enable tamper-evidence features (e.g., S3 Object Lock, Azure Immutable Blob, WORM storage, log-file validation).
AWS: practical steps
In AWS, centralize logs into a dedicated logging account and use AWS Organizations and SCPs to block broad delete permissions. Send CloudTrail, VPC Flow Logs, and CloudWatch Logs to an S3 bucket owned by the logging account; enable S3 Object Lock in compliance mode and enable SSE-KMS with a CMK that only a narrow set of log-admin roles can use. Enable CloudTrail log file validation so you can detect tampering; configure an S3 bucket policy that denies s3:DeleteObject unless the principal assumes a specific "log-admin" role, and enable CloudTrail for S3 data events to audit any access to the log bucket. Example controls: an IAM policy that denies s3:DeleteObject/PutBucketPolicy for everyone except principals in a dedicated log management group, and an SCP preventing the creation of new S3 buckets outside the logging account.
Azure: practical steps
For Azure, route platform and resource diagnostics to a Log Analytics workspace and long-term storage in a dedicated Storage Account under a separate subscription or management group. Use Azure RBAC roles to restrict write/delete on the storage account and assign only the log-admin principal the Microsoft.Storage/*/delete and Microsoft.Insights/* permissions. Enable immutable blob storage (time-based retention or legal hold) and soft delete on the storage account; enable resource locks on the storage account to prevent accidental deletion. Use Azure Policy to require diagnostic settings across subscriptions, send Activity Logs to the central workspace or storage account, and enable Azure Monitor private links and firewall rules so logs cannot be exfiltrated externally. Use Microsoft Sentinel as the SIEM to enforce RBAC inside the SIEM and enable audit logs for Sentinel workspaces and playbooks.
On‑prem: practical steps
On-premise environments should forward Windows Event Logs via Windows Event Forwarding (WEF) to a dedicated, hardened collector and use syslog-ng/rsyslog for Linux hosts to a central syslog server. Protect collectors by placing them on a management network, using host-based firewalls, and enforcing file system permissions (NTFS ACLs, root-owned files) that only allow the log-admin service account to manage log archives. Use append-only file systems if available or a WORM-capable appliance for long-term retention. Ensure agents communicate over TLS with certificate-based authentication, and configure the SIEM to ingest via network collectors rather than allowing remote administrators to log in to the collector machines directly.
SIEM & audit-tool configuration
Configure your SIEM so access to raw logs, archives, and deletion controls is restricted by RBAC and logged itself — every admin action should generate an audit event that is immutable and forwarded to a separate audit index. Establish distinct roles: log-ingest (write-only), log-analyst (read-only), and log-admin (manage retention & keys). Enable cryptographic integrity checks where available (checksums, log file validation), and store hashes off-host — for example, compute SHA-256 of daily log bundles and export the hashes to an external verifier or to a blockchain audit record if required. Create SIEM rules that alert on anomalies such as sudden drops in log volume, deletions of log groups, changes to retention settings, or new principals granted log-management permissions.
Small-business examples and scenarios
Example 1: A 25-seat company with a hybrid environment uses AWS for servers and an on-prem VMware cluster. They create a dedicated AWS logging account, set up CloudTrail and VPC Flow Logs to write to S3 with Object Lock, and forward on-prem ESXi and Windows logs over TLS to a managed SIEM (Splunk Cloud or Sentinel). The IT manager retains a single "log-admin" account secured with MFA and uses a ticketing workflow (change/approval) before any log retention change. Example 2: A small MSP uses Azure and leverages Log Analytics + Sentinel; they place log retention controls under a separate subscription with Azure Policy enforcing diagnostic settings and use Conditional Access and Privileged Identity Management (PIM) to require justification and time-limited elevation for the log-admin role.
Risks of non‑implementation and best practices
Failing to enforce privileged-only management of logs risks undetected tampering, loss of forensic evidence, regulatory noncompliance, breach of contract with government customers, and potential data exfiltration. Best practices include: enforce least privilege and MFA for all log-management roles, use separate accounts/subscriptions for logging, enable immutability and log-file validation, maintain an auditable change control process for retention and deletion actions, perform periodic access reviews, and automate alerts for any log-management activity. Regularly test incident response using tampered-log scenarios so teams know how to detect and prove log integrity in an investigation.
Summary
To meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AU.L2-3.3.9, a combination of architecture (centralized logging account), enforcement (RBAC, SCPs, Azure Policy, storage immutability), detective controls (log-file validation, SIEM alerts), and process controls (PIM, change control, access reviews) is required. Small businesses can reach compliance by using built-in cloud safeguards (S3 Object Lock, Azure Immutable Blob), restricting key usage to log-admins, and ensuring the SIEM itself is configured to treat log management actions as auditable events. Implement these measures incrementally: start by centralizing logs, restrict destructive permissions, enable immutability, and then add monitoring and automation to maintain compliance over time.
