SOC 2 requirements: what auditors ask for
SOC 2 has no checklist of required controls. It has criteria you must meet and controls you choose to meet them with, which is why the honest answer to what is required is always: it depends on your system.
There is no official list of SOC 2 controls. The framework sets out criteria your system has to meet, and you decide which controls meet them. An auditor then judges whether your controls are suitable for the criteria and, in a Type 2 engagement, whether they operated. This is why two companies can both hold a clean SOC 2 report with quite different control sets.
What is fixed is the criteria themselves, and the kinds of evidence auditors ask for against them. That is what this page sets out: the five Trust Services Criteria, the nine common criteria series inside Security, and the documents and screenshots that get requested in real engagements.
The five Trust Services Criteria
Security is mandatory and is the only one many companies include. The other four are elective and you add them because a customer needs them, not because more looks better. Each addition widens scope, evidence and fee.
| Criterion | What it covers | What it adds to the audit |
|---|---|---|
| Security | Protection against unauthorized access, disclosure and damage. Known as the common criteria. | The base. Every report includes it. |
| Availability | The system is available for operation and use as committed. | Capacity monitoring, backup and restore testing, incident and outage records, disaster recovery testing. |
| Confidentiality | Information designated confidential is protected as committed. | Data classification, handling and retention rules, secure disposal evidence, confidentiality clauses in contracts. |
| Processing integrity | Processing is complete, valid, accurate, timely and authorized. | Input validation, error handling and reprocessing records, output reconciliation. Rarely needed outside payments and calculation engines. |
| Privacy | Personal information is collected, used, retained and disposed of as committed. | Notice and consent records, data subject request handling, retention schedules, third party disclosure records. |
Privacy criterion or privacy law
Including the privacy criterion does not make you PIPEDA compliant, and excluding it does not excuse you from privacy law. They are separate. Canadian companies handling personal information are governed by PIPEDA, or by Law 25 in Quebec, or by a provincial statute, regardless of what is in a SOC 2 scope. Sort out which law applies before deciding whether the privacy criterion is worth the scope it adds.
The nine common criteria series
Security is organized into nine numbered series. This is the structure your auditor works through, and it maps closely to the COSO internal control framework, which is why the first series is about governance rather than technology.
| Series | Subject | What it means in practice |
|---|---|---|
| CC1 | Control environment | Board or ownership oversight, defined roles, background checks, a code of conduct, security training that people actually completed. |
| CC2 | Communication and information | Policies published where staff can find them, security commitments communicated to customers, a channel for reporting concerns. |
| CC3 | Risk assessment | A documented risk assessment, refreshed at least annually, that names risks, owners and treatments. Fraud risk gets an explicit mention. |
| CC4 | Monitoring activities | Evidence that you check whether controls are working, and that findings get remediated and closed. |
| CC5 | Control activities | Controls selected and deployed against the risks you identified, including technology controls. |
| CC6 | Logical and physical access | The largest series. Provisioning, deprovisioning, access reviews, multi-factor authentication, encryption, key management, physical access to any facility you run. |
| CC7 | System operations | Vulnerability management, logging and monitoring, alerting, incident response including a test or a real incident with records. |
| CC8 | Change management | Changes are authorized, tested and approved before release. Emergency changes have a defined path and a record. |
| CC9 | Risk mitigation | Business disruption planning and vendor risk management, including a vendor register with review evidence. |
CC6 and CC7 generate the most exceptions by a wide margin. Access reviews get skipped a quarter, an offboarded contractor keeps a repository token, alerting exists but nobody can show that anyone responded. None of these are hard problems. They are consistency problems, and a Type 2 tests consistency.
What an auditor actually asks for
Evidence requests vary by firm, but the shape is stable. Expect most of the following, and expect a sample of dates rather than a single example.
| Area | What they ask to see |
|---|---|
| Policies | Information security, access control, change management, incident response, business continuity, vendor management, acceptable use, with approval dates and a review cycle. |
| Onboarding | For a sample of hires: offer letter or contract with confidentiality terms, background check, policy acknowledgement, security training completion, access grant ticket. |
| Offboarding | For a sample of leavers: termination date against the timestamp on each access revocation. This one catches people. |
| Access reviews | Periodic reviews of production, cloud console, source control and administrative access, with evidence of who reviewed, when, and what was removed. |
| Authentication | Multi-factor enforcement settings, password policy configuration, single sign-on coverage, service account inventory. |
| Change management | A sample of pull requests or change tickets showing review and approval by someone other than the author, plus deployment records. |
| Vulnerability management | Scan output, dependency alerts, a remediation SLA by severity, and evidence that the SLA was met or exceptions were accepted. |
| Penetration test | A report from an independent tester within the last twelve months, plus remediation evidence for anything material. |
| Logging and monitoring | Log sources, retention settings, alert rules, and a sample of alerts with what was done about them. |
| Incident response | The plan, plus either a real incident with a timeline and post-incident review, or a documented tabletop exercise. |
| Backups and recovery | Backup configuration and a restore test performed during the period. Configuration alone is not enough. |
| Vendors | A register of subservice organizations and vendors with data access, risk ratings, and their SOC 2 or ISO reports on file. |
| Risk assessment | The assessment itself, dated inside the observation period, with owners and treatment decisions. |
| Encryption | Configuration showing encryption in transit and at rest, plus key management arrangements. |
The word to notice throughout is "during the period". A Type 2 samples dates inside the observation window. A restore test done the week before fieldwork, covering a window that started nine months earlier, is an exception no matter how well it went. The difference between the two report types comes down almost entirely to this.
The policy set
Auditors expect written policies, approved by someone with authority, reviewed at least annually, and acknowledged by staff. The trap is not writing them. It is writing ones you do not follow.
A policy that says access reviews happen quarterly, in a company that does them twice a year, creates an exception that would not exist if the policy said twice a year. Write the policy to match reality, then improve reality and update the policy. Downloading a template set and approving it unread is the single most common self-inflicted wound in a first audit.
Deciding what is in scope
Scope is your decision and it drives everything else. You define the system: which product, which environments, which supporting infrastructure, and which third parties are carved out.
Carving out a subservice organization such as AWS or Google Cloud is normal and expected. You are not auditing Amazon's data centres. What you are responsible for is the controls you operate on top, and for monitoring that the provider's own report stays current, which is itself a CC9 control.
Keep the first scope narrow. One product, one production environment, the Security criteria. You can widen later, and widening a scope is much less painful than discovering mid-window that a legacy system you included has no logging.
Canadian specifics worth building in
Nothing in SOC 2 is Canada-specific, but a few local obligations are worth handling with the same evidence so you do the work once.
- PIPEDA requires a record of every breach of security safeguards for 24 months, including ones you assessed as low risk. Your incident log satisfies both this and CC7 if you keep it that way.
- Quebec's Law 25 requires privacy impact assessments in defined circumstances. That work is separate from SOC 2 but shares the data inventory.
- Ontario health information brings PHIPA agent obligations, including a duty to notify the custodian. That belongs in your incident response plan whether or not privacy is in your SOC 2 scope.
- Buyers who require Canadian data residency will read your system description for it. Describe your regions accurately rather than vaguely.
Find out what your gap actually is
Tell us your stack and scope and we will connect you with Canadian firms that do readiness assessments and SOC 2 audits.
Get matchedCommon questions
How many controls does SOC 2 require?
There is no fixed number, because you choose the controls. A typical Security-only report lists somewhere between 60 and 120 controls mapped to the common criteria. More controls is not better. Fewer controls that you can evidence consistently produces a cleaner report than many you cannot.
Which Trust Services Criteria should we include?
Security only, unless a customer has named another. Availability is the usual second choice for companies selling an uptime commitment. Confidentiality is worth including if customers send you their own sensitive data. Processing integrity applies to a narrow set of transaction processing businesses. Privacy is expensive and often better handled through actual privacy law work.
Is a penetration test required for SOC 2?
The criteria do not name one, but auditors expect independent testing as evidence for vulnerability management, and buyers reading the report look for it. Treat it as required in practice. Annual is the normal cadence, scheduled early in the observation window so remediation and retesting fit inside it.
Do we need a written information security policy?
Yes, and it needs an approval date, an owner, an annual review, and evidence that staff acknowledged it. Auditors also expect supporting policies covering access control, change management, incident response, business continuity and vendor management. Keep them short and accurate rather than long and aspirational.
What is the most common reason companies fail their first SOC 2?
Reports rarely fail outright. What happens is exceptions, and the most common ones are missed access reviews, offboarding that lagged the termination date, and controls that were only performed once near the end of the observation window. All three are consistency failures rather than security failures.
Does SOC 2 require encryption at rest?
The criteria require protection appropriate to the risk rather than naming a technology, but in practice every auditor expects encryption in transit and at rest for a cloud service, and every buyer's security reviewer looks for it. Since the major cloud providers give it to you by default, arguing the point costs more than enabling it.