04 Trust Services Criteria

The Trust Services Criteria (TSC) form the foundation of SOC 2 reporting.

They provide the criteria service organizations use to design, operate, and demonstrate controls related to:

Security

Availability

Processing Integrity

Confidentiality

Privacy

The most important point to understand is:

SOC 2 is not built around a fixed list of mandatory controls. It is built around criteria that organizations satisfy through controls appropriate to their own systems, risks, commitments, and operations.

This means two companies can both have successful SOC 2 examinations while implementing different controls.

For GRC professionals, the Trust Services Criteria provide the bridge between:

Business Risk
      ↓
SOC 2 Criteria
      ↓
Enterprise Control
      ↓
Evidence
      ↓
Auditor Testing
      ↓
SOC 2 Assurance

Learning Objectives

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

Explain the purpose of the Trust Services Criteria.
Understand the five Trust Services Categories.
Explain the role of the Common Criteria.
Understand Control Environment criteria.
Understand Communication and Information criteria.
Understand Risk Assessment criteria.
Understand Monitoring Activities criteria.
Understand Logical and Physical Access criteria.
Understand System Operations criteria.
Understand Change Management criteria.
Understand Risk Mitigation criteria.
Understand Availability criteria.
Understand Processing Integrity criteria.
Understand Confidentiality criteria.
Understand Privacy criteria.
Translate criteria into practical controls.
Build TSC-to-control mappings.
Identify appropriate control evidence.
Design control-testing procedures.
Identify TSC coverage gaps.
Prepare a SOC 2 readiness control matrix.

1. What Are the Trust Services Criteria?

The Trust Services Criteria are used to evaluate controls relevant to the security and reliability of systems and information.

The framework can be viewed as:

Trust Services Criteria
        ↓
Common Criteria
        +
Additional Category Criteria
        ↓
Enterprise Controls
        ↓
Evidence
        ↓
SOC 2 Examination

2. The Five Trust Services Categories

The categories are:

Security

Availability

Processing Integrity

Confidentiality

Privacy

Security is foundational.

The other categories are selected based on the service organization’s commitments and system requirements.

3. Security

Security addresses protection of information and systems against unauthorized access, unauthorized disclosure, damage, and other threats that could compromise the organization’s objectives.

A simple model:

Threat
      ↓
Unauthorized Access
      ↓
System / Data Impact
      ↓
Security Controls

4. Availability

Availability concerns whether systems and services are available for operation and use as committed or agreed.

It may involve:

Capacity

Resilience

Monitoring

Backup

Recovery

Continuity

5. Processing Integrity

Processing Integrity addresses whether processing is:

Complete

Valid

Accurate

Timely

Authorized

for the intended purpose.

6. Confidentiality

Confidentiality addresses protection of information designated as confidential.

Examples include:

Customer Data

Trade Secrets

Source Code

Contracts

Internal Business Information

7. Privacy

Privacy addresses personal information throughout its lifecycle.

Example:

Collection
      ↓
Use
      ↓
Retention
      ↓
Disclosure
      ↓
Access
      ↓
Deletion

8. The Common Criteria

The Security category contains the criteria commonly referred to as the Common Criteria.

These provide the foundation for SOC 2.

They cover broad control areas such as:

Control Environment

Communication & Information

Risk Assessment

Monitoring Activities

Control Activities

Logical & Physical Access

System Operations

Change Management

Risk Mitigation

9. Why They Are Called Common Criteria

They are called common because they form the foundation that supports the broader Trust Services framework.

Conceptually:

Security Common Criteria
        ↓
Foundation

        +

Availability
Processing Integrity
Confidentiality
Privacy

10. Criteria vs Controls

This distinction is critical.

A criterion describes an objective or condition that should be achieved.

A control describes what the organization actually does.

Example criterion concept:

Restrict logical access.

Possible control:

Privileged access to production systems requires approved role assignment, MFA, and quarterly access review.

11. One Criterion Can Have Multiple Controls

Example:

Logical Access Criterion
      ↓
User Provisioning

MFA

RBAC

Access Review

Termination

Several controls may collectively satisfy the criterion.

12. One Control Can Support Multiple Criteria

Example:

Centralized Logging

may support:

Security

Monitoring

System Operations

Incident Response

This is why control mapping matters.

13. Control Environment

The Control Environment establishes the governance foundation for security and compliance.

It includes concepts such as:

Leadership

Ethics

Accountability

Authority

Responsibility

Oversight

14. Governance Example

An organization should clearly define:

Board / Management Oversight

Security Leadership

Control Ownership

Escalation

Accountability

15. Security Governance Control

Example:

Management establishes and periodically reviews information-security policies defining organizational security responsibilities and expectations.

Evidence:

Approved Policy

Approval Record

Review History

16. Organizational Structure

Roles should be clearly defined.

Example:

CISO
      ↓
Security Governance

SOC
      ↓
Monitoring

IAM
      ↓
Identity Controls

Engineering
      ↓
Secure Systems

17. Control Ownership

Every key control should have an accountable owner.

Example:

Control	Owner
MFA	IAM Director
Logging	SOC Manager
Change Management	Engineering Manager

18. Competence

Organizations should ensure personnel responsible for controls have appropriate skills and knowledge.

Evidence may include:

Job Descriptions

Training Records

Qualifications

Performance Reviews

19. Accountability

Control failures should not remain ownerless.

A strong environment answers:

Who owns this control?

Who operates it?

Who reviews it?

Who escalates failure?

20. Communication and Information

The organization should identify and communicate information needed to support controls.

Examples:

Security Policies

Standards

Procedures

Risk Information

Incident Escalation

Customer Commitments

21. Internal Communication

Employees should understand relevant responsibilities.

Examples:

Acceptable Use

Access Rules

Incident Reporting

Data Handling

22. External Communication

Organizations may also communicate with:

Customers

Vendors

Regulators

Auditors

Business Partners

23. Communication Control Example

Security policies and relevant changes are communicated to employees through approved internal channels and training processes.

Evidence:

Policy Publication

Training Record

Acknowledgment

24. Risk Assessment

Risk assessment is central to SOC 2.

The organization should understand risks that could prevent achievement of its commitments and system objectives.

A practical process:

Asset / Service
      ↓
Threat
      ↓
Vulnerability
      ↓
Likelihood
      ↓
Impact
      ↓
Risk
      ↓
Control

25. Risk Identification

Risks may include:

Cyberattack

Credential Compromise

Service Failure

Vendor Failure

Data Leakage

Processing Error

Privacy Violation

26. Fraud Risk

Organizations should also consider fraud-related risks where relevant.

Examples:

Unauthorized Transactions

Privilege Abuse

Data Manipulation

Management Override

27. Change Risk

Major organizational or technology changes can introduce new risk.

Examples:

New Cloud Provider

Acquisition

AI Feature

New Data Region

Architecture Migration

These should trigger reassessment.

28. Risk Assessment Control Example

The organization performs formal security risk assessments at least annually and following significant changes to systems, services, or business operations.

Evidence:

Risk Register

Assessment Report

Risk Treatment Plan

29. Monitoring Activities

Organizations should monitor whether controls continue to operate effectively.

Monitoring may include:

Control Testing

Management Reviews

Metrics

Audits

Automated Monitoring

30. Ongoing Monitoring

Example:

MFA Coverage
      ↓
Daily Measurement

Logging Coverage
      ↓
Continuous Monitoring

31. Separate Evaluations

In addition to ongoing monitoring:

Internal Audit

Control Assessments

SOC Readiness Reviews

can provide independent evaluation.

32. Deficiency Communication

Control failures should be communicated to responsible management.

Example:

Control Failure
      ↓
Finding
      ↓
Owner
      ↓
Remediation
      ↓
Retest

33. Monitoring Control Example

Control owners periodically review control-performance metrics and remediate identified deficiencies according to documented timelines.

34. Logical and Physical Access

Access criteria address protection of systems and information from unauthorized access.

Major control areas include:

Identity Lifecycle

Authentication

Authorization

Privileged Access

Physical Security

Access Removal

35. User Provisioning

A standard process:

Access Request
      ↓
Approval
      ↓
Account Creation
      ↓
Role Assignment

36. Least Privilege

Users should receive only the access needed.

Weak:

Developer
→ Global Administrator

Strong:

Developer
→ Required Development Role

37. MFA

Strong authentication is especially relevant for:

Administrators

Remote Access

Sensitive Systems

Critical SaaS

38. Privileged Access

A mature privileged-access lifecycle:

Request
      ↓
Approval
      ↓
Temporary Access
      ↓
Logging
      ↓
Review
      ↓
Removal

39. Access Reviews

Example:

Privileged user access is reviewed quarterly by authorized management.

Evidence:

User Population

Reviewer

Review Decisions

Removed Access

40. Termination

Access should be removed when no longer required.

Example:

HR Termination
      ↓
Identity Platform
      ↓
Access Removed

41. Physical Access

Where the organization operates physical facilities, controls may include:

Badge Access

Visitor Management

CCTV

Restricted Areas

For cloud-hosted systems, some physical controls may be inherited from providers.

42. Logical Access Control Example

Production administrative access requires an individually assigned identity, MFA, approved role assignment, and centralized logging.

43. System Operations

System Operations criteria address the secure and reliable operation of systems.

Areas may include:

Monitoring

Vulnerability Management

Incident Detection

Incident Response

Backup

System Maintenance

44. Security Monitoring

Organizations should monitor relevant security events.

Examples:

Suspicious Authentication

Administrative Changes

Malware

Configuration Changes

45. Vulnerability Management

A lifecycle:

Discover
      ↓
Assess
      ↓
Prioritize
      ↓
Remediate
      ↓
Validate

46. Incident Detection

Example:

Security Event
      ↓
SIEM
      ↓
Detection Rule
      ↓
Alert
      ↓
Investigation

47. Incident Response

A typical lifecycle:

Prepare
      ↓
Detect
      ↓
Analyze
      ↓
Contain
      ↓
Recover
      ↓
Learn

48. Incident Control Example

Security incidents are documented, classified, investigated, escalated, and resolved according to the approved incident-response procedure.

49. Backup Operations

Relevant controls may cover:

Backup

Retention

Failure Monitoring

Restore Testing

50. System Operations Evidence

Examples:

Monitoring Alerts

Incident Tickets

Vulnerability Reports

Backup Reports

Recovery Tests

51. Change Management

Change Management criteria address controlled modification of systems and infrastructure.

A standard process:

Change Request
      ↓
Risk Review
      ↓
Testing
      ↓
Approval
      ↓
Deployment
      ↓
Validation

52. Change Authorization

Changes should be approved before implementation where required.

Evidence:

Change Ticket

Approver

Deployment Record

53. Testing

Changes should be tested before production deployment.

Examples:

Functional Testing

Security Testing

Regression Testing

54. Segregation of Duties

Where practical:

Developer
      ↓
Cannot Independently
Approve + Deploy

55. Emergency Changes

Emergency changes should still be controlled.

Example:

Emergency Change
      ↓
Immediate Implementation
      ↓
Post-Implementation Review

56. Infrastructure as Code

Modern change-management evidence may include:

Pull Request

Peer Review

CI/CD Logs

Policy-as-Code Results

Deployment Records

57. Change Management Control Example

Production changes must be documented, tested, approved, and deployed through authorized change-management processes.

58. Risk Mitigation

Risk Mitigation criteria address how organizations identify and respond to risks arising from business relationships and changes.

This includes areas such as:

Third Parties

Vendors

Subprocessors

Business Changes

Technology Changes

59. Third-Party Risk

A typical lifecycle:

Vendor Request
      ↓
Risk Assessment
      ↓
Security Review
      ↓
Approval
      ↓
Monitoring
      ↓
Offboarding

60. Vendor Due Diligence

Evidence may include:

SOC 2 Report

ISO Certificate

Security Questionnaire

Risk Assessment

Contract

61. Provider Monitoring

Critical providers should be reassessed periodically.

Triggers may include:

Major Incident

SOC Report Expiry

Material Service Change

Subprocessor Change

62. Risk-Mitigation Control Example

Critical third-party service providers undergo risk-based due diligence before onboarding and periodic reassessment throughout the relationship.

63. Availability Criteria

If Availability is included, organizations should establish controls supporting commitments regarding system availability.

Key areas include:

Capacity

Resilience

Backup

Recovery

Monitoring

64. Capacity Management

Organizations should understand whether resources can support demand.

Example:

Usage
      ↓
Threshold
      ↓
Alert
      ↓
Capacity Expansion

65. Availability Monitoring

Evidence:

Uptime Dashboard

Availability Alerts

Incident Records

66. Resilience

Controls may include:

Redundancy

Multiple Availability Zones

Failover

Load Balancing

67. Backup

Backup controls support recovery but do not alone prove availability.

Remember:

Backup Exists
≠
Recovery Works

68. Recovery Testing

A recovery test should validate:

Can data be restored?

Can systems be recovered?

Are RTO/RPO objectives met?

69. Availability Control Example

Critical services are monitored continuously, backed up according to approved schedules, and periodically tested for recovery against established objectives.

70. Processing Integrity Criteria

Processing Integrity addresses whether processing achieves its intended purpose.

Key concepts:

Complete

Accurate

Authorized

Timely

Valid

71. Input Controls

Examples:

Data Validation

Required Fields

Format Checks

Authorization

72. Processing Controls

Examples:

Automated Rules

Calculation Logic

Duplicate Prevention

Error Handling

73. Output Controls

Examples:

Output Validation

Reconciliation

Exception Reports

74. Processing Error Example

Transactions Submitted:
10,000

Transactions Processed:
9,600

A reconciliation control should identify the difference.

75. Processing Integrity Control Example

The system validates submitted transactions, identifies processing exceptions, and reconciles input and output totals to ensure complete and accurate processing.

76. Confidentiality Criteria

Confidentiality applies when the organization makes commitments to protect information designated as confidential.

Controls may cover:

Classification

Access

Encryption

Sharing

Retention

Deletion

77. Classification

A classification model may include:

Public

Internal

Confidential

Restricted

78. Access to Confidential Information

Use:

Need to Know

Least Privilege

Role-Based Access

79. Encryption

Relevant controls may address:

Data at Rest

Data in Transit

Key Management

Confidential information should not be shared without authorization.

Examples:

External Sharing

File Transfer

SaaS Sharing

API Access

81. Retention

Confidential information should not remain indefinitely without business or legal need.

82. Secure Disposal

Examples:

File Deletion

Storage Destruction

Cloud Data Deletion

83. Confidentiality Control Example

Confidential information is classified, access-restricted, encrypted where required, retained according to policy, and securely disposed when no longer needed.

84. Privacy Criteria

Privacy addresses personal information.

A privacy lifecycle may include:

Notice
      ↓
Collection
      ↓
Use
      ↓
Retention
      ↓
Access
      ↓
Disclosure
      ↓
Deletion

85. Privacy Notice

Organizations should communicate relevant privacy practices.

86. Collection

Personal information should be collected appropriately according to defined purposes.

87. Use

PII should be used consistently with authorized purposes.

88. Retention

Personal information should be retained according to defined requirements.

89. Individual Rights

Depending on applicable commitments and requirements, organizations may support:

Access

Correction

Deletion

90. Disclosure

Personal information sharing should be controlled.

91. Privacy Incident Management

Privacy events should be identified and managed.

Examples:

Unauthorized Disclosure

Incorrect Recipient

Excessive Access

Improper Retention

92. Privacy Control Example

Personal information is collected, used, retained, disclosed, and deleted according to documented privacy commitments and approved processing requirements.

93. Mapping TSC to Enterprise Controls

A scalable SOC 2 program uses:

Trust Services Criterion
      ↓
Enterprise Control
      ↓
Owner
      ↓
Evidence
      ↓
Testing

94. Example — Access

Criterion area:

Logical Access

Controls:

IAM-001
User Provisioning

IAM-002
Privileged MFA

IAM-003
Quarterly Access Review

IAM-004
Termination

95. Example — Change Management

Controls:

CHG-001
Change Authorization

CHG-002
Testing

CHG-003
Production Deployment

CHG-004
Emergency Changes

96. Example — Security Operations

Controls:

LOG-001
Central Logging

IR-001
Incident Response

VUL-001
Vulnerability Management

BCK-001
Backup

97. Build a TSC Mapping Matrix

Create:

01 Trust Services Criteria Mapping Matrix

Use:

Criterion Area	Risk	Enterprise Control	Owner	Evidence

98. Build Common Criteria Control Register

Create:

02 Common Criteria Control Register

Recommended fields:

Control ID

Criterion Area

Control Statement

Owner

Frequency

Evidence

Status

99. Build Risk-to-TSC Mapping

Create:

03 Risk-to-TSC Mapping

Use:

Risk	TSC Area	Control	Residual Risk

Example:

| Privileged Credential Compromise | Logical Access | IAM-002 | Low |

100. Build SOC 2 Evidence Matrix

Create:

04 SOC 2 Evidence Matrix

Use:

Control	Evidence	Source	Frequency	Owner

101. Evidence Example — Access Control

User Inventory

Access Request

MFA Report

Access Review

Termination Ticket

102. Evidence Example — Change Management

Change Ticket

Pull Request

Approval

Test Results

Deployment Log

103. Evidence Example — Incident Response

Incident Register

Investigation Ticket

Timeline

Post-Incident Review

104. Evidence Example — Vendor Risk

Vendor Inventory

Risk Assessment

SOC Report

Approval

Reassessment

105. Evidence Example — Availability

Availability Report

Backup Report

DR Test

Incident Record

106. Build Control Testing Checklist

Create:

05 SOC 2 Control Testing Checklist

For each control document:

Population

Sample

Evidence

Test Procedure

Exceptions

Conclusion

107. Test Design Effectiveness

Ask:

If this control operates exactly as designed, will it reasonably satisfy the criterion and address the risk?

Example:

Risk:

Privileged Access Abuse

Control:

Administrator list reviewed once every five years.

The control may exist but be poorly designed.

108. Test Operating Effectiveness

Ask:

Did the control operate as designed throughout the assessment period?

Example:

Quarterly Review

Q1 ✓
Q2 ✓
Q3 ✗
Q4 ✓

Conclusion:

Partially Effective

109. Population Definition

For each control identify the full population.

Example:

Access Requests:
1,250

or:

Quarterly Reviews:
4

110. Sampling

For manual controls, auditors may sample.

Examples:

Access Requests

Changes

Incidents

Vendor Reviews

111. Complete-Population Testing

Automation may enable testing:

100% MFA Coverage

100% Encryption Coverage

100% Logging Coverage

112. Exception Analysis

For every test exception ask:

Requirement?

Condition?

Cause?

Risk?

Frequency?

Systemic?

113. Example Finding

Control:

Terminated users are disabled within 24 hours.

Population:

75 Terminations

Sample:

Exceptions:

Potential finding:

Three of twenty-five sampled terminated-user accounts remained active beyond the required removal period.

114. Root Cause

Possible root cause:

HR termination feed
does not include contractors.

Corrective action should address the process, not just disable three accounts.

115. Trust Services Coverage Matrix

Create:

Category	Applicable	Controls	Status
Security	Yes	40	Effective
Availability	Yes	8	Effective
Processing Integrity	No	—	N/A
Confidentiality	Yes	7	Partial
Privacy	No	—	N/A

116. Why Applicability Matters

Do not include optional categories merely because they sound good.

They should reflect:

Service Commitments

System Requirements

Customer Expectations

Risk

117. Criteria Gap

Example:

Availability Included

but:

No Recovery Testing Control

Result:

Control Coverage Gap

118. Evidence Gap

Example:

Quarterly Access Review Control Exists

but:

Q2 Evidence Missing

Result:

Evidence / Operating Effectiveness Gap

119. Control Design Gap

Example:

Vulnerability Scan
→ Annual

but the risk requires significantly more frequent assessment.

Result:

Design Gap

120. SOC 2 Readiness Lifecycle

A practical readiness process is:

Define Scope
      ↓
Select TSC Categories
      ↓
Map Criteria
      ↓
Inventory Controls
      ↓
Identify Owners
      ↓
Map Evidence
      ↓
Perform Gap Assessment
      ↓
Remediate
      ↓
Operate Controls
      ↓
Readiness Review
      ↓
SOC 2 Examination

121. Common Criteria Readiness Checklist

Governance

Security policies established.
Roles defined.
Management oversight established.
Control owners assigned.
Employee responsibilities communicated.

Risk

Risk assessment performed.
Fraud risk considered.
Major changes assessed.
Risk treatment documented.

Monitoring

Control monitoring established.
Findings documented.
Deficiencies escalated.
Corrective actions tracked.

Access

User provisioning controlled.
MFA implemented.
Privileged access controlled.
Access reviews performed.
Termination process established.
Physical access controlled where applicable.

Operations

Security monitoring implemented.
Vulnerability management established.
Incident response established.
Backup monitored.
Operational issues tracked.

Change Management

Changes documented.
Testing performed.
Approval required.
Production deployment controlled.
Emergency changes reviewed.

Third Parties

Vendor inventory maintained.
Vendor risk assessed.
Critical providers monitored.
Provider assurance reviewed.

122. Common TSC Implementation Mistakes

Mistake 1 — Copying Controls From Another Company

Controls should reflect your own system.

Mistake 2 — Treating Criteria as a Checklist

The objective is effective control, not wording duplication.

Mistake 3 — No Risk-to-Control Connection

Controls become compliance theater.

Mistake 4 — Too Many Controls

Control environments become difficult to operate and evidence.

Mistake 5 — Controls Too Broad

Example:

Security is monitored.

Not testable.

Mistake 6 — No Control Owner

Evidence collection becomes difficult.

Mistake 7 — Evidence Defined Only at Audit Time

Audit preparation becomes chaotic.

Mistake 8 — Optional Categories Selected Without Need

SOC 2 scope becomes unnecessarily complex.

Mistake 9 — Automated Controls Not Governed

Automation itself may fail.

Mistake 10 — Failed Controls Do Not Update Risk

SOC 2 becomes disconnected from enterprise risk.

123. Weak TSC Implementation

TSC Requirement
      ↓
Copy Generic Control
      ↓
Collect Screenshot

124. Strong TSC Implementation

System Commitment
      ↓
Risk
      ↓
Applicable Criterion
      ↓
Enterprise Control
      ↓
Owner
      ↓
Evidence
      ↓
Testing
      ↓
Remediation

125. GRC Analyst Responsibilities

A GRC professional supporting the Trust Services Criteria may:

Determine applicable TSC categories.
Interpret criteria.
Build control mappings.
Maintain the SOC 2 control library.
Assign and track control ownership.
Map risks to criteria.
Map evidence to controls.
Perform readiness assessments.
Identify control-design gaps.
Review operating-effectiveness evidence.
Coordinate control testing.
Track findings.
Facilitate remediation.
Maintain SOC 2 dashboards.
Support external auditors.

GRC connects:

Management

Security

Engineering

IAM

SOC

Privacy

Legal

Vendors

Auditors

126. TSC Maturity Model

Level 1 — Criteria Checklist

Generic controls

Manual evidence

Level 2 — Defined Controls

Owners

Processes

Evidence

Level 3 — Risk-Based

Risk Mapping

Control Testing

Gap Management

Level 4 — Integrated Assurance

Automated Evidence

Control Metrics

Continuous Monitoring

Level 5 — Continuous SOC 2 Governance

Dynamic Risk

Continuous Control Status

Automated Evidence

Audit-Ready Assurance

127. Trust Services Criteria Mindset

For every criterion ask:

What commitment does this support?

What system is in scope?

What risk does it address?

What control satisfies it?

Who owns the control?

How often does it operate?

What evidence proves it?

Is the evidence reliable?

How will an auditor test it?

What happens if the control fails?

Does the failure affect another TSC category?

How will remediation be validated?

When these questions can be answered, the Trust Services Criteria become an operational control framework rather than an audit checklist.

Key Takeaways

The Trust Services Criteria form the foundation of SOC 2.
The five categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Security and its Common Criteria provide the core SOC 2 foundation.
Criteria describe desired outcomes; controls describe how organizations achieve those outcomes.
One criterion may require multiple controls, and one control may support multiple criteria.
The Common Criteria address governance, communication, risk assessment, monitoring, access, operations, change management, and risk mitigation.
Availability focuses on service availability, capacity, resilience, backup, and recovery.
Processing Integrity focuses on complete, valid, accurate, timely, and authorized processing.
Confidentiality focuses on information designated as confidential.
Privacy governs personal information across its lifecycle.
Controls should be specific, owned, repeatable, and testable.
Evidence should be defined before audit time.
Design effectiveness and operating effectiveness are separate questions.
SOC 2 readiness requires criteria mapping, control inventory, evidence mapping, testing, remediation, and sustained operation.
GRC plays a central role in translating Trust Services Criteria into practical controls and audit-ready assurance.

Knowledge Check

Before continuing, make sure you can answer:

What are the Trust Services Criteria?
What are the five Trust Services Categories?
What are the Common Criteria?
What is the difference between a criterion and a control?
Why can one control support multiple criteria?
What does the Control Environment address?
Why is communication important?
How does risk assessment support SOC 2?
What are Monitoring Activities?
What should logical access controls cover?
What does System Operations address?
What is the purpose of Change Management?
How does vendor risk relate to Risk Mitigation?
What does Availability address?
What does Processing Integrity address?
What does Confidentiality address?
How is Privacy different from Confidentiality?
What is design effectiveness?
What is operating effectiveness?
What role does GRC play in applying the Trust Services Criteria?

What’s Next?

➡️ Next: 05 — Security Principle

In the next lesson, you will focus specifically on the Security category, which forms the mandatory foundation of every SOC 2 engagement.

You will go deeper into:

Security Governance
      ↓
Risk Management
      ↓
Identity & Access Management
      ↓
Privileged Access
      ↓
Network Security
      ↓
Vulnerability Management
      ↓
Security Monitoring
      ↓
Incident Response
      ↓
Change Management
      ↓
Third-Party Security

You will also build practical SOC 2 artifacts including a Security Control Matrix, IAM Evidence Register, Vulnerability Management Control Map, Security Monitoring Evidence Matrix, Incident Response Control Register, and Security Control Testing Checklist.