When Controls Compete With Each Other

Key Takeaways

• Controls Can Work Alone and Fail Together: Individual controls may operate exactly as designed while creating conflicts, delays, or gaps when applied alongside other requirements.
• Employees Experience Controls as a System: Organizations often design and test controls individually, but employees must satisfy multiple security, compliance, financial, procurement, and operational requirements at once.
• Workarounds Can Reveal Design Problems: Repeated exceptions and circumvention may indicate that controls are imposing incompatible demands, not simply that employees are failing to follow procedure.
• Exceptions Need Their Own Governance: Organizations should establish who can authorize departures from normal controls, under what circumstances, and which compensating measures apply.
• Internal Audit Should Examine Control Interactions: Effective testing should consider dependencies, bottlenecks, competing objectives, and how controls behave together, particularly during disruption.

Deep Dive

A critical system goes down, and the operations team needs an administrator inside it immediately. Privileged access, however, requires approval, and the designated approver is unavailable. A change may restore the system, but normal procedure requires testing before anything reaches production. Meanwhile, the recovery clock is running.

There is nothing obviously wrong with any of these controls. Restricting privileged access is sensible, as is requiring approval before it is granted. Production changes should be tested. Critical systems should also be restored within the recovery times the organization has established. The difficulty appears only when all of those requirements have to be satisfied at once.

This is one of the less examined weaknesses of internal control. Organizations tend to design, document and test controls individually, even though employees encounter them as a system. Procurement, cybersecurity, finance, privacy, compliance and operations may each impose requirements on the same process, and each requirement may be entirely reasonable within the risk it was designed to address. Taken together, however, they can create delays, contradictions and occasionally situations in which complying with one control means departing from another.

Procurement offers an obvious example. Competitive bidding and third-party due diligence protect against fraud, conflicts of interest, financial instability and other supplier risks. But if a critical provider suddenly fails, operations may need a replacement within hours rather than weeks. The same tension appears elsewhere. Segregation of duties can prevent one employee from initiating and approving a transaction until a staffing shortage leaves only one qualified person available. Privacy controls can properly restrict access to personal information that fraud investigators need to compare across systems. Change-management procedures can require a testing period that cybersecurity cannot afford when attackers are exploiting a newly discovered vulnerability.

These are not necessarily cases of poor control design. Often both requirements exist for good reasons. The more difficult question is whether the organization considered what would happen when those reasons came into conflict.

Effective Alone, Ineffective Together

Internal control has traditionally been easier to assess in pieces. An auditor can test whether privileged access was properly approved, whether a vendor underwent due diligence or whether a production change received the required review. Each control has an objective, an owner, a procedure and some form of evidence showing whether it operated as intended. That approach remains necessary, but it can also produce a reassuring picture that disappears when the controls are viewed together.

Consider the original outage. An auditor might test privileged-access controls and find that elevated permissions consistently require appropriate authorization. Incident-management procedures might separately show that critical systems have defined recovery objectives and escalation processes. Change-management testing could confirm that production changes receive the required review. Each control passes. Yet a serious outage reveals that restoring the service within its recovery objective requires access that cannot be approved quickly enough and a change that cannot clear the ordinary process in time.

Nothing in the individual testing necessarily identifies the problem because the weakness does not belong entirely to any one control. It exists in the relationship among them.

Organizations have become adept at mapping controls to risks, policies, regulations and frameworks, but the relationships among controls themselves tend to receive less attention. Some controls reinforce one another. Others duplicate work or depend on another control being completed first. Still others pull in opposite directions, imposing competing demands on the same employee, system or process. A control library can document hundreds or thousands of controls without making those relationships particularly visible.

The difficulty grows with organizational complexity. Cybersecurity restricts access while resilience planning requires critical systems to be restored quickly. Privacy limits the use of information while compliance and investigations may require broader visibility into it. Procurement imposes conditions on suppliers while operations is measured partly by its ability to keep the business running. Finance establishes approval thresholds while crisis management may require commitments before the normal chain of approval can move.

Each function is responding to a legitimate risk, and each may be able to demonstrate that its controls are effective. What is harder to establish is whether the resulting collection of controls still produces an effective process.

What Workarounds Can Tell You

Organizations can live with these contradictions for surprisingly long periods because employees are good at making imperfect processes work. They find the approver who responds quickly, maintain a spreadsheet outside the official system, make an urgent purchase and obtain approval afterward, or move a discussion from a ticketing system to a phone call when the formal process cannot keep pace. Sometimes these are simply control failures. Sometimes the workaround is telling the organization something about the control itself.

The distinction matters. A culture in which employees casually disregard controls presents an obvious governance problem, but so does a process that routinely requires capable employees to circumvent it in order to do their jobs. If the same requirement is repeatedly bypassed at the same point, internal audit should be interested not only in why employees failed to comply but in why compliance became impractical in the first place.

That question becomes more important during disruption because ordinary operations can conceal a surprising amount of friction. When there is enough time, another signature can be obtained, a vendor review can take another day, an access request can remain in the queue and a production change can wait for its testing window. An incident removes that margin. Decisions compress, ordinary personnel may be unavailable, and the systems supporting the control process may themselves be affected. Requirements that coexisted comfortably during normal operations can suddenly become incompatible.

This is where internal control and operational resilience begin to overlap. A resilient control environment cannot simply discard safeguards whenever circumstances become difficult, but neither can it assume that procedures designed for normal operations will remain workable during a crisis. What matters is whether the organization has decided in advance how control should change when circumstances do.

Exceptions Are Controls, Too

Exceptions are sometimes treated as departures from the control environment, when in practice they are part of it. No sufficiently complex organization can design a single procedure that works under every possible circumstance. There will be emergency access, expedited purchases, unusual transactions, staffing shortages and systems that need to be changed before the next scheduled approval meeting. The question is not whether exceptions will occur, but whether they have been governed before they are needed.

An emergency production change, for example, may not be able to undergo the usual testing period. That does not mean it should proceed without control. Authorization can be narrowed, monitoring increased and retrospective review required. Emergency privileged access can be granted quickly while remaining time-limited, logged and subject to subsequent examination. A critical supplier can be brought into service through an expedited process while certain payments, system permissions or data access remain restricted until outstanding due diligence is completed.

In each case, the organization is not abandoning control so much as changing the way the risk is controlled. Doing that well requires decisions about who can authorize an exception, what circumstances justify it, how long it may remain in place and what compensating measures are necessary. Those decisions are much easier to make before an incident than in the middle of one.

The exceptions themselves can then become useful evidence about the health of the wider control environment. An occasional exception may show that a process has enough flexibility to accommodate unusual circumstances. A steady stream of them suggests that the supposedly unusual circumstance may no longer be unusual at all. Patterns in who requests exceptions, why they are requested, how long they remain open and which controls repeatedly require them can reveal weaknesses that conventional testing misses.

Looking Across the Control Environment

The implication for internal audit is not that control-by-control testing has become obsolete. Organizations still need to know whether approvals occur, access is restricted, reconciliations are completed and changes are reviewed. The opportunity is to add another level of inquiry: not only whether the control works, but what happens around it.

That means examining dependencies and sequencing as well as effectiveness. What has to happen before this control can operate? Which other requirements affect the same process? What happens when they are applied simultaneously? Under what circumstances would an employee be unable to satisfy both? If one requirement must temporarily give way, who decides, and what takes its place?

Those questions inevitably cross organizational boundaries. The cybersecurity team may own one control, finance another and procurement a third. Each can have sound reasons for the requirements it has established without anyone being responsible for determining whether the combined process remains workable. The problem becomes more pronounced as organizations respond to failures by adding controls. A regulatory finding produces another approval. A cyber incident leads to tighter access. A procurement failure adds another review. An audit recommendation creates another reconciliation. Each addition addresses a real weakness, but the cumulative effect receives far less scrutiny.

Over time, a control environment can become individually rational and collectively cumbersome. Duplication accumulates. Dependencies multiply. One safeguard begins to interfere with another. More controls may make the organization look better protected while quietly making the underlying process harder to operate, particularly when something goes wrong.

That is why control effectiveness cannot be judged entirely by asking whether each component performs as designed. Internal audit also needs to understand how those components behave together, where they reinforce one another, where they create bottlenecks and where legitimate objectives begin to compete.

There will always be moments when two valid requirements cannot be satisfied equally. A mature control environment does not pretend otherwise. It identifies those points of tension, determines how they should be handled and gives employees a governed way through them.

Otherwise, when two controls compete, the organization has not resolved the conflict. It has simply left the person caught between them to decide which one matters more.

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.