Solution Overview
READI + One Identity
Complete Connectivity, Automation, and Governance.
In a recent post, we argued that “connected” should mean you can act on access, not just see it, and that many integrations quietly stop at reading. This post picks up where that one ended. Once an organization accepts that some of its applications are not truly governed, only observed, the next question is what it costs to leave them that way. The answer is usually more than it looks, because the cost of “good enough” governance is designed to stay hidden until something forces it into the open.
Every identity program has a set of applications it governs by hand. Access is tracked in a spreadsheet. New requests move through a ticket queue. Periodic reviews are run by exporting a list of accounts, emailing it to a manager, and importing the marked-up version back. When an application cannot be connected properly, this is the fallback, and for a while it works. The reviews get completed. The spreadsheet gets updated. The audit gets its evidence.
That is exactly why the problem persists. Manual governance produces artifacts, and artifacts are reassuring. A completed access review looks the same on paper whether the underlying access was actually controlled or merely documented. The paperwork of governance is present. The control is not.
The core issue is a confusion between evidence of activity and governance of access. A ticket showing that an account was removed, a captured record confirming an action was taken, a signed-off spreadsheet: these show that something happened. They are not proof that access is in the state it should be right now.
Consider what a spreadsheet or an exported file actually is. It is a snapshot, accurate at the moment it was captured and decaying from that point forward. Between reviews, people join, change roles, and leave, and the file knows none of it. By the time the next review runs, the document describes a version of reality that no longer exists. Evidence that a review was performed is easy to produce. Continuous governance of the underlying access is a different thing entirely, and it is the thing manual processes cannot deliver.
The real cost of “good enough” governance rarely appears in a budget. It shows up somewhere else.
The first is that it is not repeatable. Manual processes live in the heads of the people who run them. They depend on someone remembering which applications need a quarterly review, who the right approver is, and what the offboarding steps are for a particular system. When that person changes teams or leaves, the process degrades quietly. Nothing announces that a control has stopped working. It simply stops.
The second is that it is not auditable at scale. A handful of spreadsheets can be reconstructed for an auditor. Hundreds cannot, at least not with confidence that they are complete, current, and consistent. Manual governance can usually answer whether a review was run, but it struggles with the harder questions: can you prove who had access to this system on a specific date, and that every change since then was authorized and applied. The larger the environment, the wider the gap between the evidence on hand and the assurance an auditor actually wants. Manual governance is a little bit like balancing your household budget on stick notes. It works while there are only a few notes. Eventually there are so many that the system itself becomes the problem.
The third is that it is not fast enough. This is the cost that turns into an incident. When someone leaves, the manual path to removing their access runs through a queue, and the queue does not know that this particular ticket is the one protecting a sensitive system from a departed employee. The lag between “should be revoked” and “actually revoked” is where standing access becomes standing risk. Manual governance is structurally too slow at the exact moment speed matters most.
None of these costs stay flat. Every new application added by hand increases the manual load. Every acquisition brings another set of disconnected systems and another stack of spreadsheets. Every audit cycle asks for more evidence than the last. The effort required to keep “good enough” from becoming “not good enough” grows with the size of the organization, while the people available to do that work do not grow at the same rate. What looked like a reasonable workaround for a dozen applications becomes an unmanaged liability across a few hundred.
The expense is real even when it is invisible. It shows up as staff hours spent assembling evidence instead of improving controls, as audit findings that require remediation projects, and as the occasional breach or near miss traced back to access that should have been removed months earlier. The budget never had a line item for “good enough governance,” but the organization pays for it continuously.
It helps to see manual governance for what it is: not a solution, but a deferral. The cost of properly governing a difficult application does not disappear when the work is handled by hand. It is postponed, and it accrues interest in the form of risk and rework. At some point the deferral is called in, usually by an auditor or an incident, and the accumulated cost is paid all at once.
The alternative is not to work harder at the manual process. It is to close the gap that made the manual process necessary, so that difficult applications are governed the same way the easy ones are: automatically, verifiably, and without depending on a spreadsheet and a person’s memory. The organizations that stop treating “good enough” as good enough are the ones that will not be surprised by what it was quietly costing them.
Insights, best practices, and real-world stories from the front lines of identity transformation.
A read-only connection tells you what access exists. Governance requires the ability to change it. ...
The systems most likely to create risk are the ones your identity program cannot see. ...