How to Build an ITDR Program: 90-Day Checklist

Photo: Unsplash

An ITDR program checklist turns Identity Threat Detection and Response from a slide into an operating system: owners, telemetry, detections, playbooks, and evidence on a fixed timeline.

Many teams buy identity alerts and still cannot revoke sessions quickly, prove coverage to auditors, or explain who owns account-takeover response at 2 a.m. A 90-day rollout forces those decisions early—before the first real identity incident sets the agenda for you.

This guide gives security, identity, and GRC leaders a practical checklist with owners, evidence packs, and workflows you can run in three 30-day phases.

This guide covers:

• Program outcomes and scope boundaries for ITDR
• RACI owners across SOC, IAM, PAM, and GRC
• A 90-day checklist with milestones and exit criteria
• Evidence packs and playbooks auditors can inspect
• Metrics that show the program is working—not just installed

GIF via GIPHY

Related guides:

• What is ITDR? Identity Threat Detection and Response
• ITDR vs XDR vs EDR: what's the difference?
• User access review
• Identity risk

---

Key takeaways

• Start with outcomes—session revoke time, covered identity sources, and rehearsed playbooks beat feature checklists.
• Name owners in week one—SOC, IAM, PAM, and GRC need explicit RACI before detections go live.
• Run a 90-day phased rollout—foundation, detection+response, then harden and prove.
• Collect evidence continuously—tabletops, alert samples, and access-review links become audit fuel.
• Govern with metrics—coverage, MTTD/MTTR, false positives, and residual identity risk.

---

Define ITDR program outcomes before tools

Before selecting or expanding tooling, write outcomes leadership can measure.

Recommended outcome statements

• Critical identity sources (IdP, MFA, privileged access, top SaaS admin logs) are monitored with documented retention
• Suspected admin account takeover can be contained (session revoke / disable) within an agreed SLA
• Identity incidents produce a reusable evidence pack for post-incident review and audits
• High-risk entitlements are reviewed on a defined cadence and linked to detection context

Scope that typically belongs in v1

• Human workforce identities in the primary IdP
• Privileged / break-glass accounts
• Top 10 business-critical apps by data sensitivity and blast radius
• Non-human identities for a small pilot set (CI deployers, cloud automation)

Scope you can defer to days 91+

• Every long-tail SaaS tenant
• Deep UEBA modeling across all apps
• Perfect false-positive rates on travel-heavy roles

For capability definitions and how ITDR fits IAM/IGA/PAM, read What is ITDR?. For stack boundaries with endpoint tools, see ITDR vs XDR vs EDR.

Outcome	Example target by day 90	Evidence
Telemetry coverage	≥90% of critical identity sources onboarded	Source inventory + log proof
Containment speed	Median session revoke ≤60 minutes for P1 identity alerts	Ticket timestamps
Playbook readiness	2 tabletops completed with action items closed	Tabletop reports
Access hygiene link	Privileged roles reviewed within last quarter	Access review export

---

Owners and RACI for ITDR

Programs stall when “security” owns everything and identity engineering owns nothing operationally.

Activity	Responsible	Accountable	Consulted	Informed
Identity source inventory	Identity engineering	CISO / Head of Security	App owners, IT	GRC
Log shipping & retention	Identity eng + SIEM owners	Head of Security Ops	Legal/privacy	SOC
Detection content	Detection engineering / SOC	SOC manager	IAM, PAM	GRC
Incident containment actions	SOC / IR	Incident commander	IAM on-call, app owners	Leadership
Privileged access controls	PAM / IAM	Identity lead	SOC	Audit
Evidence & control mapping	GRC	Compliance lead	SOC, IAM	External auditors
Executive reporting	SOC + GRC	CISO	Identity lead	Board / risk committee

On-call expectations to write down

• Who can disable accounts after hours?
• Who approves break-glass use during an identity incident?
• What is the escalation path if IAM on-call does not respond within 15 minutes?

If those answers are unclear, pause new detections and fix ownership first.

---

90-day ITDR program checklist

Days 1–30: Foundation (inventory, access, telemetry)

Checklist

• Appoint ITDR program lead and publish RACI
• Inventory identity systems: IdP, directories, MFA, PAM, HRIS feeds, critical SaaS admin logs
• Rank apps/accounts by blast radius (admins, finance, production cloud, customer data)
• Confirm log delivery for authentication, MFA, privileged elevation, and admin audit events
• Document retention periods and who can access raw identity logs
• Baseline MFA posture and privileged standing access (counts + owners)
• Align with latest user access review cycle for high-risk roles
• Draft P1/P2 severity definitions for identity alerts

Exit criteria for day 30

• Signed RACI
• Source inventory with coverage status (green/yellow/red)
• At least one end-to-end log path proven (event → SIEM/ITDR console → analyst view)

Days 31–60: Detect and respond (use cases + playbooks)

Checklist

• Enable 5–10 high-fidelity detections (start with ATO, MFA anomalies, privilege abuse, break-glass)
• Build investigation checklist: identity graph, recent entitlement changes, device/session history
• Publish response playbooks: revoke sessions, force re-auth, disable account, rotate secrets, remove OAuth grants
• Wire ticketing with required fields (identity ID, apps impacted, containment actions, evidence links)
• Run tabletop #1: stolen admin session, no malware
• Capture false-positive themes and tune before scaling alert volume
• Confirm after-hours IAM actions with a live drill (not only a document)

Exit criteria for day 60

• Playbooks approved by SOC + IAM
• Tabletop #1 report with owners and due dates
• Demonstrated containment on a non-production or approved test account

Days 61–90: Harden and prove (coverage, metrics, audit evidence)

Checklist

• Expand detections to service accounts / workload identities in the pilot set
• Add cloud control-plane and top SaaS admin anomalies where gaps remain
• Run tabletop #2: MFA fatigue against a privileged user (see also MFA bypass lessons)
• Close tabletop remediation items from days 31–60
• Publish metrics dashboard: coverage, alert volume, MTTD, MTTR, false-positive rate
• Assemble audit evidence pack (see next section)
• Present day-90 readout to security leadership with residual risks and next-quarter backlog
• Schedule quarterly identity detection review

Exit criteria for day 90

• Documented coverage ≥ agreed critical sources
• Two tabletops completed
• Evidence pack stored in GRC / compliance repository
• Backlog prioritized for days 91–180

Phase	Focus	Primary owners	Must-have artifact
Days 1–30	Foundation	Identity eng, SOC, GRC	Inventory + RACI
Days 31–60	Detect & respond	SOC, IAM, PAM	Playbooks + tabletop #1
Days 61–90	Harden & prove	SOC, GRC, Identity lead	Metrics + evidence pack

---

Evidence packs to collect as you go

Do not wait until audit season. Attach evidence to each phase exit gate.

Core evidence bundle

Evidence item	Why it matters	Typical owner	Refresh cadence
Identity source inventory	Proves monitoring scope	Identity engineering	Monthly
Detection catalog	Shows what abuse you claim to catch	Detection engineering	Monthly
Alert → contain sample cases	Demonstrates real response	SOC	Quarterly (or after P1s)
Playbooks + revision history	Shows controlled process	SOC + IAM	After each tabletop
Tabletop reports	Proves rehearsal	IR / GRC	Semi-annual minimum
Privileged access review exports	Links hygiene to detection	IGA / IAM	Per review cycle
Retention & access policy for logs	Privacy + audit readiness	Security + Legal	Annual
Metrics snapshot	Leadership and board narrative	SOC manager	Monthly

Folder structure teams commonly use

• /itdr/inventory
• /itdr/detections
• /itdr/playbooks
• /itdr/tabletops
• /itdr/incidents
• /itdr/access-reviews
• /itdr/metrics

Store the same artifacts in SecureSlate (or your GRC system) with control mappings so customer questionnaires reuse the work.

---

Detection and response workflows that stick

Triage workflow (analyst)

1. Validate identity signal (not a mis-tagged service account or known travel exception)
2. Establish blast radius (roles, apps, data stores, admin rights)
3. Check concurrent endpoint/email alerts for multi-domain campaigns
4. Decide severity using the P1/P2 definitions from days 1–30
5. Execute containment from the approved playbook
6. Preserve evidence links before volatile sessions expire
7. Trigger access recertification or secret rotation follow-ups

Containment workflow (identity actions)

Condition	First action	Follow-up within 24h
Suspected workforce ATO	Revoke sessions + step-up auth	Credential reset, device review
Privileged account abuse	Disable elevation + freeze standing admin	PAM review, session audit
Risky OAuth grant	Revoke grant	App allowlist update
Service account anomaly	Disable key / rotate secret	Owner attestation, scope reduction
Break-glass used	Open incident automatically	Post-use review with ticket proof

Handoffs that prevent stalled cases

• SOC → IAM: account state changes and federation issues
• SOC → App owner: SaaS-side session kills and audit log pulls
• SOC → GRC: customer notification assessment when contractual triggers may apply
• IAM → IGA: entitlement cleanup after confirmed abuse

Write these handoffs into the ticket template so they are not tribal knowledge.

---

Metrics, governance, and what “done” looks like

Metrics worth reviewing monthly

• Coverage: % of critical identity sources with healthy log flow
• MTTD / MTTR: identity-specific, not blended with malware cases
• Containment SLA attainment: % of P1s meeting revoke/disable targets
• False-positive rate: by detection rule
• Privileged review currency: % of high-risk roles reviewed on time
• Tabletop closure rate: action items closed by due date

Governance cadence

Forum	Cadence	Agenda
ITDR working group	Biweekly	Coverage gaps, tuning, blockers
Security operations review	Monthly	Metrics and incident themes
Risk / compliance sync	Quarterly	Evidence pack + control mapping updates
Executive readout	Quarterly	Residual identity risk and investment asks

Day-90 “done” definition (v1)

You are not “finished” with ITDR at day 90—but v1 is typically done when:

• Critical sources are monitored
• High-fidelity detections are in production with owners
• Containment actions are rehearsed and timed
• Evidence packs exist without heroic archaeology
• A next-quarter backlog is approved

Everything else—broader SaaS coverage, deeper non-human identity analytics, tighter correlation with XDR—belongs on the backlog with dates, not as excuses to delay v1.

---

Streamline ITDR program evidence with SecureSlate

A 90-day ITDR rollout creates artifacts fast. SecureSlate helps you keep those artifacts tied to controls, owners, and audits instead of scattered drives.

• Assign owners and due dates for inventory, playbook, and tabletop tasks
• Map identity controls to the frameworks and customer questionnaires you answer most
• Store evidence packs for access reviews, MFA posture, and incident follow-ups
• Track remediation when tabletops or detections expose governance gaps
• Stay audit-ready with reusable proof that identity detection and response are operational

Get started for free: Create your SecureSlate account

---

FAQ

How many people do we need to run a 90-day ITDR rollout?

Many mid-size teams succeed with a named program lead plus part-time support from SOC detection, IAM engineering, and GRC. The critical factor is clear RACI and on-call authority—not a large dedicated team on day one.

What if we already have XDR?

Keep XDR for correlation, but still complete this checklist for identity-native coverage, containment actions, and evidence. XDR alone commonly under-models OAuth, PAM, and non-human identity abuse.

Should GRC own ITDR?

GRC typically owns evidence and control mapping. SOC and identity engineering typically own detection and containment. Shared outcomes work; single-threaded ownership of all technical response usually does not.

What is the minimum viable detection set?

Start with account takeover indicators, MFA anomalies, privileged elevation anomalies, break-glass usage, and risky admin audit events for your top apps. Expand only after triage quality is acceptable.

How do we keep the program from decaying after day 90?

Keep the biweekly working group, refresh the inventory monthly, retune detections from false-positive reviews, and require a tabletop at least semi-annually. Tie metrics to leadership reviews so coverage regressions are visible.

---

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.