Control Assurance: Turning Controls Into Confidence
Most organizations have hundreds of controls on paper. Far fewer know which ones are actually working. Control assurance is the discipline, and increasingly the technology, that closes that gap: giving leadership, auditors, and regulators evidence-based certainty about whether controls are operating as designed, rather than a comforting assumption that they probably are.
What control assurance actually means
Control assurance is the process of systematically verifying that an organization’s internal controls, the policies, procedures, systems, and behaviors designed to manage risk, are correctly designed, operating effectively, and producing the outcomes they were built for. It answers the question every board, regulator, and auditor is really asking, even when they phrase it differently: how do you know your controls are working?
Control assurance sits at the intersection of risk management, compliance, and internal audit. It’s the mechanism that turns a control library from a static document into a living, evidence-backed program. Without it, a control framework is a list of intentions. With it, an organization can say something much stronger: our controls are tested, evidenced, and demonstrably operating as designed.
That work happens across what’s known as the three lines model. The first line, business operations, self-assesses its own controls day to day. The second line, risk and compliance, independently monitors and validates. The third line, internal audit, provides independent assurance to the board. In theory, the three lines reinforce each other. In practice, most organizations run them as three disconnected programs that rarely compare notes, which is where a surprising amount of this story begins.
The core problem in one line: organizations don’t lack controls. They lack a reliable, current answer to whether those controls are actually working right now.
The gap that keeps producing headlines
A static, periodically tested control framework fails in a few specific and recurring ways.
It shows a picture that’s already out of date. Controls are typically tested quarterly at best, annually at most. That means a control can fail quietly and stay failed for months before anyone in risk, compliance, or the boardroom finds out, and the discovery usually comes from an audit, an incident, or a regulator, not from the organization’s own monitoring.
That’s not a hypothetical risk. In October 2024, the UK’s Financial Conduct Authority fined Starling Bank £29 million over financial crime and sanctions control failures. At the center of the case was an automated sanctions-screening control with a system error dating back to 2017. For seven months, from July 2022 to January 2023, that control generated zero alerts, and nobody caught it through periodic review. It surfaced through Starling’s own internal investigation, by which point the bank had onboarded nearly 49,000 high-risk customers, some of them in breach of a separate commitment it had already made to regulators not to. The control had been assumed to be working. It hadn’t been, for years, and the assumption itself was the failure.
It turns testing into a manual grind. In most organizations, control testing runs on spreadsheets and email: a control owner receives a request, gathers evidence by hand, sends it back, waits for review, revises, resubmits. For an organization running several hundred controls across multiple frameworks, that cycle consumes an enormous amount of person-hours a year and produces results that vary depending on who happened to do the testing.
It tests the same thing over and over. Most organizations operate under several overlapping frameworks, SOX, ISO 27001, GDPR, PCI-DSS, at once. Without a unified control library, the same underlying control gets tested separately by each framework’s auditors: the same evidence gathered repeatedly, the same control owner interviewed repeatedly, the same result recorded in several different systems. In reality, a large share of controls across any two frameworks are substantially equivalent, an access control that satisfies SOX Section 404 typically also satisfies ISO 27001 A.9.4.1 and GDPR Article 32, but without a shared library, nobody captures that overlap.
Its evidence can’t defend itself. When a regulator asks for proof of control effectiveness, the typical response in a manual program is a multi-week scramble through email attachments, SharePoint folders, and personal drives, often with no consistent naming convention or chain of custody. And increasingly, regulators aren’t just asking whether controls exist; they want proof of how rigorously they were tested. DORA Article 11, for instance, requires financial entities to test their ICT business continuity and response and recovery plans at least yearly, subject those plans to independent internal audit review, and keep readily accessible records of what happened during any disruption. A platform with immutable, timestamped audit trails is built for that kind of ongoing obligation. A folder of email attachments is not.
Its three lines of defense don’t talk to each other. The first line self-assesses using its own templates. The second line re-tests a subset using different templates. The third line audits yet another subset with its own methodology. Deloitte’s own research on the three lines model describes this as a structural problem rather than an occasional inefficiency: as second-line risk and compliance functions take on more testing responsibility, internal audit often ends up covering the same ground with a similar skill set, producing real duplication and, for the first line caught in the middle, genuine audit fatigue. Nobody sets out to build three redundant assurance programs. It happens gradually, and then nobody owns fixing it.
It can’t tell you what actually matters. A control framework disconnected from the risk register can tell you whether controls are working, but not whether the right controls exist for the risks that matter. It’s common for a post-incident review to discover a well-documented risk with no control ever built to address it, right alongside extensive controls consuming real resources that map to no material risk at all. Without that linkage, residual risk, the exposure that remains after controls are applied, can’t be calculated. Organizations end up reporting inherent risk instead: a picture of how bad things could be, not how exposed they actually are today.
And it reports in a language nobody trusts. Board and executive reporting on controls is, in most organizations, a quarterly exercise: a team manually assembles data from half a dozen sources into a presentation that’s already stale by the time it’s delivered. Regulators have noticed. The UK FCA’s Dear CEO letters, the Federal Reserve’s MRA process, and the ECB’s SREP process all set specific expectations for board-level control reporting that manual, backward-looking decks consistently fail to meet.
What a living control assurance program actually does differently
Fixing this isn’t about adding another audit. It’s about changing what a control framework fundamentally is: from a document reviewed periodically to a system that watches itself continuously.
Testing shifts from periodic to continuous. Instead of checking a control once a quarter, a modern platform polls the underlying systems directly, verifying that privileged access policies are enforced in Active Directory, that firewall rule sets haven’t drifted from policy, that segregation-of-duties configurations in the ERP remain intact. Deviations trigger an alert and a workflow immediately, not at the next scheduled review. For the categories of control that lend themselves to this, IT access, system configuration, financial transaction controls, the majority can be monitored this way, which removes most of the manual testing burden for those control types entirely.
One test, mapped everywhere it applies. A unified control library maps each control to every framework it satisfies at once, so testing a control once produces evidence for SOX, ISO 27001, GDPR, and whatever else applies, rather than repeating the same conversation with four different teams. Beyond eliminating duplication, this also surfaces coverage gaps: which frameworks are thinly controlled, which risks have nothing mapped to them, which controls are redundant given the current risk profile.
Evidence that can defend itself. Every piece of evidence lives in a centralized, tamper-evident repository with full metadata: who collected it, when, from which system, using what methodology. When a regulator asks, the platform can assemble a complete, structured evidence package in hours instead of weeks, one that demonstrates not just that a control exists but the rigor behind how it was tested.
Three lines, one shared picture. Each line keeps its own workflow and methodology, but all three now draw from the same control library and evidence repository. First-line self-assessments become visible to the second line as they happen. Second-line findings inform third-line audit planning, so internal audit can concentrate effort on the areas with the least existing assurance rather than spreading evenly across everything. The result is an assurance map the audit committee can actually read at a glance: what’s well-covered, what isn’t, and where effort is being duplicated for no reason.
Residual risk that updates itself. By combining the inherent risk score with a live control-effectiveness score, residual risk recalculates automatically the moment a control degrades or a new one comes online. That gives the CRO and the board a genuinely current picture of exposure, not the theoretical worst case that inherent risk alone represents, and it lets control investment follow the risk that’s actually rising rather than the risk that was highest at the last quarterly review.
Where this connects to something bigger
What makes this worth building well, rather than bolting on as an afterthought, is that control assurance rarely lives in isolation. A control failure is never just a compliance finding; it’s a threat to something the business is actually trying to achieve, a strategic objective, a KPI, a risk appetite threshold the organization set for a reason. Platforms like Corporater‘s Business Management Platform build that connection in directly, so a degraded control shows up not as an isolated red flag in a GRC tool, but in the context of the business outcome it’s actually putting at risk. That’s a more honest way to talk about control assurance with a CFO or a board: not as a compliance cost, but as a direct line to whether the business is protecting what it says it cares about.
The bottom line
Every organization already believes its controls are working. That belief is usually based on the last time someone checked, and for most control types, that’s measured in months, not minutes. The distance between “we have a control for that” and “we can prove that control worked yesterday” is where regulatory fines, board surprises, and failed audits actually come from, not from an absence of controls, but from an absence of continuous, evidence-backed certainty about them.
Control assurance closes that distance. It replaces periodic reassurance with continuous evidence, manual assembly with automatic mapping, and disconnected lines of defense with one shared picture of what’s actually working. The organizations that get this right stop discovering control failures at the next audit cycle and start seeing them the moment they happen, which, as the Starling Bank case shows, is exactly the difference that matters.
Xponential Digital