In This Article
Understanding Findings and Exceptions
SOC 2 audits don't result in "pass" or "fail" in the traditional sense. Instead, auditors issue an opinion on whether your controls meet the criteria. Along the way, they may identify:
Exceptions
Instances where a control didn't operate as designed. For example:
- An access review wasn't performed in Q2
- A change was deployed without approval documentation
- A terminated employee's access wasn't removed for 5 days
Design Deficiencies
Controls that aren't designed to meet the criteria. For example:
- No process for reviewing access at all
- Change management only applies to some systems
- No termination checklist exists
Isolated exceptions: Usually noted but don't affect the opinion
Pervasive exceptions: May result in a modified (qualified) opinion
Design deficiencies: More serious - control doesn't meet criteria
Access Control Issues (Most Common)
Access control findings appear in the majority of SOC 2 reports. They're both common and avoidable.
Finding #1: Delayed Access Removal
What auditors find: Terminated employees retained access for days or weeks
Why it happens:
- HR doesn't notify IT promptly
- No automated deprovisioning
- Systems not included in termination checklist
How to prevent:
- Automate deprovisioning through identity provider
- Establish same-day or next-day SLA for termination
- Complete offboarding checklist covering all systems
Finding #2: Missing Access Reviews
What auditors find: Quarterly or semi-annual access reviews weren't performed on schedule
Why it happens:
- No calendar reminders
- No assigned owner
- Process is manual and burdensome
How to prevent:
- Calendar reminders with ownership
- Automated access review tools
- Make reviews part of regular rhythm (e.g., first week of quarter)
Finding #3: Generic/Shared Accounts
What auditors find: Shared credentials, generic admin accounts, or service accounts with multiple users
Why it happens:
- Legacy systems that don't support individual accounts
- Convenience over security
- Developer shortcuts
How to prevent:
- Individual accounts for all users
- Service accounts with controlled access (secrets management)
- Document exceptions with compensating controls
Change Management Gaps
Change management is scrutinized heavily because unauthorized changes can introduce security vulnerabilities.
Finding #4: Changes Without Approval
What auditors find: Production changes without documented approval
Why it happens:
- Emergency changes without follow-up documentation
- Approval happens verbally, not in tickets
- Developers self-approve
How to prevent:
- Enforce approval in CI/CD pipeline
- Require pull request approvals before merge
- Document emergency change procedures with retroactive approval
Finding #5: Missing Change Documentation
What auditors find: Changes can't be traced to tickets, or tickets lack required information
Why it happens:
- Informal change process
- Tickets created after the fact (or not at all)
- No template or required fields
How to prevent:
- Mandatory ticket creation before changes
- Required fields in ticket template
- Link deployments to tickets automatically
Finding #6: Inadequate Testing
What auditors find: Changes deployed without evidence of testing
Why it happens:
- Testing happens but isn't documented
- "Tested in staging" without records
- Small changes skip testing
How to prevent:
- Automated test gates in CI/CD
- Document test results in tickets
- Define testing requirements by change type
Risk Assessment Problems
Risk assessment is required but often done superficially or not at all.
Finding #7: No Annual Risk Assessment
What auditors find: Organization can't produce a current risk assessment
Why it happens:
- Done once for certification, never updated
- No scheduled review cycle
- Ownership unclear
How to prevent:
- Annual risk assessment schedule
- Clear ownership (typically InfoSec)
- Management review and sign-off
Finding #8: Risk Treatment Not Documented
What auditors find: Risks identified but no documented decision on treatment
Why it happens:
- Risk register exists but treatment column empty
- Decisions made but not recorded
- Risks identified but no follow-up
How to prevent:
- Complete risk treatment for every identified risk
- Document accept/mitigate/transfer/avoid decisions
- Track mitigation activities to completion
Monitoring and Incident Response Failures
Finding #9: Insufficient Logging
What auditors find: Key events aren't logged, or logs aren't retained
Why it happens:
- Logging not enabled on all systems
- Retention period too short
- Cost concerns limit logging scope
How to prevent:
- Define logging requirements by system type
- Retain logs for at least the audit period + buffer
- Verify logging is working (test retrievability)
Finding #10: No Incident Response Testing
What auditors find: Incident response plan exists but hasn't been tested
Why it happens:
- "We had real incidents, that's our test"
- No schedule for tabletop exercises
- Testing planned but never done
How to prevent:
- Annual tabletop exercise (minimum)
- Document lessons learned and improvements
- Include multiple scenarios over time
Vendor Management Issues
Finding #11: Missing Vendor Assessments
What auditors find: Critical vendors not assessed for security
Why it happens:
- No inventory of vendors
- Vendor classification unclear
- Assessment process doesn't exist
How to prevent:
- Maintain vendor inventory
- Classify by risk (data access, criticality)
- Assess critical vendors annually
Finding #12: No SOC 2 Review for Subservice Orgs
What auditors find: Carved-out subservice organizations' SOC 2 reports not reviewed
Why it happens:
- Assumed AWS/Azure "are secure"
- SOC 2 reports obtained but not reviewed
- No process for reviewing subservice org reports
How to prevent:
- Obtain SOC 2 reports from all carved-out vendors
- Review for exceptions relevant to your use
- Document review and any concerns
Documentation Issues
Finding #13: Outdated Policies
What auditors find: Policies reference old systems, processes, or haven't been reviewed
Why it happens:
- Policies written once, never updated
- No review cycle
- Organization changed faster than documentation
How to prevent:
- Annual policy review cycle
- Version control and approval tracking
- Policy owners responsible for accuracy
Finding #14: Policies Don't Match Practice
What auditors find: Policy says one thing, evidence shows another
Why it happens:
- Aspirational policies (what we want to do)
- Process changed but policy didn't
- Policy written by someone who doesn't do the work
How to prevent:
- Document what you actually do
- Have practitioners review policies
- Align policy updates with process changes
Prevention Strategies
1. Build Controls Into Workflows
Controls that require manual intervention fail more often. Automate where possible:
- CI/CD enforcement of approval and testing
- Automated access provisioning and deprovisioning
- Automated evidence collection
2. Assign Clear Ownership
Every control needs an owner who is responsible for execution and evidence. Unclear ownership = control failures.
3. Create Reminders and Schedules
Periodic controls (access reviews, risk assessments, backup tests) need calendar reminders. Don't rely on memory.
4. Test Your Evidence
Before the audit, verify you can actually produce the evidence you'll need. Can you pull access reviews from 9 months ago? Change tickets from Q1?
5. Document Exceptions in Real Time
When controls don't operate as designed, document what happened and what you did about it. Real-time documentation is more credible than explanations created during the audit.
The organizations with the cleanest SOC 2 reports aren't perfect - they've built sustainable processes that generate evidence naturally and catch issues before auditors do.