SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams

No regulator requires SOC 2. It is a service organisation control report defined by the AICPA, and the only people who demand it are your customers and their auditors. The trigger is commercial: a procurement or third-party-risk team makes "send us your SOC 2 Type 2" a condition of signing, or a master services agreement already promises one annually. In North American enterprise, fintech and health-tech sales the request is near-universal above the contract value where a questionnaire stops being enough. European and APAC buyers more often ask for ISO 27001; many SaaS companies hold both.

You are a candidate if you run a multi-tenant SaaS, a hosting or managed service, a data pipeline, payroll, or any processing on a customer's behalf. SOC 2 covers security and operational controls; SOC 1 (AT-C section 320) covers controls relevant to a customer's financial reporting and is a different engagement.

Ignoring it costs you three ways. Deals slip while you answer 300-line questionnaires. Contracts get signed with a "SOC 2 within 12 months" clause that becomes a breach risk. And when you finally do it under pressure, the window is too short and the report arrives with a list of exceptions every reader sees — which can hurt a sales cycle more than having no report at all.

Three AICPA documents define a SOC 2 examination. The 2017 Trust Services Criteria with revised points of focus (2022) are what your controls are tested against. The 2018 description criteria with revised implementation guidance (2022) govern the system description in Section III of the report. The examination itself runs under the attestation standards — SSAE No. 18 as amended, AT-C section 105 (common concepts) and AT-C section 205 (assertion-based examination engagements) — with the AICPA's SOC 2 guide (2022 edition) as the practitioner's handbook.

The criteria sit in five trust services categories. Only Security is mandatory; it is expressed as the Common Criteria, CC1–CC9, 33 criteria. CC1–CC5 are the COSO 2013 principles (control environment, communication, risk assessment, monitoring, control activities) applied to a service organisation; CC6–CC9 add logical and physical access, system operations, change management and risk mitigation. The optional categories add Availability (A1.1–A1.3), Confidentiality (C1.1–C1.2), Processing Integrity (PI1.1–PI1.5) and Privacy (P1.1–P8.1, 18 criteria). All 61 are in the control library below this guide.

Each criterion carries points of focus. They are illustrative, not requirements: the auditor opines on whether your controls meet the criterion, not on whether every point is ticked. The 2022 revision changed only the points of focus — more on data management, and a split between what applies to data controllers and to processors in the privacy criteria — and there has been no new edition since.

The attestation layer is moving. On 26 February 2026 the Auditing Standards Board issued an exposure draft revising AT-C sections 105, 205 and 210; comments closed on 30 June 2026 and, if issued as final, it would apply to engagements beginning on or after 15 June 2029. The AICPA also spent 2026 on SOC 2 quality: Ethics Staff Insights (13 April 2026) on independence threats when a CPA firm has a business arrangement with a SOC 2 tool provider, and a peer-review alert (May 2026) treating identical reports, risk assessments, sample sizes and tests across a firm's clients as nonconforming. Expect tailored sampling and harder questions than two years ago.

Type 1 versus Type 2. A Type 1 report opines on whether controls were suitably designed and implemented as of a date. A Type 2 also tests whether they operated effectively throughout a period and prints the tests and results in Section IV. Type 2 is what customers mean by "your SOC 2". A SOC 3 is a general-use summary you can publish.

Scope in SOC 2 is "the system": the services you report on and the infrastructure, software, people, procedures and data that deliver them. You draw the boundary; the auditor tests inside it. Four decisions follow.

1. Products and environments. Name the services, production accounts, subscriptions or projects, regions and legal entities. "The Acme platform in AWS accounts prod-eu and prod-us" is a boundary; "our cloud environment" is not, and the auditor will treat every account in the organisation as in scope.
2. Categories. Add Availability if you publish an SLA (most SaaS). Add Confidentiality if you hold customer data under NDA-style commitments; it costs two criteria, C1.1 and C1.2. Add Processing Integrity when customers rely on what you compute — billing, payments, analytics (PI1.1–PI1.5). Add Privacy only when you make commitments directly to data subjects; it adds 18 criteria from P1.1, and most processors evidence GDPR or HIPAA obligations separately instead.
3. Subservice organisations. AWS, Azure and GCP are subservice organisations. Nearly everyone uses the carve-out method: their controls are excluded, you list the complementary subservice organisation controls you rely on (physical security, hypervisor isolation), and you obtain and review their SOC 2 reports under CC9.2. You also state complementary user entity controls — what customers must do for your controls to work.
4. Type and period. A Type 1 first is optional. For a first Type 2, a three-month window that starts only when every control is running beats a twelve-month window with a weak first half. Mature programmes settle into annual twelve-month periods.

The scoping mistakes that cost the most: bringing every product in "for completeness"; forgetting that corporate IT — laptops, identity provider, email, source control — is in scope for Security regardless of product; adding Privacy because it sounds thorough; and opening the window before access reviews, logging and change control actually operate.

The plan assumes a 20–200 person SaaS company on one or two cloud providers heading for a first Type 2. Shift the weeks, not the order.

Weeks 0–2: decide and inventory

• Choose categories, system boundary, Type and target window. Appoint one accountable owner with executive backing (CC1.3).
• Select the CPA firm now: it must accept scope and timing, and its control-matrix format shapes your evidence.
• Inventory every cloud account, SaaS tool, repository, endpoint and vendor; run a gap assessment against all 61 criteria.
• Deliverables: scope statement, gap register, engagement letter, project plan.

Weeks 2–6: governance, risk and policy

• Approve the policy set — information security, access control, change management, incident response, continuity and disaster recovery, vendor management, risk management, data classification and retention, acceptable use, HR security — each with an owner, approval date and review cadence (CC5.3).
• Run a documented risk assessment whose register links risks to controls (CC3.2), including fraud (CC3.3).
• Start the quarterly management security review with minutes (CC1.2), awareness training and background checks (CC1.4).
• Deliverables: approved policies, risk register, org chart with security roles, control matrix mapping every criterion to named controls and owners.

Weeks 4–12: technical controls

• Identity: SSO everywhere, MFA enforced, no shared or long-lived credentials, a documented joiner/mover/leaver flow (CC6.2, CC6.3), first quarterly access review done.
• Logging, detection and vulnerability management wired to a ticket queue; EDR and MDM on every endpoint; encryption in transit and at rest enforced by policy.
• Change management enforced in the pipeline; backups with a successful restore test; incident response plan with a tabletop; vendor inventory with reviews of critical vendors.
• Deliverables: configuration exports per control and the first recurring records (access review, vulnerability report, restore test, tabletop).

Weeks 10–14: operate, then open the window

• Run every recurring control at least once, fix what the readiness review finds, and only then set the Type 2 start date. Take a Type 1 here if a customer needs paper quickly.
• Draft the Section III system description against the description criteria while the design is fresh.
• Deliverables: readiness report, evidence calendar (what, who, how often), draft system description.

Window, fieldwork and after

• During the 3–12 month window, collect evidence as it is generated; late backfill is the biggest source of exceptions.
• Fieldwork: walkthroughs, sampling, exception discussion, management responses, then the assertion and representation letter.
• The next window starts the day this one ends. Keep the cadence, issue bridge letters on request, and re-scope yearly as products and vendors change.

These criteria generate most of the engineering tickets in a readiness project. "Done" means a configuration export and a sampled record both agree with the control description.

CC6.1 — logical access and encryption at rest

• AWS: IAM Identity Center federated to your IdP; no IAM users with long-lived keys; service control policies denying root use and unused regions; KMS customer-managed keys on RDS, EBS and S3; S3 Block Public Access at account level.
• Azure: Entra ID Conditional Access requiring MFA; Privileged Identity Management for just-in-time Owner and Contributor; Azure Policy in deny mode for unencrypted storage; Key Vault with purge protection.
• GCP: Cloud Identity groups bound to IAM roles; organisation policy constraints iam.disableServiceAccountKeyCreation and storage.publicAccessPrevention; CMEK via Cloud KMS on Cloud SQL, GCS and disks.
• Done: no standing privileged access, MFA at 100 per cent of the user list, a quarterly access review with a named reviewer and documented removals.

CC6.6 and CC6.7 — boundaries and encryption in transit

• AWS: default-deny security groups; Config rules for unrestricted SSH and RDP; WAF on CloudFront or ALB; load-balancer TLS policies at 1.2 or later with ACM certificates.
• Azure: network security groups on every subnet; Azure Firewall or Application Gateway WAF on public endpoints; "secure transfer required" and minimum TLS 1.2 on storage and App Service.
• GCP: VPC firewall rules with no 0.0.0.0/0 on management ports; Cloud Armor on external load balancers; SSL policies at minimum TLS 1.2; VPC Service Controls around data projects.
• Done: Security Hub, Defender for Cloud or Security Command Center shows no open public-exposure findings, and the pipeline fails on a change that creates one.

CC7.1 and CC7.2 — vulnerability management, monitoring and detection

• AWS: an organisation-wide CloudTrail trail to a central object-locked S3 bucket; GuardDuty in every account and region; Inspector for EC2, Lambda and ECR; Security Hub findings routed to on-call.
• Azure: Activity Log and diagnostic settings to a central Log Analytics workspace; Defender for Cloud with Defender for Servers; Sentinel analytics rules that open incidents.
• GCP: Data Access audit logs enabled explicitly — they are off by default for every service except BigQuery — with aggregated sinks to a logging project; Security Command Center Premium (the Enterprise tier is deprecated and shuts down on 21 May 2027).
• Done: any sampled alert traces alert → ticket → triage → closure, and vulnerability tickets close within your policy's SLA.

CC6.8 — malware protection and EDR

• MDM on every laptop enforcing disk encryption, screen lock and automatic updates; an EDR agent whose inventory reconciles with HR and MDM.
• AWS: GuardDuty Malware Protection for EC2 and S3; ECR scanning gating deploys. Azure: Defender for Servers with the Defender for Endpoint integration; Defender for Containers. GCP: Artifact Analysis on images; Security Command Center VM threat detection.
• Done: three inventories (HR, MDM, EDR) that match, and a sampled alert with a response record.

CC8.1 — change management

• Branch protection with required review and passing CI on the production branch; infrastructure as code with plan output reviewed in the pull request; a dedicated deploy identity so engineers cannot push to production by hand.
• Alerts on console-originated production changes from CloudTrail, Activity Log or Cloud Audit Logs; an emergency path that records approval after the fact.
• Done: for a sample of changes (expect 25 or more) each has a ticket, a reviewer who is not the author, test evidence and a deployment record.

CC9.2 — vendor and subservice-organisation management

• A vendor register classified by data access; annual review of SOC 2 or ISO 27001 reports for critical vendors, with their complementary user entity controls mapped to yours. Hyperscaler reports come from AWS Artifact, the Microsoft Service Trust Portal and Google Cloud's Compliance Reports Manager.
• Done: a dated review record per critical vendor inside the window, plus offboarding records.

A1.2 and A1.3 — backup and recovery testing

• AWS: AWS Backup plans with cross-region or cross-account vault copies and vault lock; RDS point-in-time recovery; restore testing plans that restore on a schedule and record duration.
• Azure: Azure Backup to a geo-redundant vault with soft delete; Site Recovery test failover on a recovery plan, which does not touch production.
• GCP: Backup and DR Service or Cloud SQL automated backups with point-in-time recovery; multi-region buckets; a scripted restore into a scratch project.
• Done: at least one restore or failover test inside the window with measured recovery time against your RTO and RPO, and an exercise report with actions.

The auditor tests each control by inquiry, observation, inspection and reperformance, and for Type 2 samples records across the window. File evidence by control, dated, with the person who produced it. Four groups cover almost everything.

• Policies and governance: the approved policy set with version history; risk assessment and register; org chart and role descriptions; management review minutes; code of conduct with signed acknowledgements; the system description and management's assertion.
• People records: background-check confirmations; onboarding and offboarding checklists for every hire and leaver in the window; training completion; acknowledgements for security roles (CC1.5).
• Technical exports: IdP user and MFA reports; cloud IAM, key and storage configuration; CSPM and vulnerability results at several points in the window; logging and alerting configuration; backup histories and restore-test results; EDR and MDM inventories; TLS settings.
• Tickets and recurring records: access requests and removals; quarterly access reviews with sign-off; change tickets with review and deployment evidence; incident tickets and post-incident reviews (CC7.4); vendor reviews; tabletop and DR reports; control-monitoring results (CC4.1).

Retention. Keep everything from a window at least until the following year's report is issued — the auditor compares consecutive periods. Beyond that, follow your own written retention policy; applying it is itself a control, and three years or longer is a common choice.

Who. Only an independent, licensed CPA firm can issue a SOC 2 report; the AICPA says it will act against members who perform SOC work outside professional standards, are not enrolled in peer review or are unlicensed. The firm cannot design, implement or operate the controls it opines on, so readiness work — gap assessments, policy drafting, tooling — is done by your team or a separate adviser. The AICPA's April 2026 ethics guidance warns that arrangements limiting the auditor's control over scope, timing, evidence or the reporting of deficiencies create independence threats; if one party promises both the readiness and the report, ask who signs the opinion.

Stages.

1. Engagement letter and planning: scope, categories, period, fee.
2. Walkthroughs: interviews with control owners; review of the control matrix and draft system description.
3. Type 1, if taken: design and implementation testing as of a date.
4. Observation window for Type 2.
5. Fieldwork: sample selection, evidence requests, reperformance; typically two to six weeks elapsed.
6. Exceptions: each deviation is written up with your management response. Exceptions do not automatically qualify the opinion; the auditor judges whether the criterion is still met.
7. Reporting: draft, management's assertion, representation letter, final report — usually within weeks of the window closing.

What the reader gets. Section I is the opinion — unmodified, qualified, adverse or a disclaimer. Section II is management's assertion. Section III is your system description. Section IV lists each criterion, your controls, the tests and the results, including exceptions. Section V, if present, is unaudited material such as management's responses. Customer risk teams read Section IV first, then the complementary user entity controls in Section III.

Cycle and cost drivers. Reports are annual and the next window follows immediately. A bridge letter — a short management statement that nothing material has changed since the report date — fills the gap for customers; it is a management document, not an auditor's report, and carries no opinion. Fees rise with the number of categories, systems, locations and subservice organisations, with sample sizes, with first-year effort, and with how hard the auditor has to chase evidence. The 2026 peer-review focus leaves less room for the cheapest "fast and easy" engagements.

1. Opening the window before controls operate. A first access review dated six weeks into a twelve-week window is an exception on day one. Fix: start after one full cycle of every recurring control.
2. Access reviews that remove nobody. Four signed quarters with zero changes read as a rubber stamp. Fix: diff against the IdP export, record each removal, and use a reviewer other than the administrator.
3. Control descriptions copied from a template. "Changes are approved by the change advisory board" when you merge pull requests is found in the first walkthrough — and identical control sets across clients now draw peer-review attention. Fix: describe what you actually do.
4. Treating points of focus as a checklist. Teams build 250 controls and evidence none. Fix: one or two well-evidenced controls per criterion; use the points of focus to test coverage.
5. Forgotten infrastructure. A sandbox account holding production data, a region nobody logs, a subscription outside Defender. Fix: enumerate from the organisation root and enforce logging and CSPM through SCPs, Azure Policy or organisation policy.
6. Hotfixes outside change control. A console database change at 02:00 is a change without a ticket. Fix: alert on console-originated production changes and route them through the emergency path with retrospective approval.
7. A one-off risk assessment. A register from eighteen months ago that no control references. Fix: review annually and on major change (CC3.4), and cite risk IDs in the control matrix.
8. No incident evidence. "We had no incidents" is not evidence of a working process. Fix: run a tabletop inside the window and push at least one real event — a phishing report, a disclosed vulnerability — through the full process.
9. A system description written the week before fieldwork. It contradicts the matrix and fails the description criteria. Fix: draft it in readiness and update it on scope change (CC2.3).

iCompaas is not a CPA firm and does not issue the report; it is the readiness and evidence layer underneath one. It pre-builds a Common Criteria control library mapped to evidence sources across AWS, Azure, GCP, Google Workspace and GitHub, and runs continuous checks across your connected cloud accounts so that an observation window starts with controls already operating rather than needing a backfill. Policy templates come with owners and review cadences, which is what CC1 and CC5 testing samples. Evidence is collected as it is generated and exported in the pack auditors expect — a control matrix, sample evidence per control, change tickets and incident tickets — so fieldwork requests map to artefacts you already hold. The 61-criterion control library on this page gives engineers the per-criterion detail, including AWS, Azure and GCP implementation notes where a criterion has a technical side, so the person who owns a control can read what the auditor will test. Scoping, the system description and the choice of auditor remain yours.