Who should be accountable for DNS access reviews?

Accountability should sit with the business or operational owners who understand why a role exists, with IAM or security enforcing the process. Access reviews should verify that each role still matches a current job function, that temporary access has expired, and that service account permissions are still needed.

Why This Matters for Security Teams

DNS access is often treated as a technical permission problem, but review accountability is really a control ownership problem. The people best placed to decide whether a DNS role still makes sense are the business or operational owners who understand the service, the change cadence, and the blast radius of a mistake. IAM and security should enforce the review process, but they should not be the only ones deciding whether access remains justified.

This matters because DNS sits on the path to availability, routing, and trust. If a stale role or service account keeps broad DNS privileges, an attacker or a careless operator can redirect traffic, obscure outages, or support follow-on compromise. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why periodic reviews must focus on current necessity, not historical convenience. The governance lesson aligns with the OWASP Non-Human Identity Top 10: non-human access fails when nobody owns it end to end. In practice, many security teams encounter DNS overreach only after a change outage, a stale service account, or an incident review has already exposed the gap.

How It Works in Practice

Effective DNS access reviews separate three responsibilities. First, business or operational owners attest that the role still matches a real service, workflow, or platform need. Second, IAM or security validates that the entitlement is still within policy and that evidence is complete. Third, DNS platform owners confirm whether the access pattern matches what the control plane actually requires.

That review should be anchored to identity type, because DNS access is not always a human user story. Service accounts, API keys, certificates, and automation tokens may require different review intervals, different approvers, and different evidence. The NHI Lifecycle Management Guide is useful here because access reviews should be tied to creation, change, rotation, and offboarding events, not just a calendar reminder. Where possible, review outputs should include:

• the exact DNS zones, records, or APIs in scope
• the workload, team, or system that consumes the access
• the last known business justification
• expiry dates for temporary or emergency access
• rotation or revocation actions for dormant service accounts

Security teams should also use telemetry to challenge stale approvals. If a DNS role has not been exercised, or if a service has been decommissioned, the review should trigger removal rather than renewal. This is consistent with current guidance from the OWASP Non-Human Identity Top 10 and with NHI Mgmt Group’s research showing that only 5.7% of organisations have full visibility into their service accounts. These controls tend to break down when DNS access is embedded in shared automation, because no single owner can quickly prove which job actually depends on the entitlement.

Common Variations and Edge Cases

Tighter DNS review governance often increases coordination overhead, requiring organisations to balance cleaner accountability against slower approvals and more maintenance work. That tradeoff is real, especially for platform teams that manage many environments or for MSP-style operations where ownership changes frequently.

There is no universal standard for every DNS scenario, so current guidance suggests adjusting accountability by risk. A production DNS admin role should usually be reviewed by the service owner plus IAM enforcement, while a low-risk read-only role may only need lightweight attestation. Emergency access is a special case: it should be time-bound, separately approved, and automatically expired, because retrospective review is not enough once the change window closes.

Another common edge case is delegated administration across subsidiaries, tenants, or outsourced operations. In those environments, accountability should still map to the party that can explain why the access exists and who can revoke it. The practical rule is simple: the reviewer must be able to answer whether the access is still needed, while the enforcer must be able to prove it was removed when no longer justified. That split keeps governance from becoming a checkbox exercise and helps prevent “approved forever” DNS access from surviving long after the underlying service has changed.

Related resources from NHI Mgmt Group

• Who is accountable when DNS weaknesses disrupt access to identity services?
• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• How should security teams govern DNS migrations without losing control of delegated access?