02 SOC 1 Explained

SOC 1 reports focus on controls at a service organization that are relevant to a customer organization’s Internal Control over Financial Reporting, commonly called:

ICFR

The core question is:

Could a failure at this service provider materially affect the financial reporting of the customer organization?

If the answer is yes, SOC 1 may be relevant.

Typical examples include:

Payroll Processing

Payment Processing

Claims Administration

Loan Servicing

Transaction Processing

Accounting Services

Financial Data Processing

SOC 1 is therefore different from SOC 2.

A simple distinction is:

SOC 1
      ↓
Financial Reporting Assurance

SOC 2
      ↓
Security & Trust Services Assurance

For GRC professionals, SOC 1 is important because service-provider controls can become part of the customer’s financial-control environment.

Learning Objectives

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

Explain the purpose of SOC 1.
Understand ICFR.
Determine when SOC 1 is relevant.
Understand control objectives.
Understand Type I and Type II SOC 1 reports.
Understand financial transaction processing risk.
Understand the role of service organizations.
Understand the role of user entities.
Understand the role of user auditors.
Review SOC 1 report scope.
Review control descriptions.
Review auditor test procedures.
Analyze control exceptions.
Understand Complementary User Entity Controls.
Understand subservice organizations.
Understand inclusive and carve-out methods.
Understand how external financial auditors use SOC 1.
Map SOC 1 controls to internal financial controls.
Build practical SOC 1 assurance artifacts.

1. What Is SOC 1?

SOC 1 is an assurance report focused on controls at a service organization that are relevant to user entities’ financial reporting.

Conceptually:

Service Organization
      ↓
Processes Financially Relevant Activity
      ↓
Operates Controls
      ↓
Independent Auditor
      ↓
SOC 1 Report
      ↓
User Entity + User Auditor

2. Why SOC 1 Exists

Organizations increasingly outsource important financial processes.

Example:

Company
      ↓
Payroll Provider
      ↓
Salary Calculation
Tax Calculation
Payment Processing
Financial Data

If the provider makes errors, the company’s financial statements may be affected.

Therefore the company’s auditor needs assurance over the provider’s controls.

3. What Is ICFR?

ICFR means:

Internal Control over Financial Reporting

These are controls intended to support reliable financial reporting.

Examples include controls designed to help ensure:

Transactions are authorized

Transactions are complete

Transactions are accurate

Transactions are recorded correctly

Financial data is protected

Changes are controlled

4. Why Service Providers Affect ICFR

Suppose a company outsources payroll.

The provider calculates:

Gross Salary

Tax

Benefits

Deductions

Net Pay

These amounts may feed:

Payroll Expense

Tax Liability

Cash

Employee Liabilities

Therefore provider processing can directly affect the financial statements.

5. When SOC 1 Is Relevant

Ask:

Does the outsourced service process, support, or influence financially significant information?

If yes, SOC 1 may be appropriate.

Examples:

Payroll

Accounts Receivable

Payment Processing

Claims Processing

Loan Administration

Investment Processing

6. When SOC 1 May Not Be the Best Report

Consider a SaaS application that stores source code but does not materially affect financial reporting.

The primary assurance need may be:

Security

Availability

Confidentiality

In that case, SOC 2 may be more relevant.

7. SOC 1 Is About Relevance to Financial Reporting

Important:

Vendor Handles Financial Data

does not automatically mean:

SOC 1 Required

The question is whether the service and controls are relevant to the user entity’s ICFR.

8. Service Organization

In SOC 1, the service organization performs outsourced functions for user entities.

Example:

Payroll Processor

The processor may operate controls over:

Employee master-data changes.
Payroll calculations.
payment files.
tax processing.
system access.
changes to payroll software.

9. User Entity

The customer consuming the service is the:

User Entity

The user entity remains responsible for its own financial reporting and internal control environment.

Outsourcing does not eliminate accountability.

10. User Auditor

The user entity’s financial-statement auditor may rely on the SOC 1 report when evaluating ICFR.

Conceptually:

User Entity
      ↓
External Financial Auditor
      ↓
Needs Assurance Over Outsourced Process
      ↓
SOC 1

11. Service Auditor

The service auditor examines the service organization’s controls.

The auditor evaluates:

System Description

Control Objectives

Control Design

Implementation

Operating Effectiveness

depending on report type.

12. SOC 1 Report Types

SOC 1 commonly exists as:

Type I

Type II

13. SOC 1 Type I

Type I reports address a specified date.

They focus on whether controls are suitably designed and implemented at that point in time.

Conceptually:

31 December
      ↓
Do Controls Exist?
      ↓
Are They Suitably Designed?

14. SOC 1 Type II

Type II covers a defined period.

Example:

01 January
to
31 December

It evaluates:

Design
+
Implementation
+
Operating Effectiveness

15. Why Type II Often Matters More

Financial-statement auditors usually need assurance over a period.

For example:

Financial Year
01 Jan – 31 Dec

A Type II report covering that period can provide more relevant evidence than a point-in-time report.

16. SOC 1 Type I vs Type II

Area	Type I	Type II
Specific Date	Yes	No
Period of Time	No	Yes
Design	Yes	Yes
Implementation	Yes	Yes
Operating Effectiveness	No	Yes

17. SOC 1 Control Objectives

SOC 1 reports often describe control objectives relevant to the service.

A control objective defines what the control environment is intended to achieve.

Example:

Controls provide reasonable assurance that payroll transactions are processed completely, accurately, and in accordance with authorized instructions.

18. Control Objective vs Control

Control objective:

Payroll changes are authorized.

Control:

Changes to employee compensation require approval from an authorized HR manager before processing.

The objective describes the desired outcome.

The control describes the activity.

19. Example Payroll Control Objective

Objective:

Employee master-data changes are authorized, complete, and accurately processed.

Controls may include:

Manager Approval

System Validation

Change Logging

Exception Reporting

20. Example Payment Processing Objective

Objective:

Payment transactions are processed completely and accurately.

Controls:

Reconciliation

Transaction Validation

Approval

Exception Review

21. Financial Reporting Assertions

SOC 1 controls may support financial-reporting concerns such as:

Completeness

Accuracy

Occurrence

Authorization

Cutoff

Classification

The exact audit relationship depends on the process and financial statements.

22. Transaction Processing Lifecycle

Consider:

Transaction Initiated
      ↓
Authorized
      ↓
Processed
      ↓
Recorded
      ↓
Reconciled
      ↓
Reported

Controls may exist at each stage.

23. Input Controls

Controls over data entering the service.

Examples:

Authorized File Submission

Input Validation

Format Validation

Duplicate Detection

24. Processing Controls

Controls over processing logic.

Examples:

Automated Calculations

Batch Controls

Error Handling

Transaction Sequencing

25. Output Controls

Controls over reports and files produced.

Examples:

Output Reconciliation

Report Review

Distribution Restrictions

Exception Reporting

26. Master Data Controls

Financial systems depend on master data.

Examples:

Employee Salary

Vendor Bank Details

Customer Accounts

Tax Rates

Changes should be controlled.

27. Example Master Data Risk

Threat:

Unauthorized Employee Salary Change

Impact:

Incorrect Payroll Expense

Improper Payment

Financial Misstatement

Control:

Compensation changes require authorized approval before processing.

28. Access Controls in SOC 1

IT access controls can be relevant when they affect financial processing.

Examples:

Privileged Access

User Provisioning

Termination

Role Assignment

Authentication

29. Why IT General Controls Matter

A financial application may have strong transaction controls.

But if unauthorized administrators can modify the application:

Transaction Controls
      ↓
Could Be Bypassed

Therefore IT controls may support financial-control reliability.

30. Change Management

Changes to financially relevant systems should be controlled.

Typical workflow:

Change Request
      ↓
Approval
      ↓
Testing
      ↓
Deployment
      ↓
Validation

31. Segregation of Duties

SOC 1 may include controls intended to reduce inappropriate combinations of responsibility.

Example:

Developer
      ↓
Cannot Independently
Develop + Approve + Deploy

32. Reconciliation Controls

Reconciliation is common in financial processes.

Example:

Input Transactions
      ↓
Processed Transactions
      ↓
Output
      ↓
Reconcile

Differences should be investigated.

33. Batch Processing Controls

For high-volume transactions:

Records Submitted:
10,000

Records Processed:
10,000

Controls may compare input and output totals.

34. Exception Processing

Systems may generate exceptions.

Example:

Invalid Bank Account

Duplicate Transaction

Missing Employee ID

Controls should ensure exceptions are:

Identified

Reviewed

Resolved

35. System Description

The SOC 1 system description defines what is included.

It may describe:

Services

Infrastructure

Software

People

Procedures

Data

36. Why Scope Matters

A payroll provider may offer:

Payroll Processing

HR Management

Expense Management

SOC 1 scope may cover only:

Payroll Processing

Do not assume the report covers every product.

37. Financial Process Scope

Identify which process matters to your organization.

Example:

Provider:
PayrollCo

Customer Uses:
Payroll + Expense

SOC 1 Covers:
Payroll Only

Expense processing may require additional assurance.

38. Report Period Alignment

Suppose the user entity’s financial year is:

01 April 2025
to
31 March 2026

SOC report covers:

01 January 2025
to
31 December 2025

There is a gap:

01 January 2026
to
31 March 2026

Additional assurance may be necessary.

39. Bridge Letter

A bridge letter may help address a period after the SOC report.

It may state whether management is aware of material changes.

Important:

Bridge Letter
≠
Independent Type II Audit

40. Complementary User Entity Controls

SOC 1 reports commonly identify controls that customers are expected to perform.

These are:

CUECs

41. CUEC Example — Payroll Input

Provider expects:

Customers submit complete and authorized employee payroll information.

Internal customer control:

HR Manager Approval
      ↓
Payroll File
      ↓
Provider

42. CUEC Example — Output Review

Provider may expect:

Customers review payroll output reports for accuracy.

The provider can process correctly but the customer still has a review responsibility.

43. CUEC Example — Access

Provider may expect customers to:

Review User Access

Remove Terminated Users

Protect Credentials

44. Why CUECs Are Critical

The SOC 1 assurance model may depend on both:

Service Organization Controls
        +
User Entity Controls

If a required customer control does not operate, the overall financial-reporting risk remains.

45. Build a CUEC Register

Use:

CUEC	Internal Control	Owner	Evidence	Status

Example:

46. Map CUECs to Internal Controls

Workflow:

SOC 1 CUEC
      ↓
Applicable?
      ↓
Internal Control Exists?
      ↓
Owner
      ↓
Evidence
      ↓
Testing

47. Missing CUEC Control

If SOC 1 expects:

Customer reviews payroll report.

but the user entity performs no review:

Customer ICFR Gap

This may need remediation.

48. Subservice Organizations

The service organization may rely on another provider.

Example:

Payroll Provider
      ↓
Cloud Hosting Provider

The hosting provider may be a subservice organization.

49. Inclusive Method

Under an inclusive approach, relevant subservice controls are included within the reported system.

50. Carve-Out Method

Under a carve-out approach, the subservice provider’s controls are excluded from direct testing within the primary report.

Conceptually:

Payroll Provider SOC 1
      ↓
Cloud Hosting
      ↓
Carved Out

Additional assurance may be required.

51. Why Carve-Out Matters to User Auditors

If a key financial-processing dependency is carved out:

Important Control Dependency
      ↓
Not Fully Covered

The user auditor may need additional evidence.

52. Complementary Subservice Controls

Reports may describe controls expected at the subservice organization.

These should be understood along with CUECs.

53. Auditor Testing

In Type II, auditors test whether controls operated effectively.

Common testing methods include:

Inspection

Observation

Inquiry

Reperformance

54. Inspection

Example:

Inspect a sample of employee master-data changes for evidence of management approval.

55. Observation

Example:

Observe the operation of a physical or procedural control.

56. Inquiry

The auditor may interview personnel.

Inquiry alone is generally weaker than corroborated evidence for many controls.

57. Reperformance

The auditor independently performs part of a control procedure.

Example:

Recalculate Batch Total

58. Sampling

A control operating hundreds of times may be tested through sampling.

Example:

Population:
1,200 Payroll Changes

Sample:
25

59. Control Exception

Suppose:

Sample:
25

Exceptions:
2

The auditor may describe the exceptions.

GRC and user auditors should assess significance.

60. Exception Example

Control:

Employee bank-detail changes require dual approval.

Test result:

2 of 25 sampled changes lacked evidence of second-level approval.

61. Analyze the Exception

Ask:

How many exceptions?

What population?

Which period?

Which financial process?

Was unauthorized activity identified?

What remediation occurred?

62. Exception Severity

Not every exception has equal impact.

Example A:

1 documentation exception
out of 40

Example B:

20 unauthorized transactions
out of 40

These are very different risk scenarios.

63. Management Response

Service management may provide a response explaining:

Cause

Correction

Corrective Action

This should be reviewed critically.

64. Auditor Opinion

Always read the opinion.

Possible outcomes may include:

Unmodified

Qualified

Adverse

The exact wording should be reviewed carefully.

65. Unmodified Opinion

An unmodified opinion does not necessarily mean:

Zero Exceptions

Individual control-testing exceptions can still exist.

66. Qualified Opinion

A qualified opinion should trigger deeper review.

Assess:

What caused qualification?

Which controls?

Which objective?

Does it affect us?

67. Adverse Opinion

An adverse opinion may indicate a significant assurance problem.

For a material financial service provider:

Immediate Finance + Audit + Risk Escalation

may be appropriate.

68. SOC 1 and Financial Statement Audits

A user auditor may use SOC 1 to understand controls over outsourced processes.

The auditor may ask:

What service is outsourced?

How does it affect financial reporting?

Which provider controls are relevant?

Which CUECs must the customer perform?

69. User Auditor Reliance

The auditor does not simply see:

SOC 1 Exists
      ↓
Done

They evaluate whether:

Correct Report

Correct Period

Correct Scope

Relevant Controls

CUECs Operating

Exceptions Acceptable

70. User Entity Responsibilities

The user entity still needs controls over:

Vendor Selection

Input Authorization

Output Review

Reconciliation

User Access

Exception Handling

71. Example Payroll Assurance Model

HR
      ↓
Approved Employee Changes
      ↓
Payroll Provider
      ↓
Processes Payroll
      ↓
Payroll Report
      ↓
Finance Review
      ↓
General Ledger

Controls exist on both sides.

72. Risk-to-Control Mapping

Example risk:

Unauthorized salary changes may result in inaccurate payroll expense and improper payments.

Provider control:

System processes only authorized changes.

Customer control:

HR approves salary changes before submission.

73. SOC 1 Control Matrix

Create:

Risk	Control Objective	Provider Control	Customer Control
Unauthorized Payroll Change	Changes authorized	Approval validation	HR approval
Incomplete Payroll	Complete processing	Batch reconciliation	Output review

74. Financial Reporting Risk Examples

Common risks include:

Unauthorized Transactions

Incomplete Processing

Duplicate Processing

Incorrect Calculation

Incorrect Account Classification

Missing Transactions

Improper Changes

75. Risk — Incomplete Processing

Example:

Payroll provider may fail to process all submitted employee records.

Controls may include:

Batch Totals

Record Counts

Reconciliation

Exception Reports

76. Risk — Duplicate Processing

Possible control:

Unique Transaction Identifier

Duplicate Detection

Reconciliation

77. Risk — Unauthorized Changes

Possible controls:

Approval

Role-Based Access

Change Logging

Review

78. Risk — Incorrect Calculation

Possible controls:

Automated Calculation Rules

Validation Testing

Exception Reporting

Reconciliation

79. Risk — Incorrect Cutoff

Transactions may be processed in the wrong accounting period.

Controls may include:

Processing Dates

Close Procedures

Cutoff Reconciliation

80. SOC 1 Report Review Workflow

Use:

Receive Report
      ↓
Confirm SOC 1
      ↓
Confirm Type
      ↓
Confirm Period
      ↓
Confirm Service Scope
      ↓
Review System Description
      ↓
Review Control Objectives
      ↓
Review Tests
      ↓
Review Exceptions
      ↓
Review CUECs
      ↓
Review Subservice Organizations
      ↓
Assess Financial Reporting Impact
      ↓
Document Decision

81. Step 1 — Confirm Report Relevance

Ask:

Does this provider affect ICFR?

If not, determine whether another assurance report is more appropriate.

82. Step 2 — Confirm Type

Record:

SOC 1 Type I

or

SOC 1 Type II

83. Step 3 — Confirm Period

Compare to your financial reporting period.

84. Step 4 — Review Service Scope

Verify the exact service used is included.

85. Step 5 — Review Control Objectives

Identify those relevant to your financial processes.

86. Step 6 — Review Test Procedures

For Type II, understand what the auditor tested.

87. Step 7 — Review Exceptions

Create an exception register.

88. Step 8 — Review CUECs

Map each applicable CUEC to your internal controls.

89. Step 9 — Review Subservice Organizations

Determine whether controls are:

Inclusive

Carved Out

90. Step 10 — Assess Audit Impact

Coordinate with:

Finance

Internal Audit

External Audit

GRC

91. SOC 1 Review Decision

Possible statuses:

Acceptable

Acceptable With Actions

Additional Assurance Required

Risk Acceptance Required

Unacceptable

92. Example Review — Payroll Provider

Provider:

GlobalPayroll

Report:

SOC 1 Type II

Period:

01 Jan – 31 Dec

Opinion:

Unmodified

Exception:

1 / 30 payroll changes
missing approval evidence

CUEC:

Customer reviews payroll output.

Decision:

Acceptable With CUEC Validation

93. Example Review — Payment Processor

Report:

SOC 1 Type I

Customer need:

Operating effectiveness
for full financial year

Potential decision:

Additional Assurance Required

because Type I may not provide the needed period-of-time assurance.

94. Example Review — Carved-Out Hosting

Provider:

Claims Processor

Subservice:

Cloud Hosting Provider

Method:

Carve-Out

Action:

Review Hosting Provider Assurance

if relevant to the financial control environment.

95. SOC 1 Gap Categories

Useful categories:

Scope Gap

Period Gap

Control Exception

CUEC Gap

Subservice Assurance Gap

Evidence Gap

96. Scope Gap

Example:

Service Used:
Expense Processing

SOC Scope:
Payroll Only

Result:

Scope Gap

97. Period Gap

Example:

SOC Ends:
30 Sep

Financial Year Ends:
31 Dec

Result:

Period Gap

98. CUEC Gap

Example:

SOC Requires:
Monthly customer reconciliation

Customer:
No reconciliation

Result:

Internal Control Gap

99. Subservice Assurance Gap

Example:

Critical Hosting Provider
Carved Out

No Separate Assurance

Result:

Assurance Gap

100. Control Exception Gap

Example:

Provider access review
has repeated exceptions.

Result:

Provider Control Risk

101. Build SOC 1 Scope Matrix

Create:

01 SOC 1 Scope Matrix

Use:

Provider	Service	ICFR Impact	SOC 1 Scope	Status

102. Build Financial Reporting Risk-to-Control Map

Create:

02 Financial Reporting Risk-to-Control Map

Use:

Financial Risk	Control Objective	Provider Control	Customer Control

103. Build Control Objective Register

Create:

03 SOC 1 Control Objective Register

Fields:

Objective ID

Control Objective

Financial Risk

Provider Control

Evidence

104. Build CUEC Register

Create:

04 SOC 1 CUEC Register

Use:

CUEC	Internal Control	Owner	Evidence	Status

105. Build SOC 1 Exception Review

Create:

05 SOC 1 Exception Review

Use:

Control	Exception	Financial Impact	Management Response	Decision

106. Build Subservice Organization Register

Create:

06 SOC 1 Subservice Organization Register

Use:

Provider	Subservice	Method	Relevance	Assurance

107. Build Period Coverage Matrix

Create:

07 SOC 1 Period Coverage Matrix

Example:

Financial Period	SOC Period	Gap	Bridge Evidence

108. Build SOC 1 Assurance Checklist

Create:

08 SOC 1 Assurance Assessment Checklist

Include:

Provider affects ICFR.
Correct SOC report obtained.
Type identified.
Report period reviewed.
Financial-period alignment evaluated.
System description reviewed.
Service scope validated.
Control objectives reviewed.
Relevant controls identified.
Auditor opinion reviewed.
Type II tests reviewed.
Exceptions reviewed.
Management responses reviewed.
CUECs identified.
CUECs mapped internally.
Subservice organizations identified.
Inclusive/carve-out method reviewed.
Additional assurance identified.
Financial reporting impact assessed.
Review decision documented.

109. Common SOC 1 Mistakes

Mistake 1 — Using SOC 1 as General Cybersecurity Assurance

Its primary purpose is ICFR-related assurance.

Mistake 2 — Assuming Every Financial Vendor Needs SOC 1

Relevance to financial reporting should be assessed.

Mistake 3 — Ignoring Report Period

Financial audit coverage may be incomplete.

Mistake 4 — Ignoring Scope

The exact service may not be covered.

Mistake 5 — Type I Used as Equivalent to Type II

Operating-effectiveness assurance differs.

Mistake 6 — CUECs Ignored

Customer controls may be required for overall assurance.

Mistake 7 — Exceptions Read Without Financial Context

Impact should be assessed against relevant financial risks.

Mistake 8 — Carve-Out Ignored

Important outsourced control dependencies may remain unassured.

Mistake 9 — SOC 1 Review Is Isolated From Finance

Finance and audit teams should be involved.

Mistake 10 — SOC 1 Report Equals Full ICFR Assurance

The user entity’s own controls still matter.

110. Weak SOC 1 Review

Vendor Has SOC 1
      ↓
Yes
      ↓
Accept

111. Strong SOC 1 Review

ICFR Relevance
      ↓
Correct Report
      ↓
Type
      ↓
Period
      ↓
Scope
      ↓
Control Objectives
      ↓
Testing
      ↓
Exceptions
      ↓
CUECs
      ↓
Subservices
      ↓
Financial Impact
      ↓
Decision

112. GRC Analyst Responsibilities

A GRC professional supporting SOC 1 may:

Identify SOC 1-relevant service providers.
Maintain provider assurance records.
Review SOC 1 reports.
Assess report scope.
Assess period coverage.
Review control objectives.
Review test results.
Analyze exceptions.
Maintain CUEC mappings.
Identify customer control gaps.
Review subservice organizations.
Coordinate with Finance.
Coordinate with Internal Audit.
Support external-audit requests.
Track remediation and assurance gaps.

GRC connects:

Service Providers

Finance

Internal Audit

External Audit

Procurement

IT

Risk Management

113. SOC 1 Maturity Model

Level 1 — Document Collection

SOC 1 Received

Level 2 — Basic Review

Type

Period

Opinion

Level 3 — ICFR Integration

Control Objectives

CUECs

Financial Risks

Exceptions

Level 4 — Integrated Assurance

SOC Controls

Internal Controls

Finance

Audit

Remediation

Level 5 — Continuous Provider Assurance

SOC Freshness

CUEC Monitoring

Provider Exception Tracking

Dynamic ICFR Risk Updates

114. SOC 1 Review Mindset

For every SOC 1 report ask:

Why is this service relevant to our financial reporting?

Which financial processes depend on it?

Which control objectives matter?

Does the report cover the service we use?

Does the period align with our financial period?

Is the report Type I or Type II?

What did the auditor test?

Which exceptions occurred?

Do those exceptions affect our financial risks?

What CUECs are expected from us?

Are our CUECs operating?

Which subservice organizations exist?

Are any critical controls carved out?

What additional assurance is needed?

Can our external auditor rely on this report?

If these questions can be answered, SOC 1 becomes part of a meaningful ICFR assurance program rather than just a vendor document.

Key Takeaways

SOC 1 focuses on controls relevant to user entities’ Internal Control over Financial Reporting.
SOC 1 is especially relevant when service organizations process financially significant transactions or data.
ICFR concerns the reliability of financial reporting.
SOC 1 Type I addresses design and implementation at a specified date.
SOC 1 Type II also evaluates operating effectiveness over a period.
Control objectives describe what the service organization’s controls are intended to achieve.
Transaction processing controls may address authorization, completeness, accuracy, reconciliation, and exception handling.
IT access and change-management controls may be relevant when they support financially significant systems.
SOC 1 scope should be matched to the exact outsourced service.
Report periods should be compared with the user entity’s financial reporting period.
CUECs are critical because user-entity controls may be necessary for the overall assurance model.
Subservice organizations can create additional control dependencies.
Carve-out arrangements may require additional assurance.
Auditor exceptions should be assessed for financial-reporting impact rather than treated mechanically.
SOC 1 assurance should be integrated with Finance, Internal Audit, External Audit, GRC, and provider governance.

Knowledge Check

Before continuing, make sure you can answer:

What is SOC 1?
What is ICFR?
When is SOC 1 relevant?
What is a service organization?
What is a user entity?
What is a user auditor?
What is the difference between SOC 1 Type I and Type II?
Why is Type II often important to financial auditors?
What is a control objective?
How does a control objective differ from a control?
Why can access management be relevant to SOC 1?
Why can change management be relevant?
What is a reconciliation control?
What are CUECs?
Why should CUECs be mapped to internal controls?
What is a subservice organization?
What is the carve-out method?
Why is report-period alignment important?
How should SOC 1 exceptions be assessed?
What role does GRC play in SOC 1 assurance?

What’s Next?

➡️ Next: 03 — SOC 2 Explained

In the next lesson, you will move from financial-reporting assurance into security and trust-services assurance.

You will learn how SOC 2 evaluates controls against the Trust Services Criteria across:

Security
      ↓
Availability
      ↓
Processing Integrity
      ↓
Confidentiality
      ↓
Privacy

You will also learn how to evaluate:

SOC 2 Scope

Type I vs Type II

System Description

Trust Services Criteria

Common Criteria

Control Mapping

Auditor Testing

Exceptions

CUECs

Subservice Organizations

SOC 2 Readiness

and build practical artifacts including a SOC 2 Scope Matrix, Trust Services Criteria Mapping, SOC 2 Control Register, CUEC Register, Exception Review, and SOC 2 Assurance Assessment Checklist.