Four gaps IRM was never built to close

A buyer’s checklist for the IRM gaps a ServiceNow program leaves open.

Many teams deploy IRM, watch the assessments come back clean quarter after quarter, and reasonably conclude they are covered. Months later, the greatest risk turns out to have been outside the sample. It may have changed the week after the review, or lived in a control type nobody tested, or lacked context or prioritization to see its importance.

Yes, the report was honest, but it was only a snapshot of an environment that had already changed. Unfortunately, that gap is a structural limit of integrated risk management, not a performance problem. You cannot work around it by working your team harder, adding people, or running the assessment more often, because each of those still produces a sample.

IRM tells you where your controls live, but it was never designed to tell you whether they are working. It is very good at what it was built for: workflow, records, and a shared system of reference, but producing continuous evidence was never part of the job.

GRC AI has had a lot of air time, but most of it accelerates the existing point-in-time method rather than replacing it. A faster sampled assessment is still a sampled assessment, leaving the four gaps below unsolved. 

Treat each gap below as a test. Run it against your own program and see how cleanly you can answer.

1 – Coverage: can you prove it, or only a sample?

It’s a simple question, but not many teams can answer it without caveats: what share of your estate was actually tested last cycle? Not how many controls you assessed, but what percentage of the applications and controls that exist across the business. Then ask how much of that environment likely changed while the cycle was still running.

A sampled assessment can only ever make claims about the sample, so the untested remainder stays invisible. In my experience, the untested remainder is exactly where the trouble starts. 

IBM’s 2026 X-Force Threat Intelligence Index found that exploitation of public-facing applications was the single most common way attackers got in last year, up 44% year over year. The applications most likely to fall outside a representative slice are often the ones under the most pressure. 

Boards have started asking for coverage as a single number, a percentage of the estate under continuous watch, and that is precisely the number a sampling-based program cannot provide. Closing this gap means testing against live evidence continuously, so that coverage is a fact about your estate rather than an estimate from a slice of it.

2 – Speed: how fast can you get to continuous coverage?

Ask yourself how long it would take to achieve continuous coverage across your estate, and how much of that estate your program actually reached by the time it went live. If you’re measuring in years, the environment has already moved underneath the program before it delivers its first full picture.

The systems-integrator model that stands up monitoring inside IRM typically prices services at 2 to 3 times the platform itself and runs on a multi-year timeline, because it depends on people translating controls into tests one at a time. That cost recurs every time your systems change, which is constantly. The program spends its life catching up to an environment that keeps reorganizing, and it never quite arrives. 

You need coverage that stands up in a matter of weeks, rather than years, and expands from there, feeding the ServiceNow environment your teams already run rather than making them wait through another multi-year build.

3 – Control types: which can you actually test?

This is a gap that most programs underestimate. The controls that automate easily are only a fraction of the ones you actually have to test. Take a single real control failure and count the systems you would have to check to prove it: the cloud configuration state, the CMDB record, the relevant policy document, the last assessment, and the business context around all of it. If your automation can read only one of those sources, it can only partly assure the control, however polished the dashboard sitting on top of it looks.

The easy part is that technical controls emit machine-readable state by default. However, much of an enterprise control set is documentation and process controls, and most of that evidence lives in unstructured places, like policy PDFs, data-processing agreements, and change tickets. Add the on-premises systems and bespoke applications that sit outside every vendor’s connector menu, and a large share of the estate is simply unreachable by tools built for structured cloud data alone.

So most enterprises end up genuinely testing only a fraction of their controls, and attesting to the rest. One program we work with was producing five hundred manual attestations a year; the same team now runs two to three hundred assessments backed by ten to fifteen thousand tests a week.

To close this gap, control testing has to reach documentation and process controls, not just the machine-readable ones. That takes a data layer, the Hybrid Data Fabric, that reads unstructured evidence as readily as structured, so nothing has to be translated by hand first.

4 – Business impact: can you tie a finding to what it would cost the business?

When a finding comes back, can you say what it puts at risk in business terms without launching a manual investigation? Pick a real finding from your last cycle and try to name the customer contract, the data-protection obligation, or the revenue it threatens, and then try to reconstruct the exact state of the environment at the moment it was raised. Most programs cannot do either one easily.

A finding with no business context attached is a ticket, not a decision. Ranking a backlog by severity score alone just organizes the guesswork of what matters to the business.

The deeper problem is durability. When the context that produced a finding is not preserved as evidence, you cannot replay it, audit it, or learn from it later. It happened, it was noted, and then the ground it stood on disappeared. 

Closing this gap means connecting every finding to the policies, risks, and commitments it affects, so that the backlog orders itself by business impact and each finding carries an evidence trail an auditor can actually follow. This is what cyber risk assurance looks like in practice.

Closing all four without leaving ServiceNow

None of these gaps is a reason to replace ServiceNow. Candidly, we didn’t build a workflow engine and we’re not trying to — ServiceNow is purpose-built for that, you already own it, and your teams already run their day inside it. It stays your system of record. The problem was never the workflow layer, it was the evidence feeding it, and that is what changes.

TrustCloud adds a continuous assurance layer inside ServiceNow, running continuous control monitoring that syncs validated, evidence-backed control signals into IRM, SecOps, and CMDB, so that findings arrive as incidents and tasks in the workflows your teams already own rather than in a separate tool nobody opens. 

The loop underneath is straightforward: 

Observe. The Hybrid Data Fabric consolidates structured and unstructured signals across cloud and on-premises sources.

Reason. The Control Graph maps those signals to the controls, policies, and obligations they affect.

Act. Assurance AI’s deterministic agents test the evidence and cite it, rather than inventing it.

In practice, one Fortune 100 technology program increased monitoring of its crown-jewel applications from 20% of the landscape under manual questionnaires to 96% under continuous monitoring.

Closing these four IRM gaps does not mean running a bigger audit or hiring a larger team. It means giving IRM something it was never built to produce on its own, a continuous stream of validated evidence, so that a clean report finally means what the board assumes it means: that you are actually covered.