AI Policies, Standards, Procedures and Guidelines

1. Why This Topic Matters

Every AI governance program ultimately rests on documented direction. Boards and senior management cannot personally supervise every model, data pipeline or prompt, so they express their intent through a documentation hierarchy: policies, standards, procedures and guidelines. In the ISACA Advanced in AI Risk (AAIR) body of knowledge, this topic sits inside the domain of AI Risk Governance and Framework Integration, and it is foundational for several reasons:

• It translates strategy and risk appetite into enforceable rules. A board may state that AI must be fair, transparent and secure, but those words only become operational when a policy requires it, a standard specifies measurable thresholds, and a procedure tells engineers exactly what to do.
• It is the primary evidence of due care. Regulators (EU AI Act, sector regulators, privacy authorities) and auditors look first for documented, approved and communicated requirements. Absence of policy is itself a control deficiency.
• It enables framework integration. Frameworks such as the NIST AI Risk Management Framework (AI RMF), ISO/IEC 42001 (AI Management System), ISO/IEC 23894 (AI risk management), COBIT and the OECD AI Principles all expect organisations to formalise their commitments in policy and supporting documents. The hierarchy is the mechanism by which external frameworks become internal practice.
• It establishes accountability. Each document has an owner, an approver and an audience. When an AI incident occurs, the question of who was responsible is answered by the documentation hierarchy.
• It reduces inconsistency and shadow AI. Without clear direction, business units adopt tools and vendors independently, creating ungoverned risk exposure.

For the exam, ISACA expects you to understand not only the definitions but the relationships between these documents, who approves them, how often they are reviewed, and how to diagnose governance gaps when a scenario describes something going wrong.

2. What It Is: The Documentation Hierarchy

Think of the hierarchy as a pyramid. At the top, few documents, high-level, stable and mandatory. Toward the bottom, many documents, detailed, frequently changing and increasingly operational. Guidelines sit alongside the pyramid as optional advice.

2.1 AI Policy
• Definition: A high-level, formal statement of management intent, direction and expectations regarding the development, acquisition, deployment and use of AI.
• Nature: Mandatory. Principle-based rather than technology-specific. Written to survive technological change.
• Approved by: Board of directors or executive management (senior-most governance body). This is a frequently tested point.
• Typical content: scope (which AI systems are covered), guiding principles (fairness, accountability, transparency, safety, privacy, human oversight), roles and responsibilities (AI governance committee, model owners, risk, compliance, audit), risk appetite statements, prohibited uses, compliance and consequence statements, and references to supporting standards.
• Review cycle: Typically annually or upon significant regulatory, business or technology change.
• Example: 'All AI systems that materially affect individuals must be subject to a documented risk assessment, human oversight and periodic performance monitoring prior to and during production use.'

2.2 AI Standards
• Definition: Mandatory, specific requirements that define how the policy is to be met. Standards set minimum acceptable levels, metrics, technologies or configurations.
• Nature: Mandatory. More detailed than policy, more stable than procedures. Standards make policy measurable and auditable.
• Approved by: Typically a management-level body such as the AI governance committee, CISO/CRO or Chief Data/AI Officer, under authority delegated by the policy.
• Typical content: model risk tiering criteria, acceptable bias and fairness metrics and thresholds, data quality and provenance requirements, model documentation requirements (model cards, data sheets), explainability requirements by risk tier, security requirements for AI pipelines (access control, adversarial testing), third-party AI vendor requirements, logging and monitoring requirements, acceptable use of generative AI.
• Example: 'High-risk models must achieve a demographic parity difference of no more than 0.05 across protected attributes before production approval and must be re-tested quarterly.'

2.3 AI Procedures
• Definition: Step-by-step instructions describing who does what, when, and in what order to comply with a standard or policy.
• Nature: Mandatory for the people performing the task. Highly detailed, operational, and changed most frequently.
• Approved by: Process or function owners (e.g., head of data science, ML operations lead).
• Typical content: model intake and risk classification procedure, data sourcing and consent verification procedure, pre-deployment validation and bias testing procedure, model change management procedure, AI incident response procedure, model retirement and decommissioning procedure, prompt and output review procedure for generative AI.
• Example: 'Step 1: Model owner submits intake form in the model inventory. Step 2: Risk function assigns tier within five business days. Step 3: For Tier 1 models, independent validation is scheduled...'

2.4 AI Guidelines
• Definition: Recommended practices, advice and suggestions that help people comply with policy and standards, but which are not mandatory.
• Nature: Discretionary. They provide flexibility where a single mandatory approach is impractical or where good practice is still evolving.
• Approved by: Subject matter experts or the AI governance function; approval is lighter-weight.
• Typical content: recommended prompt-engineering practices, suggested explainability techniques for different model types, tips for writing effective model documentation, recommended approaches to human-in-the-loop design, guidance on selecting fairness metrics for different use cases.
• Example: 'When explaining tree-based models to non-technical stakeholders, consider using SHAP summary plots supplemented with plain-language narratives.'

2.5 Quick Comparison
• Policy – WHY and WHAT at a high level; mandatory; board/executive approved; stable.
• Standard – WHAT specifically (minimum requirements, metrics); mandatory; management approved; moderately stable.
• Procedure – HOW, step by step; mandatory for performers; process-owner approved; changes often.
• Guideline – recommended HOW; discretionary; expert approved; flexible.

A useful memory aid: Policies set direction, standards set the bar, procedures set the steps, guidelines offer the advice.

3. How It Works in Practice

3.1 The Document Lifecycle
1. Identify the need – triggered by strategy, risk assessment, regulatory requirement (e.g., EU AI Act obligations for high-risk systems), audit findings, incidents or framework adoption.
2. Draft – with input from legal, compliance, privacy, security, data science, ethics and business stakeholders. Good AI policy development is cross-functional because AI risk is multidisciplinary.
3. Review and consult – stakeholders validate feasibility; a policy that cannot be implemented creates compliance debt.
4. Approve – at the appropriate level of authority. Approval level signals importance and establishes accountability.
5. Communicate and train – publish, make accessible, require acknowledgement, deliver role-based training. An unpublished policy is unenforceable.
6. Implement – embed into processes, tooling (model registries, MLOps pipelines, access controls) and contracts.
7. Monitor and enforce – measure compliance through KRIs/KPIs, control testing, exception tracking and internal audit. Define consequences for non-compliance.
8. Review and update – on a defined cycle and upon triggers. AI documents need more frequent review than traditional IT documents because the technology and regulatory landscape shift quickly.
9. Retire – formally withdraw superseded documents to prevent conflicting direction.

3.2 Exception Management
Because standards are mandatory, there must be a formal exception (waiver) process: documented business justification, risk assessment, compensating controls, approval by an appropriate authority, expiry date and periodic re-review. Unmanaged exceptions silently erode the standard. The exam often tests that exceptions should be formally approved, time-bound and risk-assessed, not granted informally by the requester or the technical team.

3.3 Integration with External Frameworks and Regulation
• NIST AI RMF – the GOVERN function explicitly calls for policies, processes and procedures that are transparent and implemented effectively; MAP, MEASURE and MANAGE functions are operationalised through standards and procedures.
• ISO/IEC 42001 – requires top management to establish an AI policy appropriate to the organisation, communicate it, and ensure it is reviewed; it also requires documented information supporting the AI management system.
• ISO/IEC 23894 and ISO 31000 – risk management principles that policy should reference, with standards defining risk criteria.
• EU AI Act – obligations such as risk management systems, data governance, technical documentation, logging, human oversight and accuracy/robustness requirements for high-risk systems map directly into standards and procedures.
• COBIT – provides the governance-versus-management distinction: governance (board) sets direction via policy; management builds and runs via standards and procedures.
• Privacy and sector regulation (GDPR, HIPAA, fair-lending rules, consumer protection) – shape mandatory content, especially around automated decision-making and explainability.

The integration principle: map each external requirement to an internal policy statement, then to a standard that makes it measurable, then to a procedure that executes it, then to evidence that proves it. This traceability is what auditors and regulators test.

3.4 Roles and Responsibilities
• Board / Governing body – approves AI policy, sets risk appetite, oversees effectiveness.
• Executive management / AI Governance Committee – approves standards, allocates resources, resolves conflicts, approves high-impact exceptions.
• Second line (risk, compliance, privacy, ethics) – drafts standards, monitors compliance, challenges first line.
• First line (model owners, data scientists, business units) – owns procedures, implements requirements, reports exceptions.
• Internal audit (third line) – independently assesses whether the hierarchy exists, is approved, communicated, followed and effective.
• Legal – ensures alignment with laws, contracts and liability considerations.

3.5 Characteristics of Effective AI Documents
• Aligned with business objectives and risk appetite.
• Clear, concise, unambiguous, written for the intended audience.
• Technology-neutral at policy level; specific at standard/procedure level.
• Owner, approver, version, effective date and review date clearly stated.
• Realistic and enforceable; measurable where mandatory.
• Consistent with each other (no conflicts between policy and standards).
• Accessible and communicated with training and acknowledgement.
• Supported by a formal exception process and consequences for non-compliance.

3.6 Common Failure Patterns
• Policy exists but no supporting standards, so it cannot be measured or enforced.
• Standards written at the wrong level (too technology-specific, requiring constant change, or too vague to audit).
• Procedures not updated when tooling or models change, leading to divergence between documented and actual practice.
• Guidelines treated as mandatory or standards treated as optional, confusing accountability.
• Approval by the wrong authority (e.g., data science team approves its own AI policy).
• No communication or training; staff unaware of requirements.
• No defined review cycle, so documents become stale as regulation evolves.
• Generative AI adopted before any acceptable-use policy exists (shadow AI).

4. How to Answer Exam Questions on This Topic

ISACA exams reward governance thinking over technical thinking. Questions typically present a scenario and ask for the BEST, MOST important, FIRST or PRIMARY action or document. Apply the following reasoning process:

Step 1 – Identify the document type the scenario describes. Ask: Is it high-level intent (policy)? A mandatory measurable requirement (standard)? Step-by-step instructions (procedure)? Recommended advice (guideline)? Many questions are simply testing whether you can classify correctly.

Step 2 – Identify the level of authority. If the question asks who should approve or own, match the document to its governance level: board/executive for policy, management for standards, process owners for procedures, experts for guidelines.

Step 3 – Look for the governance gap. If something went wrong, ask which layer is missing or deficient. A root cause is usually one level up from where the symptom appears. Inconsistent practices across teams point to missing standards; staff unaware of rules points to communication/training failure; practices that violate a rule nobody enforces point to monitoring and enforcement failure.

Step 4 – Apply the ISACA sequencing logic. Governance flows top-down: direction before design, policy before standard, standard before procedure, approve before communicate, communicate before enforce, assess risk before granting exceptions. When asked what to do FIRST, choose the foundational or diagnostic step, not the implementation detail.

Step 5 – Eliminate distractors. Typical wrong answers: technical fixes to governance problems, actions by the wrong role, treating a guideline as mandatory, informal or verbal approvals, skipping risk assessment, and overly detailed content placed in a policy.

5. Exam Tips: Answering Questions on AI Policies, Standards, Procedures and Guidelines

• Tip 1 – Mandatory versus discretionary is the single most tested distinction. Policies, standards and procedures are mandatory. Guidelines are recommended. If an answer describes a guideline as a compliance requirement, it is wrong.
• Tip 2 – Policy approval belongs to the highest governance level. When asked who approves the AI policy, choose the board or executive management, not the CIO, data science lead or AI ethics officer alone.
• Tip 3 – Policies should be technology-neutral and principle-based. If a choice places detailed metrics, tool names or thresholds in the policy, it misplaces content that belongs in a standard.
• Tip 4 – Standards make policy measurable. If the scenario says a policy exists but compliance cannot be assessed, the missing element is a standard, not more procedures or more training.
• Tip 5 – Procedures change most often and are owned by operations. When asked which document to update after a tooling or workflow change, think procedure first.
• Tip 6 – 'FIRST' questions favour review, assessment or alignment. Before writing or revising a document, assess requirements, risk and existing documentation. Before enforcing, communicate. Before granting an exception, assess risk.
• Tip 7 – 'BEST indicator of effectiveness' questions favour evidence of compliance and outcomes, such as monitored adherence, exception trends and reduced incidents, rather than the mere existence or publication of documents.
• Tip 8 – Exceptions must be formal, risk-assessed, approved at the right level and time-bound. Any answer implying permanent, informal or self-approved exceptions is a distractor.
• Tip 9 – Communication and training are controls. A documented policy that staff do not know about provides little assurance. If users are unaware of acceptable use rules, the primary gap is awareness, not the policy content.
• Tip 10 – Think framework traceability. When a question mentions NIST AI RMF, ISO/IEC 42001 or the EU AI Act, the correct governance response usually involves mapping external requirements into the internal policy hierarchy and verifying coverage, not adopting the framework verbatim.
• Tip 11 – Review cycles are risk-based and trigger-based. Answers stating that AI policy should be reviewed only when problems arise, or never, are wrong; answers that combine periodic review with event triggers (regulatory change, incidents, new technology) are typically correct.
• Tip 12 – Watch for role confusion. First line implements, second line sets standards and monitors, third line provides independent assurance. Internal audit should not write the policies it audits.
• Tip 13 – Prefer the governance answer over the technical answer. AAIR tests risk and governance judgement. If the problem is a lack of direction or accountability, the solution is a document, approval, communication or enforcement action, not a new model or algorithm.
• Tip 14 – Use the hierarchy to resolve conflicts. When documents conflict, the higher-level document prevails and the lower-level document must be corrected. Policy over standard, standard over procedure.
• Tip 15 – Read qualifiers carefully. MOST, BEST, PRIMARY, FIRST and GREATEST each change the correct answer. Several options may be true; only one best satisfies the qualifier.

6. Worked Examples

Example 1. An organisation has an approved AI policy requiring that high-risk models be free from unlawful bias. Business units interpret this differently and use different fairness tests. What is the BEST action?
Reasoning: Policy exists; the gap is inconsistent interpretation of a mandatory requirement. The missing layer is a standard defining acceptable fairness metrics and thresholds. Answer: Develop an AI fairness standard specifying required metrics and acceptable thresholds by risk tier.

Example 2. Who should approve the enterprise AI policy?
Reasoning: Policy is the top of the hierarchy and expresses governance intent. Answer: The board of directors or senior executive management.

Example 3. A data science team wants to deploy a model that does not meet the explainability standard, citing business urgency. What should the risk manager recommend?
Reasoning: Standards are mandatory; deviation requires a formal exception. Answer: Submit a formal, risk-assessed, time-bound exception request with compensating controls for approval by the designated authority.

Example 4. Employees are using public generative AI tools with customer data. The organisation has no direction on this. What is the FIRST step?
Reasoning: No governance direction exists; start at the top of the hierarchy and address the most urgent risk. Answer: Establish and communicate an acceptable use policy (or interim directive) for generative AI, followed by supporting standards and training.

Example 5. A document recommends preferred techniques for documenting training data lineage but states teams may use alternatives. What type of document is this?
Reasoning: Recommended, not mandatory, flexible. Answer: A guideline.

Example 6. Which provides the BEST evidence that the AI policy is effective?
Reasoning: Effectiveness is about outcomes and adherence, not existence. Answer: Monitoring results showing compliance with supporting standards and a declining trend in policy exceptions and AI incidents.

7. Key Takeaways

• The hierarchy is: Policy (why/what, board-approved, mandatory, stable) → Standards (specific mandatory requirements, management-approved) → Procedures (step-by-step, operationally owned, mandatory) with Guidelines (recommended, discretionary) providing supporting advice.
• Documents must be approved at the right level, communicated, trained, enforced, monitored and reviewed on a risk-based cycle with defined triggers.
• Exceptions must be formal, risk-assessed, approved and time-bound.
• External frameworks and regulations are integrated by mapping their requirements into the internal hierarchy and tracing them to evidence.
• On the exam, classify the document, identify the correct authority, locate the governance gap, apply top-down sequencing, and prefer the governance answer over the technical one.