SOC 2 Control Self-Test Worksheet
A SOC 2 Control Self-Test Worksheet for checking whether your Trust Services controls are designed, operating, and backed by evidence before the auditor arrives.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: Saas · Fintech · Healthcare Technology · B2b Software · Managed Services
Overview
This SOC 2 Control Self-Test Worksheet is a pre-audit inspection template for verifying that your Trust Services controls are in place, operating, and supported by evidence. It is organized the way a reviewer would actually work: first confirming scope and readiness, then testing security, availability and resilience, processing integrity, confidentiality and privacy, and finally documenting exceptions and sign-off.
Use it when you need to prepare for a SOC 2 audit, validate recurring controls during the audit period, or close gaps after a prior review. It is especially useful when multiple teams own different controls and evidence is spread across ticketing systems, cloud consoles, shared drives, and monitoring tools. The worksheet helps you confirm control ownership, evidence dates, and whether the proof matches the stated control frequency.
Do not use it as a substitute for the system description or the auditor’s request list. It is not meant to prove every possible control in your environment, and it should be tailored to the Trust Services Criteria in scope for your engagement. If a control is not in scope, remove it. If a control is automated, document the system-generated evidence instead of forcing a manual sign-off. The goal is to surface deficiencies early, not to create paperwork that cannot be defended during testing.
Standards & compliance context
- This worksheet supports SOC 2 readiness by organizing evidence around the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy.
- The control checks align with common expectations in ISO 9001-style evidence discipline and internal control testing, where ownership, traceability, and documented exceptions matter.
- Security logging, access review, incident handling, and change management items should be mapped to your actual policies and procedures so they can be defended during auditor testing.
- If privacy controls are in scope, use the worksheet to track request handling, retention, and disposal evidence in a way that supports your privacy program and applicable legal obligations.
- Availability and recovery items should reflect your business continuity and disaster recovery practices, including restore testing and current plan ownership.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Inspection Scope & Readiness
This section confirms you are testing the right system, the right period, and the right owners before any evidence review begins.
-
Control scope matches the in-scope system and Trust Services Criteria
Verify the worksheet is limited to the scoped services, locations, and Trust Services Criteria in the audit period.
-
Evidence period covers the audit window
Confirm evidence dates fall within the period under review.
-
Control owner identified for each in-scope control
Each control has a named owner responsible for operation and evidence retention.
-
Evidence repository is accessible and organized
Assess whether evidence can be retrieved quickly and consistently during auditor testing.
Security Controls
This section checks the core security operating controls auditors usually sample, including access, change, logging, and incident handling.
-
User access reviews completed on schedule
Verify periodic access reviews were performed and exceptions were remediated.
-
Privileged access is restricted and approved
Confirm elevated access is limited to authorized users with documented approval.
-
Change management evidence exists for sampled changes
Check that sampled production changes have request, approval, testing, and deployment evidence.
-
Security logging and monitoring alerts are reviewed
Confirm logs are generated, retained, and reviewed for suspicious activity.
-
Security incidents are tracked and investigated
Verify incident records show triage, investigation, containment, and closure.
Availability & Resilience Controls
This section verifies that backups, restore tests, monitoring, and recovery planning are current and supported by proof.
-
Backups are performed and monitored
Verify backup jobs ran successfully and failures were remediated.
-
Restore test evidence is available
Confirm a recent restore test was completed and documented with results.
-
Availability monitoring thresholds are defined
Check that uptime or service health thresholds are documented and monitored.
-
Business continuity or disaster recovery plan is current
Verify the plan has been reviewed within the required cycle and reflects current dependencies.
Processing Integrity Controls
This section focuses on whether data is validated, exceptions are handled, and outputs are reconciled as intended.
-
Input validation rules are documented and operating
Confirm key data validation checks are defined and functioning as intended.
-
Exception handling and reprocessing are evidenced
Verify exceptions are logged, reviewed, and reprocessed where appropriate.
-
Output reconciliations are performed
Check that output totals or reconciliations are reviewed for completeness and accuracy.
Confidentiality & Privacy Controls
This section checks whether sensitive data is classified, protected, retained, disposed, and tracked according to policy and legal obligations.
-
Data classification and handling requirements are documented
Verify confidential and personal data handling rules are defined for the scoped environment.
-
Encryption at rest and in transit is implemented where required
Confirm encryption controls are enabled for systems and data in scope.
-
Data retention and disposal controls are followed
Check retention schedules and secure disposal evidence for records in scope.
-
Privacy requests or incidents are tracked to closure
Verify privacy-related requests, complaints, or incidents are documented and resolved.
Evidence Quality, Exceptions & Sign-Off
This section captures deficiencies, assigns remediation, and records formal attestation so the self-test ends with accountable next steps.
-
Exceptions and deficiencies are documented with owners and due dates
Record any non-conformance, deficiency, or missing evidence discovered during the self-test.
-
Corrective actions have been assigned
Confirm remediation owners and target dates are assigned for all open issues.
-
Inspector attestation
Inspector confirms the worksheet was completed based on available evidence and observed results.
How to use this template
- 1. Define the audit period, in-scope system, and Trust Services Criteria so the worksheet only tests controls that belong in the engagement.
- 2. Assign each control row to a named owner and link the evidence repository, ticketing record, or system report that proves the control operated during the period.
- 3. Walk through each section in order, checking the control description against the actual process and attaching dated evidence for the sample or frequency required.
- 4. Record every exception, deficiency, or missing artifact with a clear owner, due date, and remediation note instead of leaving blanks or informal comments.
- 5. Review the completed worksheet with compliance and management, then sign off only after open items are either resolved or formally accepted with a plan.
Best practices
- Tie every control to a specific owner and evidence source before the self-test begins, or the review will stall when proof is needed.
- Use evidence dated inside the audit window, not screenshots or exports from outside the period under review.
- For recurring controls such as access reviews, backups, and monitoring, verify the cadence as well as the result so the control can be defended as operating effectively.
- Keep the evidence repository organized by control name and date so an auditor can trace each item without a manual search.
- Document exceptions as deficiencies with impact, owner, and due date instead of treating them as informal notes.
- For automated controls, capture system output, logs, or workflow history that shows the control executed, not just a policy stating that it should.
- Review restore tests, incident records, and change approvals for completeness because these are common failure points in SOC 2 testing.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What does this SOC 2 Control Self-Test Worksheet cover?
This worksheet covers the core areas auditors usually expect to see supported by evidence: scope and readiness, security, availability and resilience, processing integrity, confidentiality and privacy, and final exceptions and sign-off. It is designed to help you verify that controls are not only documented, but also operating during the audit period. Use it to collect proof, identify gaps, and assign follow-up actions before formal testing begins.
When should we run this worksheet?
Run it before your SOC 2 audit window closes, and again after any major system, vendor, or process change. Many teams use it as a pre-audit readiness check, then repeat it quarterly or monthly for controls that need recurring evidence such as access reviews, backups, and log monitoring. If a control is high risk or frequently changes, test it closer to the audit period.
Who should complete the self-test?
The control owner should complete each section, with review from security, compliance, IT, operations, or privacy depending on the control. A single coordinator can manage the worksheet, but the evidence should come from the people who actually run the control. For sign-off, use someone who can confirm the results and assign remediation, not just collect files.
Does this worksheet map to the SOC 2 Trust Services Criteria?
Yes, it is structured around the Trust Services Criteria areas commonly tested in SOC 2 engagements: security, availability, processing integrity, confidentiality, and privacy. It is a self-test tool, not the auditor’s workpaper, so it helps you prepare evidence and spot deficiencies early. You can customize the control list to match your system description and the criteria in scope.
What are the most common mistakes this template helps catch?
Common issues include missing evidence for the full audit period, access reviews that were done but not retained, backups that were performed but never restore-tested, and change records that do not show approval or testing. Teams also miss ownership, so controls exist on paper but no one can prove who ran them. This worksheet makes those gaps visible before the auditor does.
How do we customize it for our environment?
Start by aligning the scope to your in-scope systems, products, and subservice organizations, then tailor each control to the way it actually operates. Add your own evidence fields, control owners, frequencies, and repository links. If you have automated controls, include screenshots, exports, or system reports that show the control ran during the period.
Can this be used with GRC tools, ticketing systems, or shared drives?
Yes. The worksheet works well alongside GRC platforms, ticketing systems, cloud logs, and shared evidence folders. Many teams link each control to Jira, ServiceNow, Google Drive, SharePoint, or a GRC record so the reviewer can jump straight to source evidence. The key is to keep the evidence organized and time-bound.
How is this different from an ad hoc audit prep checklist?
An ad hoc checklist usually asks whether a control exists, while this worksheet asks whether it operated during the period and whether the evidence is sufficient. That distinction matters in SOC 2 because auditors test design and operating effectiveness, not just policy presence. This template also includes exceptions, corrective actions, and sign-off so you can track closure instead of stopping at discovery.
Related templates
Go deeper on the topic
-
Predictive scheduling laws — also called fair workweek laws or secure scheduling — require employers in covered industries to publish employee schedules...
-
Overtime calculation is the process of applying federal, state, local, and contractual rules to hours worked to determine the correct pay — including...
-
A near-miss is an event that could have caused injury or damage but didn't — a slip that didn't fall, a load that shifted but didn't drop, a machine that...
-
Lockout/tagout (LOTO) is the procedure for controlling hazardous energy — electrical, hydraulic, pneumatic, mechanical, thermal, chemical — before...
-
Spring '26 brings AI Course Creation, Power BI-connected AI Agents, and smarter content governance to MangoApps. See what's new across the platform.
-
Integrated digital workplace task management tips to keep work moving, reduce stalls, and turn conversations into accountable action.
-
When scheduling tools lack leave and budget data, costly errors follow. See how integrated workforce management closes the context gap.
-
Data governance for AI: Build a trusted knowledge base with MangoApps to deliver accurate, permission-aware enterprise AI answers.
Ready to use this template?
Get started with MangoApps and use SOC 2 Control Self-Test Worksheet with your team — pricing built for small business.
