IAM should govern issuance, roles, and entitlement decisions, while ITDR should watch how those identities behave after access is granted. If those responsibilities are mixed together, teams end up overrelying on provisioning controls for problems that only appear at runtime. Clear separation improves both governance and response.
Where IAM Governance Stops and ITDR Begins
IAM governance and ITDR answer different questions, and the separation matters. IAM decides who should receive access, which roles are valid, and when entitlements should be granted, reviewed, or removed. ITDR starts once access exists and asks whether the resulting identity activity looks normal, risky, or compromised. That boundary keeps policy decisions from being confused with runtime defence.
When teams blur the two, they tend to treat provisioning as if it were detection. That creates blind spots because a clean approval trail does not tell you whether an account is being abused after login, whether a token has been replayed, or whether a service principal is moving laterally. The operational rule is simple: govern access at issuance, then monitor behaviour after issuance.
That split is easier to sustain when the organisation also treats identity lifecycle as a distinct control plane. NHI lifecycle management covers provisioning, rotation, and offboarding, while ITDR consumes the signals that show whether those identities are acting inside or outside expected patterns.
What Each Function Should Own in Practice
IAM governance should own the questions that are inherently structural: is the identity legitimate, does it need this role, does it still need this entitlement, and who approved the change. That work is about authorization design, entitlement hygiene, and lifecycle control. ITDR should not try to decide those things in the first place, because its value comes from detecting misuse, abnormal access paths, and compromise indicators after the control plane has already allowed access.
A practical way to divide ownership is to separate preventive decisions from investigative decisions. IAM manages joiner, mover, leaver outcomes, access reviews, role engineering, and entitlement policy. ITDR manages behavioural baselines, risky sign-in patterns, privilege abuse signals, impossible travel, unusual tool usage, token abuse, and post-authentication escalation indicators. The same identity may be in both systems, but the question each system answers is different.
This is also why programme design matters. A broad identity operating model, such as the Identity Security Programme Guide, helps teams keep governance, operations, and response in separate lanes instead of collapsing them into one generic “identity team” backlog. For runtime response, the ITDR guide is the better anchor because it focuses on identity attack techniques, detections, and response playbooks.
How to Design the Hand-off Between Governance and Response
The hand-off should be explicit at the control boundary. IAM should emit authoritative records of approved access, role membership, and entitlement changes. ITDR should ingest those records as context, then compare them with observed behaviour in sign-ins, directory activity, SaaS actions, cloud privilege changes, and session use. That makes IAM the source of truth for expected access and ITDR the source of truth for suspicious execution.
Teams often get this wrong by routing every anomaly back into the approval workflow. That slows response and dilutes accountability. If the issue is an unapproved entitlement, IAM handles it. If the entitlement was approved but is now being abused, ITDR handles detection and incident response. If you need both, sequence them: contain the behaviour first, then correct the governance state.
For platforms such as Active Directory and Entra ID hardening guidance, the same principle applies to privileged groups and delegation. Governance determines who may hold privileged access; ITDR watches whether those privileged paths are used in ways that suggest compromise or abuse.
Risk and Threat Considerations
When governance and detection are mixed together, organisations can miss active abuse because they assume an approved identity is therefore a safe identity. That assumption fails fast when valid accounts, tokens, or privileged sessions are hijacked, repurposed, or used for lateral movement. The result is slower containment and a wider blast radius than necessary.
Failure mechanism: A preventive approval process is treated as if it were a runtime control, so suspicious behaviour is evaluated only through access records instead of behavioural evidence.
Impact: Attackers can persist inside legitimate identities, evade policy-only oversight, and exploit the gap between “authorised” and “safe” to reach sensitive systems before the issue is detected.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | IAM governance must right-size access before ITDR monitors misuse. |
| AU-6 — Audit Record Review, Analysis, and Reporting | ITDR depends on reviewing identity activity after access is granted. | |
| IA-5 — Authenticator Management | Separates credential lifecycle governance from post-authentication detection. | |
| Recommendation — Enforce least privilege so approved access stays narrowly scoped and reviewable. Correlate identity events and investigate anomalous activity promptly. Manage authenticators centrally and rotate or revoke them on risk. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | Maps to IAM's role and entitlement governance responsibilities. |
| DE.CM-01 — Networks and systems are monitored to detect anomalous events | Supports ITDR's runtime monitoring of authenticated identity behaviour. | |
| Recommendation — Define, approve, and periodically review access permissions. Monitor identity activity continuously and flag anomalous behaviour. | ||
| CIS Controls v8 | CIS-5 — Account Management | Separates account lifecycle governance from detection of misuse. |
| Recommendation — Maintain account inventories and remove stale or excessive access promptly. | ||
Practitioner Guidance
What to verify: Make sure every identity event has a clear owner and downstream consumer. IAM changes should feed ITDR with current roles, entitlements, and high-risk account flags so runtime alerts can be judged against approved state, not guesswork.
Common mistake: Do not let the response team rewrite access policy every time an alert fires. That creates confusion between remediation of behaviour and remediation of entitlement, and it usually means neither problem gets handled cleanly.
What good looks like: IAM can answer “who should have access” without discussing alerts, while ITDR can answer “what is this identity doing right now” without reopening the approval process. The two teams share context, not ownership.
Practitioner takeaway: Separate the decision to grant access from the decision to trust ongoing activity, because governance can make access legitimate, but only ITDR can show whether that access is being abused.