01 Introduction to SOC Reports

Organizations increasingly depend on third-party service providers to operate critical business and technology services.

Examples include:

Cloud Providers

Payroll Providers

Payment Processors

SaaS Platforms

Managed Service Providers

Data Centers

Identity Providers

Financial Processing Services

When an organization relies on another company, an important assurance question appears:

How do we know the service provider has appropriate controls in place and that those controls are operating effectively?

One of the most common answers is a SOC report.

SOC reports provide independent assurance over controls operated by service organizations.

For GRC professionals, SOC reports are important because they are frequently used during:

Third-party risk assessments.
Vendor onboarding.
Customer assurance.
Internal audits.
External audits.
Cloud-provider reviews.
Financial reporting assessments.
Security compliance reviews.

This lesson introduces the SOC reporting ecosystem before we go deeper into SOC 1, SOC 2, Trust Services Criteria, readiness assessments, evidence collection, and audit support.

Learning Objectives

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

Explain what a SOC report is.
Understand why organizations use SOC reports.
Explain the role of service organizations.
Understand the role of service auditors.
Distinguish SOC 1, SOC 2, and SOC 3.
Understand Type I and Type II reports.
Explain the concept of a system description.
Understand control objectives and criteria.
Understand complementary user entity controls.
Understand subservice organizations.
Understand inclusive and carve-out methods.
Identify important sections of a SOC report.
Evaluate report scope and period.
Identify control exceptions.
Understand management assertions.
Understand auditor opinions.
Understand restricted-use considerations.
Use SOC reports during third-party risk reviews.
Build a practical SOC report review workflow.

1. What Does SOC Mean?

SOC commonly refers to:

System and Organization Controls

SOC reports are independent assurance reports examining controls at service organizations.

A simplified model is:

Service Organization
      ↓
Operates Controls
      ↓
Independent Auditor
      ↓
Tests / Evaluates Controls
      ↓
SOC Report
      ↓
Customers & Auditors

2. Why SOC Reports Exist

Consider an organization using an external payroll provider.

The customer may need assurance that the provider appropriately controls:

Access

System Changes

Processing

Security

Availability

Data Protection

It may be impractical for every customer to perform its own full audit of the provider.

SOC reporting creates a standardized assurance mechanism.

3. Service Organization

A service organization provides services to other organizations.

Examples include:

Payroll Processor

Cloud Provider

Managed IT Provider

SaaS Vendor

Payment Processor

Data Processing Company

The services may affect the customer’s:

Financial reporting.
Security posture.
Availability.
Confidentiality.
Processing integrity.
Privacy.

4. User Entity

The organization consuming the service is commonly referred to as a user entity in the SOC context.

Conceptually:

Service Organization
      ↓
Provides Service
      ↓
User Entity

Example:

Payroll SaaS Provider
      ↓
Payroll Service
      ↓
Customer Company

5. Service Auditor

The SOC report is examined by an independent practitioner.

The service auditor evaluates the service organization’s controls against the applicable reporting criteria.

The auditor may:

Review Documentation

Interview Personnel

Inspect Evidence

Perform Walkthroughs

Sample Transactions

Test Controls

6. Why Independent Assurance Matters

Without independent assurance:

Vendor Says:
"Our controls are effective."

With SOC assurance:

Vendor Management Assertion
      +
Independent Auditor Examination

This provides stronger evidence.

7. SOC Reports Are Not Certifications

An important distinction:

SOC Report
≠
Certification

SOC reporting provides an auditor’s opinion and detailed assurance over defined controls and criteria.

It is not simply a pass/fail certificate.

8. Main SOC Report Types

The most commonly discussed reports are:

SOC 1

SOC 2

SOC 3

They serve different purposes.

9. SOC 1

SOC 1 focuses on controls relevant to user entities’ internal control over financial reporting, commonly abbreviated:

ICFR

SOC 1 is especially relevant when the outsourced service could affect financial statements.

Examples:

Payroll Processing

Claims Processing

Transaction Processing

Financial Record Processing

10. SOC 1 Example

Suppose a company outsources payroll.

The payroll provider processes:

Salary

Tax

Deductions

Payments

Errors could affect financial reporting.

Therefore a SOC 1 report may be relevant.

11. SOC 2

SOC 2 focuses on controls relevant to the Trust Services Criteria.

These criteria cover areas including:

Security

Availability

Processing Integrity

Confidentiality

Privacy

SOC 2 is widely used for:

SaaS providers.
Cloud providers.
Technology vendors.
Security service providers.
Data processors.

12. SOC 2 Example

An enterprise is evaluating a SaaS provider storing confidential customer data.

The GRC team may review the provider’s SOC 2 report to understand controls related to:

Access Control

Change Management

Logging

Incident Response

Vendor Risk

Data Security

13. SOC 3

SOC 3 covers Trust Services Criteria similar to SOC 2 but is designed for more general distribution.

A simplified comparison:

SOC 2
→ Detailed Assurance Report

SOC 3
→ General-Use Summary Report

SOC 3 usually provides less detailed control and testing information.

14. SOC 1 vs SOC 2

A useful distinction:

SOC 1
      ↓
Financial Reporting Controls

SOC 2
      ↓
Security & Trust Services Controls

This distinction is fundamental.

15. SOC 2 vs SOC 3

SOC 2
→ Detailed / Restricted Distribution

SOC 3
→ General Distribution

For detailed GRC due diligence, SOC 2 is generally far more useful.

16. Type I vs Type II

SOC 1 and SOC 2 reports can generally be issued as:

Type I

Type II

These provide different levels of assurance.

17. Type I

A Type I report focuses on control design and implementation at a specified date.

Conceptually:

Single Point in Time

Example:

As of:
31 December 2026

The key question is:

Are the controls suitably designed and implemented at that date?

18. Type II

A Type II report covers a period of time.

Example:

1 January
through
31 December

The auditor also evaluates operating effectiveness during the defined period.

Conceptually:

Design
+
Implementation
+
Operating Effectiveness

19. Why Type II Is Often Stronger

Example control:

Privileged access is reviewed quarterly.

A Type I assessment may establish that the process exists at a particular date.

A Type II report can test whether the quarterly control actually operated over the review period.

20. Type I vs Type II Summary

Area	Type I	Type II
Point in Time	Yes	No
Period of Time	No	Yes
Design	Yes	Yes
Implementation	Yes	Yes
Operating Effectiveness	No	Yes

21. SOC Report Period

Always identify:

Report Start Date

Report End Date

Example:

01 January 2026
to
31 December 2026

22. Why Report Period Matters

Suppose today’s date is:

August 2026

and the latest SOC report covers:

January–December 2024

The evidence may be too old for current assurance.

The GRC team should evaluate freshness.

23. Bridge Letters

Sometimes a SOC report period does not extend to the customer’s current audit period.

A provider may issue a bridge letter or similar interim representation describing relevant changes after the SOC report period.

Conceptually:

SOC Report Ends
      ↓
Gap Period
      ↓
Bridge Letter
      ↓
Current Review

A bridge letter is not equivalent to another full independent SOC examination.

24. SOC Report Scope

Always determine:

Which Service?

Which Locations?

Which Systems?

Which Legal Entity?

Which Control Environment?

Do not assume a vendor’s SOC report covers every service it sells.

25. Scope Example

Provider offers:

Cloud Hosting

Email Platform

AI Analytics

Backup Service

SOC report scope:

Cloud Hosting Only

Therefore:

AI Analytics
→ Not Covered

This matters during third-party assessment.

26. System Description

An important part of a SOC report is the description of the service organization’s system.

It may include:

Services

Infrastructure

Software

People

Procedures

Data

Boundaries

This helps readers understand exactly what is being examined.

27. Why System Description Matters

Controls cannot be evaluated properly without understanding the system.

For example:

SOC Report
→ SaaS Production Platform

does not necessarily cover:

Corporate IT

Experimental AI Service

Acquired Subsidiary

28. Infrastructure

System descriptions may identify:

Cloud Infrastructure

Servers

Networks

Databases

Data Centers

This helps evaluate service boundaries.

29. Software

The description may include:

Applications

Operating Platforms

Supporting Tools

Security Systems

30. People

SOC reports often describe roles involved in:

Security

Operations

Development

Customer Support

Management

31. Procedures

The system description may include:

Change Management

Incident Response

User Access

Monitoring

Backup

Vendor Management

32. Data

The report may describe categories of information processed by the service.

This can be useful for:

Confidentiality assessments.
Privacy reviews.
Data-flow understanding.

33. Management Assertion

Management of the service organization provides assertions regarding the description and controls.

Conceptually:

Management
      ↓
Makes Assertions
      ↓
Auditor Examines

The independent auditor then expresses an opinion.

34. Auditor Opinion

The auditor’s opinion is one of the most important sections.

GRC should determine whether the opinion is:

Unmodified

Qualified

Adverse

or otherwise affected by identified matters.

35. Unmodified Opinion

An unmodified opinion generally indicates that the auditor did not identify matters requiring modification of the opinion based on the applicable criteria.

This does not mean:

No Exceptions Anywhere

Individual control-testing exceptions may still exist.

36. Qualified Opinion

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

This should trigger careful GRC review.

37. Adverse Opinion

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

For a critical provider, this would normally require serious risk assessment and management attention.

38. Control Description

SOC reports may contain detailed descriptions of controls.

Example:

Privileged system access is approved by authorized management and reviewed quarterly.

GRC should determine:

Who performs it?

How frequently?

What systems?

What evidence?

What testing occurred?

39. Test of Controls

In a Type II report, the service auditor may describe procedures performed to test controls.

Example:

Control:
Quarterly privileged access review

Auditor Test:
Selected quarterly reviews
and inspected evidence of management approval.

40. Test Results

Results may state:

No Exceptions Noted

or describe exceptions.

These sections are extremely important.

41. Control Exception

Example:

For 2 of 25 sampled access requests, evidence of manager approval was not available.

This does not automatically mean the entire provider is unacceptable.

GRC must assess:

Control

Exception

Frequency

Cause

Provider Response

Customer Impact

42. Exception Evaluation

Ask:

Is the control relevant to us?

Is the exception isolated?

Is it systemic?

What services are affected?

What data is affected?

What compensating controls exist?

43. Provider Management Response

A SOC report may include management’s response to exceptions.

Example:

Issue:
Access approval evidence missing

Provider Response:
Workflow updated and automated

GRC should determine whether the response adequately addresses the issue.

44. Exception Does Not Automatically Equal Failure

For example:

25 Samples
      ↓
1 Exception

may represent a different level of concern from:

25 Samples
      ↓
18 Exceptions

Context matters.

45. Complementary User Entity Controls

One of the most important SOC concepts is Complementary User Entity Controls, commonly called:

CUECs

These are controls the service organization expects its customers to implement.

46. Why CUECs Matter

Example:

Provider control:

Provider protects platform.

CUEC:

Customer must manage
authorized user access.

If the customer fails:

Provider Controls Effective
+
Customer Control Missing
=
Overall Risk

47. CUEC Example — Access

Provider expects customer to:

Remove terminated users.

Protect administrator credentials.

Review authorized users.

The customer GRC team should map these into its own control environment.

48. CUEC Example — Configuration

A SaaS provider may require customers to configure:

Security Settings

Retention

Sharing

MFA

These are customer responsibilities.

49. CUEC Review Workflow

For each SOC report:

Identify CUECs
      ↓
Determine Applicability
      ↓
Map Internal Control
      ↓
Assign Owner
      ↓
Validate Evidence

50. CUEC Register

Create:

CUEC	Applicable	Internal Control	Owner
User Access	Yes	IAM-001	IAM
Security Configuration	Yes	CFG-001	Cloud Team
Backup	No	N/A	N/A

51. Why CUECs Are Often Missed

Weak vendor review:

SOC Report Received
      ↓
No Major Exceptions
      ↓
Approved

Strong review:

SOC Report
      ↓
Scope
      ↓
Opinion
      ↓
Exceptions
      ↓
CUECs
      ↓
Customer Control Validation

52. Subservice Organizations

A service organization may rely on other providers.

Example:

SaaS Provider
      ↓
Cloud Infrastructure Provider

The cloud infrastructure provider may be a subservice organization.

53. Why Subservice Organizations Matter

The customer’s service depends on:

Primary Provider
      +
Underlying Provider

This introduces additional control dependencies.

54. Examples

Possible subservice organizations include:

Cloud Hosting Provider

Data Center Provider

Payment Processor

Managed Security Provider

55. Inclusive Method

Under an inclusive approach, relevant controls of the subservice organization may be included within the report’s scope.

Conceptually:

Primary Service Organization
      +
Subservice Organization Controls
      ↓
SOC Report Scope

56. Carve-Out Method

Under the carve-out method:

Subservice Organization Controls
→ Not Directly Included

The report instead describes the dependency and related responsibilities.

57. Why Carve-Out Matters

Example:

SaaS Provider
      ↓
Hosted on Cloud Provider

SOC report uses carve-out.

Then certain underlying infrastructure controls may need separate assurance.

GRC may review:

Cloud Provider SOC Report

as additional evidence.

58. Complementary Subservice Organization Controls

Reports may also identify controls expected to operate at subservice organizations.

This is another important dependency.

59. SOC Assurance Chain

A real enterprise chain might look like:

Customer
      ↓
SaaS Provider
      ↓
AWS
      ↓
Data Center / Other Provider

GRC should understand where assurance originates.

60. Restricted Use

Detailed SOC reports are typically distributed to defined audiences rather than publicly posted.

This matters because reports may contain:

Security Controls

System Architecture

Testing Details

Control Exceptions

They should be handled appropriately.

61. SOC Report Handling

Treat detailed SOC reports as sensitive vendor assurance information.

Common controls include:

Restricted Access

Approved Repository

No Public Sharing

Defined Retention

62. SOC 3 for Public Assurance

If an organization wants publicly shareable assurance, a SOC 3 report may be more appropriate.

It usually does not contain the same detailed control-testing information as SOC 2.

63. SOC Reports in Third-Party Risk

A vendor review may use:

Security Questionnaire
      +
SOC Report
      +
Contract Review
      +
Risk Assessment

SOC reports should not always be used alone.

64. SOC Report Does Not Answer Everything

A SOC 2 report may not fully address:

Financial Stability

Geopolitical Risk

Every Privacy Requirement

Custom Customer Requirements

Product-Specific Configuration

Customer Architecture

Additional due diligence may still be required.

65. SOC Reports and ISO

SOC and ISO are different assurance models.

A provider may have:

SOC 2

ISO/IEC 27001

Both

These can provide complementary assurance.

66. SOC 2 vs ISO/IEC 27001

A simplified distinction:

SOC 2
→ Independent assurance report over controls

ISO/IEC 27001
→ Certification of an ISMS against the standard

Each can be useful for third-party assurance.

67. SOC 2 and Cloud Compliance

For cloud providers, SOC 2 may provide evidence related to:

IAM

Monitoring

Incident Response

Change Management

Availability

Data Protection

But customer cloud responsibilities still remain.

68. SOC Report + Shared Responsibility

Example:

Cloud Provider SOC 2
      ↓
Provider Controls

Customer
      ↓
Customer Configurations

The SOC report proves only the defined provider-side assurance.

69. SOC Report Review Workflow

A practical review process is:

Receive Report
      ↓
Validate Report Type
      ↓
Validate Period
      ↓
Validate Scope
      ↓
Review Auditor Opinion
      ↓
Review System Description
      ↓
Review Controls
      ↓
Review Test Results
      ↓
Review Exceptions
      ↓
Review CUECs
      ↓
Review Subservice Organizations
      ↓
Assess Customer Impact
      ↓
Record Risk Decision

70. Step 1 — Validate Report Identity

Record:

Provider

Service

SOC Type

Type I / Type II

Audit Firm

Report Period

71. Step 2 — Confirm Required Report

Ask:

Are we reviewing:

SOC 1?

SOC 2?

SOC 3?

Do not use SOC 1 as a substitute for a security-oriented SOC 2 review when security assurance is the actual need.

72. Step 3 — Review Report Period

Record:

Start Date

End Date

Review Date

Determine whether bridge evidence is needed.

73. Step 4 — Review Scope

Determine:

Service Covered

Locations Covered

Infrastructure Covered

Product Features Covered

74. Step 5 — Review Auditor

Record the independent service auditor.

This supports report authenticity and traceability.

75. Step 6 — Read the Opinion

Do not begin with individual control tables.

First understand the overall auditor conclusion.

76. Step 7 — Review System Description

Understand:

What service is actually being examined?

77. Step 8 — Identify Relevant Controls

Prioritize areas based on customer risk.

Example:

IAM

Logging

Incident Response

Backup

Encryption

Change Management

78. Step 9 — Review Test Results

For Type II reports examine:

Testing Method

Sample

Exceptions

Result

79. Step 10 — Review Exceptions

Create an exception register if necessary.

Example:

Control	Exception	Relevance	Risk

80. Step 11 — Review CUECs

Do not approve the provider until customer responsibilities have been understood.

81. Step 12 — Review Subservice Organizations

Determine:

Inclusive?

Carved Out?

Separate assurance available?

82. Step 13 — Assess Risk

Use:

Report Scope

Opinion

Exceptions

CUECs

Subservice Organizations

Service Criticality

Data Sensitivity

83. Step 14 — Document Review Decision

Possible outcomes:

Acceptable

Acceptable With Actions

Additional Evidence Required

Risk Acceptance Required

Not Acceptable

84. SOC Review Register

Create:

Provider	Report	Period	Opinion	Exceptions	Status

85. Example SOC Review

Provider:

CloudCRM

Report:

SOC 2 Type II

Period:

1 Jan – 31 Dec

Opinion:

Unmodified

Exceptions:

2 Minor Access Review Exceptions

CUEC:

Customer must review administrators quarterly.

Decision:

Acceptable With Customer-Control Validation

86. Example High-Risk SOC Review

Provider:

Critical Payment Service

Report:

SOC 2 Type II

Finding:

Material exceptions in privileged-access controls

Customer impact:

Critical

Response:

Additional Due Diligence

Provider Remediation Review

Risk Owner Decision

87. Common SOC Review Metrics

Track:

Providers With Current SOC Reports

Reports Expiring

Qualified Opinions

Open Provider Exceptions

Unmapped CUECs

Carved-Out Subservice Organizations

88. SOC Assurance KPI

Example:

KPI:
Percentage of critical SOC-relevant providers
with current reviewed reports

Target:

100%

89. SOC Assurance KRI

Example:

KRI:
Number of critical providers
with unresolved material SOC exceptions

Tolerance:

90. Bridge Period KRI

Another useful metric:

Critical providers with SOC assurance
older than approved freshness threshold

91. SOC Report Evidence Register

Create:

Provider

Report

Period

Scope

Opinion

CUECs

Exceptions

Review Date

Reviewer

92. Report Authenticity

Where appropriate, obtain reports through:

Provider trust portal.
Authorized vendor contact.
Secure exchange.

Avoid relying on unverified documents from unknown sources.

93. Common SOC Report Review Mistakes

Mistake 1 — SOC 2 Means Vendor Is Secure

A SOC report still requires analysis.

Mistake 2 — SOC 1 Used as Security Assurance

SOC 1 has a different purpose.

Mistake 3 — Type I and Type II Treated as Equal

Operating-effectiveness coverage differs.

Mistake 4 — Report Period Ignored

Evidence may be stale.

Mistake 5 — Scope Ignored

The service in use may not be covered.

Mistake 6 — Opinion Not Read

Review starts only with control tables.

Mistake 7 — Exceptions Ignored

Potential provider risk remains unidentified.

Mistake 8 — CUECs Ignored

Customer-side control gaps remain invisible.

Mistake 9 — Carve-Out Ignored

Subservice-provider assurance may be missing.

Mistake 10 — SOC Report Treated as Entire Vendor Assessment

Other risks remain unassessed.

94. Weak SOC Review

Vendor Has SOC 2?
      ↓
Yes
      ↓
Approved

This provides weak assurance.

95. Strong SOC Review

SOC Report
      ↓
Correct Report?
      ↓
Current?
      ↓
Correct Scope?
      ↓
Opinion?
      ↓
Exceptions?
      ↓
CUECs?
      ↓
Subservice Organizations?
      ↓
Customer Impact?
      ↓
Risk Decision

96. Practical Activity — Build SOC Report Inventory

Create:

01 SOC Report Inventory

Use:

Provider	SOC Type	Report Type	Period	Status

Add at least five fictional providers.

97. Practical Activity — Build SOC Review Checklist

Create:

02 SOC Report Review Checklist

Include:

Provider confirmed.
Service confirmed.
SOC type confirmed.
Type I / Type II confirmed.
Period reviewed.
Scope reviewed.
Opinion reviewed.
System description reviewed.
Controls reviewed.
Exceptions reviewed.
CUECs reviewed.
Subservice organizations reviewed.
Risk decision documented.

98. Practical Activity — Build CUEC Register

Create:

03 Complementary User Entity Control Register

Use:

CUEC	Provider	Internal Control	Owner	Status

99. Practical Activity — Build SOC Exception Register

Create:

04 SOC Exception Register

Use:

Provider	Control	Exception	Impact	Action

100. Practical Activity — Build Subservice Organization Register

Create:

05 SOC Subservice Organization Register

Use:

Primary Provider	Subservice Provider	Method	Assurance	Status

101. Practical Activity — Perform SOC Review

Use this fictional scenario:

Provider:
CloudPayroll

Report:
SOC 1 Type II

Period:
01 Jan – 31 Dec

Auditor Opinion:
Unmodified

Exception:
2 payroll-change approvals lacked evidence

CUEC:
Customers must review payroll-input reports

Subservice:
Cloud Hosting Provider — Carved Out

Document:

Report Relevance

Exception Risk

Customer Responsibility

Additional Assurance Needed

Final Review Decision

102. SOC Report Review Checklist

Before accepting a report:

Report type is appropriate.
Type I / Type II understood.
Report period is current.
Scope includes required service.
Legal entity is appropriate.
System description understood.
Auditor opinion reviewed.
Relevant controls identified.
Testing reviewed.
Exceptions analyzed.
Management responses reviewed.
CUECs identified.
CUECs mapped internally.
Subservice organizations identified.
Inclusive/carve-out method understood.
Additional assurance identified if needed.
Residual risk evaluated.
Review decision documented.
Reassessment date established.

103. GRC Analyst Responsibilities

A GRC professional reviewing SOC reports may:

Request SOC reports from providers.
Validate report type.
Validate report period.
Review system scope.
Review auditor opinions.
Analyze control testing.
Analyze exceptions.
Identify CUECs.
Map CUECs to internal controls.
Identify subservice organizations.
Review carve-out dependencies.
Request additional assurance.
Perform provider risk analysis.
Track report freshness.
Prepare audit evidence.
Support vendor approval decisions.

GRC connects:

Provider

Procurement

Security

Privacy

Finance

Internal Audit

External Audit

Business Owners

104. SOC Assurance Maturity

Level 1 — Checkbox

SOC Report Exists?
→ Yes / No

Level 2 — Document Review

Report Type

Period

Opinion

Level 3 — Risk-Based Review

Scope

Exceptions

CUECs

Subservice Providers

Level 4 — Integrated Assurance

SOC Findings

Vendor Risk

Internal Controls

Remediation

Level 5 — Continuous Assurance

Report Expiry Monitoring

CUEC Tracking

Provider Findings

Dynamic Risk Updates

105. SOC Report Review Mindset

For every SOC report ask:

Why do we need this report?

Is it SOC 1 or SOC 2?

Is Type I or Type II more relevant?

What period does it cover?

Does it cover the service we use?

What does the system description include?

What is the auditor's opinion?

Which controls matter to us?

What exceptions were identified?

What did management do about them?

Which controls must we perform ourselves?

Which subservice organizations are involved?

Are any providers carved out?

What additional evidence do we need?

What residual risk remains?

If these questions can be answered, a SOC report becomes meaningful assurance rather than simply a compliance document.

Key Takeaways

SOC reports provide independent assurance over controls at service organizations.
SOC 1 focuses on controls relevant to user entities’ internal control over financial reporting.
SOC 2 focuses on controls evaluated using the Trust Services Criteria.
SOC 3 provides more general-use assurance with less detailed control information.
Type I reports focus on a specified date.
Type II reports evaluate controls over a defined period and include operating-effectiveness testing.
SOC reports should be reviewed for period, scope, system boundaries, and auditor opinion.
Individual control exceptions may exist even when the overall opinion is unmodified.
Control exceptions should be assessed for customer relevance and risk.
Complementary User Entity Controls identify controls customers are expected to operate.
CUECs should be mapped into the customer’s internal control framework.
Subservice organizations create additional assurance dependencies.
Inclusive and carve-out methods affect how subservice controls are addressed.
A SOC report is one input into vendor assurance, not necessarily the entire vendor-risk assessment.
GRC professionals should connect SOC assurance to provider risk, customer controls, evidence, and audit readiness.

Knowledge Check

Before continuing, make sure you can answer:

What is a SOC report?
What is a service organization?
What is a user entity?
What is the role of a service auditor?
What is SOC 1 primarily designed to address?
What is SOC 2 designed to address?
How does SOC 3 differ from SOC 2?
What is a Type I report?
What is a Type II report?
Why is Type II often valuable for operating-effectiveness assurance?
Why should report period be reviewed?
What is a bridge letter?
Why is report scope important?
What is a management assertion?
What is an auditor opinion?
What is a control exception?
What are Complementary User Entity Controls?
Why should CUECs be mapped internally?
What is a subservice organization?
What is the difference between inclusive and carve-out methods?

What’s Next?

➡️ Next: 02 — SOC 1 Explained

In the next lesson, you will go deeper into SOC 1 reports and controls relevant to Internal Control over Financial Reporting (ICFR).

You will learn how SOC 1 assurance works across:

Business Processes
      ↓
Financial Reporting Risk
      ↓
Control Objectives
      ↓
Service Organization Controls
      ↓
Complementary User Entity Controls
      ↓
Subservice Organizations
      ↓
Type I / Type II
      ↓
Control Testing
      ↓
Exceptions
      ↓
Financial Audit Reliance

You will also build practical artifacts including a SOC 1 Scope Matrix, Financial Reporting Risk-to-Control Map, Control Objective Register, CUEC Register, SOC 1 Exception Review, and SOC 1 Assurance Assessment Checklist.