How do audit and monitoring responsibilities differ between infrastructure teams and identity teams?

Infrastructure teams collect the activity, but identity teams need that activity to be attributable, reviewable, and certifiable. The difference is not ownership of logs but ownership of evidence quality, because access governance breaks down when administrative action cannot be linked to an accountable identity.

What infrastructure teams own, and what identity teams own

Infrastructure teams are usually responsible for collecting and retaining the raw activity: system events, platform logs, device telemetry, and administrative traces. Identity teams own the control story around that activity, including whether it can be tied to a specific actor, reviewed in a consistent workflow, and used as evidence for certification, access review, or exception handling.

The operational split matters because a log stream by itself does not prove accountable action. To support governance, the record must preserve who acted, what privilege was used, when it happened, and whether the event can be replayed or validated without ambiguity. That is why regulatory and audit perspectives on non-human identities are often discussed alongside access governance rather than infrastructure monitoring alone.

Why evidence quality is the identity-team problem

Infrastructure monitoring answers “what happened on the system,” but identity monitoring must answer “who had authority to make it happen.” That means identity teams care about attribution, privileged session correlation, recertification evidence, and whether the source data is complete enough to survive audit scrutiny. Missing actor context, shared administrative paths, and inconsistent naming conventions are governance defects, not just logging defects.

Identity teams also have to judge whether the evidence is reviewable at scale. If a control produces thousands of alerts but cannot distinguish routine automation from human misuse, the control looks busy while remaining weak. This is why lifecycle visibility and ownership metadata are part of the evidence model, not an afterthought; see the NHI Lifecycle Management Guide for the connection between lifecycle state, visibility, and access governance.

How the two teams should divide monitoring responsibilities

Infrastructure teams should focus on reliable collection, retention, time synchronisation, log integrity, and coverage across hosts, platforms, and administrative surfaces. Identity teams should define which events are evidence-bearing, which identities must be attributable, which reviews require certification, and what minimum context makes an event usable for governance. In practice, the boundary is not “who runs the tool,” but “who owns the evidence standard.”

That division becomes especially important when accounts, service credentials, or delegated administrative paths are involved. The identity owner needs enough signal to support least-privilege review and offboarding decisions, while the infrastructure owner needs enough instrumentation to preserve forensic fidelity. The Top 10 NHI Issues is useful here because many monitoring failures begin with stale ownership, excessive permissions, or reused credentials rather than with the logging platform itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Audit review turns raw logs into evidence for accountable access decisions.
	IA-5 — Authenticator Management	Credential lifecycle determines whether administrative action can be tied to the right identity.
	AC-2 — Account Management	Account ownership and lifecycle are central to who is responsible for access evidence.
Recommendation — Review audit events for attribution gaps and escalate records that cannot support certification. Track credential issuance, rotation, and revocation so activity remains attributable. Maintain current account ownership and deprovision stale accounts before relying on logs for governance.
ISO/IEC 27001:2022	A.5.15 — Access control	Access control requires clear responsibility for who may act and how that action is evidenced.
Recommendation — Define access ownership and review responsibilities so administrative activity remains certifiable.
CIS Controls v8	CIS-5 — Account Management	Account management directly supports attribution, review, and revocation of administrative access.
Recommendation — Inventory and review privileged accounts so monitoring data maps to accountable identities.

Practitioner Guidance

What to verify: Check that every administrative event can be mapped to an accountable identity, a privilege source, and a reviewable timestamp. If the evidence cannot distinguish shared access from named access, treat it as insufficient for certification even if the logs are complete.

What good looks like: Infrastructure telemetry is broad and durable, while identity evidence is attributable, queryable, and attached to a defined review process. The best split is one where platform teams can prove collection integrity and identity teams can prove decision quality.

Decision rule: If the question is about whether an action happened, infrastructure owns the trace. If the question is whether the action can support access governance, identity owns the evidence standard and the certification outcome.

Practitioner takeaway: Treat logs as raw material and attribution as the control objective, because audit failure usually comes from weak evidence quality, not from missing system activity.