What Are Exceptions in SOC Reports?
Exceptions are deviations from expected control operation identified during testing in a SOC 1 or SOC 2 examination. They represent instances where controls did not function as designed, were not consistently applied, or failed to achieve their stated objectives during the review period.
Why Exceptions Matter
Exceptions are critical because they:
- Indicate potential gaps in the service organization's control environment
- May impact user entities' financial reporting or operational security
- Require user auditors to perform additional substantive testing
- Influence reliance decisions on service organization controls
- Can affect the service organization's reputation and client relationships
Exception vs. Control Deficiency
It's important to distinguish between exceptions and control deficiencies:
- Exception: A specific instance where a control did not operate as expected during testing (e.g., 3 out of 25 sampled access reviews were not completed timely)
- Control Deficiency: A design or operating deficiency that affects the control's ability to meet objectives (e.g., access review process has no automated notification system)
Types of Exceptions
Exceptions can be categorized by their nature and impact:
1. Timing Exceptions
Controls performed outside the required timeframe.
Example: Quarterly access reviews required within 5 business days of quarter-end were completed 12 days late in 2 out of 4 quarters.
2. Execution Exceptions
Control activities not performed or performed incorrectly.
Example: Management review and approval signature missing on 5 out of 40 change requests tested.
3. Evidence Exceptions
Insufficient or missing documentation to support control operation.
Example: Control description states backup logs are retained for 90 days, but logs only available for 60 days for 3 months tested.
4. Scope Exceptions
Controls not applied to all in-scope systems, processes, or populations.
Example: Password complexity requirements enforced on production systems but not on development systems that access production data.
5. Rate/Frequency Exceptions
High error rates that exceed acceptable thresholds.
Example: 8 out of 30 new user access requests (27%) granted privileges not aligned with job responsibilities.
Severity Assessment Framework
Assessing exception severity helps prioritize remediation and determine appropriate responses.
| Severity | Criteria | Impact |
|---|---|---|
| Critical |
| Immediate action required; may affect audit opinion |
| Significant |
| Additional testing required; heightened monitoring |
| Minor |
| Document and monitor; limited additional procedures |
Factors to Consider
- Frequency: Single occurrence vs. recurring pattern
- Root Cause: Human error vs. systematic control weakness
- Detection Timing: Real-time vs. after-the-fact discovery
- Financial Magnitude: Potential dollar impact on user entities
- Affected Population: Number of transactions or users impacted
- Remediation Status: Whether issue has been corrected during period
Evaluating Impact on User Entities
Understanding how exceptions affect user entities is crucial for proper audit planning and risk assessment.
SOC 1 Impact Assessment
For SOC 1 reports, evaluate impact on financial reporting assertions:
- Completeness: Could exception result in transactions not being recorded?
- Accuracy: Could exception lead to incorrect amounts being recorded?
- Validity: Could unauthorized transactions be processed?
- Authorization: Were proper approvals obtained?
- Cutoff: Were transactions recorded in the correct period?
SOC 2 Impact Assessment
For SOC 2 reports, evaluate against applicable Trust Service Criteria:
Security
Could exception lead to unauthorized access to systems or data? Consider confidentiality, integrity, and availability of information.
Availability
Could exception result in system downtime or service disruption? Evaluate impact on business continuity commitments.
Processing Integrity
Could exception compromise data accuracy, completeness, or timeliness? Consider impact on processing quality.
Quantitative vs. Qualitative Assessment
Use both approaches to fully understand impact:
- Quantitative: Number of transactions affected, dollar value exposure, percentage of population impacted
- Qualitative: Nature of risk, potential for fraud, regulatory implications, reputational concerns
Compensating Controls Analysis
Compensating controls can mitigate the impact of exceptions and may reduce severity assessments.
What Qualifies as a Compensating Control?
A control that:
- Addresses the same risk as the control with the exception
- Operates at a sufficient level of precision
- Was operating effectively during the exception period
- Provides sufficient mitigation to achieve the original control objective
Common Compensating Controls
Detective Controls
Reconciliations, monitoring, reviews, or automated alerts that detect issues
Example: If preventive access controls fail, detective monitoring of privileged user activity logs may serve as compensating control
Redundant Controls
Multiple controls addressing the same objective through different methods
Example: If automated backup verification fails, manual verification procedures performed by different team may compensate
Supervisory Controls
Management oversight, review, and approval processes
Example: If segregation of duties exception exists, enhanced management review of transactions may provide compensation
Evaluating Compensating Control Effectiveness
Ask these questions:
- Was the compensating control in place during the exception period?
- Does it operate at sufficient frequency to detect/prevent the risk timely?
- Is it performed by personnel independent of the failed control?
- Is there evidence the compensating control operated effectively?
- Does it provide coverage for 100% of the population affected by the exception?
Documentation Requirements
Thorough documentation of exceptions is essential for audit quality and professional standards compliance.
Essential Documentation Elements
- 1. Exception Description
- Specific control tested and control objective
- Nature of the deviation observed
- Sample size and number of exceptions identified
- Dates or periods when exception occurred
- 2. Root Cause Analysis
- Why did the exception occur?
- Was it isolated or systemic?
- Were there contributing factors?
- 3. Impact Assessment
- Severity classification (critical, significant, minor)
- Effect on control objective achievement
- Potential impact on user entities
- Financial reporting or security implications
- 4. Compensating Controls
- Identification of any compensating controls
- Evidence of compensating control operation
- Assessment of mitigation effectiveness
- 5. Additional Procedures Performed
- Extended sample testing
- Alternative procedures applied
- Inquiries made with management
- 6. Conclusion
- Overall effect on reliance strategy
- Recommendations for user auditors
- Impact on audit opinion (if applicable)
Documentation Best Practices
- Use standardized templates for consistency across the audit team
- Cross-reference exception documentation to specific test procedures
- Obtain and document management responses to identified exceptions
- Clearly link exceptions to specific control objectives and trust service criteria
- Include specific sample items tested (dates, IDs, amounts)
- Document discussion with service organization management
- Maintain evidence supporting severity and impact assessments
Communicating Exceptions to Clients
Clear communication about exceptions helps clients make informed decisions about their audit approach.
Key Communication Principles
- Be Specific: Avoid vague language; provide concrete details about what occurred
- Be Timely: Communicate significant exceptions as soon as identified
- Be Balanced: Acknowledge both the exception and any compensating factors
- Be Actionable: Provide clear guidance on implications and next steps
What to Include in Client Communications
- 1. Exception Summary: Brief description of what happened and when
- 2. Relevant Controls: Which control objectives are affected
- 3. Your Assessment: Severity rating and rationale
- 4. Impact Analysis: How this may affect their financial statements or operations
- 5. Compensating Factors: Any mitigating controls or circumstances
- 6. Recommended Actions: Suggested additional audit procedures or areas of focus
- 7. Questions for Client: Information needed from the service organization or user entity
Sample Communication Template
Subject: [Service Organization Name] SOC 1 Report - Exception Identified
Dear [Client Name],
During our review of the [Service Organization] SOC 1 Type II report for the period [dates], we identified the following exception that may impact your audit:
Exception: [Specific description]
Affected Control: [Control objective and ID]
Severity: [Critical/Significant/Minor]
Our Assessment: [Brief analysis]
Recommended Actions:
- [Specific recommendation 1]
- [Specific recommendation 2]
Please let us know if you have questions or need additional information.
Best Practices and Common Pitfalls
Best Practices
✓ Establish Clear Evaluation Criteria
Define severity thresholds and impact assessment methodologies before beginning review work to ensure consistency.
✓ Consider the Full Context
Look at the exception within the broader control environment. Single exceptions in an otherwise strong control environment may be less concerning than patterns of deficiencies.
✓ Leverage Technology
Use tools like SOC Review to automatically extract and categorize exceptions from SOC reports, reducing manual effort and improving accuracy.
✓ Engage Early with Clients
Don't wait until audit completion to discuss significant exceptions. Early communication allows for timely planning of additional procedures.
Common Pitfalls to Avoid
✗ Dismissing Minor Exceptions
Multiple minor exceptions may collectively indicate systemic issues. Don't ignore patterns even if individual instances seem insignificant.
✗ Over-Relying on Compensating Controls
Ensure compensating controls truly address the same risk and operated effectively. Don't assume compensation without proper evaluation and evidence.
✗ Insufficient Documentation
Inadequate documentation of your exception analysis and conclusions can lead to peer review findings and quality issues. Document your thinking, not just your results.
✗ Failing to Assess Pervasiveness
Don't evaluate each exception in isolation. Consider whether exceptions in one area suggest broader control environment weaknesses.
Professional Skepticism Checklist
Apply professional skepticism by asking:
- Is the service organization's explanation for the exception reasonable?
- Are there additional exceptions that testing might have missed due to sample size?
- Could this exception indicate more pervasive issues in the control environment?
- Are compensating controls genuinely effective, or is management over-representing their reliability?
- Has the exception been remediated, and if so, is there evidence of sustained improvement?
- Were similar exceptions noted in prior periods?
Streamline Exception Analysis with SOC Review
SOC Review automatically extracts and categorizes exceptions from SOC reports, highlighting severity and linking to affected control objectives. Save hours of manual review time while improving accuracy and consistency.