Clarifying Risk Management concepts: so you can clarify your architecture and processes

Something that keeps coming up in conversations about AI, security and governance is that everyone is using the same words, but not always to mean the same things.

One person says “compliance” and means security controls. Another says “governance” and means an approval committee. Someone else says “governance” and means policy-as-code in CI/CD. A regulator might say “risk management” and mean a whole organisational system of accountability, challenge, evidence and remediation. An engineer might hear “risk management” and think about threat models, evals, access control, logging and deployment gates. Quite often products list compliance or governance as one of their features, but its a very narrow view or only refers the products internal certification/testing.

None of these interpretations are completely wrong. That is what makes the conversation awkward. The problem is that they sit at different layers. Compliance is not the same thing as security. Governance is not the same thing as the software development lifecycle. Safety is not just a nicer word for security. Standards are not laws. Policies are not controls. Controls are not always technical. Policy-as-code is useful, but it is not a board. A dashboard is useful, but it is not oversight. An approval is useful, but it is not assurance.

This may sound like a semantic problem. In practice it becomes a delivery problem very quickly. If a customer, product team, security team, legal team and risk team all use the same words differently, then the organisation can end up with gaps, duplicated effort, theatre, or the worst version of compliance: a large amount of paperwork that proves very little about whether the system is actually under control.

The aim of this post is to try provide definitions and clarity so that we can have a clear conversation about all the things you need in place to scale, and how different tools and offerrings compliment or overlap.

The short version

The simplest version I have found is this:

1. External obligations: regulation, codes of practice, standards, contracts, customer promises
2. Governance: objectives, accountability, risk appetite, policy, decision rights
3. Risk management: what could go wrong, how bad, how likely, what we will do
4. Controls: preventive, detective, corrective, directive, evidential, compensating
5. Delivery and operations: SDLC, change, runtime, incidents, vendors, business process
6. Compliance and assurance: evidence, testing, reporting, independent challenge, audit

Or, in plainer language:

Governance decides what should happen. Risk management decides what could go wrong and what level of risk is acceptable. Controls make the decision operational. Compliance proves obligations are being met. Assurance checks whether the proof is reliable.

That distinction does a lot of work.It means security is not compliance. Security is one important risk domain. Safety is another. Privacy is another. Operational resilience is another. Conduct, fairness, customer harm, model performance, data quality, AML, KYC and vendor dependency may all matter depending on the use case. It also means governance is not just documents. If governance decisions never become controls, they remain aspirations. But the reverse is also true: if every governance problem is treated as a technical enforcement problem, we end up pretending that accountability can be delegated to code. Computers can’t be held to account.

Why this gets confusing

There are a few reasons this conversation becomes tangled.

The first is that modern frameworks overlap. NIST has a Cybersecurity Framework and an AI Risk Management Framework. ISO has standards for information security management and AI management systems. The EU AI Act brings a risk-based regulatory structure. Singapore’s IMDA has published a governance framework for agentic AI. Security teams have control baselines. Engineering teams have SDLC gates. Risk teams have risk registers. Compliance teams have obligation maps. Auditors have evidence requests. From a distance, these can all look like competing frameworks. In reality, many of them are doing different jobs.

NIST’s Cybersecurity Framework 2.0 is a good example. It organises cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond and Recover, and it is designed to be understandable by executives, managers and practitioners, not just security specialists.¹ The NIST AI Risk Management Framework is doing something different. It is trying to help organisations manage the risks of AI systems and promote trustworthy, responsible AI over time, using functions such as Govern, Map, Measure and Manage.² Those two frameworks are related, but they are not interchangeable. One is primarily about cybersecurity risk. The other is about AI risk more broadly. If we collapse both into “security compliance”, we lose important parts of the problem.

The second reason is that the same word can refer to different levels of abstraction. “Policy” can mean a broad management intent, such as “we do not use AI for material customer decisions without approval.” It can also mean an executable rule, such as “deny deployment if the agent has write access to a production system and no human approval gate.” Both are policies in a loose sense. Only one is policy-as-code.

The third reason is that technology people are used to attacking brittleness, make things executable and repeatable. That instinct is often good. It gave us infrastructure-as-code, policy-as-code, automated testing, CI/CD gates, runtime monitoring and machine-readable evidence. But it can also lead to an overcorrection: the belief that governance has not really happened unless it has been codified.

Governance includes judgement. It includes deciding who is accountable, what risk the organisation is willing to accept, which use cases are prohibited, which harms matter, who can approve exceptions, what evidence is good enough, and when a system should be paused or stopped. Some of that can be codified, some can’t, and some shouldn’t.

Start with obligations, not controls

A common mistake is to start the conversation at the control layer. The question becomes: do we have encryption, logging, vulnerability scanning, approvals, model evals, red teaming, access reviews, vendor checks and monitoring. Those are all useful things. But they are answers to a question that has not yet been asked.

The better starting point is: what obligations apply?

• Law and regulation: binding obligations, penalties, market access rules and reporting duties
• Supervisory guidance: regulator expectations, often principles-based and outcome-focused
• Codes of practice: practical guidance, sometimes voluntary, sometimes quasi-regulatory
• Standards: recognised structures for management systems, controls and assurance
• Contracts: customer-specific commitments, security schedules and audit rights
• Internal policy: the organisation’s own risk appetite, principles and operating rules

This distinction is useful because people often mix these up. A regulation is not the same as a standard. A standard is not the same as a code of practice. A code of practice is not the same as internal policy. A customer contractual promise may be more specific than all of them. The EU AI Act, for example, is a legal framework that uses a risk-based structure for AI systems.³ ISO/IEC 27001 is a standard for information security management systems.⁴ ISO/IEC 42001 is a standard for AI management systems.⁵ Singapore’s Model AI Governance Framework for Agentic AI is guidance for organisations deploying agents responsibly, with emphasis on human accountability and technical and non-technical measures.⁶ These are not the same type of thing. They should not be presented as if they are. A useful seperation is:

Regulation tells you what is required. Standards and codes help structure how you meet those requirements. Policies translate the organisation’s choices into internal rules. Controls make those rules operational. Evidence shows what actually happened.

Governance is the decision system

Governance is one of those words that can become almost meaningless because it is used everywhere. I find it more helpful to use a very plain definition:

Governance is the system by which an organisation makes, owns, escalates and reviews important decisions.

For technology and AI systems, governance answers questions like:

• What are we trying to achieve?
• Who owns the system?
• Who owns the risk?
• What obligations apply?
• What level of risk is acceptable?
• What uses are prohibited?
• What decisions require approval?
• Who can approve exceptions?
• What must be monitored?
• What evidence is required?
• Who gets to challenge the answer?
• What happens when reality disagrees with the plan?

This is why governance cannot be reduced to the SDLC. The SDLC is important, but it is only one control surface. Governance also includes runtime monitoring, incident response, vendor management, business ownership, customer communication, access review, periodic reassessment and independent assurance. For AI agents this is especially important. I wrote recently that agent risk management is about supervising delegated autonomy over time, not simply approving a model before release.⁷ That same point applies here. If the system can act, call tools, change state, trigger workflows, interact with customers or continue across multiple steps, then governance cannot stop at pre-deployment approval.

The governance question becomes: what authority did we grant, who granted it, how do we know the system is staying inside that authority, and what happens when it does not? That is not a purely technical question. It is an organisational question with technical consequences.

Risk management is the discipline of asking what could go wrong

Risk management is often made to sound more complicated than it needs to be. At its core, it asks a few practical questions:

• What are we doing?
• What could go wrong?
• Who or what could be harmed?
• How likely is it?
• How severe would it be?
• What can we do about it?
• What risk remains?
• Who is allowed to accept that remaining risk?
• How will we know if the risk changes?

Operational risk is a useful anchor because it is so broad. In the Basel language, operational risk is the risk of loss from inadequate or failed internal processes, people and systems, or from external events.⁸ In plain English, it is the risk that the business does not operate the way it is supposed to. That matters for AI and agentic systems because many failures will not look like exotic AI failures. They will look like operational failures.

An agent sends the wrong message. A workflow closes the wrong case. A tool call updates the wrong record. A retrieval system pulls stale policy. A model output is treated as ground truth by another system. A human reviewer rubber stamps an automated recommendation. A vendor changes a model or platform behaviour. A permission is broader than anyone realised. A dashboard exists, but no one has authority to act on it. That is not just “AI risk”. It is operational risk, technology risk, data risk, security risk, conduct risk, vendor risk and change risk tangled together. This broader set of risk domains is in scope because Agents are being used in a range of risk domains and the systems are no longer deterministic so that compliance outcome isn’t pushed to the process or specification, its a core part of the system with agency.

Controls are where governance becomes real

A control is simply something that helps manage risk. That sounds boring, but it is a useful definition because it avoids making controls synonymous with security tools. Some controls are technical. Some are procedural. Some are organisational. Some are manual. Some are automated. Some prevent bad things from happening. Some detect them. Some correct them. Some simply create evidence.

A simple control taxonomy looks like this:

The evidential category is particularly important for compliance. A control that operates but leaves no evidence may still reduce risk, but it is hard to prove. A control that creates evidence but does not reduce risk may satisfy a checklist while doing very little useful work. That is the heart of the compliance problem. Good compliance evidence should not be theatre. It should be a trace of real control operation.

For example, a policy might say:

Agents must not perform irreversible customer-impacting actions without human approval.

That can become several different controls:

• Governance control: a defined approval authority for exceptions
• Design control: classification of agent actions as reversible or irreversible
• Technical control: workflow gate before irreversible tool calls
• Runtime control: logging of the proposed action, approval and execution
• Detective control: monitoring for attempts to bypass approval
• Corrective control: ability to pause the agent or revoke tool access
• Evidential control: retained trace showing who approved what, when and why

This is where technical approaches are extremely useful. Policy-as-code, infrastructure-as-code checks, deployment gates, access-control rules, runtime monitoring and automated evidence capture can all make governance more concrete. Open Policy Agent, for example, is designed for policy evaluation and uses Rego to reason over structured data such as API requests, infrastructure-as-code files and configuration data.⁹ Note: The technical control do not make those decisions, they implemented part of them. That is the correct relationship between the concepts.

Compliance is a claim, not a control domain

Compliance is often spoken about as if it were a department, a control set or a synonym for security. I think that creates confusion. Compliance is better understood as an evidence-backed claim:

We have identified the obligations that apply to us, translated them into requirements, implemented controls, collected evidence and can show that we are meeting them or managing exceptions.

Security may be part of that claim. Privacy may be part of it. Safety may be part of it. Accessibility, fairness, human oversight, record keeping, customer disclosure, vendor management, audit rights, resilience and incident reporting may also be part of it. A system can be secure and non-compliant. For example, it may have strong access control and encryption but lack required transparency, documentation, human oversight, retention controls or audit evidence. A system can also look compliant and still be insecure. It may have policies, sign-offs and screenshots, while the actual runtime permissions are too broad or the monitoring is ineffective.

This is why the phrase “secure and compliant” is useful only if we remember that the two words are not the same. These concepts overlap, but they are not interchangeable.

The three lines are about ownership and challenge

The three lines model is a useful way to explain accountability:

• Board or governing body: sets objectives, risk appetite and oversight expectations
• Line 1 — business, product, engineering and operations: owns the system, owns the risk and operates the controls
• Line 2 — risk, compliance, legal, security, privacy and model risk: sets standards, supports, monitors, challenges and reports
• Line 3 — internal audit: provides independent assurance

The Institute of Internal Auditors describes the first line as most directly aligned with delivery, the second line as providing expertise, support, monitoring and challenge, and the third line as independent assurance.¹⁰

The key point is that the second line does not magically own the risk because it owns the framework. The first line still owns the system and the risk created by the system. The second line helps set expectations and challenge whether those expectations are met. The third line checks whether the governance, risk management and controls are actually working.

This matters a lot for AI. It is tempting for business teams to say “the AI governance team approved it” or for technology teams to say “legal signed off” or for risk teams to say “the product team owns it”. Each statement may contain some truth, but none of them is enough.

A good governance model should make ownership visible. Who owns the agent and who owns the things it depends on?

Four common traps

There are four traps I see repeatedly.

1. “Compliance is just security”

Security is one risk domain. It is very important, but it is not the whole compliance problem. For AI systems, the gap is obvious. A system may need cybersecurity controls, but it may also need human oversight, transparency, documentation, testing, logging, bias management, data governance, user communication, incident processes and vendor due diligence. Some of those are security controls. Many are not. Treating compliance as security narrows the problem too early.

Its also important to note that many product/business obligations are now being delegated to agents. As engineers we are used to thinking about NIST, but now we also need to think about AML (Anti-Money Laundering) and customer protection rules. These often attract different control types as their logic moves into the process layer or data plane and are no longer within the scope of any control plane we may have.

2. “Governance can be codified”

This is only Partly true. A lot of governance should become executable where possible. Access rules, deployment thresholds, environment restrictions, approval requirements, prohibited data flows and logging requirements are all good candidates for automation. But governance also includes judgement, accountability and risk acceptance. A policy engine can deny a deployment. It cannot decide the organisation’s risk appetite. Terraform can help enforce infrastructure rules. It cannot decide whether a use case is appropriate. A workflow tool can route an exception. It cannot make the board accountable.

So the better formulation is:

Governance can be partially automated, but accountability cannot be delegated to code or an agent.

3. “No parts of governance can be codified”

If governance never becomes executable, it remains too abstract. The organisation may have beautiful principles and weak control. This is common in AI governance: high-level principles about fairness, transparency, safety and accountability, but little connection to what teams must do before deployment or what the runtime system must prove after deployment.

The useful distinction is:

• Judgement layer: objectives, risk appetite, accountability, exceptions, residual-risk acceptance
• Codified layer: access rules, policy checks, deployment gates, runtime constraints, evidence capture

Both layers matter.

4. “Governance is all in the SDLC”

The SDLC is only one part of the system. For many traditional software systems, a lot of control effort is concentrated before release. That still matters. But AI systems, and especially agents, keep changing after release because the environment changes, users change, data changes, vendors change, models change and the system may behave differently in real workflows than it did in testing. For agents, runtime is not an afterthought. It is part of governance. This also has broader implications for operating models, I will share some thoughts on that topic in a future post.

Conclusion

The unit of control is the socio-technical system doing work: model, prompts, data, tools, APIs, permissions, workflow, humans, vendors, monitoring, escalation paths and business process. In order to make a socio-technical system safe over time you need all the layers of governance, compliance, risk management and assurance. These work together and its important to understand them all and how they fit together.

References

Attribution

This post was prepared in conjunction with GPT-5.5 Pro. The concepts and writing are my own.