<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
---
name: building-exception-management-process
description: >-
  Design and operationalize security policy exception and risk acceptance processes with formal workflows, approval hierarchies, time-bound tracking, and compensating control requirements.
domain: cybersecurity
subdomain: governance-risk-compliance
tags:
  - exception-management
  - risk-acceptance
  - policy-exception
  - compensating-controls
  - waiver
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: []
---

# Building Exception Management Process

## Overview

Security exceptions are inevitable in complex organizations. This technique covers building formal exception management processes that maintain governance rigor while enabling business agility — with approval workflows, compensating controls, time limits, and automated tracking.

Mode: `[MODE: ARCHITECT]` — Exception management process design and governance.

## Prerequisites

| Requirement | Details |
|---|---|
| Security policy framework | Policies to grant exceptions against |
| Approval authority matrix | Defined approval hierarchy |
| Python 3.10+ | For agent tooling |

## Workflow

### 1. Exception Request Workflow

```
Exception lifecycle:
├── 1. Request submission
│   ├── Requestor identifies policy/standard
│   ├── Documents business justification
│   ├── Describes scope and duration
│   ├── Proposes compensating controls
│   └── Identifies affected systems/data
├── 2. Risk assessment
│   ├── Security team evaluates risk
│   ├── Quantifies residual risk with exception
│   ├── Reviews compensating controls adequacy
│   └── Compares to risk appetite thresholds
├── 3. Approval routing
│   ├── Low risk: Security manager approval
│   ├── Medium risk: CISO approval
│   ├── High risk: Risk committee approval
│   └── Critical risk: Board/CRO approval
├── 4. Implementation
│   ├── Compensating controls deployed
│   ├── Monitoring enabled
│   ├── Expiration date set (max 12 months)
│   └── Exception logged in register
├── 5. Monitoring
│   ├── Compensating controls verified working
│   ├── Risk level reassessed quarterly
│   └── Approaching expiration alerts
└── 6. Closure
    ├── Remediated: original control implemented
    ├── Renewed: re-justified and re-approved
    └── Expired: exception revoked, compliance required
```

### 2. Exception Register Schema

```
Exception entry:
├── Exception ID: EXC-2026-001
├── Policy: Encryption Standard §4.2
├── Requestor: VP Engineering
├── Business justification: Legacy system cannot support TLS 1.2
├── Scope: Internal API between systems A and B
├── Compensating controls:
│   ├── Network segmentation (VLAN isolation)
│   ├── IP-based access restrictions
│   └── Enhanced logging and monitoring
├── Residual risk: Medium (score: 9)
├── Approver: CISO
├── Approved date: 2026-01-15
├── Expiration: 2026-07-15
├── Status: Active
└── Renewal count: 0
```

### 3. Escalation Matrix

```
Approval authority by risk level:
├── Low (score 1-4): Security Manager
│   └── Max duration: 12 months
├── Medium (score 5-9): CISO
│   └── Max duration: 6 months
├── High (score 10-16): Risk Committee
│   └── Max duration: 3 months
└── Critical (score 17-25): CRO/Board
    └── Max duration: 1 month, mandatory monthly review
```

## Verification

- [ ] Process documented and approved
- [ ] Stakeholders identified and engaged
- [ ] Tooling configured and automated where possible
- [ ] Outputs reviewed and validated
- [ ] Reporting integrated into GRC program
- [ ] Periodic review schedule established
