13 SOC Audit Findings & Exceptions

SOC examinations are designed to provide assurance over controls.

When testing shows that a control did not operate as expected, the result may become a:

Control Exception

Audit Finding

Control Deficiency

Evidence Gap

Scope Gap

These terms are related, but they are not always identical.

The important GRC question is not simply:

Did an exception occur?

The stronger question is:

What failed, how significant is the failure, what risk does it create, is the issue isolated or systemic, and what must be done to prevent recurrence?

A mature findings lifecycle looks like:

Control Test
      ↓
Exception Identified
      ↓
Validate Condition
      ↓
Determine Scope
      ↓
Assess Risk
      ↓
Determine Severity
      ↓
Management Response
      ↓
Root Cause Analysis
      ↓
Correction
      ↓
Corrective Action
      ↓
Retest
      ↓
Close / Reopen

For GRC professionals, this is where evidence, audit testing, enterprise risk, control ownership, and remediation come together.

Learning Objectives

By the end of this lesson, you will be able to:

Explain what a SOC control exception is.
Distinguish an exception from a broader finding.
Understand readiness gaps versus audit exceptions.
Distinguish isolated from systemic failures.
Understand evidence exceptions.
Understand population exceptions.
Assess exception significance.
Evaluate financial, security, operational, and customer impact.
Understand management responses.
Perform root cause analysis.
Distinguish correction from corrective action.
Build remediation plans.
Understand retesting.
Understand modified auditor opinions.
Understand qualified and adverse opinions.
Build SOC exception and findings registers.
Prepare management responses.
Track closure evidence.
Build SOC findings dashboards.

1. What Is a SOC Exception?

A control exception occurs when evidence shows that a control did not operate as described or expected.

Example control:

Production changes require approval before deployment.

Auditor test:

Sample:
40 Production Changes

Result:

37
→ Approval Before Deployment

3
→ Approval After Deployment

The three deviations are control exceptions.

2. Exception vs Finding

An exception is often the specific deviation identified during testing.

A finding is the broader documented issue and its impact.

Conceptually:

Exception
      ↓
Analysis
      ↓
Finding

Example:

Exception:
3 changes lacked timely approval

Finding:

Production change-management controls did not operate consistently during the examination period, increasing the risk of unauthorized or inadequately tested production changes.

3. Exception vs Readiness Gap

A readiness gap is identified before the formal SOC examination.

Example:

SOC Readiness Review
      ↓
Q2 Access Review Missing

The organization may still have time to remediate.

An audit exception is identified during formal examination testing.

Auditor Testing
      ↓
Control Failure

4. Why Readiness Gaps Matter

A readiness program attempts to find:

Potential Audit Exceptions

before:

Formal Auditor Testing

This is why readiness work reduces surprises.

5. Common Exception Categories

Useful categories include:

Control Execution

Evidence

Population

Timing

Authorization

Scope

Configuration

Review

Remediation

6. Control Execution Exception

Example:

Control:

Quarterly access reviews are performed.

Expected:

Q1
Q2
Q3
Q4

Actual:

Q1 ✓
Q2 ✓
Q3 ✗
Q4 ✓

This is an operating exception.

7. Evidence Exception

Example:

Control Owner:
Review was completed.

But:

Evidence:
Unavailable

The auditor may not be able to confirm control operation.

8. Population Exception

Example:

Control population provided:

Employees

but excludes:

Contractors

even though contractors are within control scope.

This is a population-completeness problem.

9. Timing Exception

Example requirement:

Terminate Access Within 24 Hours

Sample:

Employee Terminated:
Monday 10:00

Access removed:

Wednesday 15:00

The control operated late.

10. Authorization Exception

Example:

High-Value Refund
      ↓
Processed
      ↓
Approval Obtained Later

This violates the preventive nature of the control.

11. Configuration Exception

Example:

Control:

All privileged users require MFA.

Result:

64 Privileged Users

61 MFA Enabled

3 MFA Disabled

The three users represent control exceptions.

12. Scope Exception

Example SOC scope:

Core SaaS Application

Actual processing:

Core SaaS
+
Support Platform

If support platform processes in-scope customer data but is excluded, there may be a scope deficiency.

13. Isolated vs Systemic Failure

This distinction is extremely important.

An isolated exception is limited in nature.

A systemic weakness suggests the control is unreliable more broadly.

14. Isolated Exception Example

Population:

500 Access Requests

Sample:

Exception:

Cause:

Approval attachment missing

The issue may be isolated depending on context.

15. Systemic Exception Example

Sample:

Exceptions:

This strongly suggests the control may not operate consistently.

16. Frequency Matters

Compare:

1 / 40

with:

20 / 40

But raw percentages alone are not enough.

Also assess:

Risk

Control Importance

Nature of Failure

Population

Cause

17. Exception Severity Factors

Consider:

Control Criticality

Risk Impact

Number of Exceptions

Duration

Data Sensitivity

Customer Impact

Regulatory Impact

Recurrence

Compensating Controls

18. Severity Model

An organization may use:

Critical

High

Medium

Low

according to its risk methodology.

19. Critical Finding Example

Example:

Privileged Authentication
      ↓
No MFA
      ↓
Multiple Production Administrators
      ↓
Security Incident Occurred

This may warrant critical escalation.

20. High Finding Example

Quarterly Access Review
      ↓
Two Consecutive Quarters Missed

for a critical platform.

21. Medium Finding Example

One Annual Policy Review
Completed 30 Days Late

with no material impact.

22. Low Finding Example

Minor documentation inconsistency that does not undermine control operation.

23. Risk Statement

A strong finding should clearly state risk.

Use:

There is a risk that [event] may occur because [control condition], resulting in [business impact].

Example:

There is a risk that unauthorized production changes may be deployed because pre-deployment approval was not consistently enforced, potentially resulting in service disruption or security weakness.

24. Exception Assessment Workflow

Use:

Exception
      ↓
Validate Evidence
      ↓
Confirm Requirement
      ↓
Confirm Population
      ↓
Determine Extent
      ↓
Assess Risk
      ↓
Classify
      ↓
Escalate if Required

25. Validate the Exception

Before documenting a finding ask:

Is the evidence correct?

Is the control description correct?

Is the sample correct?

Is the transaction actually in scope?

False assumptions should be corrected before finalizing a finding.

26. False Positive Example

Auditor identifies:

Missing Access Approval

Investigation finds:

Approval Exists
in Authoritative IAM Workflow

but was not included in the original evidence package.

This may be:

Evidence Submission Issue

rather than a control failure.

27. Confirm the Requirement

A finding should be tied to a requirement.

Examples:

Control Description

Policy

Standard

TSC Criterion

Customer Commitment

Procedure

Avoid findings based only on opinion.

28. Strong Finding Structure

Use:

Requirement
      ↓
Condition
      ↓
Evidence
      ↓
Risk

29. Example Finding

The Access Control Standard requires privileged access to be reviewed quarterly. The assessment identified that the Q3 privileged-access review was not performed for the production environment. This increases the risk that excessive or inappropriate privileged access may remain undetected.

30. Finding Documentation

Recommended fields:

Finding ID

Control ID

Criterion

Requirement

Condition

Evidence

Population

Sample

Risk

Severity

Owner

Status

31. Build SOC Exception Register

Create:

01 SOC Exception Register

Use:

ID	Control	Exception	Severity	Owner	Status

32. Exception Register Example

ID	Control	Exception	Severity
EX-001	IAM-003	Q3 Review Missing	High
EX-002	CHG-001	3 Changes Missing Approval	High
EX-003	VUL-001	Monthly Review Late	Medium

33. Finding Severity Matrix

Create:

02 Finding Severity Matrix

Use:

Factor	Low	Medium	High	Critical

Possible factors:

Control Impact

Customer Impact

Data Sensitivity

Frequency

Recurrence

Compensating Controls

34. Example Severity Logic

Critical:

Material control failure
+
Severe business/security impact

High:

Important control weakness
+
Significant residual risk

Medium:

Limited control weakness
+
Manageable risk

Low:

Minor deviation
+
Limited impact

35. Auditor Exception vs Management Finding

The service auditor determines how testing results are reflected in the formal SOC report.

Management may maintain a more detailed internal finding record.

Example:

Auditor Report:
1 exception

Internal remediation:

Root Cause

Technology Gap

Process Gap

Training Gap

may be much more detailed.

36. Management Response

Management may be asked to provide a response to a control exception.

A strong response should include:

Acknowledgment

Context

Root Cause

Immediate Correction

Corrective Action

Target Date

37. Weak Management Response

Avoid:

We disagree and believe the control is generally effective.

unless supported by evidence.

Also avoid:

The team has been reminded.

if the underlying process remains unchanged.

38. Strong Management Response

Example:

Management acknowledges the exception. The issue occurred because emergency production deployments bypassed the standard approval workflow. Effective 15 August, emergency changes require documented approval through the central ITSM process, followed by mandatory post-implementation review. The updated process will be monitored monthly by Engineering Operations.

39. Management Response Template

Create:

03 Management Response Template

Use:

Finding ID:

Management Position:

Root Cause:

Immediate Correction:

Corrective Action:

Owner:

Target Date:

Retest Evidence:

40. Root Cause Analysis

Do not stop at:

Human Error

or:

Forgot

Ask why the process allowed the error.

41. Five Whys

Example:

Problem:

Access Review Missed

Why?

Manager Did Not Complete It

Why?

Reminder Was Missed

Why?

Manual Calendar Used

Why?

No Central Control Scheduling

Root cause:

Recurring compliance controls are not centrally scheduled and escalated.

42. Build Root Cause Analysis Record

Create:

04 Root Cause Analysis Record

Include:

Problem

Immediate Cause

Contributing Factors

Root Cause

Control Weakness

43. Root Cause Categories

Useful categories include:

Process

Technology

People

Governance

Ownership

Training

Architecture

Third Party

44. Process Root Cause

Example:

No Formal Access Removal Workflow

45. Technology Root Cause

Example:

SaaS Platform Not Integrated
with Identity Provider

46. Governance Root Cause

Example:

No Owner Assigned
for Recovery Testing

47. Architecture Root Cause

Example:

Legacy Application
Requires Permanent Admin Accounts

48. Third-Party Root Cause

Example:

Provider Cannot Generate Required Logs

49. Correction vs Corrective Action

This distinction is essential.

Correction fixes the immediate problem.

Corrective action prevents recurrence.

50. Example — MFA

Finding:

3 Admin Accounts Without MFA

Correction:

Enable MFA on 3 Accounts

Corrective action:

Implement Continuous Privileged MFA Monitoring

51. Example — Missed Access Review

Correction:

Perform Overdue Review

Corrective action:

Automated Review Scheduling
+
Escalation

52. Example — Change Approval

Correction:

Review Affected Changes

Corrective action:

CI/CD Deployment Blocked
Without Approved Change Record

53. Example — Vendor Review

Correction:

Review Overdue Vendors

Corrective action:

Automated Vendor Reassessment Calendar

54. Build Corrective Action Tracker

Create:

05 Corrective Action Tracker

Use:

Finding	Correction	Corrective Action	Owner	Target	Status

55. Remediation Status

Use:

Open

Planned

In Progress

Blocked

Ready for Retest

Closed

56. Remediation Target Dates

Set according to:

Severity

Risk

Complexity

Dependencies

Do not use one generic timeline for every finding.

57. Example Targets

An organization might use:

Critical
→ Immediate / Urgent

High
→ 30 Days

Medium
→ 90 Days

Low
→ 180 Days

according to internal policy.

58. Blocked Remediation

If remediation depends on:

Vendor Upgrade

Budget

Migration

Architecture Change

document the blocker.

59. Compensating Controls

When permanent remediation cannot be immediate, use compensating controls.

Example:

Legacy System
Cannot Support SSO

Compensating controls:

MFA

Restricted Network

Reduced Administrators

Enhanced Logging

Monthly Review

60. Risk Acceptance

If residual risk remains:

Finding
      ↓
Risk Assessment
      ↓
Risk Owner Decision

GRC should not silently convert unresolved findings into accepted risk.

61. Exception vs Approved Exception

A SOC testing exception means:

Control Did Not Operate as Expected

An approved internal exception means:

Management Formally Accepted
a Defined Temporary Deviation

These are different concepts.

62. Approved Internal Exception

Should include:

Requirement

Scope

Reason

Risk

Compensating Controls

Owner

Approver

Expiry

63. Auditor View of Approved Exceptions

An internal exception does not automatically mean the auditor will conclude:

No Audit Exception

The auditor evaluates the control against the report criteria and control description.

64. Retesting

After remediation, the control should be retested.

Use:

Original Failure
      ↓
Correction
      ↓
Corrective Action
      ↓
Retest

65. Retest Objective

Ask:

Does the control now operate effectively and has the underlying cause been addressed?

66. Retest Example — MFA

Before:

61 / 64

After:

64 / 64

Also test:

Monitoring

to ensure future accounts cannot bypass MFA.

67. Retest Example — Change Control

Before:

3 / 40
Missing Approval

After remediation:

New Sample:
20 / 20
Approved Before Deployment

Also verify:

Deployment Enforcement Active

68. Retest Register

Create:

06 SOC Retest Register

Use:

Finding	Retest Date	Population	Result	Reviewer	Closure

69. Closure Evidence

A finding should not close based only on:

Owner Confirmation

Closure evidence may include:

Updated Configuration

New Workflow

Testing

Sample Evidence

Policy-as-Code

Monitoring

70. Closure Decision

Use:

Effective
→ Close

Partially Effective
→ Keep Open

Ineffective
→ Reopen / Escalate

71. Failed Retest

If retest fails:

Finding Reopened
      ↓
Deeper Root Cause Analysis

Ask:

Was Root Cause Wrong?

Was Scope Too Narrow?

Was Implementation Incomplete?

Did the Process Fail Again?

72. Repeat Findings

Recurring findings are important.

Example:

2025
Access Review Gap

2026
Access Review Gap

This may indicate:

Systemic Governance Weakness

73. Repeat Finding KRI

Track:

Number of Repeat SOC Findings

Target:

for high-risk issues.

74. Audit Opinion

SOC reports include the service auditor’s opinion.

A control exception does not automatically determine the entire opinion.

The auditor evaluates the report as a whole.

75. Unmodified Opinion

An unmodified opinion generally means the auditor did not identify matters requiring modification of the opinion.

Important:

Unmodified Opinion
≠
Zero Exceptions

Individual control-testing exceptions may still be reported.

76. Qualified Opinion

A qualified opinion indicates a material issue affecting part of the auditor’s conclusion.

Conceptually:

Overall Criteria
      ↓
Mostly Satisfied

Except for:
Specific Material Matter

77. Adverse Opinion

An adverse opinion indicates a more significant issue with the subject matter being examined.

For a critical provider, this should trigger significant risk review.

78. Disclaimer / Inability to Obtain Evidence

In some assurance contexts, insufficient evidence may prevent an auditor from forming the intended opinion.

The exact audit-report terminology should be interpreted carefully with the auditor.

79. Modified Opinion Review

If reviewing a provider SOC report:

Qualified / Adverse / Other Modification
      ↓
Identify Cause
      ↓
Determine Customer Relevance
      ↓
Risk Assessment
      ↓
Additional Assurance

80. Provider SOC Exception Review

A customer GRC analyst should not simply record:

Provider Has Exceptions

Instead ask:

Which Control?

Which Service?

Which TSC?

How Many?

What Cause?

What Customer Impact?

81. Example Provider Exception

Control:

Terminated user access removed within 24 hours.

Auditor result:

40 Samples

5 Exceptions

Customer uses provider for:

Sensitive Customer Data

Potential assessment:

High Relevance

82. Provider Management Response

Review whether provider says:

Issue Fixed

versus whether there is evidence of:

Root Cause Corrected

New Control Implemented

Retest Planned

Sometimes the provider SOC report is clean, but the customer fails to implement a CUEC.

Example:

Provider expects:

Customer Reviews Admin Users Quarterly

Customer:

No Review Performed

This is a customer-side control gap.

84. Subservice Organization Findings

A provider may depend on:

Cloud Provider

and use the carve-out method.

If underlying assurance is unavailable:

Assurance Gap

may remain even if primary provider controls are effective.

85. Finding Ownership

Findings should have an accountable owner.

Examples:

IAM Finding
→ IAM Director

Change Finding
→ Engineering Director

Vendor Finding
→ Procurement / TPRM

Backup Finding
→ Infrastructure Manager

86. Finding Owner vs Risk Owner

These may differ.

Example:

Finding Owner:
IAM Director

Risk Owner:
CISO

87. Finding Escalation

Escalate based on:

Severity

Due Date

Repeat Failure

Business Impact

88. Example Escalation

High Finding
      ↓
Overdue 30 Days
      ↓
CISO / Risk Committee

89. Finding Aging

Track:

0–30 Days

31–60 Days

61–90 Days

>90 Days

90. Findings Dashboard

Useful metrics:

Open Findings

High Findings

Overdue Findings

Repeat Findings

Ready for Retest

Failed Retests

Closed Findings

91. Example Dashboard

Metric	Current
Open Findings	18
High Findings	4
Overdue Findings	3
Ready for Retest	5
Failed Retests	1
Repeat Findings	2

92. Finding KPI

Example:

KPI:
Percentage of SOC findings
remediated within target date

93. Finding KRI

Example:

KRI:
High-risk SOC findings
past remediation target

Tolerance:

94. Repeat Finding KRI

High-risk repeat findings
from previous examination

95. Failed Retest KRI

Findings failing independent retest

96. Finding Trend Analysis

Track by domain:

IAM

Change Management

Vendor Risk

Incident Response

Availability

This helps identify systemic control weakness.

97. Example Trend

IAM Findings:
Q1 2
Q2 5
Q3 8

Trend:

Deteriorating

Management should investigate broader IAM governance.

98. Build Finding Trend Register

Create:

07 SOC Finding Trend Register

Use:

Period	Domain	Findings	Repeat	Overdue

99. Audit Finding Lifecycle

Use:

Detection
      ↓
Validation
      ↓
Classification
      ↓
Ownership
      ↓
Management Response
      ↓
Root Cause
      ↓
Remediation
      ↓
Retest
      ↓
Closure

100. Finding Governance Meeting

For material findings, review:

Status

Risk

Blockers

Target

Evidence

Retest

with responsible management.

101. Management Reporting

Executives usually need:

What Failed?

How Serious?

What Risk?

Who Owns It?

When Will It Be Fixed?

not detailed audit sampling methodology.

102. Executive Finding Summary

Example:

Four high-risk SOC readiness findings remain open. The most significant relate to privileged MFA coverage, production change approval, vendor reassessment, and disaster-recovery testing. Remediation plans are active, with two items expected to be ready for retest this month.

103. Audit Committee Reporting

Where relevant, report:

Material Findings

Repeat Findings

Overdue Remediation

Modified Opinions

Management Risk Acceptance

104. Findings and Risk Register

Material SOC findings should connect to enterprise risk.

Example:

SOC Finding
      ↓
Privileged MFA Failure
      ↓
Cyber Risk Register

105. Findings and Control Library

Update control status:

Effective
      ↓
Partially Effective

where appropriate.

106. Findings and Policies

If the audit reveals a design issue:

Update Policy / Standard

may be part of remediation.

107. Findings and Training

Training may help where a knowledge gap exists.

But avoid using:

Retrain Staff

as the only corrective action when the process itself is weak.

108. Findings and Automation

Repeat manual failures may indicate automation opportunity.

Example:

Missing Access Approval
      ↓
Automated Workflow Enforcement

109. Findings and Preventive Controls

Mature remediation moves from:

Detect Failure

toward:

Prevent Failure

Example:

Unauthorized Deployment
      ↓
CI/CD Policy
Blocks Deployment

110. Findings and Continuous Monitoring

After correction:

Control
      ↓
Continuous Signal
      ↓
Violation Alert

can reduce recurrence.

111. Example — IAM Finding Lifecycle

Finding:

3 Privileged Users Without MFA

Correction:

Enable MFA

Root cause:

Local Admin Accounts
Excluded From Central Monitoring

Corrective action:

Include Local Admins
in Privileged Identity Monitoring

Retest:

100% Privileged MFA

112. Example — Change Management Finding

Finding:

3 of 40 Changes
Approved After Deployment

Root cause:

Emergency Deployment Workflow
Bypasses Approval

Corrective action:

Emergency Workflow
Requires Approval
+
Post-Implementation Review

113. Example — Vendor Risk Finding

Finding:

8 Critical Vendors
Past Annual Assessment

Root cause:

Manual Spreadsheet Tracking

Corrective action:

Automated Reassessment Workflow
+
Escalation

114. Example — Availability Finding

Finding:

Recovery Test Not Completed
for Critical Service

Root cause:

No Central DR Schedule

Corrective action:

Central Recovery Calendar
+
Executive Escalation

115. Example — Evidence Finding

Finding:

Q2 Access Review Evidence Missing

Root cause:

Review Performed Through Email
No Evidence Repository

Corrective action:

Central Review Workflow
+
Automated Retention

116. Common Findings Management Mistakes

Mistake 1 — Arguing Every Exception

Not every issue should become a negotiation exercise.

Mistake 2 — No Requirement in Finding

The finding becomes subjective.

Mistake 3 — Severity Based Only on Sample Percentage

Risk context is ignored.

Mistake 4 — Correction Equals Remediation

Root cause remains.

Mistake 5 — Human Error Used as Root Cause

Process weaknesses remain hidden.

Mistake 6 — Owner Says Fixed

No independent validation.

Mistake 7 — Failed Retest Closed Anyway

Assurance becomes unreliable.

Mistake 8 — Repeat Findings Not Escalated

Systemic weakness continues.

Mistake 9 — Management Response Too Defensive

The real issue is not addressed.

Mistake 10 — Audit Findings Not Linked to Risk

Compliance and risk management become disconnected.

117. Weak Findings Process

Auditor Finds Issue
      ↓
Team Fixes Sample
      ↓
Close

118. Strong Findings Process

Exception
      ↓
Validate
      ↓
Determine Scope
      ↓
Risk Assessment
      ↓
Root Cause
      ↓
Correction
      ↓
Corrective Action
      ↓
Evidence
      ↓
Retest
      ↓
Close

119. Practical Activity — Build SOC Exception Register

Create:

01 SOC Exception Register

Add at least 15 fictional exceptions across:

IAM

Change Management

Vulnerability Management

Incident Response

Vendor Risk

Availability

Confidentiality

120. Practical Activity — Build Finding Severity Matrix

Create:

02 Finding Severity Matrix

Define:

Critical

High

Medium

Low

using:

Risk

Frequency

Impact

Control Criticality

Recurrence

121. Practical Activity — Build Root Cause Record

Create:

03 Root Cause Analysis Record

Use five fictional findings and perform:

Problem
      ↓
Why?
      ↓
Why?
      ↓
Why?
      ↓
Root Cause

122. Practical Activity — Build Corrective Action Tracker

Create:

04 Corrective Action Tracker

Use:

Finding	Correction	Corrective Action	Owner	Due	Status

123. Practical Activity — Build Retest Register

Create:

05 SOC Retest Register

Add:

Retest Date

Population

Sample

Evidence

Result

124. Practical Activity — Build Management Response Template

Create:

06 Management Response Template

Include:

Acknowledgment

Context

Root Cause

Correction

Corrective Action

Target Date

Owner

Retest

125. Practical Activity — Build Findings Dashboard

Create:

07 SOC Findings Dashboard

Track:

Open Findings

Severity

Overdue

Repeat

Ready for Retest

Failed Retest

Closed

126. Practical Activity — Analyze a SOC Exception

Use this fictional case:

Control:
Terminated user access
removed within 24 hours

Population:
125 Terminations

Sample:
25

Exceptions:
4

Maximum Delay:
9 Days

1 User:
Privileged Account

Document:

Requirement

Condition

Risk

Severity

Root Cause

Correction

Corrective Action

Retest Procedure

127. SOC Findings Checklist

Validation

Requirement confirmed.
Exception validated.
Evidence reviewed.
Population confirmed.
Sample confirmed.
False positive ruled out.

Risk

Business impact assessed.
Security impact assessed.
Customer impact assessed.
Frequency evaluated.
Compensating controls considered.
Severity assigned.

Finding

Requirement documented.
Condition documented.
Evidence referenced.
Risk clearly stated.
Owner assigned.

Root Cause

Immediate cause identified.
Process analyzed.
Technology analyzed.
Governance analyzed.
Root cause documented.

Management Response

Management acknowledges condition.
Correction identified.
Corrective action identified.
Owner assigned.
Target date defined.

Remediation

Immediate issue corrected.
Root cause addressed.
Compensating controls implemented if required.
Evidence collected.

Retesting

Retest procedure defined.
Appropriate population selected.
Control retested.
Corrective action validated.
Result documented.

Closure

Finding closed or reopened.
Risk register updated.
Control status updated.
Dashboard updated.
Repeat-finding status evaluated.

128. GRC Analyst Responsibilities

A GRC professional managing SOC findings may:

Review audit exceptions.
Validate findings.
Coordinate evidence clarification.
Assess risk.
Facilitate severity classification.
Maintain the exception register.
Coordinate management responses.
Facilitate root-cause analysis.
Maintain corrective-action plans.
Track remediation.
Coordinate retesting.
Maintain closure evidence.
Track repeat findings.
Escalate overdue findings.
Update risk registers.
Update control status.
Prepare management dashboards.
Support auditor communication.

GRC connects:

Auditors

Control Owners

Security

Engineering

IAM

Risk Owners

Executive Management

Internal Audit

129. SOC Findings Maturity Model

Level 1 — Reactive

Auditor Finds Issue
      ↓
Team Fixes It

Level 2 — Tracked

Finding Register

Owners

Due Dates

Level 3 — Risk Based

Severity

Root Cause

Corrective Action

Retesting

Level 4 — Integrated

Risk Register

Control Library

Automation

Trend Analysis

Level 5 — Continuous Improvement

Continuous Monitoring

Preventive Controls

Predictive Risk Signals

Repeat-Finding Elimination

130. SOC Findings Mindset

For every exception ask:

What requirement failed?

What exactly happened?

How do we know?

How much of the population is affected?

Is the problem isolated or systemic?

What risk does it create?

Did any incident occur?

What compensating controls exist?

What caused the failure?

What should be fixed immediately?

What process must change permanently?

Who owns remediation?

What evidence will prove completion?

How will we retest?

Could this happen again?

For every repeat finding ask:

Why did the previous remediation fail?

If these questions can be answered, SOC findings become an improvement mechanism rather than simply an audit problem.

Key Takeaways

A SOC exception is a deviation from expected control operation.
An exception and a broader audit finding are related but not identical.
Readiness gaps are identified before the formal examination.
Exceptions can involve control execution, evidence, population, timing, authorization, scope, or configuration.
Isolated and systemic failures should be distinguished carefully.
Severity should consider risk, frequency, impact, recurrence, control criticality, and compensating controls.
Strong findings contain a requirement, condition, evidence, and risk.
Management responses should acknowledge the issue and describe root cause, correction, and corrective action.
Human error alone is rarely a sufficient root cause.
Correction fixes the immediate issue; corrective action prevents recurrence.
Internal approved exceptions and auditor control exceptions are different concepts.
Retesting should independently confirm that remediation is effective.
Failed retests should reopen or escalate the finding.
Repeat findings may indicate systemic control or governance weakness.
Individual control exceptions do not automatically mean a modified auditor opinion.
Qualified and adverse opinions require careful risk assessment.
SOC findings should connect to enterprise risk, control status, management reporting, and continuous improvement.

Knowledge Check

Before continuing, make sure you can answer:

What is a SOC control exception?
How is an exception different from a finding?
What is a readiness gap?
What is an evidence exception?
What is a population exception?
What is a timing exception?
What is the difference between isolated and systemic failure?
What factors should influence severity?
What should a strong finding contain?
What should a management response contain?
Why is “human error” usually an incomplete root cause?
What is the difference between correction and corrective action?
What are compensating controls?
How is an internal approved exception different from an auditor exception?
What is retesting?
What happens when retesting fails?
Why are repeat findings important?
Can an SOC report contain exceptions and still have an unmodified opinion?
What does a qualified opinion indicate?
What role does GRC play in SOC findings management?

What’s Next?

➡️ Next: 14 — SOC Audit Process

In the next lesson, you will bring the entire SOC program into the formal examination lifecycle and follow the audit from planning through final report issuance.

You will work through:

Audit Planning
      ↓
Scope Confirmation
      ↓
Engagement Kickoff
      ↓
PBC Requests
      ↓
Walkthroughs
      ↓
Population Submission
      ↓
Sample Selection
      ↓
Evidence Testing
      ↓
Exception Discussion
      ↓
Management Responses
      ↓
Report Review
      ↓
Final SOC Report

You will also build practical artifacts including a SOC Audit Project Plan, Auditor Request Tracker, Walkthrough Schedule, Population Submission Register, Sample Tracker, Exception Discussion Log, Management Response Register, and Final Report Review Checklist.