# Control 3.12: Agent Governance Exception and Override Management

**Control ID:** 3.12<br>
**Pillar:** Reporting<br>
**Regulatory Reference:** SOX 302/404, FINRA 3110, FINRA RN 24-09, OCC Bulletin 2026-13 (formerly OCC 2011-12), Fed SR 26-2 (formerly SR 11-7)<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

## Objective

Establish formal processes for requesting, approving, tracking, and monitoring temporary exceptions to agent governance policies through time-bound approvals, supervisory oversight, audit trails, and automated expiration enforcement. This control helps support documented justification, monitoring, and systematic remediation of policy deviations so that exceptions remain auditable rather than becoming undocumented governance debt.

!!! info "Process-Based Control (No Dedicated Microsoft UI)"
    Control 3.12 is a **procedural control** requiring organizational processes and workflows. Microsoft does not provide a native "exception management" interface for agent governance. Exception tracking must be implemented using:
    
    - **Dataverse custom tables** for exception registers
    - **Power Automate approval flows** for multi-level exception requests
    - **SharePoint lists** for lightweight exception tracking
    - **Purview audit logs** to capture policy deviations
    - **Teams notifications** for exception alerts and renewals
    
    Organizations should design exception management workflows aligned with existing change management and risk acceptance processes.

---

## Why This Matters for FSI

- **SOX 302/404:** Internal controls over financial reporting require documented exception processes with management approval, monitoring, and remediation. Undocumented governance overrides undermine control effectiveness assessments and create audit findings
- **FINRA RN 24-09 / Rule 3110:** Supervisory procedures require documented exceptions to written supervisory procedures with principal-level approval and periodic review. AI agent governance exceptions must follow the same supervisory framework
- **OCC Bulletin 2026-13 (formerly OCC 2011-12):** Model Risk Management guidance requires formal exception processes for model limitations, compensating controls, and risk acceptance decisions. AI agents qualifying as models must have tracked exceptions with time limits and renewal oversight
- **Fed SR 26-2 (formerly SR 11-7):** Model governance framework must include processes for temporary policy waivers, compensating controls, and management override. Exception registers demonstrate effective ongoing governance and risk monitoring

Formal exception management supports regulatory examination readiness by demonstrating that the organization maintains accountability and oversight even when policy deviations are necessary for business needs.

---

!!! info "No companion solution by design"
    Not all controls have a companion solution in [FSI-AgentGov-Solutions](https://github.com/judeper/FSI-AgentGov-Solutions); solution mapping is selective by design. This control is operated via native Microsoft admin surfaces and verified by the framework's assessment-engine collectors. See the [Solutions Index](../../reference/solutions-index.md#coverage-scope) for the catalog and coverage scope.


## Control Description

Agent governance policies (DLP, environment controls, approval gates, inventory requirements) are designed for comprehensive protection, but business realities occasionally require temporary exceptions. Control 3.12 establishes formal processes for managing these exceptions with accountability, time limits, and audit trails.

**Exception Management Principles:**

| Principle | Description | Implementation |
|-----------|-------------|----------------|
| **Justification Required** | Every exception must have documented business justification and risk assessment | Exception request template with mandatory justification field |
| **Time-Bound** | All exceptions have expiration dates; no permanent exceptions allowed | Dataverse tracking with expiration date field; automated renewal alerts |
| **Multi-Level Approval** | Higher-risk exceptions require escalating approval authority | Zone 3: manager + compliance + CISO approval |
| **Compensating Controls** | Temporary risk mitigation measures during exception period | Documented in exception request; verified during audits |
| **Audit Trail** | Complete history of exception requests, approvals, modifications, and closures | Dataverse audit fields; Purview audit log integration |
| **Automated Monitoring** | System alerts for expiring exceptions and policy violations during active exceptions | Power Automate flows; Teams notifications |

### Exception Types

| Exception Type | Example Scenario | Approval Authority | Maximum Duration |
|----------------|------------------|-------------------|------------------|
| **Policy Override** | Temporarily allow blocked connector for time-sensitive project | Zone 1/2: Power Platform Admin; Zone 3: Power Platform Admin + CISO | 30 days (Zone 3), 60 days (Zone 2), 90 days (Zone 1) |
| **Approval Bypass** | Fast-track agent deployment for regulatory deadline | Zone 2: AI Governance Lead; Zone 3: AI Governance Lead + Compliance Officer | 14 days with post-implementation review |
| **Inventory Grace Period** | Allow agent operation while metadata completion in progress | Zone 1/2: Power Platform Admin; Zone 3: Compliance Officer | 30 days (one-time only) |
| **Environment Reclassification** | Temporarily deploy Zone 3 agent in Zone 2 for pilot testing | CISO + Compliance Officer | 30 days (Zone 3 only) |
| **Risk Acceptance** | Deploy agent with known limitation pending permanent fix | Zone 2: Manager + AI Governance Lead; Zone 3: Manager + Compliance Officer + CISO | 60 days (Zone 2), 30 days (Zone 3) |

### Exception Lifecycle Workflow

```
[Exception Request] 
    → [Risk Assessment] 
    → [Multi-Level Approval] 
    → [Compensating Controls Implementation] 
    → [Active Monitoring] 
    → [Expiration Alert (7 days before)] 
    → [Renewal or Remediation] 
    → [Closure and Audit]
```

### Dataverse Exception Register Schema

Organizations implementing Control 3.12 should create a custom Dataverse table for exception tracking:

| Column Name | Data Type | Description | Required |
|-------------|-----------|-------------|----------|
| `fsi_exceptionid` | Autonumber | Unique exception identifier | Yes |
| `fsi_requestdate` | Date and Time | When exception was requested | Yes |
| `fsi_requestor` | Lookup (User) | Person requesting exception | Yes |
| `fsi_agentname` | Text | Name of agent requiring exception | Yes |
| `fsi_exceptiontype` | Choice | Policy Override, Approval Bypass, Risk Acceptance, etc. | Yes |
| `fsi_justification` | Multi-line text | Business justification and necessity | Yes |
| `fsi_riskassessment` | Multi-line text | Risk analysis and impact | Yes |
| `fsi_compensatingcontrols` | Multi-line text | Temporary risk mitigation measures | Yes |
| `fsi_zone` | Choice | Zone 1, Zone 2, Zone 3 | Yes |
| `fsi_approvalstatus` | Choice | Pending, Approved, Denied, Expired, Closed | Yes |
| `fsi_approver1` | Lookup (User) | First-level approver (manager) | Yes |
| `fsi_approvaldate1` | Date and Time | First approval date | No |
| `fsi_approver2` | Lookup (User) | Second-level approver (compliance) | Zone 2/3 |
| `fsi_approvaldate2` | Date and Time | Second approval date | No |
| `fsi_approver3` | Lookup (User) | Third-level approver (CISO) | Zone 3 only |
| `fsi_approvaldate3` | Date and Time | Third approval date | No |
| `fsi_expirationdate` | Date | When exception expires | Yes |
| `fsi_renewalcount` | Whole Number | Number of times renewed | Yes (default: 0) |
| `fsi_closuredate` | Date and Time | When exception was closed | No |
| `fsi_closurereason` | Multi-line text | Reason for closure (remediation, expiration, etc.) | No |

### SharePoint Alternative (Lightweight Implementation)

For organizations without Dataverse licensing or requiring faster implementation, SharePoint lists can provide basic exception tracking:

1. Create SharePoint list: **Agent Governance Exception Register**
2. Add columns matching Dataverse schema (Person fields for approvers, Date columns, Choice columns)
3. Configure Power Automate approval flows to update SharePoint list status
4. Enable list versioning for audit trail
5. Create Power BI dashboard connected to SharePoint list for exception reporting

> **Note:** SharePoint-based tracking lacks Dataverse's audit capabilities and Power Automate integrations but provides acceptable baseline for Zone 1 and small Zone 2 deployments.

### Microsoft Purview Audit Log Integration

While Purview does not have built-in exception tracking, organizations can capture policy deviations in the audit log:

1. **DLP Policy Override Events:** Purview captures when DLP policies are modified or disabled
2. **Permission Elevation Events:** Audit log tracks when admin roles are assigned or elevated
3. **Environment Configuration Changes:** Purview logs environment security group changes, sharing modifications
4. **Custom Audit Events:** Use Power Automate to write custom audit events to Purview when exceptions are approved

Query Purview audit logs to correlate exception approvals with actual policy changes during exception periods.

---

## Key Configuration Points

- Define exception types, approval authorities, and maximum durations by governance zone
- Create Dataverse custom table (fsi_governanceexceptions) or SharePoint list for exception register
- Configure Power Automate approval flows with zone-specific approval routing (1-level for Zone 1, 2-level for Zone 2, 3-level for Zone 3)
- Implement exception request form in Power Apps or SharePoint with mandatory fields (justification, risk assessment, compensating controls)
- Establish compensating control validation process verifying temporary mitigations are implemented before exception approval
- Deploy automated expiration monitoring with 7-day advance alerts to requestor and approvers via Teams
- Configure renewal workflow requiring re-justification and risk reassessment for extended exceptions
- Implement maximum renewal limits (2 renewals maximum; 3rd renewal requires executive escalation)
- Integrate exception register with quarterly governance reporting and audit reviews
- Establish exception closure process documenting remediation actions and lessons learned

---

## Zone-Specific Requirements

| Zone | Requirement | Rationale |
|------|-------------|-----------|
| **Zone 1** (Personal) | Exception requests via email or SharePoint form; single-level approval (Power Platform Admin); 90-day maximum duration; annual review of all exceptions | Personal productivity agents have limited risk; lightweight process acceptable |
| **Zone 2** (Team) | Formal exception request via Power Automate flow; two-level approval (manager + compliance); 60-day maximum duration; mandatory compensating controls; documented in Dataverse; quarterly review | Team collaboration increases risk exposure; structured oversight required |
| **Zone 3** (Enterprise) | Power Apps exception request with full risk assessment; three-level approval (manager + compliance + CISO); 30-day maximum duration with mandatory renewal justification; automated expiration enforcement; compensating controls verified before approval; board-level reporting on active exceptions | Customer-facing and regulated operations require strictest exception governance and senior oversight |

---

## Roles & Responsibilities

| Role | Responsibility |
|------|----------------|
| Agent Owner | Request exceptions with documented justification, risk assessment, and proposed compensating controls; implement compensating controls during exception period; submit renewal requests before expiration; document remediation when exception closes |
| Power Platform Admin | Review and approve Zone 1 exceptions; implement technical compensating controls; verify exception closures; maintain exception register integrity |
| Compliance Officer | Review and approve Zone 2/3 exceptions; validate regulatory compliance implications; monitor active exceptions; escalate overdue exceptions to senior management |
| CISO/Security Lead | Approve Zone 3 exceptions; accept risk on behalf of organization; review renewal requests; report exception metrics to board or executive leadership |
| AI Governance Lead | Define exception policies and approval authorities; review exception trends; identify systemic issues requiring policy updates; conduct quarterly exception audits |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [2.6 - Model Risk Management OCC Bulletin 2026-13 (formerly OCC 2011-12)/Fed SR 26-2 (formerly SR 11-7)](../pillar-2-management/2.6-model-risk-management-sr-26-2.md) | Model risk exceptions (limitations, compensating controls) require exception tracking; Control 3.12 provides exception management framework |
| [2.2 - Environment Groups and Tier Classification](../pillar-2-management/2.2-environment-groups-and-tier-classification.md) | Zone classification determines exception approval requirements and maximum durations |
| [3.3 - Compliance and Regulatory Reporting](3.3-compliance-and-regulatory-reporting.md) | Exception register data flows into quarterly compliance reports demonstrating governance oversight |
| [2.12 - Supervision and Oversight FINRA 3110, FINRA RN 24-09](../pillar-2-management/2.12-supervision-and-oversight-finra-rule-3110.md) | FINRA supervisory exception processes apply to agent governance exceptions; principal approval required |

---

## Implementation Playbooks

!!! info "Step-by-Step Implementation"

    This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

    - [Portal Walkthrough](../../playbooks/control-implementations/3.12/portal-walkthrough.md) — Step-by-step Dataverse table creation and Power Automate flow configuration
    - [PowerShell Setup](../../playbooks/control-implementations/3.12/powershell-setup.md) — Scripts for exception monitoring and reporting
    - [Verification & Testing](../../playbooks/control-implementations/3.12/verification-testing.md) — Test cases and evidence collection
    - [Troubleshooting](../../playbooks/control-implementations/3.12/troubleshooting.md) — Common issues and resolutions

---

## Verification Criteria

Confirm control effectiveness by verifying:

1. Exception management policy is documented defining types, approval authorities, maximum durations, and renewal procedures
2. Dataverse exception register table (or SharePoint list) is created with all required columns including justification, risk assessment, compensating controls, approvers, and expiration dates
3. Power Automate approval flows are configured with zone-specific routing (1-level for Zone 1, 2-level for Zone 2, 3-level for Zone 3)
4. Exception request form (Power Apps or SharePoint) requires mandatory fields and validates data before submission
5. Automated expiration monitoring sends alerts 7 days before exception expiration to requestor and approvers
6. Renewal workflow requires re-justification and prevents automatic renewals beyond policy limits (2 renewals maximum)
7. Active exceptions are reported in quarterly governance reports with status, justification, and compensating controls
8. All Zone 3 exceptions have documented compensating controls that are verified before approval
9. Exception register shows complete audit trail including request date, approvals, modifications, renewals, and closure
10. No active exceptions have exceeded maximum duration without renewal or remediation
11. Board or executive leadership receives quarterly exception metrics for Zone 3 (count, types, risk ratings)
12. Closed exceptions document remediation actions taken and lessons learned for continuous improvement

---

## Additional Resources

- [Power Automate Approval Flows](https://learn.microsoft.com/en-us/power-automate/get-started-approvals)
- [Dataverse Custom Tables](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-custom-entity)
- [SharePoint Lists for Governance Tracking](https://learn.microsoft.com/en-us/sharepoint/dev/business-apps/get-started/set-up-sharepoint-site-lists-libraries)
- [Microsoft Purview Audit Log](https://learn.microsoft.com/en-us/purview/audit-search)
- [Power Apps Canvas Apps for Governance Forms](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/getting-started)
- [Teams Adaptive Cards for Notifications](https://learn.microsoft.com/en-us/power-automate/create-adaptive-cards)

### Exception Management Best Practices

Organizations implementing formal exception management should consider:

**Approval Authority Tiering:**

| Risk Level | Approval Authority | Example |
|------------|-------------------|---------|
| **Low Risk** | Single approver (manager or Power Platform Admin) | Zone 1 inventory grace period; non-critical connector temporarily enabled |
| **Medium Risk** | Two approvers (manager + compliance or AI Governance Lead) | Zone 2 DLP policy override; approval bypass for time-sensitive project |
| **High Risk** | Three approvers (manager + compliance + CISO) | Zone 3 environment reclassification; risk acceptance for known security limitation |

**Expiration and Renewal Guidelines:**

- **Initial Duration:** Set conservative initial durations (30 days preferred) forcing early review and remediation planning
- **Renewal Justification:** Require updated risk assessment and evidence that remediation is in progress or still infeasible
- **Maximum Renewals:** Limit to 2 renewals (90 days total for Zone 3, 180 days for Zone 2); 3rd renewal requires executive escalation
- **Automatic Expiration:** Exceptions expire automatically; no grace periods unless new exception requested

**Compensating Controls Validation:**

- **Before Approval:** Verify compensating controls are technically feasible and provide adequate risk mitigation
- **During Exception:** Monitor compensating control effectiveness (e.g., enhanced logging, manual reviews, restricted access)
- **Evidence Collection:** Document compensating control implementation with screenshots, logs, or configuration exports

**Quarterly Exception Audit:**

1. Export all active and closed exceptions from Dataverse register
2. Review active exceptions for overdue renewals, missing compensating controls, or excessive duration
3. Analyze exception trends by type, zone, requestor, and approver to identify systemic issues
4. Report findings to AI Governance Lead and Compliance Officer
5. Update exception policies if patterns indicate need for permanent policy changes

### Implementation Caveats

!!! warning "Regulatory Compliance Considerations"
    Implementation of this control requires:
    
    - **Change Management Integration:** All policy overrides and exceptions must follow documented change management procedures with approval gates and rollback plans
    - **Audit Trail Preservation:** Exception records must be retained per regulatory requirements (typically 7 years for FSI) even after closure
    - **Separation of Duties:** Exception requestors cannot approve their own exceptions; approvers must be independent of the requesting business unit
    - **Board Reporting:** Zone 3 exceptions, especially risk acceptance decisions, should be reported to board or executive risk committees quarterly
    - **Regulatory Notification:** Certain exceptions (e.g., DLP policy overrides affecting customer data) may require notification to regulators or disclosure in supervisory examinations
    
    Organizations should verify that exception management procedures align with SOX internal control frameworks, FINRA supervisory procedures, and OCC/Fed model governance requirements. Consult legal and compliance teams before implementing exception processes for regulated agents.

### Exception vs. Policy Change

Not all policy deviations require exceptions. Organizations should distinguish:

| Scenario | Requires Exception? | Appropriate Action |
|----------|--------------------|--------------------|
| Temporary one-time override for specific agent/project | Yes | Exception process with time limit and approval |
| Permanent policy change based on business need | No | Formal policy update through governance committee |
| Emergency policy suspension for security incident | Partial | Incident response process; exception documented post-incident |
| Policy interpretation clarification | No | Governance documentation update; no policy override |

Use the exception process for **temporary deviations only**. If the same exception is requested repeatedly, evaluate whether the underlying policy should be updated permanently.

---

*Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current*
