CF01-004: Policy Exception Process

AI Control Library / CF-01: Lifecycle Governance

Designation: Core | Control types represented: Operational

Exceptions can quietly become the operating model if approval has no expiry or follow-up. An exception records a deliberate risk decision; it does not make an absent safeguard effective or override binding external obligations.

Control requirement

Use a documented process to request, assess, approve, monitor and expire exceptions to AI policy requirements. Identify the affected requirement, justification, residual risk, compensating measures, accountable owner and end date.

Why this matters

The control is effective when its required decisions and safeguards can be demonstrated in the actual workflow. An approved document or completed form alone is insufficient if the described actions are not performed.

How the control types work together

Operational controls provide the policies, decisions and recurring processes described here.

When it applies

Proposed departures from internal AI requirements. Legal and contractual departures require separate review of whether discretion actually exists.

Tailor depth and review frequency to potential impact, system authority and uncertainty. Document the reason for any exclusion; a supplemental designation does not make an otherwise applicable safeguard optional.

Ownership

The policy owner assesses the departure; a designated risk authority approves acceptance and the system owner maintains compensating measures.

Implementation guidance

  1. Require a request tied to a specific system, requirement, business need and proposed duration; reject blanket or retroactive approvals as routine practice.
  2. Assess impact and alternatives, including delaying deployment or reducing functionality; involve legal or compliance where external duties may be affected.
  3. Specify compensating measures, monitoring, remediation milestones and approval authority independent of the requester where practicable.
  4. Track expiry and trigger reapproval or closure; verify reinstatement of the requirement or disable the affected exception-dependent activity.

How to verify it

Use a representative sample of actual records or an authorized controlled exercise. A reviewer with suitable expertise should compare observed practice with the approved scope and acceptance criteria.

Test Expected result
Inspect an active exception Scope, authority, measures and expiry are explicit.
Test an expired exception scenario Continued use is blocked or escalated through a new authorized decision.
Verify a claimed compensating measure Evidence shows it operates over the exception’s actual scope.

Record a finding when a required result is absent, evidence cannot substantiate the claim, or practice differs materially from the approved conditions. An exception may record accepted risk, but does not turn a failed safeguard into an effective one.

Evidence to retain

  • Exception request and risk analysis
  • Approval and expiry register
  • Compensating-measure evidence
  • Closure or renewal decisions

Protect evidence according to its sensitivity and approved retention requirements. Retain enough detail to substantiate the assessment without unnecessarily duplicating confidential or personal information.

If the control fails

Escalate unauthorized, expired or over-broad exceptions to the risk authority. Restrict affected activity when compensating measures fail; do not treat retrospective documentation as approval.

Example in practice

Hypothetical example: A team cannot yet retain the required audit events. A limited internal pilot receives a short exception with read-only permissions and manual records; production action-taking remains prohibited until logging is verified.

Related controls

Framework mappings

  • CSA AICM (GRC-04)
  • NIST AI RMF (GOVERN 1.2)
  • ISO 42001 (Cl. 6.1)

Review and maintenance

Review at the interval approved by the control owner and after a material change, relevant incident or failed assessment. Reassess the affected scope, update records and verify corrective actions before closing findings.

Back to Lifecycle Governance

Version 1.0

Scroll to Top