Domain 4 of 4 · Chapter 2 of 3

AI Lifecycle GRC Integration

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing CompTIA SecAI+ premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • Where governance attaches to the AI lifecycle
  • Who owns what before any artefact exists
  • The AI inventory and use-case register
  • Assessing AI risk and recording the decision
  • TEVV and the gates it feeds
  • Third-party models, data and suppliers
  • Re-approval when the model or its inputs change
  • Post-deployment duties, from monitoring to retirement
  • Internal audit, management review and evidence
  • Exam-pattern recognition

What each AI RMF function contributes to the governance loop

AspectGOVERNMAPMEASUREMANAGE
Question it answersWho decides, under which policy, with what authority?What is this system, where is it used, and what could go wrong?How good is it, against which criteria, judged by whom?What do we do about the risks that were found?
When it runsContinuously, around the other threeAt intake, and again whenever the system or its context changesBefore release and continuously in productionAfter MAP and MEASURE, and on every incident
Artefact it producesPolicy, accountability chart, risk tolerance statement, inventory mechanismRegister entry: intended purpose, context, affected people, impact and likelihoodTest sets, metrics, evaluation records, monitoring outputTreatment decision, owner sign-off, residual-risk record, incident and retirement actions
Who typically owns itSenior leadership and the AI governance committeeThe model owner, with domain, privacy and legal inputEvaluators who did not build the systemThe named risk owner
What breaks if you skip itDecisions carry no authority and no consistent lineUnlisted systems and unknown use cases, which is shadow AIApproval rests on opinion instead of measured evidenceFindings pile up with nobody accountable for closing them

Decision tree

In the use-case register?noRegister it before anything elseintake gate: classify, name model and risk ownersyesAll data sources approved?noApprove every data source firstdata gate: source, licence, sensitivityyesPassed evaluation thresholds?noEvaluate before releaserelease gate: thresholds set before the testyesBehaviour or scope changed?yesRe-approve the changechange gate: re-run affected MAP and MEASUREnoStill needed, inside tolerance?noRetire it deliberatelyretirement gate: deactivate, decommission, retain recordsyesOperate and watchmonitor indicators, review on the recorded date
Cheat sheet

Cheat sheet

  • Governance is a loop you re-enter, not an approval you file
  • Build the AI inventory before the policy, because policy governs only what you can see
  • Shadow AI includes approved tools that gained AI features in an update
  • One model serving three business processes is three use-case register entries
  • The AI RMF helps you prioritise risk but refuses to set your tolerance
  • Appetite is the board's broad line, tolerance is the specific one you measure against
  • Of the four risk treatments, only avoidance drives residual risk to zero
  • Accepted risk counts only when it is signed, owned and dated
  • Residual risk is documented outward, to downstream acquirers and end users
  • A KPI grades a control, a KRI warns that the risk is climbing
  • TEVV runs at every lifecycle stage, not as a phase before launch
  • The people producing the evaluation evidence are not the people being judged
  • Set the pass thresholds before running the evaluation, not after reading it
  • Document the risks you did not measure, not only the ones you did
  • A supplier questionnaire is self-attestation, never independent assurance
  • A hosted model can change version without your deployment changing at all
  • A new user population reopens the approval even with no technical change
  • Serious-incident reporting runs on three clocks: 15 days, 2 days, 10 days
  • Retire a model through a defined process, because deleting it can raise risk
  • Someone must be both able and permitted to switch the system off
  • Separate the person accountable for the system from the person who signs for its risk
  • An AI governance committee authorises, it never owns a risk
  • Writing the AI incident procedure is due care, exercising it is due diligence
  • An assessor reads records; the policy is where a programme starts, not what proves it runs

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) Whitepaper
  2. AI RMF Core: the GOVERN, MAP, MEASURE and MANAGE functions with their categories and subcategories Whitepaper
  3. NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0), full text Whitepaper
  4. EU AI Act Article 9: Risk management system
  5. EU AI Act Article 72: Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems
  6. EU AI Act Article 17: Quality management system
  7. NIST AI RMF Playbook: GOVERN function suggested actions and documentation Whitepaper
  8. LLM AI Cybersecurity and Governance Checklist, version 1.1 Whitepaper
  9. NIST IR 8286Ar1: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management (supersedes IR 8286A) Whitepaper
  10. EU AI Act Article 73: Reporting of serious incidents
  11. ISO/IEC 42001:2023, Information technology - Artificial intelligence - Management system Whitepaper