A security leader reading the AI frameworks for the first time usually reaches the same two conclusions in order: this is enormous, and most of it looks familiar. The second conclusion is the accurate one. Access control, change management, logging, vendor assessment and incident response appear in every AI framework because they were already the right controls, and a firm running ISO 27001 or a mature SOC 2 programme has most of them operating. What is genuinely new is narrow, and identifying that narrow part is the whole job. Treating an AI framework as a fresh programme is how a small team burns a year rebuilding what it already had.
Overview: five things a CISO needs from an AI framework
- Most controls already exist under other names. Map first, and the remaining work shrinks to something a small team can actually deliver.
- Only one of the main frameworks is certifiable. That matters when a customer asks for evidence rather than an assertion.
- The genuinely new obligations are few. Impact assessment on affected people, model and data provenance, and monitoring after deployment are the three that have no equivalent in a traditional security programme.
- Regulatory pressure is tiered by use, not by technology. Obligations attach to what a system decides about people, so an internal drafting assistant and a hiring screen are not the same problem.
- Frameworks are complementary rather than competing. They differ in intent, and picking one does not mean rejecting the others.
This is written for security and IT leaders at firms between 50 and 500 people who already run a recognised security programme and have been asked what the AI equivalent looks like. If the underlying programme is what needs building, our piece on building a compliance framework comes first.
Why the AI frameworks overlap your existing programme
Control mapping to ISO 27001 or to whatever framework you already run is the first exercise, not a later refinement, because it determines how much of the AI work is genuinely new. Skipping it produces a parallel programme with duplicated controls and two sets of evidence for the same thing.
Controls that map almost one to one
Access management, secure development, supplier assessment, logging, incident response and change control appear in the AI frameworks in close to their familiar form. A firm with these operating has substantial coverage on day one and should claim it rather than rebuild it.
The objection worth taking seriously is that mapping can be lazy, marking a control as covered when the AI context changes what it means. Supplier assessment is the clearest case: assessing a model provider involves questions about training data and model provenance that a standard supplier questionnaire does not ask. Map the control, then check the AI specific questions are actually in it.
The three obligations with no existing equivalent
Impact assessment on affected individuals is the first. Traditional risk assessment asks what happens to the business, and the AI frameworks ask what happens to the person the system makes a decision about. That is a different question with a different method.
Model and data provenance is the second. Knowing what a model was trained on, what version is running, and what changed between versions has no counterpart in a conventional asset inventory. Post deployment monitoring is the third, because a model can degrade without any change on your side, which is unlike almost every other system you operate.
Those three are where a small team should spend its effort. Everything else is mapping work. Our AI risk assessment engagements are structured this way for exactly that reason.
Where mapping goes wrong
The common failure is mapping at the framework level rather than the control level, producing a document saying the programme is broadly aligned and nothing an assessor or customer can test. Map individual controls to individual requirements, note the ones that are partially covered, and be specific about what partial means.
The frameworks worth knowing, and what each is for
The NIST AI RMF functions, the ISO management system standard and the regional regulations serve three different purposes, and a CISO generally ends up using all three in different places rather than choosing between them.
NIST AI Risk Management Framework as the organising structure
The framework organises work into four functions, which are govern, map, measure and manage. Govern establishes policy and accountability, map builds context and intended purpose, measure analyses the identified risks, and manage prioritises and acts.
Its strength is that it is voluntary, free, well written and structured the way security teams already think. Its weakness is the same voluntariness: there is no certification, so it cannot be handed to a customer as proof. The Generative AI Profile extends it to the risks specific to generative systems, which is the part most firms need first.
ISO 42001 where you need something certifiable
The ISO management system standard for AI is certifiable, which is the difference that matters commercially. When a customer or an insurer asks for evidence of AI governance, a certificate answers the question and an internal framework alignment does not.
The cost is the cost of any management system: documented scope, defined roles, internal audit, management review, and an external certification body. For a firm already certified to ISO 27001 the incremental work is manageable because the management system machinery exists. For a firm with no certification at all, it is a substantial undertaking. The same governance-as-infrastructure argument appears in our piece on CMMC as governance rather than IT security.
Regional regulation as the obligation floor
Regulatory regimes classify systems by use and attach obligations accordingly, with the heaviest requirements falling on systems affecting employment, credit, education, essential services and safety. A drafting assistant and a hiring screen sit at opposite ends of that scale.
The practical implication is that a use case register is the prerequisite artifact again, because obligations attach per use rather than per organisation. Firms that inventory tools rather than uses cannot determine which obligations apply to them. That register overlaps directly with the data governance work described in our piece on data governance against data security.
Security specific guidance for the threat model
Frameworks aimed at securing AI systems rather than governing their use cover a different threat model: prompt injection, training data poisoning, model extraction and supply chain compromise of model artifacts. These belong in the security programme rather than the governance one.
A CISO needs both, and conflating them produces a governance document that does not address attacks and a threat model that does not address fairness or transparency. Keep them separate and cross reference. Our IT risk assessment work treats them as two workstreams that share an inventory.
Running the programme without new headcount
An AI risk programme at this size succeeds or fails on whether it fits inside the cadence a small team already runs, which means attaching it to existing meetings and existing reviews rather than creating new ones.
Tiering so effort lands where consequence does
Assess use cases at a depth proportional to what they decide. A system affecting a person’s access to a service, employment or credit gets a full impact assessment. An internal summarisation tool gets a register entry and a retention decision.
The failure mode is tier inflation downward, where everything ends up low risk and the programme becomes decorative. Define the tiers before classifying anything, and have somebody other than the use case owner confirm each tier. The same discipline that keeps a HIPAA risk assessment honest applies here.
Monitoring that survives contact with a busy quarter
Post deployment monitoring is the obligation most likely to quietly stop happening, because nothing breaks when it does. Attach it to something that already occurs: a quarterly review, a release checklist, a standing agenda item with a named owner.
Monitoring does not have to be elaborate to be real. A sampled review of outputs, a check that the model version has not moved, and a look at whatever complaint or escalation channel exists will catch most of what matters at this scale. The evidence discipline behind it is the same one our cyber security audit and compliance practices apply everywhere else.
Frequently Asked Questions
Which AI risk framework should a mid sized company adopt?
Use the NIST framework as the organising structure because it is free, well written and familiar in shape. Add ISO 42001 certification only when a customer or insurer needs evidence rather than an assertion, since the certification carries real cost.
Is ISO 42001 worth certifying against?
It is worth it when someone external is asking for proof, and it is substantially easier for a firm that already holds ISO 27001 because the management system machinery is in place. Without an existing certification it is a large undertaking for an internal benefit.
How much of an AI framework is already covered by ISO 27001 or SOC 2?
A large share. Access control, change management, logging, supplier assessment and incident response map closely. The genuinely new obligations are impact assessment on affected individuals, model and data provenance, and post deployment monitoring.
Do AI risk frameworks apply to companies that only use vendor AI tools?
Yes, and the obligations attach to how you use the system rather than to whether you built it. Using a vendor model to make decisions about people carries the assessment and monitoring obligations regardless of who trained the model.
What is the difference between AI governance and AI security?
Governance covers whether a system should be used, what it decides about people, and how that is documented and monitored. Security covers attacks against the system, including prompt injection, data poisoning and model extraction. Both are needed and they are separate workstreams.
Who is behind this guidance
Mindcore builds and runs security programmes for small and mid sized firms across healthcare, legal, financial services and manufacturing, which means most of our AI framework work begins as a mapping exercise against a programme the client already operates. The approach above comes from engagements where the useful output was a short list of genuinely new obligations rather than a new framework document.
Matt Rosenthal, our chief executive, focuses on how firms without large security teams meet obligations designed with larger organisations in mind. His position on the AI frameworks is that the overlap with existing controls is the good news, and that a team which fails to claim it ends up doing the same work twice.
Map what you have before you adopt anything
The sequence that keeps this proportionate is short. Map your existing controls against the AI framework at control level, not framework level, and be honest about partial coverage. Isolate the three obligations with no existing equivalent and build only those. Inventory use cases rather than tools, because obligations attach per use. Tier by what a system decides about people, and attach monitoring to a cadence you already run. Pursue certification only when somebody outside the business needs the evidence.
If you want help running that mapping against your current programme, book a free strategy call and we will work out how much of this you are already doing.
