Skip to content
Chapter 07 · 11 min

Governance & assurance

Technical defences keep the system safe. Governance proves it — to your customers, your auditors, and your regulators — and makes the safety repeatable as the team and the system change. For a business selling to North American enterprises, this layer is often what closes the deal. This chapter ties the technical to the organisational.

“Locks keep honest people honest. Governance is the paperwork that proves you fitted the locks.”

Threat-model your AI system on purpose

Before the frameworks, the foundational practice: sit down and reason about your specific system. What are the assets (data, capabilities, reputation)? Who might attack it and why? Where are the trust boundaries? What's the worst thing a compromised model could do? Classic threat-modelling methods like STRIDE adapt cleanly to AI — you're just adding the model's failure modes to the list.

The output is a prioritised list of risks tied to your architecture, which tells you where to spend the defences from the last chapter. A generic checklist tells you what's possible; a threat model tells you what matters here. Do the threat model.

The frameworks worth knowing

You don't need to memorise standards, but you should know the map, because customers and auditors will reference them:

  • NIST AI Risk Management Framework — a voluntary US framework for identifying and managing AI risks across a system's lifecycle. The common reference point for North American AI governance.
  • OWASP Top 10 for LLM Applications — the practitioner's list of the most critical LLM-app vulnerabilities; maps directly to chapters 2–5.
  • MITRE ATLAS — a knowledge base of real-world adversarial tactics against AI systems, modelled on the ATT&CK framework.
  • SOC 2 — not AI-specific, but the trust report North American enterprises ask for; your AI features fall inside its scope.
  • Sector and regional rules — HIPAA, GLBA, CCPA/CPRA, PIPEDA, and the EU AI Act if you touch that market.

Assurance: proving it to someone else

Assurance is the evidence that your security exists and works. For an enterprise buyer, "trust us" is not an answer; they need to see it. That means policies (written rules for how AI is built and used), documented controls (what you do and why), audit trails (the logs and traces from chapter 6, serving as evidence), and a track record of testing (your red-team findings and their fixes).

This is where SDEN's positioning meets the technical work: SOC 2, CCPA, and PIPEDA alignment aren't bureaucratic overhead bolted on at the end — they're the natural output of having done the engineering well and written it down. A system built with the controls in this course produces the evidence almost as a byproduct. A system that wasn't can't fake it.

Governance as a living process

Governance fails when it's a document written once and filed. AI systems change weekly — new prompts, new models, new tools, new data — and each change can alter the risk picture. Governance has to be a process that keeps pace: a change-review step that asks "does this affect our risk or controls," periodic re-assessment, and clear ownership so security isn't everyone's job and therefore no one's.

  • Ownership — a named person or team accountable for AI security, not a diffuse "we all care about it."
  • Change review — model, prompt, tool, and data changes pass a lightweight risk check, not just a quality eval.
  • Periodic re-assessment — threat model and controls revisited on a schedule, not only after an incident.
  • Incident response — a rehearsed plan for when something gets through, including who decides to pull the feature.
  • Vendor management — the provider and tool trust decisions from chapter 5, tracked and reviewed.

Where to go from here

You now have the full arc: the new attack surface, the threats that live on it, the layered defences, and the governance that proves and sustains them. The throughline is simple — you cannot trust the model, so you constrain it, watch it, and document it. Pair this with the Building with AI course for the engineering, and SDEN's security work is exactly this discipline applied to real systems under real obligations.

In one line each

  • Threat-model your specific system (STRIDE plus LLM failure modes) — a generic checklist says what's possible; a threat model says what matters here.
  • Know the framework map — NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS, SOC 2 — as shared structure, not as a substitute for real controls.
  • Assurance is proving it with policies, documented controls, audit trails, and a testing track record — the byproduct of doing the engineering well.
  • Governance must be a living process: clear ownership, change review, periodic re-assessment, and a rehearsed incident plan.

Where to go next

Governance & assurance · AI courses · SDEN