From regulatory pressure to business decisions: Put compliance on the bridge

There is no pause button for the extended enterprise.

I occasionally imagine what would happen if we operated a starship the way some organizations manage regulatory change. An asteroid warning arrives. Someone records it in the appropriate system, assigns an owner, updates the asteroid avoidance policy, and circulates a briefing. A committee requests clarification on whether the asteroid falls within the existing taxonomy. The dashboard eventually turns green because everyone has acknowledged the warning. Meanwhile, nobody has changed course. The large rock approaching the observation window remains thoroughly unimpressed by our document management capabilities.

My concern is not that organizations lack hardworking compliance professionals. It is that we have too often designed their operating environment around processing regulatory information rather than influencing business decisions. Identifying a change, interpreting it, and assigning tasks are necessary activities. But the business ultimately needs to understand what that change means for its objectives, operations, customers, investments, and choices. A regulatory alert is an input. A defensible business decision is an outcome. The distance between the two is where much of the real work of GRC belongs.

The inbox is not the business

I am interested in how quickly an organization can identify relevant regulatory development. I am considerably more interested in whether it understands the consequences. A beautifully summarized requirement is of limited value when nobody can explain which products it affects, which legal entities are in scope, which processes must change, or whether the implementation competes with an already approved strategic initiative. Faster delivery of information does not automatically create better judgment. Sometimes it simply gives everyone more material to misunderstand before lunch.

This is why I keep returning to the purpose of GRC. OCEG frames it around the capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity. That is a business-centered definition, not a mandate to build the world’s most impressive obligations repository. The repository matters because it supports those capabilities, not because its existence proves they are working.

For me, moving from compliance to decision-making does not mean moving away from compliance. It means bringing obligations into the decisions that shape the business, rather than discovering them after the product has launched, the contract has been signed, and someone has confidently announced the savings.

The rules are already pointing toward the bridge

Consider the EU’s Digital Operational Resilience Act, or DORA. For financial entities within its scope, it addresses governance, technology risk management, incident handling, testing, and third-party dependencies. Responsibility sits with management bodies, not simply with the person maintaining the compliance checklist. I read that as an unmistakable invitation to connect regulatory obligations with how the organization actually operates and how leadership oversees it. A policy library cannot, by itself, establish that a critical service will withstand disruption.

The UK Corporate Governance Code offers another useful example. Under its comply-or-explain framework, the revised Provision 29 calls for a board declaration on the effectiveness of material controls at the balance sheet date, spanning financial, operational, reporting, and compliance controls. It applies to financial years beginning on or after January 1, 2026, with reporting expected from 2027. The Financial Reporting Council also makes clear that materiality is company-specific and that external assurance is not automatically required. The challenge is therefore not to accumulate the largest possible evidence mountain; it is to establish a credible basis for the board’s judgment. 

These are different instruments with different scopes. But my takeaway is consistent: governance becomes meaningful when leadership can connect obligations, business exposure, control performance, and evidence. Counting completed activities is not an adequate substitute.

Make business impact the unit of work

Consider a hypothetical bank preparing to launch a digital product when a new customer-disclosure requirement is identified. A document-centered response might update the policy, revise a template, assign training, and record completion. A decision-centered response would examine the actual customer journey: application screens, approval steps, distribution partners, customer communications, and the systems generating disclosures. It would also identify whether the requirement changes the launch plan and what compliant alternatives are available.

I would want the impact assessment to answer four questions:

• What changes for this business? Which entities, products, customers, processes, and objectives are affected, and when?
• What choices remain available? Can we redesign the journey, introduce appropriate interim control, narrow the launch, or change its timing?
• What are the consequences of each option? What happens to customers, implementation costs, operational capacity, revenue timing, and remaining risk?
• Who must decide, and on what evidence? Who has authority, what assumptions require validation, and what would trigger reconsideration?

The output should be a decision brief, not merely a forwarded regulatory summary. It should preserve the source requirement, applicability assessment, interpretation, alternatives, recommendation, accountable owner, and implementation timetable. Uncertainty belongs in that brief as well. A qualified interpretation is more useful than unwarranted certainty wearing an executive-summary font.

There is an important boundary here: business impact analysis is not permission to disregard mandatory obligations because compliance looks expensive. The exercise is to identify lawful options and make informed choices among them. Risk appetite is not a magic wand that turns a legal requirement into a suggestion.

What leading teams do differently

The maturity distinction I look for is not the size of the regulatory affairs function or the sophistication of its dashboard. It is whether regulatory intelligence changes decisions while there is still time to make a difference. Four practices deserve particular attention:

• They establish applicability before mobilizing the organization. A proposal, final rule, supervisory communication, and enforcement development should not be treated as interchangeable. Teams need to establish legal status, scope, timing, and relevance, with qualified review where necessary. Otherwise, the organization can spend substantial energy preparing for something that does not apply while overlooking a less dramatic development that does.
• They connect requirements to the operating business. An obligation should lead to identifiable processes, controls, systems, owners, and evidence—not simply another folder. Where several requirements can be supported by the same control, I favor reuse after validating scope, frequency, and evidence requirements. Similar wording does not establish equivalence. Equally, a relaxed requirement is not automatically a reason to retire a control that still serves another obligation or business purpose.
• They put decisions into existing management forums. Material regulatory impacts belong in product governance, investment decisions, supplier selection, operational planning, and executive oversight. Compliance should not have to establish a parallel universe to obtain attention. Give decision-makers a clear choice, explain the consequences, establish authority, and record the rationale. An issue assigned to “the business” has not acquired an owner; it has acquired a hiding place.
• They monitor change in both directions. Regulatory developments can change business obligations, but business developments can also change regulatory applicability. Entering a market, acquiring a company, changing a product, or introducing a new technology may alter the picture even when the rulebook has not changed. I want impact assessment triggered by both sides of that relationship, with assumptions revisited when operations or evidence change.

These practices require cooperation without blurring accountability. The IIA’s Three Lines Model distinguishes management’s ownership of risks and controls, the expertise and challenge provided through second-line roles, and internal audit’s independent assurance and advice. Sharing information should strengthen those contributions, not turn internal audit into the owner of management’s compliance decisions.

For internal audit, the opportunity is to examine the reliability of the whole process: whether material developments are identified, applicability judgments are sound, decisions reach the right people, and implemented changes actually work. That is a more consequential assurance question than whether every field in the change register has been populated.

Buyers need navigation, not a more articulate inbox

As an analyst, I see the buying conversation shifting from administrative efficiency toward business relevance. Regulatory coverage, workflow, and reporting remain important. But the more consequential expectation is the ability to show how a development affects this organization and supports a timely, explainable response. In my assessment, too much market positioning still celebrates the volume of information processed without making the resulting decision appreciably clearer.

My advice to buyers is to test the complete journey. Bring a representative regulatory development into the evaluation and ask the provider to demonstrate its progression through applicability, business impact, ownership, options, approval, implementation, and verification. Examine what the system knows, what it assumes, and what a person must validate. A polished demonstration should survive contact with an awkward exception.

As I argued in my earlier article on GRC AI, summarization and automation become more valuable when connected to trusted information, organizational context, relationships, and human accountability. An AI-generated explanation of a requirement can be useful; it does not, on its own, establish what the organization should do about it. 

Nor does this require pretending that every relevant activity will live inside one application. I care more about coherent information and coordinated action across the operating environment than about how many modules share a navigation menu. The bridge needs reliable connections to engineering, not matching wallpaper.

Measure the decision, not just the paperwork

I would evaluate progress through four dimensions: efficiency, effectiveness, resilience, and agility. Efficiency means reducing duplicate interpretation, evidence collection, and administrative effort. Effectiveness means reaching sound applicability judgments and implementing controls that fulfill their purpose. Resilience means addressing weaknesses that threaten important outcomes. Agility means adapting products, services, and operations without repeatedly rediscovering the organization’s obligations from scratch.

The measures should reflect those outcomes. Track the time from a relevant development to a validated impact assessment and an authorized decision—not simply the time to create an alert. Examine whether remediation is verified before the applicable deadline, whether recurring control failures decline, and whether business changes encounter fewer late-stage surprises. Keep the completion statistics, but do not confuse them with a verdict on business readiness.

I would start with one important product or service and follow a material regulatory change all the way through. Find where context disappears, where ownership becomes ambiguous, and where the process produces paperwork instead of a decision. Repair those connections before commissioning another dashboard.

Ultimately, I do not want compliance relegated to the communications room, faithfully receiving warnings while everyone else determines the course. I want its intelligence on the bridge, informing choices alongside strategy, risk, performance, and operational reality. The objective is not to become exceptionally good at documenting the asteroid. It is to help the organization reach its destination—with its obligations honored, its customers protected, and its hull intact.