How to derive and manage AI controls from frameworks and assessments

An AI control is a measure you put in place to manage a risk from AI. You derive AI controls by holding the frameworks you govern against up to the assessments you run on each system, then give every control an owner and track whether it is applicable, implemented and tested. This guide explains what a control is in an AI governance programme, where controls come from and how you get them in place and keep them current. It is written for the person standing up the programme.

What a control is here

A control is a measure you put in place to manage a risk. In an AI governance programme, controls are the doing layer. Above them sit the frameworks you have adopted, which describe what good governance looks like. Below them sits the evidence that a control is working. A framework tells you what to aim for and an assessment tells you where you stand. A control is the thing you actually do about it.

An adopted framework is a statement of intent and a register of your AI systems is a catalogue, and neither of those on its own manages a risk. The controls are where the programme stops describing and starts working, so getting them in place is the step that turns “we have adopted a framework” into “we have governance running”.

Where controls come from

Controls are derived, not drawn up from a blank page. Two inputs generate them.

The first is the frameworks you enable. Each framework sets out what it expects of an organisation running AI. ISO/IEC 42001, the AI management system standard, sets out reference controls in Annex A, grouped by control objective, covering areas such as AI policies, internal organisation, resources, impact assessment, the AI system life cycle, data for AI systems, information for interested parties, use of AI systems and third-party relationships. The NIST AI Risk Management Framework is organised around four functions, Govern, Map, Measure and Manage, each broken into categories and subcategories that describe outcomes to work towards. National and sector frameworks add their own expectations on top.

The second is the assessments you run. An org-wide assessment looks at how your organisation governs AI as a whole. A per-system assessment looks at a single AI system, its purpose, its data, the decisions it affects and the risk it carries. The findings tell you which of a framework’s expectations actually apply to you and how far they reach.

Put together, the enabled frameworks say what is expected and the assessments say what is relevant. The controls are what you get when you hold those two against each other.

Building controls by hand versus having them derived

Built by hand, this is slow and expensive work. An analyst reads through Annex A of ISO/IEC 42001, the NIST subcategories and each framework you have adopted, works out which expectations apply to each of your systems, writes a control for each one and tracks the lot in a spreadsheet. A consultant does the same on a day rate. Either way you are paying for someone to translate frameworks and assessment findings into a control set, one line at a time, and to redo the translation every time a system or a framework changes.

Deriving the controls shortens that translation. The frameworks and the assessments are the input, and the controls are drafted from them, so you review a control set already written against your systems rather than building one from nothing. The time goes into judging what fits, which is the part that needs your people.

Derived controls are drafts for review, not impositions. You read what has been derived, you decide what fits and you own the result.

How to get controls in place

1. Enable the frameworks that apply to you. Choose the frameworks your organisation governs against, such as ISO/IEC 42001 or the NIST AI RMF, plus any national or sector frameworks that apply where you operate. The frameworks you enable set the expectations the controls are derived from.

2. Register your AI systems. Hold the AI systems in use in a register, versioned as systems change. A control set is only as complete as the register it is drawn against, so this is the foundation. The AI system register guide covers it.

3. Run the assessments. Assess how your organisation governs AI as a whole, for example with a maturity assessment, then run a per-system assessment for each registered system. The risk assessment guide sets out the method.

4. Review the derived controls. With the frameworks enabled and the assessments run, review the control set derived from both. Keep what fits and set aside what does not apply, recording why.

5. Assign an owner to each control. A control without an owner does not get done. Assign each control to the person accountable for it, so the programme has names against measures rather than a list on a page.

6. Track what is in place and keep it current. Track each control on three separate questions. Is it applicable, is it implemented, and has it been tested? As you register new systems, run new assessments or enable new frameworks, re-derive and version the set so the controls move with your real usage rather than drifting out of date.

Tracking what is in place

A control set is not a one-off deliverable. Systems change, new AI comes into use, assessments are re-run and frameworks are updated. The value of tracking controls in one place is that the state of the programme is legible at a glance. You can see which controls are in place, which are outstanding and who owns each one, without reconstructing it from a spreadsheet each quarter.

Keep implemented and tested apart. A control that has been put in place but never tested is a claim, and auditors working against ISO/IEC 42001 will ask for evidence that it operates. Some controls can be made executable on live traffic, such as redacting personal information from prompts or limiting which tools an agent may call. The guardrails guide covers that step.

How Aicura fits

In Aicura, the two inputs are literal. An administrator enables frameworks in Settings, and each risk assessment applies them to one system in the AI Register and drafts suggested controls for the risks it finds. Those land in Risks and Controls, where each control shows the risks it addresses and its applicable, implemented and tested status, with actions tracked beside them. Publishing the set saves it as a new version, and on Pro the set can be copied across to your governance, risk and compliance (GRC) platform. Which frameworks you can enable depends on your plan, set out on the pricing page.

Some controls go further. A guardrail rule can be marked as derived from a control, so the control that says personal information is redacted is the same thing that redacts it at the gateway. Whether a control is adequate, whether a system’s risk is acceptable and whether the programme is where it needs to be are calls for you and the accountable business owner. Aicura does not issue a compliance verdict, produce a score or stand in for professional advice.

In Australia

Australian organisations commonly govern against the National AI Centre’s Guidance for AI Adoption (AI6, October 2025), which superseded the Voluntary AI Safety Standard, and NSW Government agencies against the NSW AI Assessment Framework. Both overlap substantially with ISO/IEC 42001 and the NIST AI RMF, so one control set can be mapped to several frameworks rather than rebuilt for each. See the Guidance for AI Adoption and NSW AI Assessment Framework pages, and the framework crosswalk, which maps the main frameworks against each other.

Where the frameworks say it

This guide is downstream of the frameworks themselves. For the source expectations, go to the primary documents.

• ISO/IEC 42001:2023 (Information technology, Artificial intelligence, Management system) and its Annex A reference controls, published by the International Organization for Standardization.
• The NIST AI Risk Management Framework (AI RMF 1.0), published by the US National Institute of Standards and Technology.

A note on this page. This is general guidance on how to derive and manage AI controls, not legal, audit or certification advice. It does not tell you whether your organisation meets any framework or obligation. The frameworks are the authority on what they require, and the decision on whether your programme is adequate rests with your organisation and its advisers.