The instinct, once a leak is suspected, is to launch a full instrumentation project. That's almost always the wrong first move. It's slow, it requires broad system access before anyone has proven the hypothesis is worth that access, and it puts a security review in the critical path before there's anything concrete for that review to look at. Gartner predicted in 2025 that organizations will abandon 60% of AI projects through 2026 due to data that wasn't ready for what the project asked of it, the exact failure mode a broad, upfront access request tends to walk straight into. A tighter sequence stages the request for access so each step only asks for as much as the previous step's finding justifies.

Days 1-7: sandbox

Test a framework like the self-assessment above against your own numbers, using synthetic or estimated data. Zero system access required. The goal isn't a real answer yet, it's identifying which department and which metric is worth testing against real numbers next.

Days 7-21: manual sample

Export an aggregated dataset yourself, ticket volumes, call-brief open rates, override counts, whatever's relevant to the hypothesis from the sandbox step, and run it through the same framework. No live connection, no IT ticket. This step alone usually produces a real, defensible dollar figure, the same kind of math behind estimating your own cost of inaction.

Days 21-60: scoped live connection (optional)

If the manual sample justifies it, set up a narrow, read-only, time-boxed connector to one system in one department. Never broader than the hypothesis requires.

Days 60-90: decide and expand

With a validated, dollar-quantified finding and a named budget owner, decide whether to widen scope. If yes, the same connector pattern extends to more departments, a scope change on an already-reviewed grant, not a new security review from scratch.

Where to go from here

The organizations that get through this sequence fastest aren't the ones with the most sophisticated data infrastructure. They're the ones that resist the urge to ask for full access on day one.

Frequently asked questions

Why not just launch a full data instrumentation project right away?

It's slow, it requires broad system access before anyone has proven the underlying hypothesis is worth that access, and it puts a security review in the critical path before there's anything concrete for that review to look at.

What happens in the first week of this path?

A sandbox test against synthetic or estimated data, with zero system access required. The goal isn't a real answer yet, it's identifying which department and which metric is worth testing against real numbers next.

When does this path actually request live system access?

Not until days 21 to 60, and only a narrow, read-only, time-boxed connector to one system in one department, and only if the manual data sample from days 7 to 21 already justified it.

← Back to Blog