Who is accountable when audit settings can be changed too broadly?

Why This Matters for Security Teams

Audit settings are not a cosmetic control. If broad administrative access allows logging to be reduced, redirected, or disabled, incident response loses its evidentiary base and compliance teams lose defensible records. The core issue is accountability: an organisation must be able to show who owns logging, who can change it, and how those changes are approved, reviewed, and detected. The NIST Cybersecurity Framework 2.0 treats logging and monitoring as a governance and detection requirement, not just a technical feature.

Teams often assume the platform is “secure enough” because logs exist somewhere. In practice, that is only true if the ability to alter audit scope is tightly limited, separately reviewed, and itself logged. When audit controls are broadly changeable, attackers and insiders can create blind spots before anyone notices. The problem usually surfaces after an incident, when teams discover that the records they needed were never preserved.

How It Works in Practice

Accountability for audit settings should be assigned at three levels: control ownership, operational administration, and independent review. Control ownership defines who is responsible for the policy that says what must be logged. Operational administration defines who can change the technical configuration. Independent review defines who checks whether those changes are appropriate and complete. If those roles are merged too broadly, the control becomes easy to bypass and difficult to evidence.

In a mature environment, audit settings should be protected by least privilege, change approval, and separation of duties. The technical implementation often includes restricted administrative roles, just-in-time elevation, and logging of every audit configuration change. Baseline expectations should also be documented so reviewers can confirm whether key events, privilege changes, and authentication activity remain captured. NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates audit generation, protection, review, and accountability into distinct control outcomes.

• Restrict who can change audit policy, retention, forwarding, and exclusion rules.
• Require approvals for audit changes that affect critical systems or privileged users.
• Log every change to audit settings in a separate, protected record.
• Review whether audit coverage still includes authentication, privilege use, and configuration changes.
• Assign a named control owner for monitoring and evidence retention, not just for system administration.

Where identity governance is involved, the question becomes whether privileged identities are too powerful over the logging stack itself. If an administrator can both change the environment and erase the trace of that change, the control design is broken. These controls tend to break down in decentralised cloud estates where platform teams, application teams, and security teams all believe another group owns the audit configuration.

Common Variations and Edge Cases

Tighter audit control often increases operational overhead, requiring organisations to balance investigative reliability against admin convenience. That tradeoff is real, especially in fast-moving cloud and DevOps environments where teams want speed and autonomy. Best practice is evolving toward stronger guardrails, but there is no universal standard for exactly how many people should have audit-change authority.

Some environments need temporary exceptions, such as during migrations, vendor support, or incident containment. Those exceptions can be justified, but they should be time-bound and independently monitored. The presence of a break-glass account does not remove accountability; it raises the need for stronger evidence, faster review, and explicit post-use reconciliation. In higher-assurance environments, organisations may also pair audit controls with zero trust principles so that administrative access is continuously verified rather than assumed.

For regulated sectors, audit ownership should be mapped to formal control evidence and internal attestations. If the business cannot demonstrate who approved logging changes, who reviewed them, and whether the resulting logs remained intact, the issue is not a tooling gap but a governance failure. That is why accountability must sit with the organisation, not with the vendor or the platform alone. In practice, many security teams discover audit-control weakness only after an investigation reveals missing records, rather than through routine change governance.

Related resources from NHI Mgmt Group

• Who is accountable when outbound traffic controls are too weak to contain an intrusion?
• Who is accountable when a signature is challenged in court or audit?
• Who is accountable when a cloud IAM deployment fails audit or access governance?
• Who is accountable when continuity arrangements fail an audit?