G.U.A.R.D.: Five Steps to Organize AI Security in Your Organization

G

Govern

Before anything else, the organization needs a way to manage AI and not just secure it. Govern is where that management process gets built: knowing where AI is actually used, defining who’s responsible for what, setting policies for how AI is built, bought, and used, running impact assessments, arranging compliance, and organizing education so AI-security know-how reaches beyond the security team. Security risk is one thread here, not the whole of it.

Ownership is where it starts. Not “IT owns security, so AI is IT’s problem,” but a clear accountability structure with a named owner, an escalation path, and a mandate covering the full lifecycle: procurement, development, deployment, and retirement. But ownership alone is hollow — a decision-owner with no policies, no impact assessments, and no compliance map has authority but nothing to apply it to.

Most organizations fail here first. AI gets spun up inside product or data science teams, security is looped in after a model is already live, and governance becomes an afterthought. Govern has to come before understanding, because it sets where AI lives, who owns it, and what rules apply — without that, “understanding” just produces reports nobody is positioned to act on. OWASP’s AI Program guidance offers a quickstart if you’re building this from scratch.

U

Understand

Governance told you where your AI lives. Understand is where you work out how to protect it. Take each system from the inventory and run it through the risk-analysis decision tree to see which threats actually apply.

For example, a model influencing credit decisions and a chatbot answering FAQs don’t carry the same risks. The risk-tree is what tells them apart. Most of those threats map to familiar, conventional security countermeasures; only if you’re training your own model does a further set of AI-specific threats come into play.

But identifying threats and controls is only half of it. The real test of this step is ability: your engineers and security professionals don’t just have to know the relevant controls — they have to be able to implement them. That’s the line between Understand and Govern. Govern is oversight; Understand is hands-on capability.

So work through the threat sections, the matching process and technical controls, and the references behind them until your people can actually build the protection, not just name it. And as you map those controls, separate the ones you own from the ones your supplier owns — folding the latter into supply-chain management, and turning to the ready-made-models guidance if you don’t train your own.

A

Adapt

Adapt extends your existing security program to cover AI rather than rebuilding it. The controls you already run like access control, data classification, incident response, vendor risk, and mostly still apply; the work is mapping each against AI-specific risks and closing the gaps. Your incident response plan gains a runbook for model-behavior anomalies; your vendor questionnaire asks about training-data provenance and folds model, data, and hosting into supply-chain management; your data classification scheme now covers model weights and training sets.

But Adapt is about practices as much as controls, and this is where most programs fall short: adapt your threat modeling to be AI-specific and cross-team, turning the risk assessment behind Understand into a repeatable capability rather than a one-off; adapt your testing to include AI-specific security testing — adversarial robustness, prompt injection, red-teaming — built into your development cycle, not saved as audit evidence; and if you build AI systems at all, extend your secure development program to cover AI engineering.

One adaptation is about regulation. New rules like the EU AI Act work differently from older standards like ISO 27001: instead of just checking that you have the right controls in place, they ask you to prove the risk was brought down to an acceptable level. That means your security management system needs to capture the evidence — risk assessments, decisions, and proof that mitigations worked. Adapt’s whole instinct is to reuse what you already have rather than build from scratch, since that’s faster and leaves fewer gaps. But reusing your existing machinery doesn’t mean skipping the new practices, like threat modeling and AI security testing, that the machinery now must run.

R

Reduce

Only now, once you know what you’re governing and what you’re working with, do you reach Reduce — and Reduce is narrower than it sounds. It isn’t the bucket where every control gets implemented; it’s the layer that assumes the AI will eventually be wrong or manipulated and works to limit what that failure can touch. Reduce is Murphy’s law applied to AI: minimize or obfuscate the sensitive data a system can reach so a leak exposes less, manage privileges so a manipulated model can’t act beyond its remit, and put guardrails and human oversight between the model’s output and anything consequential.

The goal isn’t a system that never fails but it’s a system whose failures stay small.

D

Demonstrate

Most frameworks skip this step, but it’s the one regulators, clients, and your board care about most. Having controls isn’t the same as proving they reduce risk — and that distinction is the whole of Demonstrate. Outcome-based regulation like the EU AI Act doesn’t ask whether a control ran; it asks whether the risk it exists to address was actually brought down to an acceptable level. So the evidence that counts isn’t “our access policy was enforced on this date” — it’s “here is the risk this system posed, here is what we did about it, and here is proof the exposure is now within the bounds we accept.”

You build that proof through transparency, testing, documentation, and communication — and it’s where the assurance processes you set up in Adapt pay off. Demonstrate means building the evidence trail as you go: risk assessments, test results showing a threat is contained, records of unwanted behavior being caught and limited, incident-drill outcomes. A mitigation you can’t evidence looks, from the outside, no different from one that was never there.