> ## Documentation Index
> Fetch the complete documentation index at: https://docs.matproof.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Getting Started with SOC 2
> How to prepare for and achieve SOC 2 Type I or Type II using Matproof.
# 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 I | Type II |
| ----------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| **What it attests** | Controls are designed appropriately at a point in time | Controls operated effectively over a review period (typically 3-12 months; 6+ months recommended) |
| **Audit duration** | 2-4 weeks | 3-6 months observation period + audit |
| **What customers want** | Proof you have controls in place | Proof controls work consistently |
| **When to pursue** | First SOC 2, fast-track option | Required 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
| Criteria | What It Covers | Required? |
| ----------------------------- | ----------------------------------------------------------------------- | ------------------------------------------ |
| **Security (CC)** | Logical and physical access, change management, risk, incident response | Always required |
| **Availability (A)** | System uptime, performance, disaster recovery | Optional — add if customers require it |
| **Processing Integrity (PI)** | Complete, accurate, and timely data processing | Optional — relevant for payment processors |
| **Confidentiality (C)** | Protection of confidential information | Optional — common for B2B SaaS |
| **Privacy (P)** | Collection, use, and disposal of personal information | Optional — relevant if you process PII |
Most SaaS companies start with **Security only**. Add Availability and Confidentiality for enterprise deals.
***
## Recommended Implementation Plan
### Step 1 — Define your system description
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.
Document the following in your **Settings → Context Hub**:
* 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
Your auditor uses this to scope the audit. Be specific and accurate — discrepancies between the description and the actual system are findings.
### Step 2 — Select your Trust Services Criteria
In **Settings → Frameworks → SOC 2**, choose which criteria apply to your system. Start with Security (Common Criteria) unless your customers explicitly require others.
The controls list will update to reflect your selected criteria.
### Step 3 — Complete Common Criteria controls
The Common Criteria (CC1-CC9) cover nine control categories. Work through them in this order:
| Category | Focus | Key Controls |
| ------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------- |
| CC1 — Control Environment | Tone from the top, code of conduct, org structure | Policy approvals, org chart |
| CC2 — Communication and Information | Internal and external communication | Security awareness training |
| CC3 — Risk Assessment | Identify and analyze risks | Risk register |
| CC4 — Monitoring Activities | Evaluating whether controls are present and functioning | Management reviews of control effectiveness, internal audit activities |
| CC5 — Control Activities | Policies, procedures, and technology controls | Access reviews, change management |
| CC6 — Logical and Physical Access Controls | Access provisioning, MFA, authentication | Access logs, offboarding evidence |
| CC7 — System Operations | Incident detection, vulnerability management, and response | Incident log, vulnerability scans, monitoring tools |
| CC8 — Change Management | Code review, deployment controls | GitHub branch protection, CI/CD |
| CC9 — Risk Mitigation | Business disruption response and vendor/partner risk management | Vendor assessments, BCP |
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.
### Step 4 — Generate and approve policies
SOC 2 auditors check for documented policies covering:
* Information Security Policy
* Access Control Policy
* Change Management Policy
* Incident Response Policy
* Vendor Management Policy
* Business Continuity and Disaster Recovery Policy
Go to **Policies → Generate** and generate all SOC 2 policies. Customize them to match your actual environment, assign owners, and mark them **Approved**.
### Step 5 — Connect integrations for automated evidence
SOC 2 evidence collection is heavily focused on access control, change management, and monitoring. Connect these integrations to automate evidence:
| Integration | Evidence It Provides |
| ---------------------------------- | ----------------------------------------------------------- |
| **GitHub** | Branch protection rules, PR review logs, deployment history |
| **Google Workspace / Okta** | User access lists, MFA enforcement status, admin logs |
| **AWS / GCP / Azure** | Configuration checks, IAM policy snapshots, CloudTrail logs |
| **Vanta / Drata-style auto-tests** | Continuous control testing |
Go to **Settings → Integrations** to connect your tools.
### Step 6 — Run access reviews
CC6 requires periodic access reviews — evidence that you regularly check who has access to what and remove inappropriate access.
1. Go to **People → Access Reviews**
2. Initiate an access review for each critical system
3. Document approvals and removals
4. Set a recurring schedule (quarterly is typical for SOC 2)
### Step 7 — Accumulate observation period evidence (Type II only)
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.
Track:
* 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
### Step 8 — Readiness assessment
Before engaging a CPA firm, run a readiness assessment:
1. Go to **Audit Programs → New Audit → SOC 2 Readiness**
2. Work through the control checklist
3. Document gaps as **Corrective Actions**
4. Close corrective actions before the formal audit begins
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 Area | Evidence to Collect |
| ------------------------ | -------------------------------------------------------------------------------------- |
| Access Control | User access list exports (quarterly), MFA enforcement screenshots, offboarding tickets |
| Change Management | PR review history, deployment approval records, code freeze policies |
| Incident Response | Incident log, post-mortem documents, escalation procedure |
| Vendor Risk | Vendor risk assessments, SOC 2 reports from key subservice orgs |
| Background Checks | Employee background check policy and completion records |
| Encryption | Encryption at rest/in transit documentation, key management policy |
| Vulnerability Management | Penetration test report, patch cadence records |
| Business Continuity | BCP 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](/features/evidence-collection) — connecting integrations and automating evidence uploads
* [People Module](/features/people) — employee records, access reviews, and offboarding checklists
* [Vendor Risk](/features/vendor-risk) — managing subservice organizations and requesting their SOC 2 reports
* [Audit Programs](/features/audit-programs) — running your SOC 2 readiness assessment