Certified: The ISACA AAIR Audio Course

In this episode, we’re going to talk about one of the most common places where AI risk programs succeed or fail in real life: exceptions. An exception is what happens when a team wants to use AI in a way that does not fully meet the organization’s policy, standard, or control requirements, but they still want to proceed. Beginners often hear exceptions and think of loopholes, but a mature program treats exceptions as controlled risk decisions, because exceptions are where pressure, urgency, and convenience collide with governance. If an organization refuses to allow any exceptions, teams may work around governance entirely and create shadow AI use, which increases risk and destroys visibility. If an organization allows informal exceptions, governance becomes meaningless because boundaries can be bypassed without accountability. The safe middle path is to allow exceptions only through a disciplined process that includes approvals, time limits, and compensating controls, with clear documentation of who accepted what risk and why. By the end, you should understand what an exception is in the AI context, why exceptions are sometimes necessary, what makes an exception defensible, and how exception management connects to the risk register, monitoring, and leadership reporting.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

The first step is to define what an exception is, because people often mix exceptions with normal approvals. A normal approval occurs when a use case meets baseline requirements, such as documentation, impact classification, and required review steps, and it is approved under standard governance. An exception occurs when a baseline requirement is not met, such as missing evidence, incomplete monitoring capability, unresolved vendor transparency gaps, or a control that cannot be implemented on schedule. The exception process is a way to decide whether the organization will temporarily accept that gap, and if so, under what conditions. In AI risk, exceptions often arise because teams are trying to move quickly, because vendors do not provide all desired information, or because monitoring and documentation capabilities are still maturing. Exceptions can also arise in emergencies, such as needing to use an AI capability to handle a surge in workload, even though the ideal control structure is not fully in place. A beginner misunderstanding is to treat exceptions as routine shortcuts, but an exception should be treated as a signal that the governance model is being stretched. That is exactly why exceptions require discipline, because they represent increased residual risk and they can create precedents that spread. When exceptions are managed well, they allow controlled flexibility without undermining the program’s integrity.

Approvals are the first pillar of safe exception management, and approvals must be aligned to decision rights and accountability. An exception is not merely a technical decision; it is a risk acceptance decision, because it involves proceeding despite a control gap. That means the approval should come from someone who owns the outcomes and has authority to accept risk, typically a business owner for the affected process and, for high-impact cases, an executive sponsor or governance authority. Technical teams may recommend and explain implications, but they should not be forced to accept business risk they do not own. Risk management, compliance, legal, privacy, and security functions often participate as reviewers or gatekeepers depending on the nature of the gap, especially if the exception involves data exposure, regulated decisions, or high-impact outcomes. The approval process should also clarify who can deny an exception, because if denial authority is unclear, exceptions can be granted through informal pressure. A defensible program ensures exceptions are approved through the same level of seriousness as other risk decisions, especially when harm potential is high. For beginners, the key point is that approvals create accountability, because they record who decided the tradeoff was worth it. Without proper approvals, exceptions become invisible risk.

A safe exception process also requires that the exception be defined precisely, because vague exceptions are difficult to control and easy to abuse. The exception should state which requirement is not being met, why it cannot be met in the required timeframe, and what risk that gap creates. It should also state what use case is affected, what AI system or vendor feature is involved, and what data and decisions are in scope. This scope definition prevents the exception from quietly expanding to other use cases or other teams. It also makes it possible to decide what controls can compensate for the missing requirement, because you can only compensate for a known gap. For example, if the gap is incomplete monitoring, a compensating control might be tighter human review and manual sampling of outcomes until monitoring is implemented. If the gap is incomplete vendor transparency, a compensating control might be restricting use to low-impact contexts and limiting data types until further evidence is obtained. If the gap is incomplete documentation, a compensating control might be a short-term deployment limitation paired with a required documentation completion deadline. Beginners should see that exception definition is part of risk management discipline, because precise definition prevents the program from drifting into informal allowances. Precision is what keeps flexibility from turning into chaos.

Time limits are the second pillar, and they are essential because an exception that has no end date becomes a permanent bypass of governance. A time limit forces the organization to revisit the decision, verify whether the gap has been closed, and decide whether continued operation is acceptable. Time limits also reduce the risk of normalizing weak controls, because people cannot simply continue using the system indefinitely under an exception. The time limit should be proportional to impact and to the nature of the gap, with shorter limits for higher-impact contexts and for gaps that increase harm likelihood. Time limits should also be realistic, because impossible deadlines will be ignored and will erode credibility, but they should still be firm enough to drive action. A time-limited exception can be paired with milestones, such as completing monitoring capability by a specific date or obtaining vendor documentation by a specific review point. If milestones are missed, the program should have a defined consequence, such as pausing the AI use case, restricting scope further, or requiring escalation to senior leadership. For beginners, the important connection is that time limits turn exceptions into managed transitions rather than indefinite compromises. They also support defensibility because the organization can show that it did not accept an uncontrolled risk permanently.

Compensating controls are the third pillar, and they are what makes an exception safer than simply ignoring a requirement. A compensating control is an alternative safeguard that reduces risk when a preferred control is missing. In AI risk, compensating controls often involve adjusting how AI outputs are used, increasing human oversight, limiting scope to lower-impact contexts, limiting data types, increasing documentation of decisions, or increasing monitoring frequency through manual processes. The best compensating controls are those that directly address the risk introduced by the missing requirement. If the missing requirement is fairness evaluation, a compensating control might involve restricting the AI to advisory-only roles and adding human review for affected decisions, while fairness evaluation is completed. If the missing requirement is data governance, a compensating control might involve banning sensitive data inputs and using synthetic or non-sensitive data for any pilot activity until data controls are in place. If the missing requirement is auditability, a compensating control might involve stricter documentation of each decision influenced by AI during the exception period, so traceability is maintained. Compensating controls should not be vague promises; they should be concrete actions with owners and monitoring expectations. Beginners should see that compensating controls are what make an exception a controlled risk decision rather than a blind leap.

Exception management also needs clear documentation rules, because exceptions are high-scrutiny events. The exception record should include the risk statement, the reason for the exception, the approvals, the time limit, the compensating controls, and the monitoring plan during the exception period. It should also include conditions for renewal, meaning what must be true for the exception to be extended, and what conditions trigger termination, meaning what would cause the organization to stop the AI use case. Documentation should be stored in a place where it can be linked to the AI inventory and the risk register, because exceptions must be visible in the overall risk picture. If exceptions are stored in private emails or informal messages, they will be lost when people change roles, and the organization will later be unable to explain why a risky system was allowed to operate. Documentation also supports assurance, because reviewers can check whether exceptions are being used appropriately and whether time limits are being respected. For beginners, this reinforces a key theme: defensibility depends on evidence, and exceptions are decisions that require especially strong evidence because they represent deviations from standard controls. A well-documented exception is not only safer, it is also more likely to lead to control improvement because the gap and the plan to close it are explicit.

A safe exception process must also integrate with the living risk register, because the register is where leadership tracks material risks and control status over time. Each significant exception should be reflected in the risk register as a factor affecting residual risk, because a control gap changes the risk posture. The register entry should note that an exception is active, what requirement is deferred, what compensating controls are in place, and when the exception expires. This allows leadership reporting to include not just risks, but also how many exceptions exist, whether exceptions are increasing, and whether certain teams or use cases rely heavily on exceptions. A rising number of exceptions can indicate that governance requirements are unrealistic, that resources are insufficient, or that AI adoption is outpacing control maturity. That trend is itself a risk signal because it suggests control health is weakening. Monitoring should also include Key Risk Indicators (K R I s) tied to exception periods, because exceptions often increase uncertainty and therefore require closer observation. For example, if monitoring is weak due to an exception, the program might increase manual sampling or require more frequent review meetings until normal monitoring is restored. This integration ensures exceptions are not hidden and that leadership can see when the program is operating under increased risk. For beginners, it is important to see that exceptions are part of risk posture, not side notes.

Another crucial aspect is preventing exception creep, which is when exceptions expand beyond their original scope or become normalized across the organization. Exception creep can happen when one team gets an exception and other teams assume they can do the same without going through the process. It can also happen when a temporary exception is renewed repeatedly without meaningful progress toward closing the gap. Preventing creep requires clear scoping, clear time limits, and consistent enforcement, but it also requires leadership support so governance teams can say no when necessary. If the culture rewards speed above all else, exception requests will increase and pressure will mount to approve them. A mature program uses exception metrics as a leadership signal, because a high volume of exceptions may indicate that the operating model needs adjustment, such as improving tooling, simplifying requirements for low-impact use, or adding resources for monitoring and documentation. Exceptions can therefore become feedback loops that improve the program when handled transparently. For beginners, it helps to understand that exception management is not only about controlling deviations, it is also about learning where governance is strained. If the program ignores that learning, it will either become too rigid or too permissive, and both outcomes increase risk.

It is also important to address the difference between planned exceptions and emergency exceptions, because emergencies can pressure organizations into making rushed decisions. A planned exception might occur when a team cannot obtain a specific vendor document by a deadline, but the use case is low-impact and can be bounded safely. An emergency exception might occur when an organization needs to deploy an AI capability quickly to respond to an urgent operational need, like a surge in customer communications, and the usual review cadence cannot be followed. Even in emergencies, safe exception management still requires a documented decision, appropriate approvals, and compensating controls, though the process may be accelerated. Emergency exceptions often require tighter time limits and more immediate follow-up reviews, because the risk of making a mistake under urgency is higher. The program should also ensure that emergency exceptions do not become a pattern, because repeated emergencies often indicate underlying planning problems. For beginners, the key is to recognize that urgency does not remove accountability; it increases the need for clear decision records and strong compensating controls. If the organization deploys AI under emergency conditions without documentation and oversight, it may later face greater legal and trust harm because it cannot demonstrate responsible behavior. A disciplined exception process protects both the organization’s mission and its defensibility.

To make this concrete, imagine a high-impact use case where an organization wants to use AI to prioritize safety-related complaints, but monitoring tooling is not fully implemented yet. An exception request might ask to proceed with limited automation while monitoring is built. A safe approval would likely require senior accountability because safety impact is high, and it would require strict scoping so AI does not make final decisions in safety categories. The time limit would likely be short, with a firm deadline for implementing monitoring and a consequence for missing that deadline, such as pausing the use case. Compensating controls might include mandatory human review for any complaint that matches certain safety indicators, manual sampling of AI decisions, and daily or weekly review of outcomes during the exception period. The exception documentation would capture the specific control gap, the rationale, the approvals, the compensating controls, and the escalation triggers if misclassification rises. The risk register would reflect the exception and track whether the compensating controls are effective, using K R I trends and incident signals. This example shows that exceptions can be managed safely, but only when they are treated as serious risk decisions rather than as administrative hurdles. Beginners should see that the discipline of exception management is what allows organizations to remain flexible without undermining safety and trust.

To close, managing AI risk exceptions safely is about allowing controlled flexibility while preserving governance integrity through approvals, time limits, and compensating controls. Exceptions occur when baseline requirements are not met, and because they represent increased residual risk, they must be approved by appropriate decision right holders who are accountable for outcomes. Safe exceptions are defined precisely, scoped narrowly to prevent creep, and documented with clear rationale and evidence. Time limits prevent exceptions from becoming permanent bypasses and force reassessment and closure of control gaps, especially in high-impact contexts. Compensating controls reduce risk during the exception period by adjusting reliance, increasing human oversight, limiting scope and data use, and increasing monitoring intensity, with clear owners and action triggers. Exceptions must be integrated into the AI inventory and living risk register so leadership can see their effect on risk posture and can respond if exceptions become frequent or prolonged. When done well, exception management strengthens a program by balancing agility with defensibility, ensuring the organization can move under pressure without abandoning responsibility. This prepares you for the next step, where we define controls and testing plans, because exceptions are easier to manage when baseline controls are clear and verification is routine.