Revenue and contract access
Large customers add SOC 2 to procurement checklists. Without a report, deals slow down or never reach signature.
Board and leadership view
Why SOC 2 matters to your board
The work is technical. The consequences of getting SOC 2 wrong show up in revenue, liability and reputation, which is why we report on it in the language of the boardroom first.
Liability and regulatory exposure
Customer contracts often carry security warranties. Documented controls and testing show you took reasonable care.
Reputation with buyers
A clean report, backed by independent testing, signals a mature supplier and shortens every later security review.
Deadlines and ownership
The observation window is fixed once it starts. Clear owners and a dated plan stop exceptions piling up inside it.
Fit
Who usually needs SOC 2
SaaS and cloud platforms
Enterprise customers add SOC 2 to security questionnaires and procurement checklists before they sign.
Fintech and payments teams
Banks and their customers expect independent proof that customer data and money movement are protected.
Managed service providers
If you operate systems or process data for clients, they will ask how you control access and changes.
Data and analytics vendors
Anyone who stores or analyses customer data is expected to show confidentiality and security controls.
Scope of work
What Summit delivers for SOC 2
One accountable team takes you from scoping to retest. The people who test your systems are the people who explain the findings to your leadership.
Gap analysis
Your current controls compared with the Trust Services Criteria, ranked by what blocks the audit first.
Penetration testing
Manual, human-led testing of the applications and infrastructure in scope, with proof of impact.
Control validation
Testing that the controls you describe operate in practice, before the auditor looks.
Evidence pack
Organised test reports, scope statements and fix records mapped to the relevant criteria.
Remediation support and retest
Guidance for engineers on each finding, then a retest and letter confirming the fixes.
Board-ready report
A plain-language summary of risk, progress and next steps for executives.
Fixed scope, one team, no hand-offsYou get a named lead, a clear scope document before work starts and a report your leadership, customers and reviewers can read without a translator. We stay with you through your review to answer questions about what we tested and found.
How it works
A realistic SOC 2 roadmap
Timelines are typical ranges, not promises. Yours depends on scope, team size and how much is already in place.
- 1
Scope the audit
Week 1Decide which categories you need and which systems and teams are in scope. Fewer, well-chosen categories mean a shorter audit.
- 2
Run a gap assessment
Weeks 2 to 4Compare your current controls with the criteria and list what is missing, from policies to access reviews.
- 3
Fix gaps and write policies
Months 1 to 3Put controls in place and make sure they leave evidence automatically, such as tickets, logs and approvals.
- 4
Test your defences
Month 2 to 3Run a manual penetration test and fix the findings, so auditors see vulnerabilities found and closed.
- 5
Observe and collect evidence
3 to 12 monthsFor a Type II report, controls must operate during the whole observation window. Keep evidence organised as you go.
- 6
Audit and report
4 to 8 weeksThe CPA firm tests your controls, asks follow-up questions and issues the report.
Deliverables
What your leadership team receives
Every engagement ends with material written for two audiences: a plain-language view for executives and the board, and full technical detail for the engineers who fix things.
An executive summary
Posture, top risks and what they mean for revenue, in a few pages.
A dated readiness roadmap
Owners, milestones and the audit window mapped to your sales calendar.
Testing evidence for the auditor
Reports and retest letters ready to hand over on request.
A remediation tracker
Every finding with an owner, severity and status you can follow.
Support through the audit
The same Summit team stays with you to answer auditor follow-ups.
The detail
What SOC 2 actually is
SOC 2 is an attestation report, not a certificate. An independent CPA firm examines the controls a service organisation has in place and gives an opinion on whether they meet the Trust Services Criteria published by the AICPA. You choose which categories are in scope, and Security is always included. Availability, Processing Integrity, Confidentiality and Privacy are optional.
There are two report types. A Type I report says your controls were suitably designed on a single date. A Type II report goes further and tests whether those controls operated effectively across an observation period, which is usually between three and twelve months. Most enterprise buyers want Type II because it shows the controls work in practice, not just on paper.
The report is private. You share it with customers under NDA, normally alongside a short summary and a bridge letter that covers the time between the end of the audit period and today.
Key terms in plain English
- Service organisation
- The company being audited, usually the SaaS or cloud provider that handles customer data.
- Trust Services Criteria
- The AICPA control objectives grouped into five categories: security, availability, processing integrity, confidentiality and privacy.
- Observation window
- The period a Type II auditor tests. Controls must operate consistently for the whole window.
- Bridge letter
- A short statement from management confirming nothing material changed between the audit period and the date you share the report.
Requirements
What auditors test, category by category
The Trust Services Criteria are written as control objectives, not as a checklist. Here is how each category translates into everyday engineering and operations work.
CC
Security: the Common Criteria, CC1 to CC9
Every SOC 2 audit includes the Common Criteria. They cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation. In practice this is where most of your policies, access reviews, logging and vulnerability management are tested.
What it looks like in practice
- Documented policies that match what the team really does
- Access is granted, reviewed and removed on a schedule, with evidence
- Changes are reviewed and approved before they reach production
- Vulnerabilities are found, tracked and fixed, including by penetration testing
A
Availability: can customers rely on the service?
Add this category if you commit to uptime or recovery targets. Auditors look at capacity planning, backups, disaster recovery and how you respond when systems fail.
What it looks like in practice
- Backups run and restores are actually tested
- A disaster recovery plan exists and has been exercised
- Monitoring and on-call alerts catch outages quickly
PI
Processing integrity: is the output right?
This category fits services that calculate, transform or move data on a customer’s behalf, such as billing engines or payment flows. Auditors check that processing is complete, valid, accurate and authorised.
What it looks like in practice
- Input validation and reconciliation checks
- Error handling and exception reports that people review
- Authorisation controls on batch jobs and data changes
C
Confidentiality: protecting information marked sensitive
Choose this category when customers send you confidential business data. It covers how you classify information, encrypt it, restrict who can see it and dispose of it.
What it looks like in practice
- Data classification and handling rules
- Encryption at rest and in transit
- Secure deletion when contracts end
P
Privacy: personal information across its lifecycle
The Privacy category applies when you collect and use personal information. It maps to notice, choice and consent, access, disclosure, quality and monitoring. It is separate from legal compliance with laws such as GDPR, although many teams reuse the same evidence.
What it looks like in practice
- A privacy notice that matches real data use
- A process to handle access and deletion requests
- Records of who personal data is shared with
Where testing fits
How penetration testing supports SOC 2
SOC 2 does not name penetration testing as a mandatory control. Auditors do, however, routinely ask for it as proof that you find and fix vulnerabilities. A manual, human-led test with a clear report and a retest is the strongest evidence you can hand them.
CC4.1
Ongoing and separate evaluations
Management must evaluate whether controls are present and working. An independent penetration test is a separate evaluation that auditors can read directly.
CC7.1
Detecting vulnerabilities
Criteria around detecting new vulnerabilities and configuration changes. Test reports show you look beyond automated scans.
CC6.6
Protection from outside threats
Boundary protection for systems exposed to the internet. External testing demonstrates how those boundaries hold up.
CC8.1
Change management
Significant changes should be tested before release. A retest after fixes shows the change process closes the loop.
Avoid these
Common SOC 2 mistakes, and how to avoid them
!
Starting the audit window too early
If controls are not operating yet, exceptions pile up inside the observation window. Run a readiness check first.
!
Treating a scanner report as a penetration test
Automated scans find known issues. Auditors and buyers want to see a human tester chain weaknesses and prove impact.
!
Scoping every category “just in case”
Each extra category adds controls to build and test. Choose the ones your customers actually ask for.
!
Collecting evidence after the fact
Screenshots gathered a week before the audit rarely hold up. Capture evidence continuously from tickets, logs and approvals.
FAQ
SOC 2 questions, answered
Is SOC 2 a certification?
No. It is an attestation report written by an independent CPA firm. There is no certificate and no pass or fail badge, only the auditor’s opinion and any exceptions they list.
What is the difference between SOC 2 Type I and Type II?
Type I checks that controls are designed properly on one date. Type II tests that they operated effectively over a period, usually three to twelve months. Enterprise buyers generally prefer Type II.
How long does it take to get a SOC 2 report?
Teams that already have solid practices can finish in a few months. Starting from scratch often takes six to twelve months once readiness work and a Type II observation window are included.
Does SOC 2 require a penetration test?
The criteria do not use those words, but auditors commonly request penetration test evidence under the monitoring and vulnerability management criteria. Most teams run at least one test per year.
Can a small startup get SOC 2?
Yes. Many early-stage companies do it to unblock enterprise deals. Keep the scope narrow, automate evidence collection and begin with Security only.
Related frameworks
Often assessed alongside SOC 2
Security assuranceISO 27001The international standard for an information security management system. Clauses, the 93 Annex A controls, and how certification works.Third-party riskVendor & TPRMHow to pass vendor security reviews faster: questionnaires (SIG, CAIQ), evidence packs and the vendor risk lifecycle.Privacy lawGDPRSeven principles, six lawful bases and the 72-hour breach clock. See how Article 32 security testing fits your obligations.
Browse all 23 security and compliance frameworks or see our penetration testing services.
Helpful resources
ChecklistPre-launch security checklistKeep reading on the Summit resources hub.ReportSample VAPT reportKeep reading on the Summit resources hub.GuideOWASP Top 10 guideKeep reading on the Summit resources hub.
Last reviewed October 2026. Requirements change; confirm current texts and dates before you commit to a plan.