Most of an identity investigation never shows up in the metrics, because it looks like this: an analyst posts in a channel asking if anyone knows what sa-integration-02 is for and who owns it. Forty minutes later someone from the IAM team answers with what the primary directory shows. That answer covers one directory, and this account exists in two. The follow-up goes to the application owner, who has to check manually because there is no inventory. That comes back the next morning. It says the account was reviewed last quarter and looked fine.
It's a reasonable question, and none of those people did anything wrong. But it still took a day and a half, and the answer that came back was about last quarter.
Assumed identity coverage
The pattern is measurable. The 2026 SANS SOC Survey asked security leaders to name the single biggest barrier to fully using their SOC's capabilities. 24% of those leaders chose lack of enterprise-wide visibility, ranking it above staffing shortfalls and above automation gaps. Practitioners described the same condition in working terms: too many uncorrelated alerts, too many tools that are not integrated, not enough context.
The SANS instructor quoted in that report explains that gap nicely...he observed that a survey covering 444 SOC practitioners in depth mentions identity only once, in passing, and that most teams he works with "have engineered their endpoint coverage, but they have assumed their identity coverage." The visibility gap execs keep naming is this identity gap. Assumed coverage is what produces the forty minute channel exchange. Nobody decided that ownership of sa-integration-02 would be unavailable at 2am. It was never anybody's deliverable, so it was never built, and the cost of that only appears when somebody needs the answer against a deadline.
The clock is set by a regulator
In regulated sectors the deadline is now written into law and measured in hours rather than days.
Under DORA, a financial entity has to file its initial notification of a major ICT-related incident within four hours of classifying it as major, and no later than 24 hours after becoming aware of it, with an intermediate report due 72 hours after that. NIS2 Article 23 sets a similar shape for essential and important entities, with an early warning inside 24 hours of awareness and a fuller notification inside 72.
Those filings describe what was affected and how severely. Getting that right means knowing which accounts were involved, who was accountable for them, and what they could reach. When establishing those three things takes a day and a half of mass messages, the four-hour filing goes out based on whatever could be confirmed quickly, and the version that the public needs to trust is the one that arrives at 72 hours.
More logging did not fix this
Most teams responded to slow investigations by collecting more. That was the right instinct for a specific class of questions. Your log platform is excellent at what was done. Which host, which process, which destination, in what order.
The questions holding up an identity investigation are about what was allowed. Who was accountable for this account, what could it reach, and what changed. Those are facts about how access is configured rather than about activity. And many of those changes do not appear in a log at all, because the systems where access lives frequently do not emit anything when it changes.
That is why the second terabyte of log data did not shorten identity investigations. The missing information was never a log. We wrote about that gap in more detail in detection without the record behind it.
The three questions that cause the delay
- Who is accountable for this account. CIS Control 5.5 has required an inventory of service accounts carrying the owning department, the purpose and a review date for years. Most identity teams still don't have this information. And the SOC analyst at 2 am definitely does not have this information. We wrote about why ownership decays in Why Nobody Owns Your Most Privileged Accounts.
- What could it reach when the alert fired. Group memberships resolve into roles, roles carry permissions on specific resources, and the chain crosses systems. Doing that by hand during an incident takes hours and produces an answer nobody fully trusts.
- What changed recently. The most useful question and usually the one with no answer available, because answering it requires comparing today's access to an earlier version that nobody kept.
All three are questions about access rather than activity, which is why a logging project does not shorten the time it takes to get answers.
The auditor asks the same three questions
An access review asks who owns an account, what it can reach, and whether that is still appropriate. PCI DSS 4.0, mandatory since March 2025, requires every account to be reviewed at least once every six months, and says explicitly that this includes application and system accounts.
The work needs to move from assembling an answer to querying for one. If ownership is already resolved, the forty minute channel exchange never happens. If entitlements are already resolved down to specific resources, what an account can reach is a lookup instead of an afternoon. If every change was kept as it happened, what changed recently is a question with an answer.
Where the answer has to live
If your identity investigations take days, the reason is almost never analyst skill. It is that the answer is being built by hand while the clock runs, out of information that already exists inside systems you own, in pieces, with nothing holding them together.
So the system of record has to be built continuously, as the changes happen, rather than assembled when somebody asks. An answer produced on demand is only ever as good as the hour whoever produced it had available.
And it has to arrive where the work already happens. An analyst on shift is not going to open another console at 2am, and an auditor in fieldwork is not going to learn a new query language. The record becomes valuable to every security team by showing up inside the platforms a team already runs, in those platforms' own fields, so people can ask the question in the language they already use.
Follow Hydden as we begin to announce the security operations platforms that are using Hydden's system of record data.
To see how much of your response time is assembly work, schedule a private risk analysis with our team.
Frequently asked questions
Why do identity investigations take longer than endpoint or network investigations?
Because the necessary context is not in the security tooling. Endpoint and network questions are usually about activity, which is logged. Identity questions are usually about what was allowed, which lives across directories, applications and vaults, and often is not logged anywhere when it changes.
Will collecting more logs speed up identity investigations?
Not by much. Logs answer what was done. Identity investigations stall on who owns the account, what it could reach, and what changed, which are facts about the state of access. Many of the systems holding that state never emit an event when it changes, so there is nothing to collect.
What slows an identity investigation down the most?
Ownership. Determining who is accountable for an account, particularly a service account, routinely takes hours and involves several teams. Until someone can confirm what an account is for, nobody is willing to disable it, so the investigation waits.
Does this affect audit and compliance work, or only incident response?
Both, because they run on the same three questions and the same systems. An access review asks who owns an account and what it can reach, which is what an analyst asks at 2am. A team that assembles that answer by hand pays the cost once per incident and again every review cycle, and PCI DSS 4.0 sets that cycle at no less than twice a year.
How do incident reporting deadlines like DORA change this?
They remove the option of taking a day and a half. DORA requires an initial notification within four hours of classifying an incident as major and no later than 24 hours from becoming aware of it, with an intermediate report 72 hours later. NIS2 Article 23 sets a 24 hour early warning and a 72 hour notification. Describing what was affected means knowing which accounts were involved, who owned them and what they could reach, so the reporting deadline becomes a deadline on the identity record.
Can you tell me what access looked like at a specific time in the past?
Every change is kept as it happens rather than captured in periodic snapshots, which is what makes historical questions answerable in principle. Turning that history into a point in time query is designed and in progress rather than shipping today. Ownership, current entitlement resolution and peer comparison are available now.
How does this reduce mean time to respond?
By converting the assembly phase into a lookup. When ownership, entitlements and recent changes are already collected and resolved, the analyst reads the answer instead of gathering it from three teams, and the escalate or dismiss decision moves into the first minutes of the alert.