SOC Reports Under Pressure: The Control and Assurance Problems Organizations Have Faced During the Past Five Years

John Blackshire
4 days ago
24 min read

Updated: 4 days ago

Obtaining a SOC Report Is Not the Same as Managing Third-Party Risk

During the past five years, organizations have become substantially more dependent on cloud providers, software platforms, payroll processors, data centers, claims administrators, payment processors, managed security providers, and other service organizations.

Obtaining a SOC Report Is Not the Same as Managing Third-Party Risk

That increased dependence has made System and Organization Controls reports, commonly known as SOC reports, a central component of:

Third-party risk management
Financial statement auditing
Sarbanes-Oxley compliance
Cybersecurity assessments
Vendor due diligence
Regulatory examinations
Internal auditing

SOC reports can provide valuable independent information about controls operated by a service organization. However, they are frequently misunderstood, over-relied upon, requested too late, reviewed superficially, or applied to risks they were never designed to address.

The most important lesson from the last five years is straightforward:

A SOC report is an assurance tool—not a compliance certificate, cybersecurity guarantee, or substitute for vendor governance.

The American Institute of CPAs continues to emphasize that organizations outsourcing important functions must identify, assess, and manage the related risks. A SOC engagement supplies information about the service organization’s controls, but the user organization remains responsible for managing the outsourced risk.

This article examines the most important SOC-report issues observed from 2021 through 2026 and explains what management, Internal Audit, external auditors, and Audit Committees should do differently.

Issue 1: Organizations Obtain the Wrong SOC Report

One of the most basic problems is also one of the most persistent: organizations request “the SOC report” without determining which report is relevant.

The three commonly encountered reports have different purposes:

SOC 1 addresses controls likely to be relevant to user organizations’ Internal Control over Financial Reporting.
SOC 2 addresses controls related to security, availability, processing integrity, confidentiality, or privacy.
SOC 3 provides a more general-use report based on the Trust Services Criteria but does not provide the detailed control-testing information found in a SOC 2 report.

The AICPA describes SOC 1 as specifically intended for user entities and their financial statement auditors when evaluating how service-organization controls affect the user entity’s financial reporting.

The mistake

An organization obtains a SOC 2 report from its payroll provider and assumes it addresses the controls needed for the financial statement audit.

A SOC 2 report may provide useful information about security and availability. It may not address the payroll-processing control objectives relevant to financial reporting.

The opposite problem also occurs. A company obtains a SOC 1 report and treats it as complete cybersecurity assurance.

Better practice

Before requesting a report, define the risk:

Does the provider affect financial reporting?
Does it store confidential information?
Is system availability essential?
Does it process transactions?
Is privacy the primary concern?
Which contractual or regulatory requirements apply?

The report should be selected after the risk is identified—not because a vendor representative says the company is “SOC certified.”

Issue 2: Type 1 Reports Are Mistaken for Evidence of Operating Effectiveness

A Type 1 report generally addresses whether controls were suitably designed and implemented as of a specified date.

A Type 2 report additionally examines whether the controls operated effectively throughout a defined period.

The mistake

Management receives a Type 1 report and concludes:

“The vendor’s controls were effective throughout the year.”

That conclusion goes beyond the evidence.

A control may have been designed and implemented on the report date without having operated consistently during the preceding or subsequent months.

Better practice

Determine whether the business decision requires:

Point-in-time evidence
Evidence covering an operating period
Additional vendor documentation
Internal compensating controls
Direct testing
Contractual assurances

A Type 1 report can be useful during a new system implementation or when a service organization is beginning its assurance program. It should not be treated as equivalent to a Type 2 report.

Issue 3: SOC Reports Do Not Cover the User Organization’s Full Reporting Period

Timing gaps have produced real financial-reporting problems.

A user organization may have a fiscal year ending December 31 while the service organization’s SOC 1 Type 2 report ends September 30. The final three months are not covered by the service auditor’s testing.

A bridge letter may address whether management is aware of material changes after the report date, but it is a representation from the service organization—not an extension of the independent examination.

A particularly clear example became public in 2022. A company disclosed that CDK Global had not provided a timely attestation report covering the gap between the prior SOC 1 report and the company’s fiscal year-end. As a result, the company could not complete its assessment of controls over unauthorized system access and change management.

The mistake

The user organization notices the coverage gap only when its external auditor asks for year-end evidence.

Better practice

Maintain a SOC-report calendar showing:

Report period
User organization’s fiscal year
Expected report-release date
Coverage gaps
Bridge-letter requirements
Additional evidence needed
Responsible reviewer
Escalation date

A contract should require the service provider to deliver reports and bridge letters within defined timeframes.

Issue 4: Management Cannot Rely on the SOC Report

Possessing a SOC report does not mean the report provides sufficient assurance.

In a 2025 public filing, B. Riley disclosed that it could not rely on a third-party service organization’s SOC 1 Type 2 report for a hosted system processing customer sales and billing information. The company concluded that the third-party internal-control processes were not designed or implemented at a sufficient level of precision, so information produced by the system could not be relied upon.

That disclosure illustrates a major point:

The existence of a SOC 1 Type 2 report does not eliminate the need to evaluate its relevance, scope, controls, testing, and results.

Reasons a report may be unusable include:

The wrong service is covered.
Relevant applications are excluded.
The control objectives do not address the user organization’s risks.
The reporting period is inadequate.
The report contains significant exceptions.
The opinion is modified.
Important subservice organizations are carved out.
Controls do not operate at sufficient precision.
Complementary user controls are missing at the user organization.

Better practice

Document why the report can—or cannot—be relied upon.

A reviewer should not merely record:

“SOC report received.”

The workpaper should explain:

Which processes depend on the provider
Which controls are relevant
Which report sections were reviewed
Whether the period is adequate
How exceptions were evaluated
Whether CUECs were implemented
What additional procedures are necessary

Issue 5: Organizations Read the Opinion but Ignore the Exceptions

An unmodified service auditor’s opinion does not necessarily mean that every control operated without exception.

A Type 2 report can contain testing exceptions while still receiving an unmodified opinion, depending on the nature and significance of those exceptions.

The mistake

The reviewer reads the opinion page, confirms it is unmodified, and closes the vendor-assessment checklist.

Important issues buried in the control-testing section may include:

Delayed removal of terminated users
Missing change approvals
Incomplete access reviews
Untested disaster-recovery procedures
Exceptions in incident-response controls
Inadequate vendor reviews
Failed backup evidence
Missing management review documentation

Better practice

For every exception, determine:

Which control failed?
What risk does the control address?
Was the failure isolated or recurring?
Could the failure affect the user organization?
Did the provider identify a cause?
Was corrective action completed?
Do compensating controls exist?
Is additional evidence required?

The AICPA continues to identify common peer-review findings, misconceptions, testing problems, and reporting pitfalls as important areas requiring service-auditor attention.

Issue 6: Complementary User-Entity Controls Are Ignored

A service organization’s controls may depend on controls operated by its customers.

These customer responsibilities are generally described as Complementary User-Entity Controls, or CUECs.

Examples include requirements for the user organization to:

Approve authorized users
Notify the vendor of terminated employees
Review processing reports
Reconcile system output
Protect credentials
Configure security settings
Review exceptions
Maintain local backups

The mistake

Management assumes the service provider’s controls are effective without determining whether its own required controls are operating.

The service organization may perform its part correctly while the user organization fails to:

Remove terminated users
Review exception reports
Reconcile processed transactions
Maintain proper system configurations

The control objective may therefore remain unachieved.

The AICPA’s current training specifically identifies CUECs as a critical consideration for both financial statement auditors and users reviewing SOC reports.

Better practice

Create a CUEC matrix:

SOC requirement	Internal owner	Internal control	Evidence	Testing status
Approve authorized users	Department manager	Access-request approval	Approved request	Tested
Remove terminated users	HR and IT	Automated termination feed	System log	Exception noted
Review provider reports	Finance	Monthly reconciliation	Signed reconciliation	Operating

CUECs should be assigned, documented, tested, and incorporated into the user organization’s control environment.

Issue 7: Complementary Subservice Organization Controls and Carve-Outs Are Missed

Service organizations frequently rely on other service providers.

A software company may depend on:

A cloud infrastructure provider
A managed security provider
A data center
A backup provider
A customer-support platform
A payment processor

These providers may be addressed through:

The inclusive method, where their relevant controls are included within the SOC engagement, or
The carve-out method, where their controls are excluded.

The mistake

The user organization reviews the primary vendor’s report without realizing that a critical cloud or data-processing provider was carved out.

The assurance chain has a gap.

The AICPA’s current SOC guidance and training continue to emphasize subservice organizations, inclusive-versus-carve-out treatment, and complementary subservice organization controls because these areas create persistent reporting and assessment difficulties.

Better practice

Identify:

Every significant subservice organization
Whether it is included or carved out
What services it performs
Which risks it creates
Whether a separate SOC report is available
Which complementary controls apply
Whether the contract provides audit and incident-notification rights

The primary vendor’s SOC report may be only the first report the organization needs to review.

Issue 8: System Descriptions Are Incomplete or Outdated

The service organization’s system description is fundamental to a SOC examination.

It should accurately describe:

Services
Infrastructure
Software
People
Procedures
Data
System boundaries
Significant changes
Subservice organizations
User responsibilities

The mistake

The service organization treats the description as a marketing document or rolls forward last year’s language without considering operational changes.

During the past five years, many providers have rapidly changed:

Cloud architecture
Remote-work processes
Cybersecurity tools
Data locations
Vendors
Artificial intelligence capabilities
Software-development methods
Incident-response arrangements

An outdated description can make the report technically polished but operationally misleading.

Better practice

Require process owners, IT, cybersecurity, legal, compliance, and Internal Audit to validate the description before management signs its assertion.

The description should reflect the actual system during the period examined.

Issue 9: SOC 2 Is Marketed as a Certification or Guarantee

“SOC 2 certified” has become common marketing language.

That wording is problematic.

A SOC 2 engagement is an independent examination under AICPA attestation standards. It is not a government-issued cybersecurity license and does not mean:

The company cannot be breached.
Every system is covered.
Every security control is effective.
The organization complies with every privacy law.
The report remains valid indefinitely.
All vendors and subprocessors were examined.

The mistake

Customers treat the SOC 2 logo or sales statement as sufficient evidence of security.

The FTC has continued bringing data-security enforcement actions against organizations that failed to take reasonable steps to protect sensitive information. Its 2026 ransomware report stated that the agency had brought more than 90 data-security enforcement actions, including actions involving technology and education-service providers.

Those enforcement actions do not establish that the companies involved had deficient SOC reports. They demonstrate the broader point that security assurance must be connected to actual operations, regulatory obligations, incident response, and data governance.

Better practice

Management should avoid saying:

“The vendor has SOC 2, so the vendor is secure.”

The defensible conclusion is narrower:

“An independent CPA examined defined controls against specified Trust Services Criteria for the identified system and period. We reviewed the opinion, scope, testing, exceptions, subservice organizations, and required user controls and performed additional procedures where necessary.”

Issue 10: Organizations Assume SOC 2 Equals Regulatory Compliance

A SOC 2 report may help support compliance with cybersecurity, privacy, financial-services, healthcare, or contractual requirements.

It does not automatically prove compliance with:

HIPAA
GLBA
PCI DSS
State privacy laws
NIST
ISO 27001
Industry-specific regulations
Customer contracts

The mistake

Management substitutes the SOC report for a regulatory gap assessment.

A SOC report may cover some relevant controls but omit:

Required breach-notification procedures
Specific retention requirements
Legal consent provisions
Data-residency rules
Industry-specific safeguards
Contractual service levels

HHS continues to report substantial numbers of large healthcare data breaches, many involving business associates and network servers. This demonstrates that outsourced processing and third-party technology remain major sources of regulatory and operational exposure.

Better practice

Map the SOC report to the applicable obligation and identify gaps.

The correct question is not:

“Do we have a SOC 2 report?”

It is:

“Which requirements does the report address, and what additional evidence do we need?”

Issue 11: The User Organization Forgets That Outsourcing Does Not Transfer Accountability

The SEC has long maintained that management remains responsible for assessing controls over outsourced operations. Management must also evaluate the controls governing the flow of information to and from the service organization.

The mistake

Management assumes:

The vendor owns the control risk.
The external auditor will review the SOC report.
Procurement completed due diligence.
Information Security is monitoring the provider.
Internal Audit will identify any problems.

Everyone assumes someone else owns the process.

Better practice

Assign a service owner accountable for:

Vendor performance
Risk assessment
SOC-report review
CUEC implementation
Contract compliance
Incident escalation
Renewal decisions
Remediation tracking

Outsourcing a process does not outsource governance.

Issue 12: SOC Reports Arrive Too Late for Effective Risk Management

Some organizations request a SOC report only when:

External Audit asks for it
A regulator requests it
A customer contract requires it
A breach occurs
A vendor review is overdue

The mistake

The organization treats the report as a document-collection requirement rather than a source of current risk information.

A report issued nine months ago may describe a system that has since undergone:

Major platform changes
Acquisition
Data-center migration
Security incident
Leadership turnover
Vendor replacement
Control redesign

Better practice

SOC reports should be incorporated into the regular third-party risk cycle.

High-risk providers may require:

Annual SOC-report review
Quarterly performance reporting
Incident notifications
Continuous external monitoring
Bridge letters
Remediation updates
Contractual audit rights
Periodic management meetings

The report should inform decisions, not merely satisfy a checklist.

Issue 13: Service Organizations Are Not Ready for the Examination Period

A SOC Type 2 examination requires controls to operate over time.

A service organization cannot manufacture a year of evidence at the end of the year.

Recurring readiness problems include:

Controls documented but not performed
Evidence not retained
Reviews completed late
Policies inconsistent with practice
Access reviews lacking proof of resolution
Changes missing approval
Vendor assessments overdue
Incident exercises not completed
Unclear control ownership
Weak exception handling

The AICPA’s current SOC training continues to address common peer-review findings and misconceptions involving planning, execution, sufficient testing, non-operating controls, CUECs, and subservice organizations.

Better practice

Conduct a readiness assessment before the examination period.

The readiness work should identify:

Scope
Criteria
Controls
Owners
Frequencies
Evidence requirements
Known gaps
Remediation deadlines
Testing strategy

The examination should validate an operating system of controls—not motivate the company to create one after testing begins.

Issue 14: Service Auditors Face Their Own Quality Problems

SOC engagements are specialized attestation engagements.

They require knowledge of:

AICPA attestation standards
SOC-specific guidance
Trust Services Criteria
Information technology
Sampling
System descriptions
Subservice organizations
Control-design evaluation
Evidence sufficiency
Reporting requirements

The mistake

A CPA firm treats a SOC engagement as a conventional financial statement audit with different report language.

The AICPA continues to provide specialized SOC schools focused on common peer-review findings and pitfalls, which indicates that engagement-quality problems remain an active professional concern.

Potential service-auditor problems include:

Inadequate risk assessment
Insufficient tests of design
Poor population validation
Weak sample selection
Failure to evaluate exceptions
Incomplete subservice organization treatment
Incorrect report language
Insufficient understanding of the technology
Failure to address non-operating controls properly

Better practice

Before retaining a service auditor, management should evaluate:

SOC experience
Industry knowledge
IT expertise
Peer-review status
Engagement methodology
Staffing continuity
Quality-review procedures
Ability to explain findings clearly

The lowest-cost provider may become the most expensive choice if customers or auditors cannot rely on the report.

Issue 15: Artificial Intelligence Is Creating New SOC Questions

During the last two years, service organizations have accelerated their use of generative AI and machine learning.

AI may influence:

Customer support
Fraud detection
Software development
Data analysis
Access decisions
Security monitoring
Content generation
Automated processing

Emerging SOC questions include:

Is AI included within the system boundary?
What customer data enter the model?
Are prompts retained?
Are outputs validated?
Who approves model changes?
Are third-party AI providers subservice organizations?
How are hallucinations and bias monitored?
How is confidential information protected?
Are AI-generated decisions logged?
Which CUECs apply to customers using AI features?

The problem

Existing SOC descriptions and control matrices may not reflect AI-enabled processing.

Better practice

Service organizations should evaluate whether AI changes:

The system description
Risk assessment
Processing-integrity controls
Confidentiality controls
Privacy controls
Vendor inventory
Change management
Incident response
Customer responsibilities

AI should not be silently added to a system that was examined under a different operating model.

What Audit Committees and Executives Should Ask

Management and governing bodies should ask:

Are we obtaining the correct SOC report for each significant provider?
Is the report Type 1 or Type 2, and does that meet our objective?
Does the report period cover our reliance period?
Is the service we use actually within scope?
Is the auditor’s opinion modified?
What testing exceptions were reported?
Which CUECs must we operate?
Which subservice organizations were carved out?
Do we need additional SOC reports?
Has the provider experienced major changes since the report date?
Does the report address our regulatory requirements?
Who owns the review and remediation process?
Can Internal Audit and External Audit rely on the report?
What compensating controls exist when they cannot?
Is AI changing the provider’s risk profile or system description?

A vague answer such as “Procurement has the SOC report” is not sufficient.

The Central Lesson from the Past Five Years

The problems surrounding SOC reporting have not resulted from a lack of reports.

Organizations now collect more reports than ever.

The problems arise because companies:

Request the wrong report
Misunderstand Type 1 and Type 2
Ignore coverage gaps
Read only the opinion
Miss exceptions
Fail to implement CUECs
Overlook carved-out providers
Treat SOC 2 as certification
Confuse assurance with regulatory compliance
Fail to integrate reports into vendor governance
Assume outsourcing transfers responsibility

The strongest organizations do not simply collect SOC reports.

They use them.

They connect the report to:

The vendor-risk assessment
Contract requirements
Financial-reporting controls
Cybersecurity governance
Regulatory compliance
Internal Audit
Business continuity
Management accountability

That is when a SOC report becomes valuable.

Learn the SOC Process from Three Perspectives

Corporate Compliance Seminars will present SSAE SOC Audits: Auditee–Auditor–Assessor Training from Tuesday through Thursday, August 18–20, 2026.

The 18-CPE program examines SOC reporting from the perspectives of:

The service organization preparing for the examination
The CPA performing the SOC engagement
The user organization or auditor assessing the completed report

Topics include:

SOC 1, SOC 2, and SOC 3
Type 1 and Type 2 reports
System descriptions
Risk and control assessment
Trust Services Criteria
Control testing
Exceptions
Subservice organizations
CUECs
Bridge letters
Auditor opinions
Regulatory applications
Third-party risk management

The course is designed for Internal Auditors, external auditors, service-organization managers, IT professionals, compliance officers, vendor-risk personnel, and other professionals who need to prepare, perform, or evaluate SOC engagements.

A SOC report can be one of the organization’s most valuable sources of third-party assurance.

It can also become an expensive document that no one properly reads.

The difference is competence.That increased dependence has made System and Organization Controls reports, commonly known as SOC reports, a central component of:

Third-party risk management
Financial statement auditing
Sarbanes-Oxley compliance
Cybersecurity assessments
Vendor due diligence
Regulatory examinations
Internal auditing

The most important lesson from the last five years is straightforward:

A SOC report is an assurance tool—not a compliance certificate, cybersecurity guarantee, or substitute for vendor governance.

This article examines the most important SOC-report issues observed from 2021 through 2026 and explains what management, Internal Audit, external auditors, and Audit Committees should do differently.

Issue 1: Organizations Obtain the Wrong SOC Report

One of the most basic problems is also one of the most persistent: organizations request “the SOC report” without determining which report is relevant.

The three commonly encountered reports have different purposes:

SOC 1 addresses controls likely to be relevant to user organizations’ Internal Control over Financial Reporting.
SOC 2 addresses controls related to security, availability, processing integrity, confidentiality, or privacy.
SOC 3 provides a more general-use report based on the Trust Services Criteria but does not provide the detailed control-testing information found in a SOC 2 report.

The mistake

An organization obtains a SOC 2 report from its payroll provider and assumes it addresses the controls needed for the financial statement audit.

A SOC 2 report may provide useful information about security and availability. It may not address the payroll-processing control objectives relevant to financial reporting.

The opposite problem also occurs. A company obtains a SOC 1 report and treats it as complete cybersecurity assurance.

Better practice

Before requesting a report, define the risk:

Does the provider affect financial reporting?
Does it store confidential information?
Is system availability essential?
Does it process transactions?
Is privacy the primary concern?
Which contractual or regulatory requirements apply?

The report should be selected after the risk is identified—not because a vendor representative says the company is “SOC certified.”

Issue 2: Type 1 Reports Are Mistaken for Evidence of Operating Effectiveness

A Type 1 report generally addresses whether controls were suitably designed and implemented as of a specified date.

A Type 2 report additionally examines whether the controls operated effectively throughout a defined period.

The mistake

Management receives a Type 1 report and concludes:

“The vendor’s controls were effective throughout the year.”

That conclusion goes beyond the evidence.

A control may have been designed and implemented on the report date without having operated consistently during the preceding or subsequent months.

Better practice

Determine whether the business decision requires:

Point-in-time evidence
Evidence covering an operating period
Additional vendor documentation
Internal compensating controls
Direct testing
Contractual assurances

A Type 1 report can be useful during a new system implementation or when a service organization is beginning its assurance program. It should not be treated as equivalent to a Type 2 report.

Issue 3: SOC Reports Do Not Cover the User Organization’s Full Reporting Period

Timing gaps have produced real financial-reporting problems.

The mistake

The user organization notices the coverage gap only when its external auditor asks for year-end evidence.

Better practice

Maintain a SOC-report calendar showing:

Report period
User organization’s fiscal year
Expected report-release date
Coverage gaps
Bridge-letter requirements
Additional evidence needed
Responsible reviewer
Escalation date

A contract should require the service provider to deliver reports and bridge letters within defined timeframes.

Issue 4: Management Cannot Rely on the SOC Report

Possessing a SOC report does not mean the report provides sufficient assurance.

That disclosure illustrates a major point:

The existence of a SOC 1 Type 2 report does not eliminate the need to evaluate its relevance, scope, controls, testing, and results.

Reasons a report may be unusable include:

The wrong service is covered.
Relevant applications are excluded.
The control objectives do not address the user organization’s risks.
The reporting period is inadequate.
The report contains significant exceptions.
The opinion is modified.
Important subservice organizations are carved out.
Controls do not operate at sufficient precision.
Complementary user controls are missing at the user organization.

Better practice

Document why the report can—or cannot—be relied upon.

A reviewer should not merely record:

“SOC report received.”

The workpaper should explain:

Which processes depend on the provider
Which controls are relevant
Which report sections were reviewed
Whether the period is adequate
How exceptions were evaluated
Whether CUECs were implemented
What additional procedures are necessary

Issue 5: Organizations Read the Opinion but Ignore the Exceptions

An unmodified service auditor’s opinion does not necessarily mean that every control operated without exception.

A Type 2 report can contain testing exceptions while still receiving an unmodified opinion, depending on the nature and significance of those exceptions.

The mistake

The reviewer reads the opinion page, confirms it is unmodified, and closes the vendor-assessment checklist.

Important issues buried in the control-testing section may include:

Delayed removal of terminated users
Missing change approvals
Incomplete access reviews
Untested disaster-recovery procedures
Exceptions in incident-response controls
Inadequate vendor reviews
Failed backup evidence
Missing management review documentation

Better practice

For every exception, determine:

Which control failed?
What risk does the control address?
Was the failure isolated or recurring?
Could the failure affect the user organization?
Did the provider identify a cause?
Was corrective action completed?
Do compensating controls exist?
Is additional evidence required?

The AICPA continues to identify common peer-review findings, misconceptions, testing problems, and reporting pitfalls as important areas requiring service-auditor attention.

Issue 6: Complementary User-Entity Controls Are Ignored

A service organization’s controls may depend on controls operated by its customers.

These customer responsibilities are generally described as Complementary User-Entity Controls, or CUECs.

Examples include requirements for the user organization to:

Approve authorized users
Notify the vendor of terminated employees
Review processing reports
Reconcile system output
Protect credentials
Configure security settings
Review exceptions
Maintain local backups

The mistake

Management assumes the service provider’s controls are effective without determining whether its own required controls are operating.

The service organization may perform its part correctly while the user organization fails to:

Remove terminated users
Review exception reports
Reconcile processed transactions
Maintain proper system configurations

The control objective may therefore remain unachieved.

The AICPA’s current training specifically identifies CUECs as a critical consideration for both financial statement auditors and users reviewing SOC reports.

Better practice

Create a CUEC matrix:

SOC requirement	Internal owner	Internal control	Evidence	Testing status
Approve authorized users	Department manager	Access-request approval	Approved request	Tested
Remove terminated users	HR and IT	Automated termination feed	System log	Exception noted
Review provider reports	Finance	Monthly reconciliation	Signed reconciliation	Operating

CUECs should be assigned, documented, tested, and incorporated into the user organization’s control environment.

Issue 7: Complementary Subservice Organization Controls and Carve-Outs Are Missed

Service organizations frequently rely on other service providers.

A software company may depend on:

A cloud infrastructure provider
A managed security provider
A data center
A backup provider
A customer-support platform
A payment processor

These providers may be addressed through:

The inclusive method, where their relevant controls are included within the SOC engagement, or
The carve-out method, where their controls are excluded.

The mistake

The user organization reviews the primary vendor’s report without realizing that a critical cloud or data-processing provider was carved out.

The assurance chain has a gap.

Better practice

Identify:

Every significant subservice organization
Whether it is included or carved out
What services it performs
Which risks it creates
Whether a separate SOC report is available
Which complementary controls apply
Whether the contract provides audit and incident-notification rights

The primary vendor’s SOC report may be only the first report the organization needs to review.

Issue 8: System Descriptions Are Incomplete or Outdated

The service organization’s system description is fundamental to a SOC examination.

It should accurately describe:

Services
Infrastructure
Software
People
Procedures
Data
System boundaries
Significant changes
Subservice organizations
User responsibilities

The mistake

The service organization treats the description as a marketing document or rolls forward last year’s language without considering operational changes.

During the past five years, many providers have rapidly changed:

Cloud architecture
Remote-work processes
Cybersecurity tools
Data locations
Vendors
Artificial intelligence capabilities
Software-development methods
Incident-response arrangements

An outdated description can make the report technically polished but operationally misleading.

Better practice

Require process owners, IT, cybersecurity, legal, compliance, and Internal Audit to validate the description before management signs its assertion.

The description should reflect the actual system during the period examined.

Issue 9: SOC 2 Is Marketed as a Certification or Guarantee

“SOC 2 certified” has become common marketing language.

That wording is problematic.

A SOC 2 engagement is an independent examination under AICPA attestation standards. It is not a government-issued cybersecurity license and does not mean:

The company cannot be breached.
Every system is covered.
Every security control is effective.
The organization complies with every privacy law.
The report remains valid indefinitely.
All vendors and subprocessors were examined.

The mistake

Customers treat the SOC 2 logo or sales statement as sufficient evidence of security.

Better practice

Management should avoid saying:

“The vendor has SOC 2, so the vendor is secure.”

The defensible conclusion is narrower:

“An independent CPA examined defined controls against specified Trust Services Criteria for the identified system and period. We reviewed the opinion, scope, testing, exceptions, subservice organizations, and required user controls and performed additional procedures where necessary.”

Issue 10: Organizations Assume SOC 2 Equals Regulatory Compliance

A SOC 2 report may help support compliance with cybersecurity, privacy, financial-services, healthcare, or contractual requirements.

It does not automatically prove compliance with:

HIPAA
GLBA
PCI DSS
State privacy laws
NIST
ISO 27001
Industry-specific regulations
Customer contracts

The mistake

Management substitutes the SOC report for a regulatory gap assessment.

A SOC report may cover some relevant controls but omit:

Required breach-notification procedures
Specific retention requirements
Legal consent provisions
Data-residency rules
Industry-specific safeguards
Contractual service levels

Better practice

Map the SOC report to the applicable obligation and identify gaps.

The correct question is not:

“Do we have a SOC 2 report?”

It is:

“Which requirements does the report address, and what additional evidence do we need?”

Issue 11: The User Organization Forgets That Outsourcing Does Not Transfer Accountability

The mistake

Management assumes:

The vendor owns the control risk.
The external auditor will review the SOC report.
Procurement completed due diligence.
Information Security is monitoring the provider.
Internal Audit will identify any problems.

Everyone assumes someone else owns the process.

Better practice

Assign a service owner accountable for:

Vendor performance
Risk assessment
SOC-report review
CUEC implementation
Contract compliance
Incident escalation
Renewal decisions
Remediation tracking

Outsourcing a process does not outsource governance.

Issue 12: SOC Reports Arrive Too Late for Effective Risk Management

Some organizations request a SOC report only when:

External Audit asks for it
A regulator requests it
A customer contract requires it
A breach occurs
A vendor review is overdue

The mistake

The organization treats the report as a document-collection requirement rather than a source of current risk information.

A report issued nine months ago may describe a system that has since undergone:

Major platform changes
Acquisition
Data-center migration
Security incident
Leadership turnover
Vendor replacement
Control redesign

Better practice

SOC reports should be incorporated into the regular third-party risk cycle.

High-risk providers may require:

Annual SOC-report review
Quarterly performance reporting
Incident notifications
Continuous external monitoring
Bridge letters
Remediation updates
Contractual audit rights
Periodic management meetings

The report should inform decisions, not merely satisfy a checklist.

Issue 13: Service Organizations Are Not Ready for the Examination Period

A SOC Type 2 examination requires controls to operate over time.

A service organization cannot manufacture a year of evidence at the end of the year.

Recurring readiness problems include:

Controls documented but not performed
Evidence not retained
Reviews completed late
Policies inconsistent with practice
Access reviews lacking proof of resolution
Changes missing approval
Vendor assessments overdue
Incident exercises not completed
Unclear control ownership
Weak exception handling

Better practice

Conduct a readiness assessment before the examination period.

The readiness work should identify:

Scope
Criteria
Controls
Owners
Frequencies
Evidence requirements
Known gaps
Remediation deadlines
Testing strategy

The examination should validate an operating system of controls—not motivate the company to create one after testing begins.

Issue 14: Service Auditors Face Their Own Quality Problems

SOC engagements are specialized attestation engagements.

They require knowledge of:

AICPA attestation standards
SOC-specific guidance
Trust Services Criteria
Information technology
Sampling
System descriptions
Subservice organizations
Control-design evaluation
Evidence sufficiency
Reporting requirements

The mistake

A CPA firm treats a SOC engagement as a conventional financial statement audit with different report language.

The AICPA continues to provide specialized SOC schools focused on common peer-review findings and pitfalls, which indicates that engagement-quality problems remain an active professional concern.

Potential service-auditor problems include:

Inadequate risk assessment
Insufficient tests of design
Poor population validation
Weak sample selection
Failure to evaluate exceptions
Incomplete subservice organization treatment
Incorrect report language
Insufficient understanding of the technology
Failure to address non-operating controls properly

Better practice

Before retaining a service auditor, management should evaluate:

SOC experience
Industry knowledge
IT expertise
Peer-review status
Engagement methodology
Staffing continuity
Quality-review procedures
Ability to explain findings clearly

The lowest-cost provider may become the most expensive choice if customers or auditors cannot rely on the report.

Issue 15: Artificial Intelligence Is Creating New SOC Questions

During the last two years, service organizations have accelerated their use of generative

AI and machine learning.

AI may influence:

Customer support
Fraud detection
Software development
Data analysis
Access decisions
Security monitoring
Content generation
Automated processing

Emerging SOC questions include:

Is AI included within the system boundary?
What customer data enter the model?
Are prompts retained?
Are outputs validated?
Who approves model changes?
Are third-party AI providers subservice organizations?
How are hallucinations and bias monitored?
How is confidential information protected?
Are AI-generated decisions logged?
Which CUECs apply to customers using AI features?

The problem

Existing SOC descriptions and control matrices may not reflect AI-enabled processing.

Better practice

Service organizations should evaluate whether AI changes:

The system description
Risk assessment
Processing-integrity controls
Confidentiality controls
Privacy controls
Vendor inventory
Change management
Incident response
Customer responsibilities

AI should not be silently added to a system that was examined under a different operating model.

What Audit Committees and Executives Should Ask

Management and governing bodies should ask:

Are we obtaining the correct SOC report for each significant provider?
Is the report Type 1 or Type 2, and does that meet our objective?
Does the report period cover our reliance period?
Is the service we use actually within scope?
Is the auditor’s opinion modified?
What testing exceptions were reported?
Which CUECs must we operate?
Which subservice organizations were carved out?
Do we need additional SOC reports?
Has the provider experienced major changes since the report date?
Does the report address our regulatory requirements?
Who owns the review and remediation process?
Can Internal Audit and External Audit rely on the report?
What compensating controls exist when they cannot?
Is AI changing the provider’s risk profile or system description?

A vague answer such as “Procurement has the SOC report” is not sufficient.

The Central Lesson from the Past Five Years

The problems surrounding SOC reporting have not resulted from a lack of reports.

Organizations now collect more reports than ever.

The problems arise because companies:

Request the wrong report
Misunderstand Type 1 and Type 2
Ignore coverage gaps
Read only the opinion
Miss exceptions
Fail to implement CUECs
Overlook carved-out providers
Treat SOC 2 as certification
Confuse assurance with regulatory compliance
Fail to integrate reports into vendor governance
Assume outsourcing transfers responsibility

The strongest organizations do not simply collect SOC reports.

They use them.

They connect the report to:

The vendor-risk assessment
Contract requirements
Financial-reporting controls
Cybersecurity governance
Regulatory compliance
Internal Audit
Business continuity
Management accountability

That is when a SOC report becomes valuable.

Learn the SOC Process from Three Perspectives

Corporate Compliance Seminars will present SSAE SOC Audits: Auditee–Auditor–Assessor Training from Tuesday through Thursday, August 18–20, 2026.

The 18-CPE program examines SOC reporting from the perspectives of:

The service organization preparing for the examination
The CPA performing the SOC engagement
The user organization or auditor assessing the completed report

Topics include:

SOC 1, SOC 2, and SOC 3
Type 1 and Type 2 reports
System descriptions
Risk and control assessment
Trust Services Criteria
Control testing
Exceptions
Subservice organizations
CUECs
Bridge letters
Auditor opinions
Regulatory applications
Third-party risk management

This seminar is also available as an in-person, three-day class for 24 NASBA-approved CPE credits.

This seminar is also available as an in-person, five-day workshop, for 40 hours of NASBA-approved CPE credits. Attendees of the workshop will receive and understand SOC documentation such as a sample client presentation, a SOC workplan, a fee estimate schedule, a client proposal, samples of auditor workpapers, samples of SOC reviewer assessments, and much more. This workshop is $4250.00.

A SOC report can be one of the organization’s most valuable sources of third-party assurance.

It can also become an expensive document that no one properly reads.

The difference is competence.