SOC 2 From Zero to Audit-Ready: Design Controls, Collect Evidence, and Understand Type I vs Type II

A prospective customer asks: ‘How do we know your cloud service protects our data?’ Sales can send a questionnaire, engineers can describe encryption, and security can share a policy. But customers increasingly need independent assurance that the service provider’s control environment is credible. SOC 2 is one way to provide it.

SOC 2 is an examination and reporting framework developed by the AICPA for service organizations. An independent licensed CPA firm examines controls relevant to one or more Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It results in an attestation report, not an ISO-style ‘SOC 2 certification’ and not a universal security maturity rating.

Why a control design is different from a control operating over time

There is no single AICPA-prescribed ‘Type II lasts exactly 12 months’ rule. The examination period is agreed in the engagement and appropriate to the needs of report users and auditors. A Type II report is not automatically ‘Level 2’ maturity; the report types describe different examination scopes.

Establish your Trust Services scope

Security is the common category included in SOC 2 engagements. The four other categories are included when relevant to the system and users’ needs:

• Availability: committed or agreed service availability.
• Processing Integrity: complete, valid, accurate, timely, and authorized system processing.
• Confidentiality: protection of information designated confidential.
• Privacy: personal-information lifecycle and relevant privacy commitments.

Security is evaluated through the Common Criteria, often referenced by CC identifiers. Do not assume that a service using encryption automatically meets every confidentiality or privacy criterion. Define commitments, system characteristics, and applicable criteria deliberately with your auditor.

The current public AICPA resources include the 2017 Trust Services Criteria with revised points of focus issued in 2022, along with the related description criteria. Proposed updates may be published for consultation before becoming effective; an exposure draft is not an adopted criterion.

Start with the system description, not an evidence collection tool

For fictional Northstar Mobility, the SOC 2 system includes its customer telemetry SaaS, production cloud tenancy, supporting employee identities, deployment process, operations, and critical subservice organizations. The system description should explain what the service does, important components, infrastructure, software, people, procedures, data, service commitments, boundaries, and relevant third parties.

Customer usersTelemetry SaaSEmployees and SSOCI/CD pipelineCloud infrastructureLogs and backupsKey service providersSOC 2 control and evidence boundary

It is crucial to identify complementary user entity controls (actions customers are expected to perform) and responsibilities of subservice organizations. The auditor may use an inclusive or carve-out treatment for subservice organizations, depending on the system description and engagement. A vendor’s SOC 2 report does not automatically prove your controls are effective.

A realistic preparation sequence

1. Assign owners and agree on the examination scope

Identify accountable executives, system owners, the security lead, HR, IT operations, engineering, support, and the external CPA firm. Select Trust Services Categories appropriate to contractual commitments. Define which environments, products, locations, and processes are included.

2. Build a control matrix

Map each control to the actual criteria and the company’s policies. The table is a planning sample, not a substitute for the full AICPA criteria.

3. Run a readiness assessment

Determine whether policies are formally approved, each control has an accountable owner, evidence exists, and artifacts can be traced to the reporting period. Check representative samples of changes, terminations, incidents, access reviews, and supplier evaluations. A readiness assessment is not itself a SOC 2 examination.

4. Operate and retain time-based evidence

For a Type II examination, it matters that controls operated across the agreed period. A screenshot captured on the final day does not prove a monthly review occurred earlier. Retain approved tickets, system exports, time stamps, samples, reviewer sign-offs, and exceptions. Protect the evidence repository with least privilege and appropriate retention.

5. Support independent testing and remediation

The CPA firm chooses its procedures and samples. Internal teams should make records retrievable, explain control owners and dependencies, and openly disclose control failures. If a quarterly review was missed, do not recreate a misleading backdated approval; document the exception and corrective action.

6. Review the report before customer distribution

Read the auditor’s opinion, system description, testing results, noted exceptions, reporting period, relevant subservice organizations, and complementary user entity controls. SOC 2 reports are normally intended for specified users rather than unrestricted public distribution; SOC 3 provides a different general-use reporting format.

Hands-on lab: Test whether recurring evidence is complete

Use the following evidence_check.py with Python 3. This synthetic example checks whether a monthly control has one dated artifact per period. It does not assess control effectiveness.

required_periods = {"period_01", "period_02", "period_03"}
artifacts = [
    {"control": "access_review", "period": "period_01", "approved": True},
    {"control": "access_review", "period": "period_02", "approved": True},
    {"control": "change_review", "period": "period_01", "approved": True},
    {"control": "change_review", "period": "period_02", "approved": True},
    {"control": "change_review", "period": "period_03", "approved": True},
]

for name in ("access_review", "change_review"):
    observed = {
        a["period"] for a in artifacts
        if a["control"] == name and a["approved"]
    }
    missing = sorted(required_periods - observed)
    print(f"{name}: {'missing ' + ', '.join(missing) if missing else 'all periods represented'}")
Code language: PHP (php)

Run python3 evidence_check.py or py -3 evidence_check.py. The access review control is missing period_03. Investigate whether the review occurred but the record is missing, or whether the control failed to operate. These are different findings and require different actions.

What credible evidence looks like

A strong change-management sample includes the requested change, risk or impact information, approval by an authorized reviewer, testing, deployment identity, release timestamp, and linkage to the production event. A strong access-review sample includes the population reviewed, reviewer’s decision, exceptions, and proof that inappropriate access was removed.

A generic policy saying ‘All changes are approved’ is design evidence. A collection of approved and tested real changes is operating evidence. Both are relevant in different ways to the examination.

Mistakes that repeatedly derail SOC 2 work

• Treating SOC 2 as a software installation or purchasing a compliance platform without a control design.
• Claiming ‘SOC 2 certified’ instead of accurately describing the issued report.
• Beginning a Type II period before processes operate consistently.
• Failing to define the system boundary and subservice organization responsibilities.
• Collecting snapshots but not evidence across the examination period.
• Confusing completion of a checklist with the independent auditor’s examination opinion.

Questions to test your understanding

Q: Can an access policy alone establish operating effectiveness over a reporting period? A: No. The auditor needs appropriate evidence that the described control operated.

Q: Is Type II a higher maturity tier than Type I? A: No. They describe different examination time bases and scope.

Q: Who issues the SOC 2 attestation report? A: An appropriately qualified independent CPA firm, not the service provider itself.

Official references

• AICPA SOC suite and criteria: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
• AICPA Trust Services Criteria: https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
• AICPA SOC 2 reporting guide: https://www.aicpa.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.