Runbook 03 — Compliance Monitoring & Exception Management

Compliance does not remain static.

Controls may be effective today and fail tomorrow because of:

Configuration Changes

New Users

New Cloud Resources

New Vendors

Expired Exceptions

Missed Reviews

Failed Integrations

Vulnerabilities

Policy Changes

Business Changes

A mature GRC program therefore cannot depend only on:

Annual Assessment
      ↓
Collect Evidence
      ↓
Report Compliance
      ↓
Wait Until Next Year

Instead, organizations need an ongoing process for:

Monitor
      ↓
Detect
      ↓
Validate
      ↓
Assess Risk
      ↓
Manage Exception
      ↓
Remediate
      ↓
Retest
      ↓
Close

This runbook provides that operational process.

The objective is to ensure that control failures, compliance gaps, approved exceptions, expired exceptions, and remediation activities remain visible and actively governed.

Mission Information

Field	Details
Runbook Type	Compliance Monitoring & Exception Management
Primary Role	GRC / Compliance Analyst
Supporting Roles	Control Owners, Security, IT, Risk, Internal Audit
Frequency	Continuous / Daily / Weekly / Monthly
Criticality	High
Primary Objective	Detect and manage compliance gaps before they become unmanaged risk
Key Outputs	Compliance Monitoring Register, Exception Register, Remediation Tracker, Control Health Dashboard
Escalation	Compliance Manager / Risk Owner / CISO / Business Owner

Runbook Objectives

This runbook provides procedures to:

monitor compliance-control status.
detect control failures.
detect compliance drift.
validate automated alerts.
classify control exceptions.
determine whether exceptions are authorized.
assess exception risk.
identify compensating controls.
obtain risk acceptance and approval.
assign exception expiry dates.
track remediation.
escalate material gaps.
monitor exception aging.
identify repeat exceptions.
validate compensating controls.
detect expired exceptions.
retest remediated controls.
validate closure.
maintain compliance dashboards.
support continuous assurance.

Operational Model

Compliance Requirement
      ↓
Control
      ↓
Monitoring
      ↓
PASS / FAIL
      ↓
Validation
      ↓
Exception?
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval / Remediation
      ↓
Retest
      ↓
Closure

Roles and Responsibilities

Compliance / GRC Analyst

Responsible for:

Monitor Control Status

Validate Exceptions

Coordinate Risk Assessment

Maintain Exception Register

Track Remediation

Escalate Overdue Issues

Prepare Compliance Reporting

Control Owner

Responsible for:

Operate Control

Investigate Failures

Implement Remediation

Provide Evidence

Maintain Compensating Controls

Risk Owner

Responsible for:

Evaluate Business Exposure

Accept Residual Risk

Approve Treatment

Escalate Material Risk

Security / IT

Responsible for technical analysis and remediation involving:

IAM

Cloud

Endpoints

Networks

Vulnerability Management

Logging

Infrastructure

Internal Audit

May independently evaluate:

Control Effectiveness

Exception Governance

Remediation

Closure Evidence

Compliance Monitoring Frequency

Continuous / Daily

Monitor controls such as:

Privileged MFA

Cloud Encryption

Security Logging

Public Exposure

Critical Vulnerabilities

Endpoint Protection

Backup Jobs

Weekly

Review:

Failed Controls

Open Exceptions

Overdue Remediation

Upcoming Exception Expiry

Compliance Drift

Integration Failures

Monthly

Review:

Compliance Trends

Exception Aging

Repeated Failures

Control Health

Risk Appetite Impact

Management Reporting

Quarterly

Review:

Exception Governance

Control Thresholds

Compensating Controls

Framework Coverage

Monitoring Effectiveness

Procedure 1 — Identify Controls Requiring Monitoring

Start with the compliance-control library.

Identify controls that are:

Critical

High Risk

Regulatory

Security Sensitive

Frequently Changing

Suitable for Automated Monitoring

Example:

Control	Frequency
Privileged MFA	Continuous
Encryption	Continuous
Vulnerability SLA	Daily
Logging	Daily
Access Review	Quarterly
Policy Review	Annual

Procedure 2 — Define Monitoring Method

Each control should specify:

Control

Data Source

Monitoring Method

Frequency

Pass Criteria

Failure Criteria

Owner

Example:

Control:
IAM-001 Privileged MFA

Source:
Identity Platform

Frequency:
Daily

Pass:
100% In-Scope Privileged Accounts Protected

Fail:
Any Unauthorized Privileged Account Without MFA

Procedure 3 — Define Control Thresholds

Avoid vague logic such as:

Mostly Compliant

Define specific thresholds.

Example:

MFA Coverage

100%
→ Healthy

Authorized Exception Only
→ Exception

Unauthorized Missing MFA
→ Failed

Procedure 4 — Monitor Control Status

Use available telemetry from:

IAM

Cloud Platforms

SIEM

Endpoint Platforms

Vulnerability Scanners

Backup Platforms

Source Control

GRC Platforms

Record:

Control

Timestamp

Population

Result

Exceptions

Source

Procedure 5 — Detect Compliance Drift

Compliance drift occurs when:

Previously Compliant
      ↓
Environment Changes
      ↓
Control No Longer Meets Requirement

Example:

Monday

100 Admins
100 MFA

PASS

Tuesday:

New Admin Created
Without MFA

Result:

99 / 100

FAIL

Procedure 6 — Detect Configuration Drift

Example:

Approved:

Production Storage
=
Private

Changed:

Production Storage
=
Public

This may create:

Security Risk
+
Compliance Failure

Procedure 7 — Create a Compliance Monitoring Event

When a control fails, create:

Monitoring Event ID

Control

Requirement

Detected Date

Source

Population

Failure

Owner

Severity

Status

Example:

MON-001

Control:
IAM-001

Failure:
2 Privileged Accounts Without MFA

Detected:
Today

Severity:
High

Procedure 8 — Validate the Alert

Do not automatically treat every failed automated test as a formal exception.

Validate:

Is the Resource In Scope?

Is the Population Complete?

Is the Integration Healthy?

Is the Test Logic Correct?

Is the Data Current?

Does an Approved Exception Exist?

Procedure 9 — Validate Scope

Example:

Test identifies:

5 Accounts
Without MFA

Investigation finds:

2 Decommissioned

1 Service Account

2 Active Administrators

The relevant failure population may therefore be:

Procedure 10 — Validate Integration Health

If monitoring depends on an integration, check:

Connection

Last Sync

Permissions

Scope

Record Count

Errors

Do not report:

100% Compliance

when:

50% of Environment
Was Never Monitored

Procedure 11 — Classify the Monitoring Result

Use statuses such as:

PASS

FAIL

REVIEW REQUIRED

APPROVED EXCEPTION

MONITORING ERROR

Procedure 12 — Determine Exception Type

A failed control may represent:

Unauthorized Exception

Approved Temporary Exception

Technical Exception

Business Exception

Compensating-Control Scenario

False Positive

Procedure 13 — Unauthorized Exception

Example:

Production Administrator
Without MFA

with:

No Approval

No Compensating Control

Status:

Unauthorized Exception

This should normally trigger immediate remediation.

Procedure 14 — Approved Exception

Example:

Legacy Application
Cannot Support MFA

but has:

Documented Risk

Approved Exception

Compensating Controls

Expiry Date

Status:

Approved Exception

Procedure 15 — Create Exception Record

Each approved exception should include:

Exception ID

Requirement

Control

Asset / Process

Business Justification

Risk

Owner

Compensating Controls

Approver

Start Date

Expiry Date

Remediation Plan

Status

Procedure 16 — Example Exception

Exception ID:
EX-001

Control:
IAM-001

System:
Legacy Payroll Platform

Reason:
Application does not support MFA

Risk:
Unauthorized Access

Compensating Controls:
PAM
Network Restriction
Enhanced Monitoring

Owner:
Application Manager

Approver:
CISO

Expiry:
90 Days

Procedure 17 — Risk Assess the Exception

Determine:

What Can Go Wrong?

What Is Exposed?

What Data Is Involved?

How Critical Is the System?

Who Can Exploit the Gap?

What Is the Business Impact?

Procedure 18 — Assess Inherent Exception Risk

Before considering compensating controls:

Likelihood
      ×
Impact
      ↓
Inherent Risk

Example:

Likelihood = 4

Impact = 5

Inherent Risk = 20
Critical

Procedure 19 — Identify Compensating Controls

A compensating control should reduce risk when the primary control cannot be fully implemented.

Example:

Primary:

MFA

Unavailable.

Potential compensating controls:

PAM

Network Restriction

Limited Access

Session Monitoring

Strong Password Controls

Enhanced Logging

Procedure 20 — Validate Compensating Controls

Do not only document:

Compensating Controls Exist

Validate:

Are They Implemented?

Are They Operating?

Do They Address the Risk?

Are They Monitored?

Are They Documented?

Procedure 21 — Assess Residual Exception Risk

After considering compensating controls:

Inherent Risk
      ↓
Compensating Controls
      ↓
Residual Risk

Compare residual risk against:

Risk Appetite

Procedure 22 — Exception Approval

Approval level should reflect risk.

Example:

Low
→ Control Owner

Medium
→ GRC Manager

High
→ Risk Owner / CISO

Critical
→ Executive Approval

Use the organization’s approved governance model.

Procedure 23 — Exception Approval Evidence

Maintain:

Who Approved?

When?

What Risk Was Accepted?

What Compensating Controls?

What Expiry?

Procedure 24 — Exception Expiry

Every temporary exception should normally include:

Expiry Date

Avoid:

No Expiry

unless an approved governance process specifically supports a different model.

Procedure 25 — Exception Duration

Duration should reflect:

Risk

Remediation Complexity

Business Need

Regulatory Requirement

Compensating-Control Strength

Procedure 26 — Monitor Upcoming Expiry

Create alerts:

30 Days Before Expiry

14 Days Before Expiry

7 Days Before Expiry

Expired

Procedure 27 — Review Near-Expiry Exceptions

Ask:

Has Primary Control
Been Remediated?

Is Exception
Still Necessary?

Has Risk Changed?

Are Compensating
Controls Still Effective?

Procedure 28 — Expired Exception

If:

Expiry Date
<
Today

then:

Exception
=
Expired

Do not silently continue operating under it.

Procedure 29 — Handle Expired Exception

Use:

Expired Exception
      ↓
Control Now Compliant?
     / \
   Yes   No
   ↓      ↓
Close   Reassess Risk
          ↓
     Renew or Escalate

Procedure 30 — Exception Renewal

Renewal should not be automatic.

Require:

Updated Business Justification

Current Risk Assessment

Compensating-Control Validation

New Remediation Plan

New Approval

Procedure 31 — Track Exception Aging

Use buckets:

0–30 Days

31–60 Days

61–90 Days

91–180 Days

180+ Days

Long-lived exceptions may indicate systemic control problems.

Procedure 32 — Monitor Repeat Exceptions

Example:

Same Control
Fails
Every Quarter

This may indicate:

Poor Control Design

Weak Automation

Insufficient Ownership

Process Failure

Procedure 33 — Escalate Repeat Exceptions

Repeated exceptions should trigger:

Root Cause Review

Control Design Review

Management Escalation

Potential Risk Reassessment

Procedure 34 — Open Remediation Action

For unauthorized or temporary exceptions requiring correction, create:

Action ID

Exception ID

Control

Owner

Action

Severity

Due Date

Status

Validation Requirement

Procedure 35 — Example Remediation

Exception:

2 Admin Accounts
Without MFA

Action:

Enable MFA

Review Admin Creation Process

Add Automated MFA Enforcement

Owner:

IAM

Procedure 36 — Define Remediation SLA

Example:

Critical
→ 24 Hours

High
→ 7 Days

Medium
→ 30 Days

Low
→ 90 Days

The organization should establish its own approved timelines.

Procedure 37 — Prioritize by Risk

Avoid prioritizing simply by:

Number of Exceptions

Consider:

Control Criticality

Asset Criticality

Exposure

Data Sensitivity

Regulatory Impact

Business Impact

Procedure 38 — Example Risk Prioritization

Exception A:

Public Production Database
Containing Customer PII

Exception B:

Test Server
Missing Optional Setting

Even if both are:

1 Exception

their risk is very different.

Procedure 39 — Track Remediation Status

Use:

Open

In Progress

Blocked

Pending Validation

Completed

Closed

Procedure 40 — Investigate Blocked Remediation

Possible blockers:

Budget

Technology Limitation

Vendor Dependency

Business Availability

Resource Constraints

Change Freeze

Document:

Blocker

Owner

Escalation

Expected Resolution

Procedure 41 — Remediation Escalation

Example:

Due Date Approaching
      ↓
Owner Reminder

Due Date Missed
      ↓
Manager

High Risk + Overdue
      ↓
Risk Owner

Critical + Overdue
      ↓
Executive

Procedure 42 — Root Cause Analysis

Do not only fix the immediate exception.

Example:

3 Admin Accounts
Without MFA

Ask:

Why?

Possible root cause:

New Administrator
Provisioning Workflow
Does Not Enforce MFA

Procedure 43 — Corrective vs Preventive Action

Corrective:

Enable MFA
on 3 Accounts

Preventive:

Modify Provisioning
Process to Prevent
Future Non-Compliant
Accounts

Procedure 44 — Monitor Corrective Action

Track:

Immediate Fix

Root Cause Fix

Preventive Action

Owner

Deadline

Validation

Procedure 45 — Validate Remediation Evidence

Examples:

Updated Configuration

System Report

Ticket Closure

New Workflow

Security Policy

Monitoring Results

Procedure 46 — Retest the Control

Do not close based solely on:

Action Completed

Run:

Control Test
Again

Procedure 47 — Retest Example

Before:

100 Administrators

98 MFA

FAIL

After:

100 Administrators

100 MFA

PASS

Procedure 48 — Validate Population During Retest

Do not only retest:

The Two Failed Accounts

when appropriate.

Validate the complete relevant population.

Procedure 49 — Confirm Root Cause Resolution

If remediation added:

MFA to 2 Accounts

but did not fix provisioning:

Next New Admin
May Fail Again

Closure may be premature.

Procedure 50 — Closure Criteria

Before closing an exception verify:

Primary Control Restored?

Remediation Complete?

Evidence Current?

Control Retested?

Root Cause Addressed?

Residual Risk Acceptable?

Procedure 51 — Close Exception

Update:

Status:
Closed

Closure Date

Validated By

Evidence

Retest Result

Procedure 52 — Preserve Exception History

Do not delete closed exception records.

Maintain:

Reason

Risk

Approvals

Compensating Controls

Remediation

Closure

for auditability.

Procedure 53 — Monitor Compliance Control Health

Create dashboard statuses:

Healthy

Degraded

Failed

Approved Exception

Unknown

Procedure 54 — Control Health Example

Control	Status
Privileged MFA	Failed
Encryption	Healthy
Logging	Degraded
Access Review	Approved Exception
Backup	Healthy

Procedure 55 — Detect Unknown Control Status

An unknown status may occur when:

Integration Failed

Evidence Missing

Population Unknown

Control Not Tested

Unknown should not be treated as:

PASS

Procedure 56 — Monitor Evidence Freshness

A control may show:

PASS

based on:

Old Evidence

Review:

Evidence Date

Control Frequency

Monitoring Frequency

Procedure 57 — Monitor Failed Integrations

Integration failure may create:

Monitoring Blind Spot

Example:

Cloud Connector
Offline 3 Days

Compliance status should potentially become:

Unknown / Monitoring Error

rather than continuing to display green.

Procedure 58 — Monitor Compliance Trends

Track:

Passing Controls

Failed Controls

Approved Exceptions

Expired Exceptions

Overdue Remediation

over time.

Example:

Month	Failed Controls
Jan	5
Feb	6
Mar	4
Apr	8

Ask:

Why Did Failures
Increase?

Procedure 59 — Monitor Compliance Drift

Example:

January
97%

February
96%

March
93%

April
91%

Do not only report the percentage.

Identify:

Which Controls?

Why?

Which Risks?

Who Owns Them?

Procedure 60 — Monitor Critical-Control Failures

Maintain separate visibility for:

Critical Controls

Example:

Overall Control Pass Rate:
98%

but:

Privileged MFA:
FAILED

This may be more important than the overall score.

Procedure 61 — Build Exception Dashboard

Track:

Total Active Exceptions

High-Risk Exceptions

Critical Exceptions

Exceptions Near Expiry

Expired Exceptions

Exceptions 180+ Days

Repeat Exceptions

Procedure 62 — Build Remediation Dashboard

Track:

Open Actions

Overdue Actions

Blocked Actions

Pending Validation

Critical Overdue

Average Closure Time

Procedure 63 — Build Control Monitoring Dashboard

Include:

Healthy Controls

Degraded Controls

Failed Controls

Unknown Controls

Approved Exceptions

Controls with Stale Evidence

Procedure 64 — Monitor Framework Impact

A single failed control may affect multiple frameworks.

Example:

IAM-001
Privileged MFA
      ↓
ISO 27001

SOC 2

PCI DSS

Do not count this as three unrelated control failures.

Procedure 65 — Use Common-Control View

Better:

One Control Failure
      ↓
Multiple Framework Impacts

This improves reporting consistency.

Procedure 66 — Compliance Impact Record

Maintain:

Control

Affected Frameworks

Affected Requirements

Severity

Exception Status

Procedure 67 — Regulatory Escalation

Some failures may create regulatory or contractual reporting obligations.

When potentially material:

Control Failure
      ↓
Compliance Review
      ↓
Legal / Privacy / Regulatory Review

Do not make legal determinations solely from the monitoring tool.

Procedure 68 — Risk Appetite Escalation

If a failed control raises residual risk above appetite:

Residual Risk
      >
Risk Appetite

escalate to:

Risk Owner

Procedure 69 — Risk Register Update

Material compliance failures may require:

Risk Rating Change

Risk Trend Change

Treatment Update

KRI Update

Procedure 70 — KRI Integration

Example:

KRI:
Privileged Accounts Without MFA

Target:
0

Current:
3

Status:
Critical

Link this to:

Identity Risk

Procedure 71 — KCI Integration

Example:

KCI:
Privileged MFA Coverage

Target:
100%

Current:
97%

This helps measure control operation.

Procedure 72 — Exception Concentration Analysis

Look for:

Many Exceptions
on Same Control

or:

Many Exceptions
in Same Business Unit

This may indicate systemic weaknesses.

Procedure 73 — Example Concentration

12 Exceptions
      ↓
Identity Domain

versus:

1–2 Exceptions
in Other Domains

This should trigger deeper analysis.

Procedure 74 — Exception Root Cause Categories

Useful categories:

Legacy Technology

Process Failure

Human Error

Configuration Drift

Resource Constraint

Vendor Limitation

Design Gap

Procedure 75 — Root Cause Dashboard

Example:

Root Cause	Exceptions
Legacy Technology	8
Process Failure	6
Configuration Drift	5
Vendor Limitation	3

This helps prioritize systemic improvement.

Procedure 76 — Monitor Exception Renewals

Track:

First Approval

Number of Renewals

Total Age

Reason for Renewal

Repeated renewals deserve scrutiny.

Procedure 77 — Long-Lived Exception Rule

Example:

Exception Age
>
180 Days

may require:

Senior Management Review

depending on organizational policy.

Procedure 78 — Compliance Monitoring Meeting

Hold periodic operational review covering:

Critical Failures

New Exceptions

Expired Exceptions

Overdue Remediation

Repeat Failures

Monitoring Gaps

Risk Appetite Breaches

Procedure 79 — Weekly Compliance Review

Recommended attendees:

GRC

Security

IAM

Cloud

IT Operations

Relevant Control Owners

Focus on:

Action

rather than simply reporting metrics.

Procedure 80 — Monthly Management Summary

Prepare:

Overall Control Health

Critical Failures

Exception Count

Expired Exceptions

Overdue Remediation

Compliance Trends

Risk Appetite Impact

Example Management Summary

CONTROL HEALTH

Healthy               92
Degraded                5
Failed                  3
Approved Exceptions     7
Unknown                 1

EXCEPTIONS

Active                 12
High / Critical         4
Near Expiry             3
Expired                 1

REMEDIATION

Open                   10
Overdue                 3
Blocked                 1
Pending Retest          2

Procedure 81 — Executive Escalation Criteria

Escalate when:

Critical Control Fails

Material Regulatory Control Fails

Residual Risk Exceeds Appetite

Critical Exception Expires

Critical Remediation Overdue

Monitoring Blind Spot Affects Critical Scope

Multiple Repeat Failures Occur

Procedure 82 — Compliance Monitoring Log

Maintain:

Date	Control	Event	Risk	Action	Owner	Status
10-Sep	IAM-001	2 admins without MFA	High	Remediation	IAM	Open
11-Sep	LOG-001	Logging disabled	High	Enabled logging	SOC	Closed

Procedure 83 — Daily Operations Checklist

critical automated control failures reviewed.
monitoring integrations healthy.
critical exceptions reviewed.
expired exceptions identified.
urgent remediation followed up.
monitoring blind spots escalated.

Procedure 84 — Weekly Operations Checklist

all failed controls reviewed.
new exceptions validated.
near-expiry exceptions reviewed.
overdue remediation reviewed.
repeat failures identified.
root causes analyzed.
compensating controls validated.
control-health dashboard updated.

Procedure 85 — Monthly Governance Checklist

exception trends reviewed.
long-lived exceptions reviewed.
renewal patterns reviewed.
compliance drift reviewed.
critical controls reviewed.
risk appetite impacts reviewed.
KRI / KCI trends reviewed.
management report issued.

Common Issue — Failed Automated Test

Condition

MFA Test
=
FAIL

Action

Validate Population
      ↓
Validate Test
      ↓
Check Exception
      ↓
Confirm Failure
      ↓
Remediate

Common Issue — Approved Exception Near Expiry

Condition

Expiry:
7 Days

Action

Contact Owner
      ↓
Review Remediation
      ↓
Reassess Risk
      ↓
Close or Renew

Common Issue — Expired Exception

Condition

Exception Expired

Action

Immediate Review
      ↓
Control Compliant?
      ↓
If No:
Escalate Risk

Common Issue — Compensating Control Failed

Condition

Primary control:

MFA Unsupported

Compensating control:

PAM

but:

PAM Monitoring Disabled

Action

Reassess Residual Risk
      ↓
Escalate
      ↓
Restore Compensating Control

The exception approval may no longer be valid.

Common Issue — Repeat Exception

Condition

Same Access Review
Missed
for 3 Quarters

Action

Root Cause Analysis
      ↓
Control Redesign
      ↓
Management Escalation

Condition

AWS Integration
Failed

for:

Critical Production Accounts

Action

Mark Status Unknown
      ↓
Restore Integration
      ↓
Validate Data
      ↓
Re-run Tests

Common Issue — Control Percentage Looks Healthy

Condition

99.5%
Compliant

but failure involves:

Production Administrator
Without MFA

Action

Prioritize based on:

Risk

not only percentage.

Exception Escalation Matrix

Severity	Example	Escalation
Critical	Critical control failure / expired critical exception	Immediate
High	High-risk unauthorized exception	Same business day
Medium	Temporary approved exception	Weekly review
Low	Minor deviation with low risk	Standard queue

Compliance Monitoring Metrics

Monitor:

Control Pass Rate

Critical Control Failures

Active Exceptions

Critical Exceptions

Expired Exceptions

Exception Aging

Repeat Exceptions

Overdue Remediation

Mean Time to Remediate

Monitoring Coverage

Example Targets

Illustrative only:

Metric	Example Target
Expired Exceptions	0
Critical Unauthorized Exceptions	0
Critical Remediation Past SLA	0
Unknown Critical-Control Status	0
Critical Monitoring Integration Failures	0

Control Health Dashboard

A useful dashboard may show:

COMPLIANCE CONTROL HEALTH

Total Controls              120

Healthy                     105

Degraded                      7

Failed                        3

Approved Exceptions           4

Unknown                       1

Exception Dashboard

EXCEPTION MANAGEMENT

Active Exceptions            18

High / Critical               5

Near Expiry                   4

Expired                       1

180+ Days                     3

Repeat Exceptions             2

Remediation Dashboard

REMEDIATION

Open Actions                 15

Overdue                       4

Blocked                       2

Pending Validation            3

Critical Past SLA             1

Required Operational Records

Maintain:

01 Compliance Monitoring Register

02 Control Health Register

03 Compliance Exception Register

04 Exception Risk Assessments

05 Compensating Control Register

06 Exception Approval Log

07 Exception Expiry Tracker

08 Remediation Register

09 Retest & Validation Log

10 Compliance Monitoring Dashboard

11 Exception Aging Dashboard

12 Compliance Operations Log

Runbook Completion Criteria

The monitoring cycle is complete when:

Control Status Is Known

Failures Are Validated

Exceptions Are Classified

Risk Is Assessed

Compensating Controls Are Verified

Approvals Are Documented

Expiry Is Tracked

Remediation Is Assigned

Retesting Is Completed

Closure Is Validated

Operational Handover

When handing over compliance monitoring operations, provide:

Critical Failed Controls

New Unauthorized Exceptions

Critical Approved Exceptions

Expired Exceptions

Exceptions Near Expiry

Overdue Remediation

Blocked Remediation

Monitoring Failures

Pending Retests

Risk Appetite Breaches

Runbook Deliverables

After implementing this runbook, maintain:

01 Continuous Compliance Monitoring Register

02 Control Failure Register

03 Compliance Exception Register

04 Exception Risk Assessment Template

05 Compensating Control Assessment

06 Exception Approval Matrix

07 Exception Expiry Dashboard

08 Remediation Tracker

09 Retest & Closure Register

10 Control Health Dashboard

11 Compliance Trend Dashboard

12 Management Compliance Report

Runbook Success Criteria

A mature compliance-monitoring and exception-management process should allow the organization to answer:

Which Controls
Are Currently Failing?

Are the Failures Real?

Which Failures
Have Approved Exceptions?

Which Exceptions
Are Unauthorized?

What Risk
Does Each Exception Create?

What Compensating
Controls Exist?

Are Those Controls
Actually Working?

Who Approved
the Exception?

When Does
It Expire?

Which Exceptions
Have Been Renewed?

Which Exceptions
Are Becoming Permanent?

Which Remediation
Actions Are Overdue?

Which Controls
Fail Repeatedly?

Has Root Cause
Been Addressed?

Was Remediation
Retested?

Are We
Within Risk Appetite?

Can Leadership See
Material Compliance Drift?

Are We Managing
Compliance Continuously?

Or Are We
Waiting for the
Next Audit?

If these questions can be answered consistently, the organization has moved from periodic compliance checking toward continuous compliance governance and disciplined exception management.

What’s Next?

➡️ Next: Runbook 04 — GRC Reporting & Executive Governance

In the next runbook, you will move from operational control monitoring into structured management and executive reporting.

You will build a repeatable process for transforming:

Enterprise Risks

Compliance Status

Control Health

Audit Findings

Third-Party Risk

Exceptions

KRIs

KCIs

Remediation

into:

Operational Reporting
      ↓
GRC Management Review
      ↓
Risk Committee Reporting
      ↓
Executive Reporting
      ↓
Board-Level Governance

The focus will be on ensuring that GRC reporting is accurate, risk-based, actionable, audience-specific, traceable, and connected to management decisions.

➡️ Next: Runbook 04 — GRC Reporting & Executive Governance