Assessing Compliance with AI Laws and Standards
Assessing compliance with AI laws and standards is a core discipline within advanced AI risk management and governance framework integration. It involves systematically verifying that an AI system, and the organization deploying it, meet applicable legal obligations (such as the EU AI Act, GDPR, sector-specific regulations like financial services or healthcare rules, and emerging national AI statutes) as well as voluntary or quasi-mandatory standards (such as ISO/IEC 42001 for AI management systems, ISO/IEC 23894 for AI risk management, the NIST AI Risk Management Framework, and IEEE ethics standards). The process begins with regulatory mapping: identifying which jurisdictions, use cases, and risk tiers apply, since obligations often scale with the system's potential for harm (e.g., 'high-risk' classification under the EU AI Act triggers conformity assessments, technical documentation, human oversight, and post-market monitoring). Next, organizations translate these requirements into concrete controls and evidence requirements—data governance records, bias and robustness testing results, transparency disclosures, logging capabilities, and incident response procedures. Framework integration is critical because overlapping obligations should be harmonized into a single control library rather than managed in silos; a well-designed control (e.g., documented impact assessments) can satisfy multiple regimes simultaneously, reducing duplication and audit fatigue. Assessment methods include gap analyses, internal audits, third-party conformity assessments, red-teaming, and continuous monitoring, supported by traceability matrices linking each legal clause to implemented controls and evidence artifacts. Advanced practice treats compliance as dynamic: model drift, retraining, new deployment contexts, and regulatory updates all require reassessment, so governance bodies establish triggers for re-evaluation and maintain living documentation. Key challenges include ambiguous legal definitions, divergent cross-border requirements, limited measurement standards for concepts like fairness or explainability, and the need to demonstrate not just procedural compliance but substantive risk reduction. Ultimately, effective compliance assessment embeds legal and ethical accountability into the AI lifecycle, producing defensible evidence for regulators, auditors, and stakeholders while reinforcing trustworthy, responsible AI deployment.
Assessing Compliance with AI Laws and Standards: A Complete Guide for the ISACA AAIA Exam (AI Risk Governance and Framework Integration)
Artificial intelligence is no longer governed only by internal policy and good intentions. Regulators around the world have moved from voluntary principles to binding law, and standards bodies have published certifiable management-system standards for AI. For an organization, failing to assess compliance means exposure to fines (the EU AI Act allows penalties up to 7% of global annual turnover for prohibited practices), forced withdrawal of systems from the market, litigation, loss of customer trust, and reputational harm.
For the ISACA AI auditor, this topic sits at the heart of the AI Risk Governance and Framework Integration domain because compliance assessment is where governance becomes verifiable. Boards and audit committees increasingly ask a simple question: Are our AI systems lawful, and can we prove it? The AI auditor must be able to answer with evidence, not assurances. The exam tests whether you can identify which obligations apply, evaluate how well an organization has mapped and implemented them, and recognize the right assurance approach when controls fall short.
2. What It Is
Assessing compliance with AI laws and standards is the structured process of determining whether an organization's AI systems, processes, and governance arrangements conform to the legal requirements, regulatory expectations, contractual commitments, and voluntary standards that apply to them. It involves three interlocking elements:
• Laws and regulations – binding rules enforced by governments (for example, the EU AI Act, GDPR, the Colorado AI Act, New York City Local Law 144 on automated employment decision tools, Canada's proposed AIDA, China's generative AI measures, and sector rules such as those from financial, health, and consumer-protection regulators).
• Standards and frameworks – voluntary or contractually required guidance such as ISO/IEC 42001 (AI Management System), ISO/IEC 23894 (AI risk management), ISO/IEC 38507 (governance implications of AI), the NIST AI Risk Management Framework (Govern, Map, Measure, Manage), the OECD AI Principles, and ISACA's own guidance.
• Internal commitments – policies, codes of conduct, customer contracts, and public statements (for example, published AI ethics principles) that create obligations the organization must honour.
The key insight is that a compliance assessment is not the same as legal advice. The auditor does not interpret the law from scratch; the auditor evaluates whether management has identified applicable requirements, translated them into controls, implemented those controls, and gathered evidence that they operate effectively.
3. The Regulatory and Standards Landscape You Must Know
EU AI Act – A risk-based regulation. It classifies AI into unacceptable risk (prohibited, e.g., social scoring, certain real-time biometric identification), high risk (e.g., AI in employment, credit, education, critical infrastructure, law enforcement, and products covered by EU safety legislation), limited risk (transparency obligations such as disclosing chatbots and deepfakes), and minimal risk. High-risk systems require a risk management system, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy/robustness/cybersecurity, a quality management system, conformity assessment, CE marking, and registration in the EU database. It also imposes obligations on general-purpose AI model providers. Roles matter: provider, deployer, importer, and distributor carry different duties.
GDPR and privacy laws – Article 22 restricts solely automated decisions with legal or similarly significant effects; Articles 13–15 require meaningful information about the logic involved; Article 35 requires Data Protection Impact Assessments for high-risk processing; principles of lawfulness, purpose limitation, data minimisation, and accuracy apply directly to training data. Many other jurisdictions (CCPA/CPRA, LGPD, PIPL) include similar automated decision-making provisions.
US landscape – No single federal AI law; instead a patchwork of executive orders, agency enforcement (FTC Section 5 on unfair or deceptive practices, EEOC on employment discrimination, CFPB on credit decisions and adverse action notices), and state laws (Colorado AI Act on algorithmic discrimination in consequential decisions, NYC Local Law 144 requiring bias audits for automated employment decision tools, Illinois AI Video Interview Act).
ISO/IEC 42001 – The first certifiable AI management system standard. It follows the familiar Plan-Do-Check-Act structure of ISO management standards, requiring context analysis, leadership commitment, AI policy, risk and impact assessments, operational controls (Annex A), performance evaluation, internal audit, and continual improvement. Because it is certifiable, auditors can use it as a benchmark and organizations can seek third-party certification.
NIST AI RMF – A voluntary US framework built around four functions: Govern (culture, accountability, policies), Map (context and risk identification), Measure (analysis and tracking of risks, trustworthiness characteristics), and Manage (prioritisation and response). Its seven trustworthiness characteristics – valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed – are frequently referenced in exam questions.
Sector-specific rules – Model risk management in banking (e.g., SR 11-7), medical device regulation for AI as software, fair lending and equal credit laws, consumer protection, and product safety regimes all overlay AI-specific requirements.
4. How a Compliance Assessment Works
A mature compliance assessment follows a repeatable lifecycle. Exam questions frequently test whether you know the correct sequence and the purpose of each step.
Step 1 – Build an AI inventory. You cannot assess compliance for systems you do not know about. The first control the auditor looks for is a complete, maintained register of AI systems, including shadow AI and third-party or embedded AI, with owner, purpose, data used, affected individuals, and deployment jurisdictions.
Step 2 – Determine applicability and classify risk. For each system, identify which laws apply based on jurisdiction (where it is developed, deployed, and whose data or decisions are affected), the organization's role (provider versus deployer), the use case, and the risk tier. Classification under the EU AI Act or a DPIA threshold analysis under GDPR occurs here. Misclassification is a root cause of many compliance failures.
Step 3 – Create a requirements and control map. Translate each legal clause or standard requirement into a specific control objective and then into concrete controls. A compliance matrix or crosswalk maps, for example, EU AI Act Article 14 (human oversight) to a documented escalation procedure, override capability, and trained reviewers. Crosswalks also map overlapping frameworks (ISO/IEC 42001 to NIST AI RMF to the EU AI Act) so one control satisfies many obligations – this is the essence of framework integration.
Step 4 – Perform a gap analysis. Compare the control map against the current state to identify missing, partially implemented, or undocumented controls. Gaps are rated by severity and regulatory deadline.
Step 5 – Test design and operating effectiveness. The auditor gathers evidence: technical documentation, model cards, data lineage records, bias testing results, impact assessments, logging samples, human-oversight records, training records, vendor contracts, conformity assessment certificates, and incident logs. Design effectiveness asks whether the control, if operating, would meet the requirement; operating effectiveness asks whether it actually operated consistently over the period.
Step 6 – Evaluate third parties. Many obligations flow through the supply chain. The auditor checks that contracts allocate responsibilities, that vendors supply required documentation, and that the organization performs due diligence rather than relying on vendor claims.
Step 7 – Report and remediate. Findings are communicated with root cause, risk rating, and recommendation. Management owns remediation; the auditor tracks closure.
Step 8 – Monitor continuously. AI laws evolve rapidly and models drift. A regulatory horizon-scanning process, periodic reassessment triggers (new jurisdiction, model retraining, change of purpose), and ongoing performance monitoring keep compliance current.
5. The Auditor's Role and Mindset
The AI auditor provides independent assurance. This means:
• Relying on evidence, not management representations alone.
• Testing the process for identifying legal requirements as well as the controls themselves – if the applicability analysis is wrong, every downstream control may be aimed at the wrong target.
• Involving legal counsel and privacy officers for interpretation while retaining independence of judgement on control adequacy.
• Recognising that compliance with a standard does not guarantee compliance with the law, and vice versa; ISO/IEC 42001 certification is helpful evidence but not a legal safe harbour.
• Applying a risk-based approach: prioritise high-risk systems and consequential decisions affecting individuals.
• Maintaining documentation that would withstand regulator scrutiny.
6. Common Challenges and Red Flags
• Incomplete inventories and shadow AI.
• Treating AI governance as purely a legal or purely a technical issue, with no integration.
• Vendor AI with no documentation, no right to audit, and unclear role allocation.
• Bias testing performed once at launch and never repeated.
• Impact assessments completed after deployment rather than before.
• Conflicting requirements across jurisdictions resolved by applying the weakest standard rather than the strictest applicable one.
• Policies that reference frameworks without mapping them to actual controls.
• No process to detect new or changed laws.
7. How to Answer Exam Questions on This Topic
ISACA questions are scenario-based and ask for the best, most important, first, or primary answer. Use this reasoning sequence:
1. Identify the role being tested. Is the question asking what the auditor should do or what management should do? The auditor assesses and reports; management designs and implements. An answer that has the auditor writing policies or fixing controls is usually wrong because it compromises independence.
2. Look for the foundational step. If the scenario describes an organization just beginning, the answer is almost always inventory, applicability analysis, or risk classification – not detailed testing. You cannot test controls against requirements you have not identified.
3. Prefer evidence over assertion. When choices include reviewing documentation, testing samples, or obtaining management confirmation, the evidence-based option wins.
4. Apply the risk-based principle. When resources are limited, focus on high-risk systems and decisions with significant effects on individuals.
5. Distinguish laws from frameworks. If a question asks about a mandatory requirement, think law or regulation. If it asks about best practice or a benchmark, think ISO/IEC 42001 or NIST AI RMF. A voluntary framework can never override a legal obligation.
6. Recognise role-based obligations. Provider versus deployer under the EU AI Act, controller versus processor under GDPR. The correct answer often hinges on which role the organization occupies.
7. When laws conflict, apply the most stringent applicable requirement or seek a harmonised control set that satisfies all; never default to the least demanding.
8. Eliminate extremes. Options such as discontinuing all AI, ignoring a requirement because it is not yet enforced, or relying entirely on a vendor's self-certification are distractors.
8. Exam Tips: Answering Questions on Assessing Compliance with AI Laws and Standards
• Tip 1 – First means first. When asked what to do first, choose understanding scope: the AI inventory, the business context, or the applicability determination. Gap analysis and testing come later.
• Tip 2 – The crosswalk is your friend. Questions about efficiency, duplicated effort, or multiple frameworks are answered by mapping requirements to a unified control set (framework integration).
• Tip 3 – Know the EU AI Act tiers cold. Be ready to classify a described use case as prohibited, high-risk, limited-risk, or minimal-risk, and to recall the high-risk obligations (risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness, conformity assessment).
• Tip 4 – Know the NIST AI RMF functions and ISO/IEC 42001 structure. Govern-Map-Measure-Manage and Plan-Do-Check-Act appear regularly. Govern is cross-cutting and foundational.
• Tip 5 – GDPR Article 22 is a favourite. Solely automated decisions with legal or similarly significant effects require a lawful basis, meaningful information, and the right to human intervention. Watch for scenarios involving credit, hiring, or benefits.
• Tip 6 – Third-party AI does not transfer accountability. The deploying organization remains accountable; the correct answer involves due diligence, contractual clauses, and obtaining evidence from the vendor – not accepting a marketing brochure.
• Tip 7 – Certification is evidence, not proof. If an option implies that an ISO certificate or a vendor attestation alone demonstrates legal compliance, it is a distractor.
• Tip 8 – Point-in-time is never enough. Answers that establish continuous monitoring, periodic reassessment, and regulatory horizon scanning beat one-time assessments.
• Tip 9 – Separate interpretation from assurance. Legal counsel interprets the law; the auditor assesses whether controls meet the interpreted requirement. If an option has the auditor providing legal opinions, be cautious.
• Tip 10 – Read for qualifiers. Words such as most effective, greatest concern, primary objective, and best evidence change the correct answer. The greatest concern is usually the gap that creates the largest legal or harm exposure, not the one that is easiest to fix.
9. Worked Example
Scenario: A multinational retailer has deployed a third-party AI tool to screen job applicants in the EU and New York City. Internal audit has been asked to assess regulatory compliance. Which of the following should the auditor do FIRST?
A. Test the vendor's bias audit results for statistical validity.
B. Confirm the system has been classified under applicable laws and the organization's role and obligations have been determined.
C. Recommend that HR add a human reviewer to every decision.
D. Verify that the vendor holds ISO/IEC 42001 certification.
Analysis: Option B is correct. Before testing any control, the auditor must confirm that management has identified that the tool is high-risk under the EU AI Act (employment), that the organization is a deployer with specific duties, that NYC Local Law 144 requires an annual independent bias audit and candidate notices, and that GDPR Article 22 and DPIA requirements apply. Option A is a later testing step. Option C is a management action and presumes a control gap not yet established. Option D treats certification as sufficient evidence and ignores the legal analysis.
10. Summary
Assessing compliance with AI laws and standards is a disciplined, evidence-driven process: know your AI systems, determine which obligations apply, map requirements to controls, find and rate gaps, test effectiveness, hold third parties accountable, report clearly, and keep monitoring as both the technology and the law change. On the exam, think like an independent, risk-based auditor who starts with scope and applicability, insists on evidence, integrates frameworks to avoid duplication, and never confuses a voluntary standard or a vendor promise with legal compliance.