Skip to main content

​
Getting Started with SOC 2

SOC 2 (System and Organization Controls 2) is the security framework US enterprise customers expect from SaaS vendors. A SOC 2 report — issued by a licensed CPA firm — attests that your organization’s controls around security, availability, processing integrity, confidentiality, and privacy meet AICPA Trust Services Criteria. Matproof maps the SOC 2 Common Criteria (CC) and selected additional criteria to your controls, evidence, and policies so you can prepare for audit without a spreadsheet.
Activate SOC 2 under Settings → Frameworks → SOC 2. Your control set (~60 controls mapped to the 33 Common Criteria) will be pre-populated. You can add criteria for Availability, Confidentiality, and Privacy separately.

​
SOC 2 Type I vs. Type II

Type IType II
What it attestsControls are designed appropriately at a point in timeControls operated effectively over a review period (typically 3-12 months; 6+ months recommended)
Audit duration2-4 weeks3-6 months observation period + audit
What customers wantProof you have controls in placeProof controls work consistently
When to pursueFirst SOC 2, fast-track optionRequired by enterprise customers
Target Type I first if you need a report quickly. Many enterprises will accept Type I while you accumulate the observation period for Type II.

​
The 5 Trust Services Criteria

CriteriaWhat It CoversRequired?
Security (CC)Logical and physical access, change management, risk, incident responseAlways required
Availability (A)System uptime, performance, disaster recoveryOptional — add if customers require it
Processing Integrity (PI)Complete, accurate, and timely data processingOptional — relevant for payment processors
Confidentiality (C)Protection of confidential informationOptional — common for B2B SaaS
Privacy (P)Collection, use, and disposal of personal informationOptional — relevant if you process PII
Most SaaS companies start with Security only. Add Availability and Confidentiality for enterprise deals.
1
Step 1 — Define your system description
2
Every SOC 2 report opens with a System Description — a document written by management that describes what your system does, the infrastructure it runs on, and the controls in place.
3
Document the following in your Settings → Context Hub:
4
  • What your product does and what data it processes
  • Cloud infrastructure (AWS, GCP, Azure regions and services)
  • Subservice organizations (Stripe, Twilio, Okta — services you rely on that have their own controls)
  • Boundaries of the in-scope system
    • 5
    Your auditor uses this to scope the audit. Be specific and accurate — discrepancies between the description and the actual system are findings.
    6
    Step 2 — Select your Trust Services Criteria
    7
    In Settings → Frameworks → SOC 2, choose which criteria apply to your system. Start with Security (Common Criteria) unless your customers explicitly require others.
    8
    The controls list will update to reflect your selected criteria.
    9
    Step 3 — Complete Common Criteria controls
    10
    The Common Criteria (CC1-CC9) cover nine control categories. Work through them in this order:
    11
    CategoryFocusKey ControlsCC1 — Control EnvironmentTone from the top, code of conduct, org structurePolicy approvals, org chartCC2 — Communication and InformationInternal and external communicationSecurity awareness trainingCC3 — Risk AssessmentIdentify and analyze risksRisk registerCC4 — Monitoring ActivitiesEvaluating whether controls are present and functioningManagement reviews of control effectiveness, internal audit activitiesCC5 — Control ActivitiesPolicies, procedures, and technology controlsAccess reviews, change managementCC6 — Logical and Physical Access ControlsAccess provisioning, MFA, authenticationAccess logs, offboarding evidenceCC7 — System OperationsIncident detection, vulnerability management, and responseIncident log, vulnerability scans, monitoring toolsCC8 — Change ManagementCode review, deployment controlsGitHub branch protection, CI/CDCC9 — Risk MitigationBusiness disruption response and vendor/partner risk managementVendor assessments, BCP
    12
    CC6 (Logical and Physical Access Controls) and CC8 (Change Management) are where most findings occur. Connect your GitHub and identity provider integrations early so evidence is collected automatically.
    13
    Step 4 — Generate and approve policies
    14
    SOC 2 auditors check for documented policies covering:
    15
  • Information Security Policy
  • Access Control Policy
  • Change Management Policy
  • Incident Response Policy
  • Vendor Management Policy
  • Business Continuity and Disaster Recovery Policy
    • 16
    Go to Policies → Generate and generate all SOC 2 policies. Customize them to match your actual environment, assign owners, and mark them Approved.
    17
    Step 5 — Connect integrations for automated evidence
    18
    SOC 2 evidence collection is heavily focused on access control, change management, and monitoring. Connect these integrations to automate evidence:
    19
    IntegrationEvidence It ProvidesGitHubBranch protection rules, PR review logs, deployment historyGoogle Workspace / OktaUser access lists, MFA enforcement status, admin logsAWS / GCP / AzureConfiguration checks, IAM policy snapshots, CloudTrail logsVanta / Drata-style auto-testsContinuous control testing
    20
    Go to Settings → Integrations to connect your tools.
    21
    Step 6 — Run access reviews
    22
    CC6 requires periodic access reviews — evidence that you regularly check who has access to what and remove inappropriate access.
    23
  • Go to People → Access Reviews
  • Initiate an access review for each critical system
  • Document approvals and removals
  • Set a recurring schedule (quarterly is typical for SOC 2)
    • 24
    Step 7 — Accumulate observation period evidence (Type II only)
    25
    For Type II, your auditor reviews evidence over a 3-12 month observation period. This means controls must operate consistently, not just be in place at audit time.
    26
    Track:
    27
  • Regular access review completions
  • Incident log entries (even if zero incidents — document that monitoring was active)
  • Change management records (PRs reviewed, deployments approved)
  • Vendor assessment records
    • 28
    Step 8 — Readiness assessment
    29
    Before engaging a CPA firm, run a readiness assessment:
    30
  • Go to Audit Programs → New Audit → SOC 2 Readiness
  • Work through the control checklist
  • Document gaps as Corrective Actions
  • Close corrective actions before the formal audit begins
    • 31
    Most CPA firms offer a readiness assessment as a paid service — doing it internally in Matproof first saves significant cost.

    ​
    Evidence Checklist

    These are the most commonly requested evidence items in a SOC 2 audit:
    Control AreaEvidence to Collect
    Access ControlUser access list exports (quarterly), MFA enforcement screenshots, offboarding tickets
    Change ManagementPR review history, deployment approval records, code freeze policies
    Incident ResponseIncident log, post-mortem documents, escalation procedure
    Vendor RiskVendor risk assessments, SOC 2 reports from key subservice orgs
    Background ChecksEmployee background check policy and completion records
    EncryptionEncryption at rest/in transit documentation, key management policy
    Vulnerability ManagementPenetration test report, patch cadence records
    Business ContinuityBCP document, DR test results

    ​
    Common Audit Findings

    ​
    1. No formal offboarding process

    The most frequent CC6 finding. “We remove access when people leave” is not sufficient — auditors want a ticket or checklist showing the exact steps taken for each departure.

    ​
    2. Access reviews not completed on schedule

    Committing to quarterly reviews in your policy and then having no evidence of review completion in the audit period is an immediate finding.

    ​
    3. Subservice organization SOC 2 reports not reviewed

    SOC 2 best practice requires you to obtain and review your key subservice organizations’ SOC 2 reports regularly (typically annually). Stripe, AWS, and your identity provider all publish these. Document that you have reviewed them.

    ​
    Next Steps

    • Evidence Collection — connecting integrations and automating evidence uploads
    • People Module — employee records, access reviews, and offboarding checklists
    • Vendor Risk — managing subservice organizations and requesting their SOC 2 reports
    • Audit Programs — running your SOC 2 readiness assessment