The Compliance Illusion: When More Controls Create More Risk

Key Takeaways

• Control Accumulation Is Becoming a Governance Problem: Organizations have gotten very good at adding controls in response to regulation, audit findings, incidents, and emerging threats. They are far less disciplined about deciding when a control should be consolidated, redesigned, or retired.
• More Controls Can Produce Less Visibility: As control environments expand, ownership fragments, evidence multiplies, and related risks scatter across functions. An organization can have hundreds of controls and still struggle to see how its most important risks connect.
• Compliance Complexity Creates Operational Drag: Every control consumes something: people, time, technology, management attention, testing capacity, and evidence. The cost rarely shows up on a compliance budget. The business feels it through slower decisions and crowded priorities.
• Control Evidence Can Create False Confidence: A completed checklist, a signed review, or a passed test each proves an activity occurred. None automatically proves the organization is more resilient, that the risk has actually fallen, or that the control still matters.
• GRC Maturity May Depend on Knowing What to Remove: The next generation of GRC will not be defined by the size of the control library. It will be defined by an organization's ability to keep that library proportionate, connected, understandable, and capable of changing when risk changes.

Deep Dive

There is a strange rule in compliance: when something goes wrong, organizations add a control. A regulator raises a concern? Add a control. An auditor finds a weakness? Add another. A cyberattack happens? Add three. A new framework arrives? Someone opens a spreadsheet. Nobody ever gets celebrated for deleting one.

Controls are born in meetings, documented in policies, assigned to owners, tested by assurance teams, displayed on dashboards, and eventually become part of the furniture. Then the business changes. The technology changes. The threat changes. The regulation changes. The people change. The control stays.

It becomes a line in a register that nobody wants to challenge because someone, somewhere, once decided it was necessary, and that decision has since outlived everyone who made it. That is how a control environment becomes something more complicated than a risk-management system. It becomes an institution, and institutions are difficult to retire.

When Every Problem Gets Another Control

Control accumulation rarely happens because someone makes one terrible decision. It happens because every individual decision seems reasonable. A privacy requirement creates a control. A cybersecurity requirement creates another. An internal audit finding produces another. A customer contract introduces another. A new regulator publishes guidance, and another appears. Then an incident occurs and management asks for additional assurance. Add another.

The problem is not any single control. The problem is the architecture created by thousands of individually reasonable decisions, none of which ever had to answer to the whole. Eventually, nobody is designing the control environment. They are maintaining its history.

The result is what might be called control inheritance: new teams inherit old controls without necessarily inheriting the reasoning behind them. A control can survive several generations of systems, policies, employees, and business models simply because removing it requires someone to ask a difficult question: What happens if we stop doing this?

That question is uncomfortable. Keeping the control is easier. So it stays, the way a houseguest stays long after anyone remembers who invited them.

The Control Library Starts Looking Like a Museum

Most organizations are good at creating control inventories. Far fewer are good at curating them. A control library can quietly become a museum of organizational history. Here is the control created after the incident. Here is the one created after the audit. Here is the control inherited from the acquisition. Here is the one created for the old system, now running in a different one. And here is the control nobody remembers creating but nobody wants to be the one to remove.

Everything is documented. Everything has a reference number. Everything has an owner, at least on paper. Yet the organization may still struggle to answer the most basic question: Which of these controls actually matters most to our current risk profile?

That is the compliance illusion. The organization mistakes the existence of controls for control over risk. Those are very different things, and only one of them shows up on the register.

When More Controls Create Less Clarity

More controls create more relationships. More relationships create more dependencies. More dependencies create more opportunities for confusion. Consider a risk involving customer data. Cybersecurity may own access controls. Privacy may own data-protection requirements. IT may operate the underlying systems. Legal may interpret contractual obligations. Procurement may manage the third party. Internal audit may provide assurance. Compliance may monitor regulatory obligations.

The risk is one thing. The control environment around it is seven things. Everyone can be doing their job correctly while the organization still fails to see the risk as one connected problem. This is where siloed GRC becomes dangerous. The organization has visibility everywhere except exactly where the pieces meet.

The Spreadsheet Becomes the Operating Model

There is a point where compliance stops being something the business does and becomes something the business does for compliance. People begin scheduling work around evidence deadlines rather than risk. Meetings are held to prepare for other meetings. Teams spend time translating one framework into another, as if risk needed subtitles. Control owners chase evidence from other control owners. Managers approve attestations they barely remember reading.

The organization becomes very good at proving that processes exist. It becomes less certain about whether those processes are changing outcomes.

That distinction matters. A control can be perfectly documented and badly designed. It can be performed exactly as written and still address the wrong risk. It can pass testing while becoming irrelevant to the business around it. A control can produce beautiful evidence while providing very little protection. The spreadsheet is green. The risk is not.

Evidence Can Become the Product

Evidence is necessary, but it has a strange ability to become the objective.

Once an organization starts measuring compliance primarily through evidence production, people naturally optimize for what can be demonstrated. A completed checklist is easier to report than an improvement in organizational resilience. A signed approval is easier to count than better judgment. A control test is easier to schedule than a meaningful reduction in exposure.

This creates a subtle shift. Instead of asking, “What risk are we trying to reduce?” the organization begins asking, “What evidence do we need to show?”

That is backwards. Evidence should support assurance. It should not become a substitute for it.

Modern regulatory expectations are moving in the same direction. GRC Report's recent coverage of Japan's AML supervision describes a shift away from simply confirming that institutions have basic risk-control frameworks toward examining whether those frameworks actually work.

The message is broader than AML. Having the framework is becoming the starting point. Proving that it works is the harder part, and the part most control environments were never built to answer.

The People Cost Nobody Puts on the Risk Register

Control complexity also creates a human problem. Every control needs someone to understand it, operate it, review it, test it, remediate it when it fails, explain it to the auditor, and update the documentation when the process changes. That is a lot of organizational attention. And attention is a finite resource, no matter how the org chart is drawn.

When the control environment becomes too crowded, the organization does not necessarily become more careful. It can become less careful. People begin prioritizing what is measured. They focus on what is due this week. They complete the control that generates an overdue notification. They satisfy the evidence request sitting in someone's inbox.

Meanwhile, the risk that nobody has turned into a task quietly stays in the background, undocumented and unbothered. This is the paradox: a control-heavy organization can create control fatigue. Fatigued control owners do not become better risk managers simply because the spreadsheet got bigger.

The Automation Trap

Technology promises an obvious answer: automate the controls. But automation can create its own illusion. If a badly designed control is automated, the organization has not solved the problem. It has simply made the problem faster.

An unnecessary manual review becomes an unnecessary automated review. A duplicate evidence request becomes an automated duplicate evidence request. A poorly designed approval process becomes a digital version of the same poorly designed approval process, now with a nicer interface.

Automation should therefore come after rationalization, not instead of it. First ask whether the control should exist. Then ask whether it can be simplified. Then ask whether it can be combined with another control. Only after those questions have been answered should the organization ask whether it can be automated. Otherwise, organizations risk building very efficient machines for doing unnecessary things.

Nobody Wants to Delete a Control

There is a psychological asymmetry at the heart of control management. Adding a control feels responsible. Removing one feels reckless. If an organization adds a control and nothing goes wrong, nobody asks whether the control was necessary. If an organization removes a control and something later goes wrong, everyone asks why it was removed.

So the incentive is obvious: keep it. Then keep the next one. And the next one. Over time, controls become organizational baggage, not because they are all bad, but because nobody has been given a strong enough reason to do the difficult work of deciding which ones no longer earn their keep.

This is why control retirement needs to become a governance activity in its own right. Controls should have lifecycles. They should have a purpose, an owner, a risk linkage, and effectiveness criteria. Importantly, they should also have a point at which someone is required to ask whether they still deserve to exist.

When Control Owners Become Traffic Controllers

The larger the control environment becomes, the more difficult coordination becomes. Compliance is watching compliance. Cybersecurity is watching cyber risk. Internal audit is watching controls. Legal is watching obligations. Procurement is watching suppliers. Operations is watching delivery. Risk is watching the enterprise.

Everyone has a dashboard. Everyone has a responsibility. And sometimes nobody has the whole picture. That is accountability fog. The danger is greatest where risks cross organizational boundaries. Third-party risk is not only a procurement problem. AI risk is not only a technology problem. Data risk is not only a privacy problem. Operational resilience is not only a business-continuity problem. Cyber risk is not only an information-security problem.

Modern risks travel. Control environments often do not.

Mitigating the Risk: Designing Controls That Know When to Die

The answer is not to eliminate controls. That would be just as irresponsible as accumulating them. The answer is to build a control environment capable of telling the difference between necessary control, duplicated control, ineffective control, obsolete control, and genuine assurance.

• Make risk the organizing principle. Start with the material risk and work toward the control, not the other way around. The question should be what needs to be controlled and why, not which framework happens to require another line on the register.
• Give every significant control a clear purpose. A control owner should be able to explain what risk the control addresses, what failure it is designed to prevent or detect, and why it still matters. If those answers are unclear, the organization has a governance problem wearing a compliance costume.
• Create a process for control retirement. Organizations build formal processes for approving new controls. They should be equally deliberate about retiring old ones. A control should be allowed to age out with the same dignity as an employee, not linger indefinitely because nobody scheduled its exit interview.
• Look for common controls. Where one well-designed control can satisfy several requirements, organizations should resist creating parallel controls simply because different frameworks use different vocabulary for the same risk.
• Measure control effectiveness, not control volume. A larger control inventory is not automatically a stronger control environment. Reporting should focus on material risks, control failures, recurring weaknesses, and evidence of actual effectiveness rather than the size of the library.
• Connect the pieces. Cross-functional risks need cross-functional views. Organizations should be able to see how cyber, privacy, third-party, operational, regulatory, and reputational exposures interact rather than having seven separate people describe the same elephant.
• Protect control owners from control overload. When the same people are responsible for operating, documenting, testing, and remediating an ever-growing number of controls, control fatigue becomes an operational risk of its own. Fatigued owners do not become more careful. They become faster at rubber-stamping.
• Simplify before automating. Technology should remove unnecessary work, not permanently enshrine it. Rationalize controls first, then decide what is worth automating.

The Control Environment Needs a Delete Button

GRC has spent years getting better at identifying what organizations should do. The next maturity challenge is getting better at deciding what organizations should stop doing.

That means asking questions that can make people uncomfortable. Which controls are still necessary? Which ones overlap? Which ones were designed for risks that no longer exist in the same form? Which ones generate evidence without generating assurance? Which ones consume more management attention than the risk justifies? Which ones exist because they are genuinely valuable, and which exist because nobody has challenged them in five years?

Those are not questions of administrative efficiency. They are questions of governance.

A control environment that cannot change is not necessarily a mature one. It may simply be an old one, wearing maturity as a disguise.

From Control Collectors to Control Architects

The strongest GRC professionals will not necessarily be the ones who can produce the largest control inventory. They will be the ones who can look at the entire system and understand how its parts interact.

They will know when two controls should become one, when a control should be automated, and when a control should simply disappear. They will understand that assurance is not the same thing as paperwork. They will challenge the assumption that every new risk requires another independent control.

And they will ask a question that is surprisingly difficult for many organizations to answer: If we removed this control tomorrow, what risk would actually increase?

If the answer is clear, keep the control. If the answer is unclear, investigate it. That is not anti-compliance. It is better compliance.

The goal is not to build an organization with the most controls. The goal is to build an organization where the right controls are connected to the right risks, owned by the right people, producing meaningful assurance, and capable of changing when the risk changes.

Eventually, there is a point where adding another control does not make an organization safer. It simply makes the organization harder to understand. And what an organization cannot understand, it cannot govern well.

The real mark of GRC maturity may not be how many controls an organization has. It may be whether it knows which ones it no longer needs.

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey.