SSAE SOC Audits Training: Learn to Prepare, Perform, Assess, and Use SOC Reports

SOC Reports Have Become Essential to Third-Party Risk Management

Organizations increasingly outsource critical business functions to cloud providers, payroll processors, data centers, claims administrators, payment processors, software companies, managed service providers, and other third parties.

Outsourcing may improve efficiency and reduce operating costs, but it does not transfer every risk.

Management remains responsible for understanding whether service organizations adequately protect information, process transactions accurately, maintain system availability, support financial reporting, and operate effective internal controls.

That is why System and Organization Controls reports, commonly called SOC reports, have become a central component of vendor due diligence, financial auditing, cybersecurity assurance, regulatory compliance, and third-party risk management.

Corporate Compliance Seminars will present SSAE SOC Audits: Auditee–Auditor–Assessor Training from Tuesday through Thursday, August 18–20, 2026. This three-day, live online program provides 18 NASBA-approved CPE credits and is designed for professionals who prepare for SOC examinations, perform SOC engagements, assess service organizations, or rely on SOC reports when evaluating vendors.

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.

What makes the CCS program distinctive is its three-perspective approach:

• The auditee, or service organization preparing for the examination

• The auditor, or CPA performing the attestation engagement

• The assessor, user auditor, compliance professional, or customer evaluating the resulting report

A SOC report cannot be used effectively unless all three perspectives are understood.

Why SOC Reporting Matters

Organizations outsource activities because specialized providers may deliver services more efficiently or economically. However, outsourcing introduces risks that user organizations must identify, assess, and manage. The AICPA explains that SOC examinations provide information about controls at service organizations so customers and other interested parties can evaluate risks associated with outsourced services.

Examples of outsourced services include:

• Cloud hosting

• Software-as-a-Service applications

• Payroll processing

• Healthcare claims administration

• Loan servicing

• Payment processing

• Data storage

• Cybersecurity monitoring

• Insurance policy administration

• Financial reporting support

A service organization’s failure may affect:

• Financial reporting

• Information security

• Privacy

• Regulatory compliance

• Customer service

• Business continuity

• Reputation

• Contract performance

A SOC report helps users understand what controls the service organization has implemented and, depending on the report, whether those controls were suitably designed and operated effectively.

SOC Reports Are Not All the Same

The term “SOC report” is often used as though it describes one document.

It does not.

The AICPA has developed several SOC reporting options for different objectives and intended users. AICPA training materials identify SOC 1, SOC 2, and SOC 3 as distinct reports with different purposes and audiences.

Understanding those differences is one of the first responsibilities of every service organization, auditor, and report user.

What Is a SOC 1 Report?

A SOC 1 report addresses controls at a service organization that are relevant to user entities’ Internal Control over Financial Reporting.

SOC 1 reports are commonly relevant when the service organization performs activities that affect a customer’s financial statements.

Examples include:

• Payroll processing

• Claims processing

• Loan servicing

• Transaction processing

• Trust accounting

• Fund administration

• Billing

• Accounts-receivable processing

• Data-center services supporting financial applications

The key question is:

Could controls at this service organization affect the financial reporting of its customers?

When the answer is yes, a SOC 1 report may be appropriate.

User auditors frequently rely on SOC 1 reports when planning and performing financial statement audits. However, the report must be read carefully to determine whether its scope, period, systems, controls, exceptions, subservice organizations, and complementary user-entity controls are relevant to the audit.

What Is a SOC 2 Report?

A SOC 2 report evaluates controls relevant to one or more of the AICPA Trust Services Criteria:

• Security

• Availability

• Processing integrity

• Confidentiality

• Privacy

SOC 2 reports are particularly common among technology and cloud-service providers.

A SOC 2 engagement may address risks involving:

• Logical access

• Authentication

• Change management

• Incident response

• System monitoring

• Encryption

• Vendor management

• Backup and recovery

• Data confidentiality

• Privacy practices

• Processing accuracy

The security category is generally included in a SOC 2 examination, while the other categories are included when relevant to the system and customer needs.

A SOC 2 report is not automatically proof that a service organization has no security weaknesses. It is an attestation report covering defined controls, criteria, systems, boundaries, and time periods.

The reader must understand exactly what was examined.

What Is a SOC 3 Report?

A SOC 3 report addresses the same general Trust Services Criteria environment as SOC 2 but is designed for broader distribution.

Unlike the detailed SOC 2 report, a SOC 3 report generally does not include the same extensive description of controls, testing procedures, and test results.

It may be useful for:

• Marketing

• Public assurance

• Customer communications

• General demonstrations of control assurance

A SOC 3 report can provide value, but it generally does not give auditors and sophisticated assessors enough detail to perform a complete control evaluation.

For detailed vendor-risk analysis, the restricted-use SOC 2 report is usually more informative.

Type 1 and Type 2 Reports Are Fundamentally Different

A major source of confusion is the distinction between Type 1 and Type 2 reports.

Type 1 Report

A Type 1 report generally addresses the design and implementation of controls as of a specified date.

It answers a question similar to:

Were the controls suitably designed and implemented at this point in time?

Type 2 Report

A Type 2 report addresses the design and operating effectiveness of controls over a specified period.

It asks:

Were the controls suitably designed, and did they operate effectively throughout the period examined?

A Type 2 report normally provides stronger evidence regarding control operation because it includes testing over time.

However, users should not assume that every Type 2 report provides the assurance they need. The report’s scope, period, testing, exceptions, and applicable controls still require careful evaluation.

SSAE Standards Form the Attestation Foundation

SOC engagements are performed under the AICPA’s Statements on Standards for Attestation Engagements.

The CCS course reviews the progression from SAS 70 to SSAE 16 and later attestation guidance, including the changes associated with SSAE 18 and subsequent updates. It also examines how these standards apply to SOC 1, SOC 2, and SOC 3 engagements.

The transition away from SAS 70 was important because SAS 70 had increasingly been used for purposes beyond its original financial-reporting focus.

Modern SOC reporting provides more clearly defined options based on:

• The subject matter

• The intended users

• Applicable criteria

• The nature of the service organization

• The risks users need to evaluate

The auditor must identify the appropriate engagement before testing begins.

The Auditee Perspective: Preparing the Service Organization

A service organization should not begin preparing for a SOC examination a few weeks before fieldwork.

A successful examination requires an operating control environment.

Preparation typically includes:

1. Defining the system and examination scope

2. Identifying applicable criteria or control objectives

3. Documenting processes and controls

4. Assigning control ownership

5. Evaluating control design

6. Collecting evidence

7. Testing readiness

8. Correcting identified deficiencies

9. Preparing management’s assertion

10. Coordinating with the service auditor

The CCS course teaches participants how organizations prepare for SOC engagements and how internal controls are identified, documented, tested, and evaluated.

Scope Is One of the Most Important Decisions

An incorrectly scoped SOC examination may produce a technically valid report that does not satisfy customer needs.

The scope should address:

• Services covered

• Systems included

• Locations included

• Infrastructure

• Applications

• Data

• People

• Procedures

• Relevant subservice organizations

• Applicable control objectives or Trust Services Criteria

A scope that is too narrow may exclude significant risks.

A scope that is too broad may increase cost, delay completion, and include controls that do not meaningfully support user needs.

Before beginning, the organization should ask:

• Who will use the report?

• What risks are they trying to evaluate?

• What contractual or regulatory requirements apply?

• Which systems support the covered services?

• What period must be examined?

• Which subservice organizations affect the service?

The System Description Must Be Accurate

Management is responsible for describing the service organization’s system.

That description may include:

• Services provided

• System boundaries

• Infrastructure

• Software

• People

• Procedures

• Data

• Control environment

• Risk assessment

• Information and communication

• Monitoring

• Significant system changes

• Subservice organizations

• Complementary user-entity controls

A generic or outdated description can create serious problems.

The report should describe how the system actually operates—not how management hopes it operates.

The description should be updated when the organization changes:

• Technology platforms

• Hosting arrangements

• Vendors

• Locations

• Processes

• Security architecture

• Customer responsibilities

Control Ownership Must Be Clear

A SOC readiness process often reveals that controls exist but are not clearly owned.

For example:

• IT believes Human Resources owns user termination.

• Human Resources believes the manager initiates access removal.

• The manager assumes the system performs it automatically.

• Security believes the application owner verifies completion.

The result may be a control gap.

Each control should identify:

• The control owner

• The performer

• The reviewer

• The frequency

• Required evidence

• Exception procedures

• Escalation requirements

A control is not mature when everyone participates but no one is accountable.

Evidence Must Demonstrate That the Control Operated

Policies and procedures establish expectations.

They do not prove that controls operated.

Evidence may include:

• System logs

• Access-review records

• Approved tickets

• Reconciliations

• Monitoring reports

• Security alerts

• Change approvals

• Incident records

• Backup test results

• Training records

• Vendor assessments

• Meeting minutes

The evidence should show:

• What occurred

• When it occurred

• Who performed it

• Who reviewed it

• What exceptions were identified

• How exceptions were resolved

A control that operates without retaining evidence may be difficult for the auditor to test.

Readiness Assessments Reduce Examination Surprises

Before the formal SOC examination, many service organizations perform a readiness assessment.

A readiness assessment can identify:

• Missing controls

• Poorly documented controls

• Inconsistent performance

• Insufficient evidence

• Scope gaps

• Weak descriptions

• Unclear user responsibilities

• Subservice-organization issues

• Exceptions requiring remediation

The objective is not to guarantee an unmodified opinion.

It is to determine whether the organization is prepared for the examination and whether identified weaknesses can be corrected before the reporting period begins or concludes.

The Auditor Perspective: Planning the SOC Engagement

The service auditor must understand:

• The service organization

• Intended users

• Services provided

• Applicable criteria

• System boundaries

• Risks

• Controls

• Subservice organizations

• Complementary controls

• Management’s assertion

The AICPA’s current SOC school emphasizes planning, executing, and reporting on SOC engagements, as well as avoiding common deficiencies and misconceptions.

Planning should be risk-based rather than a mechanical repetition of prior-year procedures.

Control Objectives and Criteria Drive the Examination

For SOC 1 engagements, control objectives are developed based on risks relevant to user entities’ financial reporting.

For SOC 2 engagements, controls are evaluated against applicable Trust Services Criteria.

The auditor should determine whether:

• The criteria are suitable

• The system description is fairly presented

• The identified controls address the criteria

• The controls are suitably designed

• The controls were implemented

• For Type 2 engagements, the controls operated effectively

Testing should connect directly to the applicable criterion or control objective.

Sampling Must Support the Conclusion

Many SOC controls operate repeatedly.

Examples include:

• User-access approvals

• Change approvals

• Incident reviews

• Backup monitoring

• Vendor assessments

• Reconciliations

• Security reviews

The service auditor may use sampling to test control operation.

The sample design should consider:

• Control frequency

• Population size

• Risk

• Expected deviations

• Nature of evidence

• Period covered

• Planned assurance

Selecting a standard number of items without considering these factors may not produce sufficient evidence.

The auditor must also verify that the population from which the sample was selected is complete and accurate.

Exceptions Must Be Evaluated Carefully

An exception does not automatically mean the entire control environment failed.

It also should not be dismissed merely because it is isolated.

The auditor should understand:

• Nature of the exception

• Cause

• Frequency

• Duration

• Population affected

• Control objective affected

• Compensating controls

• Potential consequences

• Whether the exception is systemic

• Effect on the opinion

A minor documentation issue may have limited effect.

An exception involving privileged access, incident response, or an unapproved production change may have greater significance.

The CCS course addresses common SOC control deficiencies, test documentation, deficiency evaluation, and how auditors form SOC opinions.

Subservice Organizations Must Be Addressed

Many service organizations depend on other providers.

Examples include:

• Cloud infrastructure providers

• Data centers

• Managed security providers

• Payment processors

• Backup providers

• Customer-support vendors

These are often called subservice organizations.

The SOC report should clearly explain how they are treated.

Two common methods are:

Inclusive Method

Relevant controls at the subservice organization are included within the report’s scope and examination.

Carve-Out Method

The subservice organization is identified, but its controls are excluded from the examination.

When the carve-out method is used, users may need to obtain and evaluate a separate SOC report from the subservice organization.

The CCS course specifically addresses vendor and subservice-organization management within the SOC scope.

Complementary User-Entity Controls Cannot Be Ignored

A SOC report may identify controls that customers must operate for the service organization’s controls to achieve the intended objectives.

These are commonly called Complementary User-Entity Controls, or CUECs.

Examples may include requirements for the customer to:

• Approve authorized users

• Remove terminated users

• Protect credentials

• Review reports

• Reconcile output

• Configure security settings

• Notify the provider of incidents

• Maintain its own backup procedures

A service organization’s SOC report does not establish that the customer performed these controls.

The user organization must identify applicable CUECs and determine whether its own controls address them.

The Assessor Perspective: Reading the SOC Report Correctly

Obtaining a SOC report is not the same as evaluating it.

A user organization should determine:

• Is this the correct type of SOC report?

• Does it cover the required service?

• Is the examination period relevant?

• Is the service auditor independent?

• Is the opinion modified?

• Are significant controls excluded?

• Were exceptions identified?

• Are subservice organizations carved out?

• Which complementary user-entity controls apply?

• Has the system changed since the report period?

• Is a bridge letter needed?

A report should not be accepted simply because the cover says “SOC 2 Type 2.”

Start with the Auditor’s Opinion

The opinion should be reviewed before the control details.

The assessor should identify whether the opinion is:

• Unmodified

• Qualified

• Adverse

• Subject to other limitations or explanatory matters

A qualified opinion does not necessarily make the report unusable.

It means the user must understand:

• The reason for the qualification

• Controls affected

• Risks created

• Whether compensating controls exist

• Whether the issue affects the services being used

Ignoring a modified opinion defeats the purpose of obtaining the report.

Review the Period Covered

A Type 2 report covers a defined period.

The user should determine whether the period aligns with:

• The financial statement audit

• Vendor review cycle

• Contract period

• Compliance obligation

• Current risk assessment

A report ending several months before year-end may require additional evidence.

A service organization may provide a bridge letter describing material changes since the report period. However, a bridge letter is management representation, not an extension of the auditor’s examination.

Read the Exceptions, Not Just the Opinion

An unmodified opinion does not mean every control test was exception-free.

The assessor should review:

• Testing procedures

• Exceptions

• Management responses

• Affected controls

• Frequency and extent

• Potential customer effect

For example, one delayed access termination may have a different implication from repeated failures involving privileged users.

The assessor should determine whether identified exceptions affect the organization’s specific use of the service.

Evaluate Complementary User-Entity Controls

A user organization should map applicable CUECs to its own controls.

A practical assessment may include:

SOC requirement	Internal owner	Existing control	Evidence	Gap
Review authorized-user lists	Application owner	Quarterly access review	Approved report	None
Remove terminated users	HR and IT	Automated termination feed	System log	Timing needs testing
Reconcile service-provider reports	Finance	Monthly reconciliation	Signed reconciliation	None

Without this mapping, the organization may rely on the SOC report while failing to perform the controls expected of it.

SOC Reports Support, but Do Not Replace, Vendor Management

A SOC report is one source of assurance.

It does not replace:

• Vendor due diligence

• Contract review

• Cybersecurity assessment

• Financial analysis

• Service-level monitoring

• Incident reporting

• Business-continuity review

• Regulatory compliance

• Ongoing performance monitoring

A vendor may have a strong SOC report but still present unacceptable risk because of:

• Financial instability

• Poor contract terms

• Geographic concentration

• Data-residency issues

• Inadequate insurance

• Regulatory restrictions

• Excessive subcontracting

• Service-performance failures

The report should be integrated into a broader third-party risk-management program.

SOC Reports and Regulatory Compliance

SOC reports may support compliance activities involving:

• Sarbanes-Oxley

• HIPAA

• Gramm-Leach-Bliley Act

• Financial statement audits

• Privacy requirements

• Cybersecurity programs

• Vendor oversight

• Internal audit

• Regulatory examinations

However, a SOC report does not automatically establish compliance with every law or framework.

The CCS course examines how SOC reports relate to SOX, HIPAA, GLBA, COBIT, NIST guidance, and other regulatory and control environments.

The user must determine whether:

• The report covers the relevant requirements

• The controls align with the obligation

• Additional evidence is needed

• Customer controls have been implemented

SOC Reports and Internal Audit

Internal Audit may evaluate SOC reports as part of:

• Vendor audits

• Financial audits

• IT audits

• Cybersecurity reviews

• SOX testing

• Compliance audits

• Business-continuity assessments

Internal auditors should avoid two extremes.

Overreliance

Assuming the SOC report resolves all vendor risk.

Underuse

Ignoring a credible source of independent assurance and duplicating work unnecessarily.

A risk-based approach considers:

• Scope

• Relevance

• Period

• Opinion

• Exceptions

• User controls

• Subservice organizations

• Changes since issuance

Common SOC Readiness Problems

Service organizations frequently encounter similar problems:

• Controls exist but are undocumented.

• Policies do not match actual practice.

• Evidence is not retained.

• Control ownership is unclear.

• Reviews are not performed consistently.

• User access is not removed promptly.

• Changes lack approval.

• Vendor reviews are overdue.

• Incident-response tests are incomplete.

• System descriptions are outdated.

• CUECs are vague.

• Subservice organizations are not fully identified.

These problems are easier to correct before the formal examination period than after the auditor begins testing.

Common SOC Report Assessment Mistakes

User organizations also make recurring mistakes:

• Requesting the wrong report

• Accepting a Type 1 report when operating evidence is needed

• Reviewing only the opinion

• Ignoring test exceptions

• Failing to evaluate CUECs

• Ignoring carved-out vendors

• Accepting an outdated report

• Treating a bridge letter as audited evidence

• Assuming SOC 2 means complete cybersecurity compliance

• Failing to document the assessment

The CCS event is designed to teach participants how to interpret and document SOC reports instead of merely collecting them.

Artificial Intelligence and SOC Engagements

AI can assist with SOC-related work by:

• Comparing control descriptions

• Mapping controls to criteria

• Summarizing exceptions

• Preparing readiness checklists

• Drafting evidence requests

• Organizing CUECs

• Identifying inconsistent terminology

• Developing assessor summaries

However, AI may also create risks involving:

• Confidential information

• Unsupported conclusions

• Incorrect criteria mapping

• Hallucinated requirements

• Inadequate human review

• Undocumented processing

AI may support the work.

The service organization, auditor, and assessor remain responsible for the conclusions.

What Participants Will Learn

The SSAE SOC Audits: Auditee–Auditor–Assessor Training program provides a complete introduction to the SOC reporting lifecycle.

Participants will learn how to:

• Understand internal-control and risk-management frameworks

• Understand AICPA attestation standards governing SOC engagements

• Distinguish among SOC 1, SOC 2, and SOC 3 reports

• Determine which report is appropriate

• Prepare a service organization for an examination

• Define the examination scope

• Identify and document controls

• Conduct and document control testing

• Evaluate physical and logical security

• Address vendors and subservice organizations

• Identify complementary user-entity controls

• Evaluate control deficiencies

• Understand how the auditor forms the opinion

• Interpret SOC reports

• Document a user organization’s assessment

• Relate SOC reports to regulatory and third-party risk requirements

Who Should Attend?

This program is designed for professionals involved at any stage of the SOC process, including:

• External auditors

• Internal auditors

• SOC engagement teams

• Service-organization management

• Compliance officers

• IT professionals

• Information-security professionals

• Vendor-risk managers

• Controllers

• User auditors

• Risk assessors

• Professionals preparing for SOC examinations

• Professionals responsible for reviewing SOC reports

The course is particularly useful for organizations that need a common understanding among operations, IT, compliance, Internal Audit, and external-assurance personnel.

Why This Training Matters

SOC reports sit at the intersection of:

• Auditing

• Internal control

• Cybersecurity

• Financial reporting

• Vendor management

• Compliance

• Risk assessment

The service organization must understand how to prepare.

The service auditor must understand how to examine.

The user organization must understand how to assess.

Weakness in any one of those roles reduces the report’s value.

Corporate Compliance Seminars’ three-day program is designed to help participants understand the entire process rather than viewing SOC reporting from only one side of the engagement.

That broader perspective helps organizations produce stronger reports, perform better examinations, and make more informed third-party risk decisions.

Register for the August 18–20, 2026 Program

The growth of outsourcing, cloud computing, managed services, and technology-based business processes continues to increase demand for credible information about service-organization controls. The AICPA continues to identify SOC 1, SOC 2, and SOC 3 examinations as important mechanisms for helping organizations evaluate risks associated with outsourced services.

The SSAE SOC Audits: Auditee–Auditor–Assessor Training event provides 18 CPE credits of practical instruction on preparing, conducting, evaluating, and using SOC engagements.

A SOC report should not be treated as a compliance certificate.

It is an assurance report that must be correctly scoped, properly examined, and intelligently evaluated.

Frequently Asked Questions

What is a SOC report?

A SOC report is an independent attestation report concerning controls at a service organization. Different SOC reports address different user needs, including financial-reporting controls and Trust Services Criteria.

What is the difference between SOC 1 and SOC 2?

SOC 1 focuses on controls relevant to user entities’ Internal Control over Financial Reporting. SOC 2 focuses on controls related to security, availability, processing integrity, confidentiality, or privacy.

What is the difference between Type 1 and Type 2?

A Type 1 report addresses control design and implementation as of a specified date. A Type 2 report also addresses operating effectiveness over a specified period.

Who can perform a SOC examination?

SOC examinations are attestation engagements performed by qualified independent CPA firms under applicable AICPA professional standards.

Does a SOC 2 report prove that a company is secure?

No. A SOC 2 report provides assurance concerning defined controls, criteria, systems, and a specified period. Users must evaluate the report’s scope, opinion, exceptions, and relevance.

What are complementary user-entity controls?

These are controls the user organization is expected to operate so that the service organization’s controls can achieve the stated objectives.

What is a subservice organization?

A subservice organization is another provider used by the primary service organization to perform part of the covered service. Its controls may be included in or carved out of the SOC examination.

How many CPE credits does the program provide?

The three-day event provides 18 NASBA-approved CPE credits in Auditing and Information Technology.