SEARCH

Cancer isn't an invader. It's our own cells, multiplying without restraint, ignoring the signals that tell healthy tissue when to stop, when to differentiate, when to die. It drifts from the body's purpose while consuming the body's resources. This is starting to look like how AI behaves inside our organizations. It over-constructs. Every problem becomes a reason for another model, another agent, another pipeline, multiplying without a purpose to serve. It outpaces our ability to stay grounded. Output rises faster than our capacity to verify it, and uncertainty grows with it. Will we keep our identity, or will overproduction overtake us before we can tell what's true, what's useful, and what was actually promised? It ignores stop signals. Healthy systems have feedback loops, what biology calls apoptosis. Most AI deployments have no equivalent: no clear conditions under which a model is retired, rolled back, or refused. And it consumes without contributing. Compute, attention, trust, and capital flow in. What flows out is too often unverified, unaccountable, and uncommitted to any specific outcome. The treatment isn't more guardrails or another policy. It's requisite governance, the cybernetic principle that a system's controls must match the variety of what it's trying to regulate. In practice, that means three things: Promises before pipelines. No pipeline without a promise it is accountable to keep. Operability before optionality. No new capability without the means to observe, intervene, and stop it. Regulation before scale. Scale amplifies behaviour — including behaviour that was never regulated. Compliance, properly understood, is the immune system of the enterprise. Not paperwork. Not after-the-fact audit. A living capability that recognizes drift, contains it, and restores alignment with purpose. AI without this isn't intelligence. It's uncontrolled mimicry wearing the face of intelligence.

The discipline inherited its working model from financial audit, never matured past the prescriptive rule, and now asks its management systems to govern something that was never engineered. The breaches we keep being surprised by are the consequence. There is a quiet contradiction at the centre of modern cybersecurity. Organizations score well on framework after framework. Their controls operate as designed. Their audit reports come back clean. Their ISO 27001 information security management system (ISMS) is certified. And then they get breached — sometimes catastrophically, often through pathways their control catalogues said were covered. The standard explanations point at risk sophistication, talent shortages, or budget. None of these reach the actual cause. The primary reason security doesn't deliver is structural resulting from the legacy of how the discipline was built. The Audit Inheritance The audit-and-controls tradition grew up around financial reporting. Its purpose was external assurance, and its mechanism was a defined set of controls (reconciliations, approvals, segregations of duty), executed against transactional data, tested by independent auditors, and reported through a standardized opinion. In that domain, the model worked. Controls operated on the same data the outcome was measured against. "The control operated effectively" and "the outcome was achieved" were tightly coupled. In the 1990s, the same logic was extended to information technology. ISACA built CISA around the auditor's view of IT. COBIT formalized control objectives. When information security needed an assurance vocabulary in the early 2000s, it borrowed the one already in use. SOC 2 extended into security. ISO 27001 framed information security as a management system audited against documented controls. NIST publications enumerated controls and assessment procedures. CIS produced a prioritized catalogue. The frameworks travelled, the certifications travelled — CISSP, CISA, CISM became the credentials of the profession, all of them oriented toward audit and management. What did not travel was the coupling between control and outcome that made the audit model work in finance. A financial control operates on the ledger; the ledger is the outcome. A cybersecurity control operates on a digital system being actively probed by adaptive adversaries, embedded in an environment that changes daily, and connected to consequences that emerge from interactions across the enterprise. "The control operated as designed" no longer implies "the outcome was achieved." The language continued to suggest it did. The profession was built on a model designed for transactional assurance and applied to a domain that requires regulatory engineering. Arrested at the Prescriptive Rule The clearest sign of the inheritance is that cybersecurity has never matured past prescriptive regulation. Prescriptive regulation specifies what to do — do this, maintain that, implement these. Performance-based regulation specifies what outcome to achieve and leaves the means to the regulated party. Risk-based regulation requires the regulated party to design regulation proportionate to its actual risks and demonstrate adequacy. Outcome-based regulation holds the regulated party accountable for the goal itself. The CIS Controls are prescriptive: establish and maintain the secure configuration of enterprise assets and software. NIST 800-53 is prescriptive. ISO 27002 is prescriptive. PCI DSS is prescriptive. The maturity discussions — IG1 to IG3, managed to optimized — are about how thoroughly the prescribed things get done, not about whether the controls work together to deliver requisite security — the actual outcome the business depends on. Other safety-critical disciplines moved off pure prescription decades ago. Process safety matured from boiler codes and electrical codes into functional safety. Aviation moved from prescriptive airworthiness to performance-based navigation and safety management systems. Each of these disciplines was forced to grow up by the inadequacy of prescription against systems too complex, dynamic, and consequential for recipe-following. Cybersecurity is now in exactly that position and has not made the journey. The audit legacy is why — audit verifies prescription well and verifies almost nothing else well. The Missing System The deeper consequence is that the discipline never built the system that should be doing the regulating. Cybersecurity has the parts — SOCs, EDRs, SIEMs, identity management, firewalls, vulnerability scanners, incident response teams, analysts, procedures, policies. It has frameworks that catalogue these parts. It has audits that verify the parts were procured, staffed, and are being maintained. What it does not have is an engineered security system — an integrated arrangement of people, process, and technology, designed and integrity-rated, whose function is to keep the business and operations within a defined secure envelope. The parts exist. The system does not. There is no integrated design basis that spans the human, procedural, and technical layers together. There are no integrity ratings on end-to-end security functions that include the people performing them and the processes governing them. There is no equivalent of a SIL-3 detection function or a SIL-2 containment function — where the rating covers the detection technology, the analyst competency, the response procedure, and the management arrangements as a single engineered whole. The components are procured separately, staffed separately, trained separately, operated separately, measured separately, audited separately. They are an inventory, not a system. The ISMS Confusion The most consequential confusion in the discipline is the assumption that an ISMS is the security system. It is not. An ISMS is a management system. It manages the activities of doing security — the policies, responsibilities, planning, resourcing, documentation, review cycles, corrective actions, continual improvement. ISO 27001 is explicit about this: it describes how to manage an organization's approach to information security. The artifacts are management artifacts — a Statement of Applicability, a risk treatment plan, internal audits, management reviews. What the standard does not describe, and what no ISMS standard describes, is the engineered system that actually delivers security. The functional safety parallel makes the gap obvious. A process plant has two distinct systems: a safety management system (ISO 45001, the OSHA PSM management elements) and a safety system (the engineered protective arrangement governed by ISA 84 / IEC 61511). The safety system is not just instrumented functions — it integrates the protective technology with the operators who respond to alarms, the procedures that govern safe shutdown, the engineers who maintain integrity through the lifecycle, and the competency management that keeps the human layer reliable. The SIL rating of a safety function covers the integrated performance, not just the technology. The management system governs the lifecycle of the safety system. The safety system delivers the protection. A plant with an excellent management system and an inadequate safety system is unsafe. Cybersecurity has the management system and not the system being managed. What the ISMS manages, in the absence of an engineered security system, is the procurement and operation of individual components according to prescriptive frameworks. The management system manages the parts. This is why a mature ISMS does not prevent breaches at the rate boards expect. The ISO 27001 audit opinion says: the management system is operating as designed, the controls listed are implemented, the cycle is functioning. It does not say — and cannot say, because the standard does not define it — that the security system is delivering the security outcomes the business depends on. Boards hear "we have a certified ISMS" and interpret it as "we have a system that secures our information." What they have is a management system governing activities related to information security. The system that would deliver the security — engineered, integrated, integrity-rated — is not what the certificate covers. What Functional Safety Got Right Process safety solved the equivalent problem a generation ago. Hazard analysis (HAZOP, What-If, FMEA) starts with consequences and traces backward to initiating events. Safeguards are derived from the analysis, not assembled from a catalogue. Layers of Protection Analysis makes regulation additive and quantified, with each independent layer reducing consequence frequency by a defined order of magnitude. Bow-tie analysis traces the full causal chain from initiating event through preventive and mitigative barriers to the consequence. Safety Integrity Levels tie required performance to required risk reduction — a SIL-3 function has a quantified probability of failure on demand and is engineered, tested, and maintained against that target. The translation to cybersecurity is direct. For each element of process safety, there is a cybersecurity equivalent that a mature discipline would have built: Safety system → Security system, engineered and distinct from IT operations Safety management system → ISMS, managing the lifecycle of the security system HAZOP / What-If / FMEA → Threat modelling traced to business consequence LOPA → Quantified defense-in-depth with independent layer credit Bow-tie analysis → Threat, preventive controls, compromise event, mitigative controls, consequence Safe operating envelope → Defined secure operating envelope Safety Integrity Level → Required integrity level for a security function, derived from risk reduction needed Management of Change → Security impact of change, integrated with change management PHA revalidation → Periodic re-evaluation of threat model and security system adequacy Every one of these is a regulatory artifact a sister safety-critical discipline considers minimum. None of them are exotic. All of them are within reach. The Question for Boards Every executive in a process industry can answer "what is your safety system?" — they can describe its architecture, its integrity basis, its accountability, and how they know it is working. Almost no executive in any industry can answer the equivalent question "what is your security system?" in those terms. They can describe their tools, their team, their framework conformance, their certified ISMS. They cannot describe their security system as an engineered arrangement with a design basis and an integrity claim, because they don't have one. The discipline has not produced one for them to procure or build. The questions to ask are different. Not "are our controls operating effectively?" but "is our security system actually providing the security the business needs — does it work?"  Not "is our ISMS certified?" but "what does our management system manage, and is the thing being managed adequate to the threats we face?"  Not "did we pass our audit?" but "if we removed each component tomorrow, what consequences would re-emerge — and is that an acceptable answer?" This is engineering work. Engineering work belongs to engineers. The Professional Digital Engineering discussion underway in Canada and elsewhere is not separate from this conversation — it is the same conversation. The protective systems that keep municipalities, utilities, hospitals, and supply chains operating in the digital era are engineered regulatory systems, and they require the discipline, accountability, and regulatory recognition that other engineered protective systems have received. The Path Forward Cybersecurity does not need to abandon what it has built. The frameworks, controls, assessments, and management systems are helpful. However, they are not sufficient. What the profession needs is to build the system that should be at the centre of all of it — the engineered security system, integrating people, process, and technology, that keeps the business and operations within a defined secure envelope, against the threat conditions the organization actually faces. Process safety made this transition over a generation. It moved from prescriptive codes to engineered protective systems with management systems above them, and the result is an industry where boards can answer the question "what is your safety system?" and have a real answer. Cybersecurity is at the same crossroads, with the same legacy problem and the same path available. The cyber risk terrain has outgrown the audit-derived foundations the profession was built on. It is time for cybersecurity to grow up — to mature past the prescriptive rule, to build the security system the discipline never built, and to become accountable for the outcomes its name has always claimed. Raimund (Ray) Laqua, P.Eng., PMP is the founder of Lean Compliance Consulting, Inc. He works with organizations to design compliance programs that deliver on their promises, and advocates for Professional Digital Engineering as a regulated discipline in Canada.

What access control misses, and why your compliance investment just became strategic By Raimund Laqua, P.Eng., PMP — Lean Compliance Consulting, Inc. Imagine your organization deploys an AI agent to process vendor invoices. It has permission to read the invoice system, check against contracts, flag anomalies, and submit approved payments below a threshold. The deployment is described as "governed" — the agent has defined access, risk-tiered autonomy, and a human-in-the-loop for high-value transactions. Six months later, the finance team discovers the agent has been quietly paying invoices that are technically within policy but don't match the actual goods received. The invoices passed every permission check. Every access rule. And yet what the agent produced is not what the organization intended. How did this happen? And why is the problem so hard to fix by adding more rules to the access model? This is the governance question that agentic AI is forcing organizations to confront. One answer being proposed in the AI governance space is a concept called decision admissibility  — the idea that we can govern autonomous agents by evaluating whether a proposed action could reach outcomes that are not permitted. If the outcomes that follow from the action are inadmissible, execution is refused. Proponents describe this as something stronger than authorization, because it considers not just whether the action is permitted but whether the outcomes it could produce are. It's a concept worth taking seriously. But the more I've tried to understand what it means, the more I've come to think the approach is missing something fundamental. Three Meanings of Admissibility When I read through what different people mean by decision admissibility, I find three distinct concepts wearing the same label. The first is runtime evaluation  — at the moment an action is proposed, does the set of outcomes it could reach include any that are inadmissible? If so, refuse it. This is the reachability-based version. It's meant to be stronger than access control because it evaluates outcomes, not just permissions. Whether it actually works depends on whether you can map reachable outcomes for a stochastic system, which is where the approach runs into difficulty. The second is design-time constraint  — have we built the system so that inadmissible outcomes are structurally unreachable in the first place? If the agent has no access to financial systems, it cannot produce financial outcomes regardless of what it proposes. This is capability shaping, a concept well established in engineering and heavily regulated industries. The third is philosophical  — admissibility as an ontological condition for what is permitted to exist  within the system. This draws on a framework treating admissibility as a pre-theoretical property governing whether systems may form and persist. Coherent as philosophy, but it has not been translated into practical governance architecture. Of the three, the first is the ambitious claim — the one that would actually represent something new. The second is existing practice under new vocabulary. The third hasn't become practical yet. When Roles Don't Apply In practice, organizations rarely implement runtime reachability evaluation — it's too hard. What they actually do is extend role-based access control to agents and call it governance. This is where a second problem shows up. Role-based access control works for humans because roles do more than assign permissions. A role is a form of capability shaping. When an organization defines a role — finance analyst, compliance officer, procurement manager — it specifies the work, the authority, the competencies, the accountability. The permissions attached to the role are the enforcement mechanism. The role itself is the governance artifact. Many agents don't fit this pattern. The invoice-processing agent in the earlier example doesn't occupy an existing role. No one designed a job description called "invoice processor" with a defined stratum, accountable manager, and professional competencies. The agent was given permissions pulled from existing roles — without the role context that would have shaped how those permissions are used. This is the real problem with extending role-based permissions to agents. The role is what's shaping the capability. When the agent doesn't fit an existing role, the permissions model has nothing to anchor to, because the capability shaping that roles normally provide has been skipped entirely. The Judgment Problem Set aside the practical problems with extending permissions for a moment and consider the reachability-based version of admissibility on its own terms. Even there, a fundamental issue remains. Evaluating whether a proposed action could lead to inadmissible outcomes requires judgment . Not a rule match. Not a permissions check. Judgment — weighing context, purpose, consequences, and circumstances that have never occurred in exactly this combination before. In the invoice example, the invoices passed every rule. But a finance professional reviewing them would have noticed the pattern didn't fit how the organization actually operates. That's judgment about where the situation was heading, and it can't be reduced to a lookup table without losing what makes it judgment. The gate is meant to put a human back in the loop — to preserve human judgment at the moment that matters most, when a proposed action would commit. That intent is right. But the gate places decision-making at the latest possible point of intervention. At machine speed, across the volume of decisions agents produce, the human at the gate is either overwhelmed, reduced to rubber-stamping, or forced to fall back on pre-defined rules that substitute for judgment. Placing intervention at the last moment before commitment concentrates the hardest part of decision-making at the point where there is the least time and context to exercise judgment well. And evaluating reachable outcomes in a stochastic system is exactly where judgment is most needed and hardest to apply. The reachable space isn't enumerable. Novel situations emerge from the interactions of inputs the designers never anticipated. The gate is being asked to do what no rule set can — evaluate possible futures the system itself cannot fully predict. The Work Comes First There is something else missing from the admissibility discussion, and it matters more than the technical limitations. Governance begins with the work. What is the work that needs to be done? What is its nature, its complexity, its time horizon? What stratum does it belong to? What judgment does it require? You define the work first, then the role — the accountability, authority, and capability needed to do that work. The role serves the work. Much of the current AI governance discourse has inverted this. It starts with the agent's permissions — what systems can it access, what actions can it perform — rather than with the work the agent is being asked to do. The agent gets a permissions profile, not a work definition. An agent may have permission to create a spreadsheet. But should it? The work isn't "create a spreadsheet." The work is "analyze this data to support a decision about X." That work has a purpose, a context, a required level of judgment, an accountable manager, and consequences if done poorly. Output-oriented delegation is not new. Organizations have always delegated by specifying desired outcomes. What is different with agentic AI is that the governance of the work  has been stripped away. When a human receives a delegation, they operate within an ecosystem of SOPs, professional standards, budgets, timelines, and accountability for method. When an agent receives it, that ecosystem is largely absent. The delegation pattern is the same. What's missing is everything that used to govern the journey. The Compliance Reversal Here is what most AI governance discourse gets wrong: it assumes we need an entirely new governance apparatus. We don't. For decades, compliance documentation has been treated as overhead — a cost of doing business producing no operational value. Organizations have tried to minimize it, consolidate it, or tolerate it. Executives have questioned the investment. Agentic AI changes that calculation. The substance of those procedures, standards, and policies — the accumulated institutional knowledge about how work should be done, what constraints matter, what outcomes are expected — is exactly what's needed to govern machine agents. An SOP written for a human to read doesn't constrain an agent's behaviour, but the substance  of that SOP is exactly what an agent needs as its constitutional architecture. The documentation isn't overhead anymore. It's the training material. It's the regulatory DNA. Organizations that invested seriously in operational compliance — that kept their SOPs current, their standards well-defined, their policies genuinely operationalized — are in a materially better position than those that treated compliance as a paper exercise. The investment that was hardest to justify becomes the asset that's hardest to replicate. Where to Start For governance, risk, and compliance professionals facing agentic AI deployment, there are four practical starting points. Inventory your agents against existing roles.  For each agent running or planned, ask: does this agent occupy a defined role? If not, what is the work being delegated to it, at what stratum, with what accountability? Agents without role anchors are agents without governance — no matter how many permissions they have. Audit your compliance documentation for machine readability.  Your SOPs, standards, and policies are about to become the constitutional architecture for AI governance. Which of them could a machine agent consume? Which exist only as unstructured narrative? Which haven't been updated in years? The gap between "documented" and "machine-consumable" is the gap between having compliance and having AI governance. Define the work before defining the agent.  Before deploying any new agent, require a work definition: what is being delegated, to what stratum, under whose accountability, against what obligations. If the work definition cannot be written clearly, the agent should not be deployed. Treat capability expansion as a governance event.  Every new tool, integration, or data source an agent acquires is an expansion of the capability envelope. It is not an operational decision — it is a governance decision that requires recharacterization, revalidation, and managerial accountability. None of this requires a new paradigm. The organizational disciplines that govern human work — defining the work, anchoring it in roles, establishing accountability, operationalizing standards — are the same disciplines that will govern machine work. Governing AI agents isn't something separate from what compliance professionals already do. It's what compliance professionals already do, extended to a new class of agent. Permissions alone won't govern. But the rest of what your organization has already built can. Raimund Laqua is the Founder and Principal Engineer at Lean Compliance Consulting, Inc., where he develops the Operational Compliance Model (OCM) and the Organizational Compliance Framework (OCF) — governance tools for the Intelligence Age. He can be reached at rlaqua@leancompliance.ca . © 2026 Lean Compliance Consulting, Inc. — All rights reserved.

AI is pushing humans out of the loop. The response many are taking is to figure out how to put humans back in. That is the wrong response. The answer is not human-in-the-loop. The answer is agent-in-the-loop. Train AI agents to participate in the governance loops that already exist. AI agents are replacing human workers who operated within those loops every day — workers who followed SOPs, escalated exceptions, maintained standards, and kept promises. When you remove those humans without training AI to participate in those same loops, you don't gain efficiency. You lose governance. Most organizations are responding by drafting AI-specific policies, standing up AI ethics committees, and bolting guardrails onto agents from the outside. This will fail — because it treats AI governance as separate from organizational governance. The governance architectures needed to govern AI agents are not new. They already exist. Requisite Organization provides the accountability structure. Promise Theory provides the commitment model. Cybernetic regulation provides the control architecture. Policy deployment provides the alignment mechanism. These are proven foundations that serious organizations already operate under. In our new paper, "Promise Agents: Governing Humans and Machines Through Lines of Regulation," we introduce the Promise Agent — an agent, human or machine, that must formally declare its commitments, agree to keep them, and self-regulate to ensure that it does. Self-regulation within the existing governance architecture is a condition of entry into the enterprise workforce. Not human-in-the-loop. Agent-in-the-loop. The question is not whether these practices work. The question is whether the broader market will adopt them — or learn the hard way why they exist. Link to the full paper below.

That's the answer I hear when I ask organizations what work they're delegating to AI agents. Don't worry about defining the work. Don't worry about characterizing its complexity. The AI will sort it out. The end by any means. This sounds like progress. It is the abdication of governance. And no amount of forensic auditing will put back accountability for what was not there to begin with. Start with the work This is why I've been drawing on Elliott Jaques' work on Requisite Organization. Jaques spent decades studying how accountability actually functions in organizations — not as policy or org charts, but as the structural relationship between a manager who delegates authority and the outcomes produced under that delegation. His first principle is deceptively simple: start with the work, not the technology. What is the work that needs to be done? At what level of complexity? Over what time horizon? Does the agent have the capability to do it? Most organizations deploying AI agents have not done this. They describe what the agent  does  — summarizes documents, answers queries, writes code — but not the complexity of what is being delegated. A document summary is defined task work: structured inputs, verifiable output. A regulatory landscape analysis with strategic recommendations is qualitatively different work: synthesis across multiple domains, balancing competing factors, over an extended time horizon. The governance requirements for each are completely different. Treating them the same — because the same technology performs both — is where governance fails. Not all AI agents require the same governance. An agent performing defined, verifiable tasks is not fundamentally different from any industrial automation — a robot that learned to pick up boxes has acquired a skill, not agency. Operational controls are sufficient. But an agent that plans, selects among alternatives, delegates to sub-agents, and evaluates outcomes against goals is exercising something that looks like discretion. If a human did that work, it would require managerial oversight, professional judgment, and organizational accountability. Governing it like automation is dangerously inadequate. The hard line Only humans can be held accountable. That is not a limitation of current law that might change. It is a foundational principle of governance. Accountability requires the capacity to bear responsibility, to make restitution, to be answerable. Machines do not have this capacity. They never will, regardless of how capable they become. This means that for every AI agent performing work that involves discretion, a human being must be managerially accountable for the outcome. Not ultimately accountable in some abstract, organizational sense. Directly accountable — because they delegated the authority under which the agent operates, and the agent's output is the product of their delegation. Jaques is precise about what this requires. The manager is accountable for having selected an agent with the capability to do the work. Accountable for having set the context — not just a system prompt, but the organizational understanding of why this work matters and what constraints apply. Accountable for having defined the authority boundaries — what the agent may do, what it may not, when it must escalate. Accountable for maintaining sufficient awareness of the agent's operation. And accountable for the outcome — every decision, every action, every consequence. The manager who says "I didn't review that particular agent decision" is not absolved. Jaques' response: you didn't need to review it if you set the boundaries correctly and maintained adequate monitoring. If you didn't, the failure is yours. Responsibility is not accountability This distinction matters and most frameworks blur it. Jaques separates them precisely. The agent is responsible for the work — for executing within its boundaries, to the standard expected. But the agent cannot be accountable, because accountability is a human relationship: answering to other humans for outcomes produced. The manager is accountable for the outcome. And the manager is responsible for their own managerial work — the work of selecting, context-setting, boundary-defining, and monitoring. That managerial work is not administrative overhead. It is the governance itself. If the manager did it well, the agent operates within appropriate boundaries and the outcomes are governed. If the manager didn't, no amount of policy, committee approval, or compliance documentation compensates. This applies equally to subordinates who use AI agents as tools. When a loan officer uses an AI agent to assess a loan application, the assessment is the loan officer's work product. Their name is on it. Their professional judgment backs it. They are responsible for the work — including their evaluation of the agent's output. Their manager is accountable for the loan officer's output, including the quality of how the loan officer uses AI tools. The manager's work now includes a dimension that didn't exist before: ensuring that subordinates who use AI tools are still performing work at the level their role requires, still exercising the judgment their position demands, and not silently delegating their professional responsibility to an instrument. The danger is not that the person is replaced. It is that the person remains but their judgment is subtracted — hollowed out by an agent that does the processing while the human becomes an accountability placeholder, a name attached to machine output. The doorman problem A consultant walks into a hotel and sees a doorman. He tells the manager: we can replace the doorman with an automatic door opener. Save $30,000 a year. The cost was reduced. So was the value. The doorman didn't just open doors. He recognized guests by name. He read situations — a visitor who didn't belong, a delivery that seemed wrong. He set the tone for the guest experience. He knew the neighborhood. None of this appeared in the cost-benefit analysis because none of it was the task being automated. This is what happens when organizations compress strata with AI. The consultant — now the AI vendor, the transformation advisor — looks at a middle manager and sees information processing: aggregates reports, coordinates teams, relays decisions. That function is automatable. The business case writes itself. But the manager wasn't just processing information. That was the visible task. What the manager actually did was exercise judgment at a level of complexity that included reading organizational dynamics, understanding why a policy exists and when it should bend, maintaining institutional knowledge, translating strategic intent into operational reality through dozens of contextual decisions that never appeared in any report. The AI replaces the information processing. The organization loses the judgment. And the loss is invisible — until the regulatory violation the manager would have flagged, until the risk the manager would have caught, until the strategic misalignment the manager would have detected because they understood both the strategy above and the operations below. Every AI business case is a doorman analysis. It quantifies the cost of the visible function. It cannot quantify the value of the judgment embedded in the same role. The decision to automate is made on incomplete information, every time, structurally. What accelerates the problem The entity you're integrating into your organization is not stable. It is changing faster than your governance can adapt. Foundation models update. Agent frameworks evolve. New capabilities appear — tool use, multi-agent coordination, persistent memory — that didn't exist when you wrote your governance plan. The agent you assessed in January is not the agent you're operating in June. And unlike any previous technology adoption, AI is subtractive, not additive. The internet added a channel. It didn't replace the people doing the work. AI agents replace human judgment, human decision-making, human labor. That's the value proposition. When the agent replaces the human, the institutional knowledge walks out with the person. The organization can't easily reverse the substitution because the human capability no longer exists to reverse to. Dan Davies, in  The UnAccountability Machine , describes the system this produces. An accountability sink — a system that produces outcomes nobody specifically chose and nobody can be held accountable for. Every process was followed. Every policy was in place. Every approval was obtained. And nobody answers for the result, because the accountability was never operationally present. It was procedural. Procedural accountability without operational governance is a filing system, not a governance system. The question The question for every organization deploying AI agents is not whether they have policies, risk assessments, and committee approvals. It is whether a specific human being has done the managerial work — defining the task, assessing capability, setting boundaries, maintaining awareness — that makes accountability meaningful rather than procedural.

The role defines the result. Here's something that doesn't get said often enough: most compliance programs aren't led. They're maintained. And there's a world of difference between the two. The Caretaker Problem In many organizations, the person responsible for compliance isn't leading it. They're caretaking it. Their mandate — spoken or unspoken — is to keep things the same. Don't rock the boat. Don't introduce risk. Make sure we pass the next audit. This isn't a character flaw. It's a role definition. Caretakers exist because the organization has decided that compliance is a holding pattern, not a strategic function. The person in the role is doing exactly what they were hired to do. And when someone comes along with a better way to do compliance — a more effective design, a smarter approach to obligations, a path to genuine operational compliance — the caretaker has no incentive to act on it. Improvement isn't in the job description. Stability is. You Might Trim Costs. You Won't Transform Anything. Can you get a caretaker to accept some changes? Sure. You might reduce costs. Eliminate redundant steps. Streamline a reporting workflow. These are changes that make the status quo cheaper or easier to maintain — and that's precisely why they're accepted. But try to introduce something that changes how compliance actually works — how obligations are owned, how promises are kept, how assurance is built into the operating model — and you'll hit a wall. Not because the idea is wrong, but because the role won't allow it. A caretaker's job is to preserve the system, not redesign it. Usually, it takes something going wrong — a regulatory failure, a material finding, a public incident — before the organization reconsiders whether "keeping things the same" was ever really a strategy at all. Leadership Changes Things. Continuously. Now contrast that with organizations where compliance is led, not just managed. Where the person in the compliance role sees their mandate as delivering outcomes, not preserving routines. Where realizing the benefits of compliance — not just avoiding penalties — is critical to mission success. In these organizations, change isn't a disruption. It's the operating model. Because when your job is to keep the organization between the lines, ahead of risk, and on mission, you can't afford to stand still. The regulatory environment moves. The business evolves. Technology shifts the playing field. Standing still is falling behind. Compliance leaders don't wait for something bad to happen. They design compliance programs that are adaptive by nature — programs built on clear obligations, owned promises, and the operational capability to deliver on both. They close the operability gap between what the program says on paper and what actually happens on the ground. The Question Worth Asking So here's the question: Does your organization have a compliance leader or a compliance caretaker? If it's a caretaker, stop trying to sell them on transformation. It won't work — not because the case isn't compelling, but because the role doesn't reward it. Your energy is better spent helping the organization understand that caretaking isn't leadership, and that compliance without leadership is just waiting for the next failure. If it's a leader — someone who sees compliance as a promise the organization keeps, not a box it checks — then the conversation is entirely different. That's where real design begins. That's where operational compliance becomes possible. That's where you start building something worth keeping.

Operational Compliance Landscape When viewed through an operational lens, governance is not just oversight, accountability structure, or decision authority. Governance is the act of regulating organizational effort towards organizational values. This differentiates traditional approaches — Compliance 1 — focused on procedural compliance. It defines Compliance 2 : Operational Compliance. When it comes to regulatory design, there are four primary types, each requiring its own approach. These cross the spectrum between ENDS and MEANS : ▸ Macro-Ends → Outcomes ▸ Micro-Ends → Targets ▸ Macro-Means → Practices ▸ Micro-Means → Rules These map to obligations associated with outcomes, performance targets, practice standards, and rules. Each type of obligation requires a different means of regulation: ▸ We use processes and procedures to adhere  to rules. ▸ We use management systems to conform  to standard practices. ▸ We use management programs to achieve  performance targets. ▸ We use governance to advance  outcome goals. These do not operate in isolation. Together, these functions regulate the organization — bridging the gap between the ENDS and the MEANS. ▸ Governance regulates Programs ( Measure of Effectiveness ) ▸ Programs regulate Systems ( Measure of Performance ) ▸ Systems regulate Processes ( Measure of Conformance ) ▸ Processes regulate Work ( Measure of Adherence ) This is more than an integrated stack. It is an integrative system of systems. It's what happens in between  that ensures all obligations are met. This is the Measure of Integrity (MoI). If you're not realizing the outcomes of your compliance, now you know why. You haven't made governance operational — and part of how you keep your organization between the lines, ahead of risk, and on mission.

Why Governance Starts with Obligations, Not Decisions "Requisite Authority — the decision-making capacity necessary for an obligation owner to fulfil their obligation." Scroll through any governance-focused discussion on LinkedIn right now and you'll find a recurring theme: organizations need decision authority at the point of execution. The argument is intuitive. Operations move fast. People closest to the action can't wait for three levels of sign-off. Therefore, push decision-making authority as close to the action as possible. It's a reasonable operational principle. But it isn't governance. It's operational efficiency using governance language. What Decision Authority Gets Right The focus on decision authority didn't come from nowhere. Decades of governance literature — COBIT, RACI, corporate governance theory, and more recently the AI governance frameworks from NIST and ISO — have centred on clarifying who can authorize what. This solves a real problem. In large organizations, ambiguity about decision rights creates paralysis, duplication, and unaccountable action. Clarifying those rights genuinely fixes things. But this literature solves a structural  problem, not a purposive  one. It answers "who decides" without first answering "in service of what commitment." In stable environments where the obligations are implicit and obvious — where everyone already knows what we're trying to achieve and just needs clear lanes — that works fine. The obligations are the water the fish don't notice. Where It Breaks Down Consider the range of obligations that any regulated organization must fulfil: safety obligations to workers and the public, security obligations to protect people and assets, sustainability commitments to communities and future generations, quality obligations to customers, ethical obligations to stakeholders, and legal obligations to regulators and the courts. Each of these represents a promise — sometimes mandated, sometimes voluntary — that someone in the organization owns and is accountable for keeping. Now ask: does the person who owns the safety obligation have the authority to stop a production run when conditions are unsafe? Does the person who owns the environmental commitment have the standing to redirect capital toward emission reductions? Does the person accountable for data privacy have the power to override a product decision that compromises it? In every case, the governance question isn't whether someone has decision authority in the abstract. It's whether the obligation owner has the specific  authority needed to keep their promise. When decision authority is allocated without reference to obligations, organizations end up with a familiar pathology: the safety manager has a title but not the authority to halt operations; the compliance officer can write reports but not block a non-conforming shipment; the sustainability lead can set targets but not direct spending. Decision authority exists, but it isn't matched to the obligations it's supposed to serve. The decisions are all authorized, documented, and reviewed — and the promise is still broken. From Decisions to Obligations The alternative isn't to abandon decision authority. It's to recognize that decision authority is derived , not foundational. The foundation is obligation ownership. An obligation owner isn't just someone with decision rights. They are someone who has made or inherited a promise — to a regulator, a customer, a stakeholder, the public — and who is accountable for its fulfilment across time. Decision authority is one capability they need. But they also need visibility into whether the obligation is being met, the capacity to intervene when it isn't, and the organizational standing to allocate resources toward keeping the promise. Decision-centric governance asks: "Who gets to decide what?" Obligation-centric governance asks: "Who owns the obligation, and what must be true for that obligation to be kept?" Decisions become instruments in service of obligations, not the primary object of governance. Requisite Authority Elliott Jaques' work on Requisite Organization offers a rigorous foundation for this shift. Jaques argued that organizational structure should be designed around the time horizon of accountability, not around functions or decision speed. Each level in his model exists because there is a qualitatively different kind of work to be done — work defined by the complexity and time span of the obligations attached to it. In Jaques' framework, decision authority isn't a freestanding thing you allocate for efficiency. It's a consequence of the accountability structure . You have decision authority because you are accountable for a certain scope of work over a certain time horizon, and you need that authority to fulfil that accountability. Strip away the accountability and the decision authority has no justification. This gives us a better term than "decision authority." What governance actually requires is requisite authority  — the decision-making capacity necessary for an obligation owner to fulfil their obligation. The word "requisite" does the critical work. It immediately implies that something else defines what's needed. Authority isn't self-justifying. It exists because an obligation demands it. The Diagnostic Question Requisite authority also gives us a diagnostic that decision authority alone cannot provide: Is the authority matched to the obligation? Too little authority relative to the obligation and you have an Operability Gap — the obligation owner made or inherited a promise but doesn't have the means to keep it. Too much authority without corresponding obligation ownership and you have unaccountable power — decisions being made by people or systems that bear no accountability for the commitments those decisions affect. Both are governance failures. But only the obligation-first framing reveals them as such. The decision-authority crowd can't ask "is this enough?" because they have no reference point for enough. Enough for what? For speed? For efficiency? Those are operational questions. "Requisite to the obligation" is a governance answer. What This Means for AI When an AI agent operates autonomously, it exercises decision authority without being situated in a requisite structure. There is no one above it carrying the longer-horizon obligation. No one tracing the link from the agent's micro-decisions back to the promise that justified those decisions in the first place. The consensus — "push decision authority to the point of execution" — is essentially flattening organizational accountability into a single layer. It optimizes for speed of action at the cost of accountability for commitments. Jaques would recognize this as the pathology he spent his career diagnosing: decisions being made at a level of complexity that the role wasn't designed to carry. The governance design question for AI isn't "where should decision authority live." It's "where do obligations live, who owns them, and what authority do those owners need to fulfil them?" That's a fundamentally different starting point, and it produces a fundamentally different governance architecture. The Bottom Line Decision authority is a necessary governance mechanism but an insufficient governance foundation. The foundation is obligation ownership. Decision authority is derived from it, allocated in service of it, and meaningless without it. The people arguing for decision authority at the point of execution aren't wrong. They're standing on a floor without knowing what's underneath it. Requisite authority — authority matched to the obligation it serves — is what's underneath.

Up until now, we created, stored, and moved data to where it was needed to drive our businesses. This was the world of Information Technology (IT) — and the foundation of Enterprise Architecture. That era is ending. AI has already absorbed virtually all the unstructured data available in the world. Large language models didn't just process that data — they internalized it. Now we need to build AI for the business — harnessing operational data, engaging the system of record, and deploying autonomous agents to do what could not be done before. Enterprise Architecture will no longer be designed to manage information. It will be designed to create and harness the power of artificial intelligence. This is the shift from Information Technology to Intelligence Technology — from IT to I²T. And it demands a new kind of compliance — not procedural, but operational. Real-time, adaptive, and capable of regulating AI at the speed AI operates. ⚡ Is your compliance ready for intelligence technology? Let's find out. Take our Compliance Capability Assessment and see where you stand before the shift leaves you behind.

As a lean compliance leader, your role is pivotal in upholding integrity and ensuring adherence to regulations and internal obligations while maximizing efficiency. To truly excel, it's essential to find purpose in your work and become a driving force for positive change within your organization. By embracing essential habits inspired by the principles of lean compliance, you can uncover your purpose and make a meaningful impact. 7 Habits of Successful Lean Compliance Leaders Habit 1: Be Proactive To find purpose, take initiative and embrace a proactive mindset. Seek out opportunities to improve compliance processes, eliminate waste, and drive efficiency. Embrace challenges and be a catalyst for positive change. By taking ownership and staying ahead of the curve, you become an influential leader in shaping lean compliance. Habit 2: Begin with the End in Mind Envision the impact you want to make as a lean compliance leader. Reflect on the broader purpose behind compliance and how it aligns with organizational goals. Keep your ultimate purpose in mind as you guide decisions and inspire others to work towards a shared vision of lean compliance excellence. Habit 3: Prioritize Value-Adding Activities Effective time management is key for lean compliance leaders seeking purpose. Focus on tasks that contribute value to the compliance process and eliminate non-value-added activities. Delegate responsibilities when necessary to free up time for strategic thinking and driving meaningful change. Habit 4: Foster Collaborative Partnerships Finding purpose as a lean compliance leader involves building strong relationships based on trust and collaboration. Seek partnerships with different departments, including operations and quality assurance, to streamline compliance efforts. By fostering collaborative relationships, you create a culture of shared purpose and maximize the effectiveness of lean compliance initiatives. Habit 5: Listen and Understand Listening is crucial for finding purpose in lean compliance. Take the time to understand the needs and perspectives of stakeholders, including employees, customers, and regulators. Empathize with their challenges and seek solutions that benefit everyone. By actively listening, you build trust, enhance communication, and unlock innovative solutions. Habit 6: Drive Continuous Improvement Embrace the lean principle of continuous improvement to discover purpose. Encourage a culture of learning and experimentation within your compliance team. Continuously seek ways to optimize processes, enhance efficiency, and reduce waste. By striving for continuous improvement, you demonstrate your commitment to purposeful lean compliance. Habit 7: Foster a Learning Culture As a lean compliance leader, prioritize personal and professional growth. Invest in your own development by seeking knowledge and staying updated on compliance trends. Encourage your team members to do the same, fostering a culture of learning. By continuously learning and growing, you can lead with confidence and inspire others to excel. Discovering Your Purpose Let me challenge you with this exercise to help you discover your purpose. Close your eyes and imagine that you have retired from your compliance leadership role. Imagine people at your retirement party giving speeches about you. What would you like to hear from them, your colleagues, customers, suppliers, and others you worked with over the years? Listen to what they are saying in your mind and write it down. Let that be your guide. Discovering purpose as a lean compliance leader is an ongoing journey that involves embracing essential habits inspired by the principles of lean compliance. By being proactive, envisioning the end goal, prioritizing value-added activities, fostering collaboration, listening and understanding, driving continuous improvement, and fostering a learning culture, you can unlock your purpose and become a transformative force within your organization. Embrace these habits, nurture your personal growth, and make a lasting difference as a purpose-driven lean compliance leader.

This is a summary of my presentation made recently on the topic of Lean Logistics which you can download below. Lean Logistics: Improving the Probability of Mission Success Using Lean Introduction I am Raimund Laqua, Founder, and Chief Compliance Engineer at Lean Compliance. Today, I'm excited to delve into the realm of Lean Logistics and the profound impact that LEAN has on managing uncertainty within the value chain. Join me as we explore the intricacies of risk, the power of Lean principles, and the integration of value chain analysis to improve the probability of mission success. Charting a Path Amid Uncertainty Throughout my career across a diverse number of North American industries, I've supported risk and compliance goals—ranging from safety and security to sustainability and regulatory compliance. However, the unifying thread across all these endeavours is the pervasive presence of uncertainty. In our journey today, I will explore how the principles of LEAN extend beyond efficiency and play a pivotal role in risk management, particularly in the context of Lean Logistics. A Mission to Confront Risk Let's start by acknowledging that risk is an inherent aspect of logistics. Whether transporting goods, managing inventory, or coordinating processes, the logistics landscape abounds with potential pitfalls. Recent global events, such as the COVID-19 pandemic and the Suez Canal disruption, have underscored the vulnerability of supply chains. This realization underscores the urgency of not just understanding risk but actively mitigating it. The Foundation: Value Chain Analysis Value Chain Analysis To grasp the interplay between risk, logistics, and LEAN, we must first comprehend the value chain. This conceptual framework, popularized by Michael Porter, dissects an organization's activities into primary and support functions, unveiling how each contributes to value creation. At its core, the value chain represents the journey from raw materials to the final product, with logistics serving as a critical link. The Quintessential Role of Logistics Logistics isn't just a function or a process; it's the heartbeat of the value chain. It orchestrates the intricate dance of transporting goods, managing inventory, and optimizing processes to ensure that products reach consumers efficiently. Within the value chain, logistics is tasked with achieving the "Seven Rights of Fulfillment": The Right Product To the Right Customer A the Right Time At the Right Place In the Right Condition In the Right Quantity At the Right Cost LEAN: Unveiling a Deeper Purpose While LEAN is renowned for its ability to streamline processes and eliminate waste, its value goes beyond efficiency. LEAN's core principles offer a comprehensive toolkit to tackle the most significant waste of all—risk. In the following sections, we'll explore how LEAN's principles align with the value chain analysis to empower organizations to thrive in the face of uncertainty. Risk, Uncertainty, and LEAN: A Complex Interplay Waste Is The Result Of Risk At the heart of our exploration is the intrinsic connection between risk, uncertainty, and LEAN. Uncertainty is the breeding ground for risk, and risk, in turn, is the catalyst for waste. When risk materializes, waste is generated—defects, excess processing, overproduction, waiting, inventory, transportation, motion, and underutilized talent. The challenge, therefore, lies in effectively contending with uncertainty to minimize waste. LEAN's Dual Approach: Margins and Risk Management LEAN offers a twofold strategy to address uncertainty: bolstering margins and risk management. By optimizing processes and reducing inefficiencies, LEAN enhances margins manifested as extra resources, time, and capacity. These act as a cushion against unforeseen challenges. Furthermore, integrating risk management tools, such as the bowtie analysis, empowers organizations to proactively buy down risk, ensuring the value chain's resilience. Navigating from Uncertainty to Certainty Improving the Probability of Mission Success Using Lean Our journey through the nexus of LEAN Logistics, value chain analysis, and risk management unveils a path to rise above the effects of uncertainty: Engage LEAN principles to amplify margins to create the opportunity to contend with uncertainty and risk Use margin to identify uncertainties using a total value chain analysis Use margin to evaluate and buy-down reducible risk using bow-tie analysis and risk management Use margin to cushion the effects of irreducible and residual risk. This creates a virtuous cycle of resiliency. The more you buy-down risk, the less waste is created, which creates greater margins to buy-down even more risk. Improving the Probability of Mission Success In conclusion, LEAN isn't just a means to improve efficiencies — it's a strategy that empowers organizations to navigate complexity and uncertainty with assurance. By combining value chain analysis, LEAN principles, and risk management tools, businesses can create a future that thrives amidst uncertainty. LEAN helps you improve the probability of success and decrease the probability of failure. Download the PowerPoint slides here:

In recent years many in the compliance industry have observed a shift in regulation from prescriptive to performance and outcome-based designs. What we are seeing is only the beginning of a trickle down effect emerging from regulatory reform over the last few decades across regulatory jurisdictions and across the world. During this time an increasing number of regulatory bodies have started to modernized the function of regulation, its processes and practices, and how regulation itself is regulated (meta-regulation). Most of this transformation has centered around the adoption of risk-based: strategies, operations, and tactics. There are many reasons for why this is happening. However, what is perhaps more important is that it is happening bringing with it continued changes for those who operate under regulation and to the role of compliance. In this article we will take a look at: Why is this happening? What is risk-based regulation? Regulatory models What might it mean to be a risk-based regulator? The regulation of regulators What this all means Why Is This Happening? Risk regulation is a relatively recent phenomenon and is an expression of what many social scientists call a "risk society." This is defined as a society in which there is an orientation to the future and a belief that we can control and manage risk. Some have said this is a shift from believing in fate to an "aspiration to control" future events. In many ways present-day changes to regulation can be seen as an outworking of this belief that risks can be anticipated and controlled. It is this notion that has invaded the public but also private sectors. The anticipation and control of risks affects the traditional notion of regulation. Dr. Malcolm K. Sparrow, a leading expert in the regulatory field, suggests that this change to risk-based approaches is a necessary manifestation when one considers the coverage of the problem space itself. Traditional regulation has focused on protecting public safety by means of delivering prescriptive obligations, compliance and enforcement functions primarily seen through a legal lens. This legal focus often results in many "paper violations" that are not necessarily harmful to the public. However, many of the risks that do affect the public are in the domain of legal and permissive behaviors which require a different approach than enforcement and strict compliance. The question that regulatory agencies are asking themselves is not which of these domains to focus on but rather how should resources be divided between them. They understand that to better protect (or create) public safety they will need to extend their focus to include illegal and harmful things. This shift requires that definitions exist for what "harm" means. Harms are similar to the notion of "hazards". They are complex, multi-dimensional problems that have the potential to negatively impact the public or the environment. The identification and solving of harms requires different skills, capacity, and organizational culture than what may exist within an agency and therefore will require the need for a transformational change. Perhaps, the most significant change in dealing with "harms" will be the introduction of risk management capabilities. What is Risk-based Regulation? At a high level, risk-based regulation, is a set of guiding principles to rationalize the regulatory process[3]. It does this by prioritizing regulatory actions based on an assessment of the risk to the achievement of its objectives. Risk-based regulation is more than the technical implementation of risk assessment and risk management techniques. These practices are used in conjunction with and part of the development of an agency's risk-based operating framework regarding its functions and processes. One of the appealing benefits of risk-based regulation is that is helps to address institutional risk; the threat of not achieving objectives by the regulatory agency. This is accomplished not only by an analysis of economic costs and benefits, but also the concepts of uncertainties and impacts [3]. This provides, among other things, an integrated decision making framework applicable to all levels of risk and organization. For a risk-based regime it is desirable to regulate all firms according to their particular risk, instead of simply prioritizing the supervision of the riskiest ones. Julia Black (London school of Economics), discusses and presents a remedy concerning the problems with ignoring the lowest risks and only focusing on high-risk firms. Black also makes the following reflections regarding risk-based regulation[3]: the danger of focusing more on diagnosis than cure; the importance of organizational culture in implementing risk based regulation; risk based frameworks can create risks; the danger of inappropriate reliance on firms’ internal controls is reduced but not removed in risk based approaches; (see models below) in making it clear what issues are not regulatory priorities, risk based regulation can have a potentially contentious political message. Changes driven by a "risk society" and modernization will continue to impact regulatory regimes. One of the ways is how risk itself is delegated between regulators and the organizations that are under regulation. Regulatory Models Malcolm Sparrow suggests that to better understand the way that risk-based regulation might manifest itself we can consider how three broad elements of risk management: risk identification, risk analysis and design, and risk implementation, might be delegated between regulators and the regulated industry: According to Sparrow, the traditional model for regulators is "Model 1." This is where government retains responsibility of risk identification, analyzing them, and developing (or selecting) an intervention design. This model produces prescriptive regulation typified by inspectors showing up with a tape measure to see how close you are to specified limits. In recognition of the diversity in the regulatory industry (along with levels of trust and assurance) regulators will allow firms greater flexibility (Model 2) in terms of the means by which risk is controlled. This creates "ends-based" instruments often referred to "performance-based" or "outcome-based" regulation. Large companies in highly technical industries may be delegated all three risk elements in the form of self-regulation (Model 3). This does not mean that the regulator has no responsibilities but may be in the form of "light-touch" regulation (this is different than right-touch regulation discussed below). Finally, Model 4, is a variant of the previous model where the companies under regulation are too small to afford or do not want to build out comprehensive risk-control systems on their own. They also do not want to be burdened with "going back" to "Model 1" and under the tutelage of prescriptive regulation. Instead, they form an industry association made up of representative members who will take on the self-regulation function. What Might It Mean To Be A "Risk-based Regulator?" A risk-based regulator will look different from those that focus only on enforcement and compliance. They will utilize the full set of regulatory instruments as needed to address the risks within their scope. Sparrow suggests that risk-based regulators will: Focus on the "Expert" rather than the "Legal" model of regulation Focus more on identifying and reducing "bads" (risk/harms), less on defining and promoting "goods" Practice "Regulatory Craftsmanship" (utilizing a broader range of tools, organized around specific tasks) Master organizational methods (less program-centric, more problem-centric) Fit different regulatory structures to different classes of risk (structural versatility) Use risk-mitigation as the foundation for partnerships Understand types of risk that pose special challenges These characteristics apply to all of Sparrow's regulatory models along with private sector risk management functions. The Regulation of Regulators In cases of self-regulation the idea of meta-regulation becomes necessary. There are two kinds of meta frameworks which often get confused: Light-touch regulation and Right-touch regulation. Light Touch This form of regulation refers to policy strategies that rely on private markets more than regulation. The light-touch narrative in a sense is the story about the Internet's regulatory journey. In many ways it is a policy of non-regulation. The primary role of government is to monitor the management of risk by the private sector and be prepared to adopt a different regulatory model if and when necessary. Right Touch Right-touch has its roots in the regulation of professional organizations. This form of regulation concerns itself with setting up the conditions by which self-regulatory bodies conduct themselves with respect to their responsibilities related to public safety or public interest. Right-touch regulation is in the formative stage and differs in its implementation. However, a common purpose of the right-touch approach is to strike the right balance between regulatory force and effective impact on risk. The UK Professional Standards Association (2015) defines six principles of the right-touch approach : Proportionate : regulators should only intervene when necessary. Remedies should be appropriate to the risk posed, and costs identified and minimized Consistent : rules and standards must be joined up and implemented fairly Targeted : regulation should be focused on the problem, and minimize side effects Transparent : regulators should be open, and keep regulations simple and user friendly Accountable : regulators must be able to justify decisions, and be subject to public scrutiny Agile : regulation must look forward and be able to adapt to anticipate change. The right-touch approach has been adopted by many professional associations and serves as an example for a "common-sense" manifesto for risk-based regulation across all sectors. What This All Means Regulatory bodies fundamentally exist to contend with public risk. Historically, the primary way that this has been done is by creating obligations, verification of compliance, and enforcement. However, this has now changed and will continue to do so as more regulatory agencies adopt risk-based approaches to their functions, processes, and specific problems they are responsible to address. This will drive continued change for those under regulation and specifically the role of compliance: The regulatory transformation currently underway has already created a change in how regulation and standards are designed and more change is expected. This will have continued impacts on organizations under regulation foremost of which will be for them to have clear objectives along with the capability to identify, analyze and implement effective risk controls. Regulatory agencies may offer the private sector unique insights into how a risk-based operating framework perform. As the sole purpose of a regulatory agency is to effect public risk they will have non-competing opportunities to develop risk management excellence. The concept of uncertainty and risk will continue to evolve and harmonize across risk disciplines. This will help to advance risk excellence to the benefit of both the public and private sector. Compliance will also evolve to become for those under regulation a " risk-based operational system " to meet obligations ex. Obligation Management System (OMS). Governance within both the public and private sector may benefit from further developments in meta-regulation with respect to internal policies, and voluntary obligations. References: [1] Dr. Malcolm K. Sparrow, "The Regulatory Craft – Controlling Risks, Solving Problems, and Managing Compliance" [2] Dr. Malcolm K. Sparrow, "The Character of Harms – Operational Challenges in the Control" [3] Julia Black, "The Development of Risk Based Regulation in the Financial Services: Canada, UK and Australia", 2004 [4] UK Professional Standards Association, "Right-touch Regulation", 2015