SOC 2: Documentation and Compliance Requirements

It covers the requirements across the main SOC 2 areas and explains them as requirements rather than a simple checklist.

A checklist only asks, "Do you have this?" This document goes one step further: What is required, and what evidence can prove that it is actually working?

________________________________________

PART 1 — Defining the SOC 2 Scope

Required for both Type 1 and Type 2

1. Define what is included in the SOC 2 report

You must clearly describe the system that will be covered by the SOC 2 report.

This should include:

• Services provided

• IT infrastructure

• Software and applications

• Employees and other people involved

• Processes and procedures

• Data handled by the system

Evidence may include:

• System description

• Network and architecture diagrams

• Data-flow diagrams

• List of applications and systems

• Locations and environments included in the scope

2. Document your commitments to customers

You must clearly document what you promise your customers and what your system must do to deliver those services.

Evidence may include:

• Customer contracts

• Service Level Agreements (SLAs)

• Published service commitments

• System requirements

3. Define what is outside the scope

You must clearly document what is not included in the SOC 2 scope and explain why.

Evidence:

• Scope exclusions

• Written reasons for each exclusion

4. Select the Trust Services Categories

You must decide which SOC 2 Trust Services Categories your report will cover.

Security is mandatory.

The other categories are optional:

• Availability

• Confidentiality

• Processing Integrity

• Privacy

Select the categories based on your business and customer requirements.

Evidence:

• Selected categories

• Reason for selecting them

Adding categories that customers do not require can create unnecessary work and cost.

5. Identify your service providers

You must identify suppliers or third parties that operate part of your system.

Examples include:

• Cloud providers

• Hosting providers

• Payroll providers

• Managed security providers

You must decide whether each supplier is:

• Included in your SOC 2 scope, or

• Treated as a separate service organisation

Evidence:

• List of subservice organisations

• Scope treatment for each supplier

• Reason for the decision

6. Document controls expected from suppliers

If a supplier is excluded from your SOC 2 scope, you must identify the controls you depend on that supplier to perform.

Evidence:

• Complementary subservice organisation controls

7. Document controls expected from customers

You must also identify what customers need to do for your system and controls to work properly.

Evidence:

• Complementary User Entity Controls (CUECs)

• Evidence that these requirements were communicated to customers

________________________________________

PART 2 — Governance and Control Environment

Required for both Type 1 and Type 2

8. Code of conduct

You must have a documented code of conduct, and employees and relevant contractors should acknowledge it.

Evidence:

• Approved and dated code of conduct

• Employee acknowledgement records

9. Reporting unethical behaviour

Employees must have a way to report unethical behaviour, and the organisation must respond appropriately.

Evidence:

• Reporting mechanism

• Communication showing employees know about it

• Records of reported issues and actions taken

10. Employee background checks

Where legally permitted, background checks should be completed before employees are hired.

Evidence:

• Background-check policy

• Screening records

11. Independent oversight

There should be a board or equivalent governing body that provides oversight independently of management.

Evidence:

• Board or governance charter

• Membership information

• Meeting minutes

• Evidence of oversight of internal controls

12. Clear organisational structure

Roles, responsibilities, reporting lines and authority must be clearly defined.

Evidence:

• Organisation chart

• Job responsibilities

• Authority limits

• Delegation matrix

13. Separation of duties

Important or conflicting responsibilities should be separated between different people where possible.

Evidence:

• Separation-of-duties analysis

• Compensating controls where a small team makes separation difficult

14. Competent employees

You must hire, train and retain people who are capable of performing their responsibilities.

Evidence:

• Job descriptions

• Security responsibilities

• Onboarding records

• Security awareness training

• Annual security training

• Cross-training for important roles

15. Employee accountability

Employees must be accountable for the controls and responsibilities assigned to them.

Evidence:

• Performance reviews

• Control responsibilities

• Records of corrective action where responsibilities were not met

________________________________________

INFORMATION AND COMMUNICATION

CC2.1, CC2.2, CC2.3

16. Collect information needed to operate controls

You must collect reliable information needed to operate and monitor your controls.

Examples include:

• System logs

• Tickets

• Dashboards

• Vulnerability scan results

• Supplier reports

Evidence:

• Information sources

• Evidence that information is complete and reliable

17. Review the information

It is not enough to generate reports. Someone must actually review them.

Evidence:

• Review records

• Reviewer name

• Review date

• Actions taken

18. Employees must understand their responsibilities

Employees should know:

• Company objectives

• Security policies

• Their responsibilities

• How to report incidents

Evidence:

• Published policies

• Employee acknowledgements

• Awareness communications

• Incident reporting process

19. Communicate with customers and external parties

Customers and relevant external parties should receive information about the system and its security controls.

Evidence:

• Service descriptions

• SLAs

• Security information

• Vulnerability reporting channel

20. Tell customers what they need to do

Customers must understand any responsibilities they have for the controls to work properly.

Evidence:

• Customer communications

• Documented CUECs

________________________________________

RISK ASSESSMENT

CC3.1, CC3.2, CC3.3, CC3.4

21. Define clear objectives

Your objectives should be clear enough to identify what could go wrong.

Evidence:

• Business objectives

• Service commitments

• System requirements

22. Perform a formal risk assessment

You must have a documented method for identifying and evaluating risks.

Evidence:

• Risk assessment methodology

• Risk criteria

• Risk register

• Likelihood and impact ratings

23. Use knowledgeable people

Risk assessments should be performed by people who understand the organisation and its systems.

Evidence:

• Names of people involved

• Assessment date

• Their responsibilities or qualifications

24. Assess fraud risks

Fraud must be specifically considered.

This can include:

• Fraudulent reporting

• Theft of assets

• Corruption

• Insider misuse

• Misuse of privileged access

• Bypassing change controls

Evidence:

• Fraud risk assessment

• Documented fraud risks and controls

25. Assess the effect of major changes

Changes to the business, technology, leadership, suppliers or regulations should be assessed for their impact on controls.

Evidence:

• Change-related risk assessments

• Updated risk register

________________________________________

MONITORING

CC4.1, CC4.2

26. Monitor whether controls are working

Controls should be monitored continuously and through periodic independent reviews.

Examples:

• Security alerts

• Dashboards

• Exception reports

• Management reviews

• Internal audits

• Self-assessments

• Penetration tests

• Third-party assessments

27. Reviews must be objective and competent

People performing independent reviews should have appropriate knowledge and sufficient independence.

Evidence:

• Qualifications

• Experience

• Independence records

28. Fix identified weaknesses

When a control weakness is identified, it must be documented, escalated and corrected.

Evidence:

• Deficiency log

• Severity

• Responsible person

• Management escalation

• Corrective action

• Retesting

________________________________________

CONTROL ACTIVITIES AND POLICIES

CC5.1, CC5.2, CC5.3

29. Map controls to SOC 2 requirements

Every SOC 2 criterion within the scope should be linked to one or more controls.

Evidence:

A control matrix showing:

• SOC 2 criterion

• Control

• Control owner

• Frequency

• Required evidence

30. Link controls to risks

Controls should address risks identified in the risk assessment.

Evidence:

• Risk register

• Control matrix

• Link between risks and controls

31. Cover IT controls

Technology controls supporting the SOC 2 system must also be covered.

Evidence:

• IT general controls

• Supporting technology controls

32. Have policies and procedures

Policies should explain what is expected.

Procedures should explain how employees actually perform the required activities.

Evidence:

• Approved policies

• Policy owner

• Review date

• Procedures

• Evidence that procedures match policies

33. Make sure procedures match actual practice

What is written must match what employees actually do.

Evidence:

• Process walkthroughs

• Interviews

• Observed activities

• Comparison between documentation and actual practice

________________________________________

ACCESS, LOGICAL AND PHYSICAL SECURITY

CC6.1–CC6.8

34. Access control

You must have an access control policy and configure authentication according to that policy.

Evidence:

• Access policy

• Password settings

• Multi-factor authentication

• Identity management configuration

35. Encryption

Sensitive information should be protected both:

• At rest

• During transmission

Encryption keys must also be properly managed.

Evidence:

• Encryption standards

• Key management arrangements

36. Maintain an asset inventory

You should know what information assets you have and how sensitive they are.

Evidence:

• Asset inventory

• Data classification

• Asset owners

37. Apply least-privilege access

People should receive only the access they need, and access should be approved before it is provided.

Evidence:

• Access request

• Approval

• Role definitions

• Provisioning records

38. Manage employee changes and exits

Access should be updated when employees change roles and removed when they leave.

Evidence:

• Joiner, mover and leaver procedure

• Termination checklist

• Access removal records

39. Review access regularly

User access should be reviewed periodically for the complete user population.

Evidence:

• Access review procedure

• Review records

• Users covered

• Actions taken

40. Control privileged accounts

Administrative and other privileged accounts must be identified, justified and monitored.

Evidence:

• Privileged account list

• Reason for access

• Monitoring records

41. Control physical access

Access to offices, server rooms and data centres must be controlled.

Evidence:

• Badge/access systems

• Visitor records

• Escort procedures

• Supplier controls where hosting is outsourced

42. Securely dispose of equipment and media

Devices and storage media must be securely erased or destroyed before disposal or reuse.

Evidence:

• Sanitisation procedure

• Destruction certificates

• Asset return records

43. Protect the network boundary

The organisation must protect systems from unauthorised external access.

Evidence:

• Firewall configuration

• VPN controls

• MFA

• Endpoint protection

44. Protect information movement

Movement of sensitive information must be controlled and protected.

Evidence:

• Encryption

• Removable-media controls

• Data Loss Prevention controls where applicable

45. Prevent malicious software

The organisation must prevent or detect malware and unauthorised software.

Evidence:

• Anti-malware coverage

• Software installation controls

• Patch management

• Vulnerability management

• Third-party dependency scanning

________________________________________

OPERATIONS AND INCIDENT MANAGEMENT

CC7.1–CC7.5

46. Detect unusual activity

You must monitor systems for configuration changes, vulnerabilities and unusual activity.

Evidence:

• Configuration monitoring

• Baseline monitoring

• Vulnerability scans

47. Log and monitor security activity

Important security events must be logged and monitored, and alerts should reach responsible personnel.

Evidence:

• What is logged

• Log sources

• Retention period

• Protection of logs

• Alert rules

• Expected response times

48. Evaluate security events

You must have a process to determine whether a security event is an actual incident.

Evidence:

• Incident classification criteria

• Triage records

49. Have an incident response plan

The plan should define:

• Roles

• Responsibilities

• Escalation

• Customer notification

• Regulatory notification

• Evidence preservation

Evidence:

• Incident response plan

• Contact list

• Notification timelines

• Evidence preservation procedures

50. Learn from incidents

After an incident, you should review what happened and improve the controls where necessary.

Evidence:

• Post-incident review

• Corrective actions

• Tabletop exercises

51. Recover from incidents

You must have backups and be able to restore systems or data when required.

Evidence:

• Backup schedule

• Backup retention

• Encryption

• Restore tests

• Recovery objectives

• Supplier commitments where applicable

________________________________________

CHANGE MANAGEMENT

CC8.1

52. Authorise changes before implementation

Changes to software, infrastructure, data and procedures must be reviewed and approved before implementation.

Evidence:

• Change management policy

• Change tickets

• Risk assessment

• Approval

• Testing

• Deployment approval

• Verification

Emergency changes should have a separate process.

53. Separate development, testing and production

Development, test and production environments should be properly separated.

Evidence:

• Environment configuration

• Access controls

• Promotion controls

54. Separate development and deployment responsibilities

Where practical, the person developing code should not be the same person deploying it.

If this is not possible, another compensating control should be used.

Evidence:

• Role separation

• Independent approval

• Compensating control

55. Use source control and code review

Software development should use source-code repositories, branch protection and code reviews.

Evidence:

• Repository configuration

• Pull requests

• Code review records

56. Have a rollback plan

Changes should have a way to be reversed if they cause problems.

Evidence:

• Rollback/back-out plan in change records

________________________________________

BUSINESS CONTINUITY AND VENDOR MANAGEMENT

CC9.1, CC9.2

57. Have business continuity arrangements

You must have a continuity plan for the systems included in your SOC 2 scope.

Evidence:

• Business continuity plan

• Testing records

• Test results

58. Manage vendor risks

You must identify, assess and monitor important vendors.

This should include:

• Vendor identification

• Risk classification

• Due diligence

• Security requirements in contracts

• Ongoing monitoring

Evidence:

• Vendor register

• Vendor risk rating

• Due diligence records

• Contracts

• Review records

59. Review suppliers' SOC 2 reports

Where applicable, you should obtain and review your suppliers' SOC 2 reports.

You should also check the complementary user entity controls identified in those reports.

Evidence:

• Supplier SOC 2 reports

• Review records

• Evidence that required customer-side controls were implemented

60. Offboard vendors securely

When a vendor relationship ends, you must have a process for retrieving or securely destroying your data.

Evidence:

• Vendor offboarding records

• Data return/destruction evidence

________________________________________

PART 3 — PREPARING FOR A SOC 2 TYPE 1 REPORT

Type 1 focuses on whether controls are properly designed and implemented at a specific point in time.

61. Review evidence before the auditor does

For every control, you should identify and review the supporting evidence before the audit.

Evidence:

• Evidence samples

• Internal review records

62. Perform internal walkthroughs

Walk through every control to confirm that it actually exists and is being performed.

63. Identify controls that exist only on paper

A control that has never actually been performed can create an audit issue.

For Type 1, controls should be properly designed and implemented by the report date.

64. Prepare management's assertion

Management must prepare the required assertion for the SOC 2 report.

Evidence:

• Draft management assertion

65. Close gaps before the report date

Every identified gap should have an owner and target completion date.

Evidence:

• Remediation plan

• Responsible person

• Completion dates

________________________________________

PART 4 — SOC 2 TYPE 2

Type 2 examines whether controls operated effectively over a period of time, rather than only at one point in time.

66. Define the audit period

You must establish:

• Start date

• End date

• Length of the audit period

The period is commonly several months, depending on the engagement.

67. Controls must operate throughout the period

Controls should operate consistently for the entire period covered by the report.

If a control starts late, the auditor can normally only test it from the date it began operating.

68. Maintain continuity between reports

If this Type 2 follows an earlier SOC 2 report, any gap between the reporting periods should be identified and addressed.

Evidence:

• Previous SOC 2 report

• Reporting dates

• Gap calculation

• Bridge letter where applicable

69. Maintain complete records of control activities

For every control, you must be able to identify every occasion when the control should have been performed.

Evidence:

• Tickets

• HR records

• Directory records

• System logs

• Code repositories

• Other system-generated records

70. Prove that your records are complete

You must be able to demonstrate that your population is complete.

Evidence may include:

• Reconciliation with another system

• System-generated totals

• Sequence checks

71. Keep records during the audit period

Do not rely on recreating evidence after the period ends.

Evidence:

• Retained exports

• Archived records

• System records

72. Evidence should show who performed the control and when

System-generated evidence should include dates and user identification wherever applicable.

Evidence:

• Automatic timestamps

• User IDs

• Workflow approvals

73. Avoid relying only on personal spreadsheets

Controls supported only by spreadsheets maintained by the control owner can receive additional auditor scrutiny.

74. Keep evidence for the entire period

Evidence must remain available for the complete audit period.

For example, if your audit period is 12 months, keeping logs for only 30 or 90 days is not sufficient.

75. Perform scheduled controls on time

If a control is scheduled monthly, quarterly or annually, you should be able to show that each required occurrence happened.

Evidence:

• Expected frequency

• Actual completion dates

• Missed or delayed activities

76. Do not backdate missed controls

If a control was missed, document the missed activity honestly.

Backdating evidence can create a more serious issue than the original missed control.

________________________________________

PART 5 — TYPE 2: EMPLOYEE AND GOVERNANCE CONTROLS

77. Maintain the employee population

You must be able to identify everyone who:

• Joined

• Left

• Worked during the audit period

This should include relevant contractors and interns.

Evidence:

• HR records

• Payroll records

• Employee population

78. Complete background checks

Where legally permitted, background checks should be completed for applicable new employees.

Evidence:

• Screening records

• Screening dates

• Employee joining dates

79. Track code-of-conduct acknowledgements

You should be able to show that employees acknowledged the code of conduct.

Evidence:

• Individual acknowledgement records

• Dates

80. Track security training

You should be able to show that employees completed required security training.

Evidence:

• Training records

• Completion dates

• Follow-up actions for employees who did not complete training

81. Maintain board or management meeting records

You should be able to show that scheduled governance meetings took place and that internal controls were considered.

Evidence:

• Meeting minutes

• Attendance

• Dates

• Missed meetings, if any

________________________________________

TYPE 2 — COMMUNICATION

82. Maintain communication records

You must be able to demonstrate that required communications were actually sent.

Evidence:

• Emails or communications

• Dates

• Recipients

• Policy publication records

83. Maintain customer notification records

If customers must be notified within a specific timeframe, you should be able to demonstrate that notifications were sent on time.

Evidence:

• Notification records

• Dates

• Required response/notification timelines

________________________________________

TYPE 2 — RISK ASSESSMENT

84. Perform risk assessments as required

Risk assessments must be performed according to the frequency defined in your policy.

Evidence:

• Risk assessment

• Date

• Approval/review records

85. Assess significant changes

Important changes during the period should be assessed for their impact on controls.

Evidence:

• Change population

• Impact assessment

• Dates

86. Review fraud risk

Fraud risk should also be considered during the reporting period.

Evidence:

• Fraud risk assessment

• Date

• Results

________________________________________

TYPE 2 — MONITORING

87. Maintain monitoring records

You must be able to provide monitoring results for the entire audit period.

Examples include:

• Exception reports

• Internal reviews

• Audits

• Vulnerability scans

• Penetration tests

88. Prove that monitoring results were reviewed

Generating a report is not enough. Someone must review it.

Evidence:

• Reviewer name

• Review date

• Review comments

• Actions taken

89. Track deficiencies

Weaknesses identified during the period should be recorded, escalated and addressed.

Evidence:

• Deficiency records

• Escalation records

• Corrective actions

• Dates

________________________________________

TYPE 2 — POLICIES AND PROCEDURES

90. Review policies on time

Policies should be reviewed and approved according to their defined review frequency.

Evidence:

• Policy register

• Review frequency

• Review date

• Approval

91. Manage changes to procedures

If a procedure changes during the audit period, the control documentation should reflect the change.

The auditor may test controls according to the version that was applicable at the time.

________________________________________

TYPE 2 — ACCESS MANAGEMENT

92. Maintain a complete access population

You must be able to identify every access:

• Granted

• Changed

• Removed

during the audit period.

Evidence:

• Access logs

• Directory records

• Access management system

93. Prove access was approved before provisioning

Access should be approved before it is granted.

Evidence:

• Approval record

• Approver

• Approval date

• Provisioning date

Retrospective approval is generally treated as a deviation.

94. Track all terminated users

You must be able to identify everyone who left during the period.

Evidence:

• HR records

• Termination records

• Contractor records

95. Remove access within the required timeframe

Access should be removed within the organisation's defined timeframe for every applicable leaver.

Evidence:

• Termination date

• Access revocation date/time

• Time taken to remove access

96. Perform access reviews as scheduled

Every required access review should be completed on time.

Evidence:

• Review schedule

• Review dates

• Reviewer

• User population reviewed

97. Review the complete user population

Access reviews should cover all relevant users, not just a selected group.

Evidence:

• User list

• Directory reconciliation

• Review records

98. Document reviewer actions

The reviewer should actually examine the access and document exceptions.

Evidence:

• Reviewer name

• Review date

• Exceptions identified

• Actions taken

99. Remove inappropriate access

If an access review identifies unnecessary or inappropriate access, it should be removed and the action documented.

Evidence:

• Access removal

• Closure date

• Corrective action

100. Demonstrate that technical controls operated throughout the period

Technical controls should not only exist when the auditor checks them. They should operate throughout the reporting period.

Examples:

• Encryption

• MFA

• Firewall controls

• Endpoint protection

Evidence:

• Configuration records from different points in the period

• Coverage reports

• Evidence of changes or gaps

________________________________________

TYPE 2 — SECURITY MONITORING AND INCIDENTS

101. Maintain a complete list of security alerts

You must be able to produce the security alerts/events recorded during the period.

Evidence:

• Monitoring platform records

• Alert population

102. Track alert investigation

Each applicable alert should be reviewed and triaged.

Evidence:

• Alert date/time

• Triage date/time

• Person responsible

• Response time

103. Identify monitoring gaps

You should be able to identify any period when monitoring was unavailable or alerts were not reviewed.

104. Maintain a complete incident record

All relevant security incidents should be recorded, including minor incidents.

Evidence:

• Incident register

• Incident dates

• Classification

• Actions taken

105. Follow the incident response process

For each incident, you should be able to show that the organisation followed its incident response procedure.

Evidence:

• Detection

• Classification

• Containment

• Remediation

• Customer notification, where required

• Regulatory notification, where required

106. Prove backups operated as required

You should be able to show that scheduled backups were completed during the period.

Evidence:

• Backup job records

• Successful and failed jobs

• Investigation of failed backups

107. Test restoration

A restore test should be completed during the reporting period.

Evidence:

• Test date

• Data/system restored

• Result

• Recovery time

The test should match what your documented recovery control actually promises.

________________________________________

TYPE 2 — CHANGE MANAGEMENT

108. Maintain a complete change population

You should be able to identify all changes deployed to production during the audit period.

Evidence:

• Change tickets

• Deployment records

• Source-control records

• Reconciliation between systems

109. Approve and test changes before deployment

Each applicable change should be:

1. Risk assessed

2. Tested

3. Approved

4. Deployed

Evidence:

• Change record

• Risk assessment

• Test results

• Approval date

• Deployment date

110. Track emergency changes

Emergency changes should be separately identified and justified.

Evidence:

• Emergency change register

• Reason for emergency

• Approval/review

111. Monitor emergency changes

You should know what percentage of changes were emergency changes.

A high percentage may lead the auditor to examine whether the normal change-management process is being bypassed.

________________________________________

TYPE 2 — VENDOR MANAGEMENT

112. Complete required vendor reviews

Vendor reviews should be performed according to your policy.

Evidence:

• Vendor register

• Risk classification

• Review dates

• Review results

113. Review supplier SOC 2 reports

If your suppliers provide SOC 2 reports, you should obtain and review them.

The supplier's reporting period should also be considered in relation to your own reporting period.

Evidence:

• Supplier SOC 2 report

• Reporting period

• Bridge letter where required

114. Review supplier CUECs

You should review the complementary user entity controls identified in supplier reports and implement the controls that apply to your organisation.

Evidence:

• Review records

• Implemented controls

115. Assess supplier exceptions

If a supplier's SOC 2 report contains exceptions or a qualified opinion, assess how this could affect your organisation.

Evidence:

• Impact assessment

• Risk evaluation

• Corrective action where required

________________________________________

PART 6 — TYPE 2 SYSTEM DESCRIPTION AND EXCEPTIONS

116. Keep the system description accurate throughout the period

The system description should represent how the system operated during the entire reporting period.

Changes should be included, such as:

• New technology

• New environments

• System migrations

• New suppliers

• Acquisitions

• Significant staffing changes

Evidence:

• Updated system description

• Change records

• Review/approval

117. Have the description independently reviewed

Someone who understands the actual system should review the description.

Ideally, this should not simply be copied from the previous year's description without review.

118. Identify your own control deviations

Before the auditor finds an issue, identify and document your own deviations.

Examples:

• Missed access reviews

• Late access removal

• Unapproved changes

• Monitoring gaps

• Missed training

• Delayed risk assessments

Evidence:

• Self-identified deviation log

119. Understand and address each deviation

For every deviation, document:

• What happened

• Why it happened

• How many cases were affected

• The risk/impact

• Corrective action

• Completion date

• Any compensating control

Being transparent about a deviation, its cause and corrective action provides the auditor with a much clearer picture than discovering it unexpectedly during testing.

________________________________________

HOW TO USE THIS DOCUMENT

SOC 2 compliance is not about creating a large number of documents just for the auditor.

The objective is to make sure that:

• Required decisions have been made.

• Responsibilities are clearly assigned.

• Policies and procedures reflect actual practices.

• Controls are operating as intended.

• Evidence is generated and retained.

• Risks are identified and managed.

• Problems are recorded and corrected.

• Employees understand what they are expected to do.

Documentation alone does not mean compliance.

A long procedure that nobody follows can create a bigger problem because the auditor can see the difference between what the document says and what the organisation actually does.

The key question is:

Does the documented process reflect what people actually do, and can the organisation provide reliable evidence that the controls are working?

For SOC 2 Type 1, the focus is mainly on whether controls are properly designed and implemented at a specific point in time.

For SOC 2 Type 2, the focus goes further: the organisation must demonstrate that those controls actually operated effectively throughout the defined reporting period.

In simple terms:

SOC 2 is not just about having policies. It is about having the right controls, actually following them, and being able to prove it with reliable evidence.