Funding an identity data project is a hard and long process. The measurable effects of a new security control can take quarters or years to quantify, which puts the request in the same queue as every other request that pays back slowly.
Incident response is measured in hours, and missing identity data is almost always something that lengthens the timeline. A responder can't start an investigation without answers that sit across several systems that belong to several teams. Those answers are the reason to build an identity record, and IR is where the urgency and often the budget already sit.
What stalls an investigation
Three identity-specific components of any investigation:
- Identification is working out what an account is and who's accountable for it. Ownership often lives in a ticket, in a spreadsheet, or with someone who's left, so the first hour goes to a question with no record behind it.
- Scoping is working out what that account could get to. It decides whether the incident is contained or still spreading. And it's one of the hardest things to assemble by hand because access is rarely granted directly. Let's say a user sits in an Active Directory group that is mapped to a role in AWS, and that role carries a policy granting write access to an S3 bucket. The account record in AD shows the group membership and nothing else. So resolving that chain at 3am means opening several consoles.
- Timeline is working out what changed and when. Plenty of systems, including most of the older ones, will tell you the current membership of a group but will never tell you the membership changed eleven days ago. When nothing recorded the change, rebuilding the timeline takes far longer.
We looked at all three from the analyst's chair in Your SOC Cannot Close an Identity Alert Without the IAM Team. None of them is produced by a tool IR owns, which is why the identity system of record can be a shared purchase between these teams.
IR budget behaves differently
An IAM improvement often gets defended with a time saving number. For example, a newer tool may cut access review prep from three weeks to two days, and finance weighs that saving against the cost. Nothing breaks if finance says no to the purchase.
An IR improvement gets defended with a retro. After a tabletop or a real investigation, somebody writes down what took too long. That document is the most persuasive budget evidence in security, because it names specific problems and those problems can be priced. The purchase gets justified against real costs rather than projected savings.
So read the last three retros before writing anything. If they contain sentences close to "we couldn't establish who owned the account" or "we couldn't tell what it could reach," the justification already exists in IR's own words and the request becomes a way to close a finding IR raised.
For a funding conversation, the useful part is being able to point to specific issues and vulnerabilities that are already on the record, stated by the people who approve security spend. Those leaders already understand the urgency. In the 2026 SANS SOC Survey they named lack of enterprise-wide visibility as the biggest barrier to using their SOC's capabilities, ahead of staffing shortfalls and automation gaps. We took that apart in Why One Identity Question Takes Two Days to Answer.
What IR should be getting
Every account should resolve to a human owner behind it. Hydden matches accounts across systems that belong to the same person or service, so one alert becomes a list of everywhere the same person or process can authenticate. From there, an account's blast radius is available on demand instead of being assembled by hand.
That blast radius arrives with the chain that explains it. Access comes back resolved on named resources with the grant path written out: the group the account was added to, the role that group holds, the permission that role carries. The record also holds when each of those grants happened, so the timeline question gets answered from the same place. The analyst reads a conclusion instead of interpreting group names under time pressure.
This data lands in the console IR already works in. Identity events are emitted as OCSF and mapped into the receiving platform's schema, so they turn up in searches the team already wrote. A playbook can call Hydden's API during triage, including a deprovision call, so containment gets triggered where the analyst already is.
Splitting the bill
IAM is buying completeness, which is what makes reviews defensible, keeps the vault from missing accounts, and ensures audit readiness. IR is buying identification, scoping and timeline.
Take the last ten identity alerts your SOC closed without a confident answer or the notes from the last tabletop. For each one, write down which of identification, scoping and timeline was missing, and roughly how long that gap held the ticket open. That list states the case in IR's numbers and it doubles as the test plan when you need to prove that an identity system of record answers those questions.
Hydden holds the identity record and feeds it into the systems that act on it, so the same collection that makes an access review defensible is what answers the question an analyst has at 3am. If you want the version you can put in front of your IR team, schedule a one-on-one risk review and bring the last ten alerts nobody could close.
Frequently asked questions
Why would an incident response team fund an identity tool?
Because the answers that stall an investigation are identity answers, and IR is measured on how fast they arrive. Establishing what an account is, what it could reach, and what changed are the first three things a responder needs, and none of them is produced on demand by a system IR owns.
Where does this sit relative to the SOC platform we already run?
That platform keeps the detections, the cases, the workflow and the data lake. Hydden holds the identity record and sends identity events and findings into it in an open format, mapped to that platform's schema, so identity behaves like every other source.
Can it tell us what an account could reach on a specific date in the past?
Not as a lookup. The state view answers what access exists now. History is answered from the change events that were collected and retained, including changes in systems that never logged them, which is why the record has to be running before the date anyone asks about.
Which team should own the line item?
Both, with the split written down. IAM is buying completeness for reviews and vaulting. IR is buying identification, scoping and timeline.