SOC 2 readiness, engineered not improvised.
Close the control gaps, wire up the evidence, and get the independent penetration test your auditor expects, before the observation window opens. We prepare engineering orgs to pass a SOC 2 examination with controls that genuinely operate, not a folder of screenshots assembled the week before. The report itself is issued by a separate licensed CPA firm; our job is to make sure it is a clean one.
Built for scale-ups and established engineering teams.
SOC 2 readiness earns its place when an audit deadline is real and the control set is not yet ready to survive it. These are the situations where engineering-led preparation pays for itself, whether you are a fast-growing product company chasing your first report or an established business modernising an ageing control environment.
Chasing your first SOC 2
An enterprise deal is gated on a SOC 2 report you do not have yet. You need controls designed, evidence flowing and a realistic path to Type I then Type II.
A deal is stalling on security
Procurement will not sign without SOC 2 assurance. Readiness turns a vague promise into a dated, examinable control set your buyer's security team will accept.
Controls exist but are not evidenced
You do the right things, but proving it means a scramble every audit. We wire evidence into the systems so control operation is captured continuously.
Moving from Type I to Type II
You passed a point-in-time design assessment and now face an observation window. Controls have to operate consistently, not just exist on paper.
Pairing SOC 2 with ISO 27001
You want both frameworks without doing the work twice. One control build, mapped to the Trust Services Criteria and ISO 27001 Annex A together.
Recovering from a failed run
A previous readiness attempt stalled on exceptions or missing evidence. We diagnose why the controls did not hold and rebuild the ones that failed.
Gap analysis first, then close the gaps for real.
SOC 2 is built on the Trust Services Criteria: Security (the common criteria, CC) is mandatory, and Availability, Confidentiality, Processing Integrity and Privacy are added only if they are relevant to what you do. A Type I report assesses whether controls are designed well at a point in time; a Type II assesses whether they also operated over a period. Readiness closes the distance between where your controls are today and what an auditor will examine. It does not make you certified: it makes the examination pass.
Principles we hold to on every readiness engagement.
- We scope the criteria honestly. Only the trust categories that apply to your service are in scope, so you are not building controls for data you never touch.
- Technical controls come first, then the policies and processes that sit alongside them, so evidence describes something that is actually true.
- Evidence is automated wherever the platform allows, so control operation is captured continuously rather than reconstructed before the audit.
- Every control has a named owner. An unowned control is an exception waiting to happen in the Type II window.
- We are honest about the timeline. Readiness closes gaps and prepares you; the audit and the report are the work of a separate licensed CPA firm, not us.
What a SOC 2 readiness engagement covers.
Gap analysis
A control-by-control assessment against the Trust Services Criteria in scope, turned into a ranked, prioritised remediation plan with owners and effort.
Technical control build
The engineering work itself: access control, change management, logging and monitoring, vulnerability management, encryption, backups and DR, wired into your stack.
Evidence automation
Control operation captured from the systems that already run it, so the audit is a query against existing evidence rather than a fire drill.
Control ownership
A control matrix mapping each Trust Services criterion to its owner, its evidence source and its cadence, so nothing drifts during the observation window.
Independent penetration test
The CC7.1 evidence auditors expect, delivered by a CREST-certified team independent of your engineers. Detailed on our penetration testing for compliance service.
Audit hand-off
A pre-audit walkthrough with your team and a clean evidence package for the licensed CPA firm that performs the examination and issues the report.
Readiness sits alongside our security practice. The independent test is delivered through penetration testing for compliance and the wider penetration testing service, and the control build often rides on a cloud transformation or Kubernetes consulting engagement already in flight.
Our SOC 2 readiness process.
Four phases, planned backwards from the observation window and the audit date. The gap analysis confirms exact scope and a realistic timeline before any control work starts.
Gap analysis
Scope the Trust Services Criteria that apply, assess current controls against them, and return a ranked remediation plan with owners and honest effort.
Remediate controls
Build the technical controls and the policies alongside them, closing the gaps the analysis found, from access and change management to logging and DR.
Evidence & pentest
Automate evidence collection, assign control owners, and run the independent penetration test that evidences CC7.1 for your Type I or Type II.
Audit hand-off
Pre-audit walkthrough and a clean evidence package handed to the licensed CPA firm that performs the examination and issues the SOC 2 report.
The controls engineers actually have to build.
SOC 2 is not a shopping list of tools. The common criteria map onto concrete engineering work that has to operate and leave evidence. These are the technical controls that carry most of the weight in a readiness engagement.
Access control & least privilege
SSO, role-based access, reviewed permissions and periodic access reviews, so every account has the minimum it needs and the review is evidenced.
Change management
GitOps and reviewed pull requests as the change record: every production change is versioned, peer-reviewed and traceable, which is the control auditors want to see.
Logging & monitoring (CC7.1)
Centralised logs, alerting and anomaly detection that can actually spot a problem, plus the independent penetration test that evidences the criterion under attack. Download our SOC 2 CC7.1 Pentest Checklist & Report Sample below.
Vulnerability management
Dependency and image scanning, a tracked remediation process with SLAs by severity, and evidence that findings are triaged and closed rather than ignored.
Encryption, backups & DR
Encryption in transit and at rest, key management, and backups with tested restores and a documented, rehearsed disaster-recovery path.
Secure SDLC & vendors
Security built into the development lifecycle, plus vendor and subprocessor management so the controls of the services you depend on are assessed and recorded.
SOC 2 Type II Pentest Checklist & Redacted Report Breakdown
Preparing for your SOC 2 audit window? What auditors demand under Common Criteria 7.1 (CC7.1), how testing scopes differ between Type I and Type II, and what a defensible letter of attestation looks like.
What Auditors Expect Under CC7.1
Common Criteria 7.1 requires organisations to demonstrate that they detect and monitor new technical vulnerabilities across infrastructure and application perimeters.
- Independence requirement: External testing performed by accredited practitioners independent of the build team
- Methodology alignment: OWASP WSTG, API Top 10, and NIST SP 800-115 with full manual exploitation (scanners alone fail audit rigor)
- Type I vs Type II difference: Point-in-time snapshot vs evidence of continuous vulnerability management and timely remediation over the 3–12 month observation window
- Attestation Letter essentials: Verified scope boundaries, timeline, testing credentials, and proof of remediated finding closure
Request the Redacted SOC 2 Pentest Report Sample
Get a view of the executive summary, vulnerability severity matrices, proof-of-concept formats, and the formal Letter of Attestation accepted by CPA auditing firms.
SOC 2 readiness FAQ.
What is SOC 2 readiness?
SOC 2 readiness is the work you do before an audit so that the audit can actually pass. It starts with a gap analysis against the Trust Services Criteria, then closes those gaps: building the technical controls engineers own, writing the policies and processes that sit alongside them, and wiring up evidence so control operation is captured continuously rather than reconstructed the week before. Readiness is preparation, not certification. It gets you audit-ready; the SOC 2 report itself is issued by a separate licensed CPA firm after they examine your controls.
What is the difference between SOC 2 Type I and Type II?
A Type I report assesses whether your controls are suitably designed at a single point in time. A Type II report assesses whether those controls also operated effectively across a period, commonly three to twelve months. Type I is a snapshot; Type II is a video. Most enterprise buyers eventually want Type II, so readiness is planned with the observation window in mind: we get controls designed for a Type I, then make sure they generate consistent evidence for the day the Type II window opens.
What technical controls does SOC 2 actually require from engineers?
SOC 2 does not hand engineers a checklist, but the common criteria map onto concrete engineering work: access control and least privilege with SSO and reviewed permissions, change management through version control and reviewed pull requests, logging and monitoring that can detect anomalies (CC7.1), vulnerability management, encryption in transit and at rest, backups with tested restores and a documented DR path, a secure SDLC, and vendor or subprocessor management. The point is not to buy a tool for each line but to build controls that genuinely operate and leave evidence.
Do we need a penetration test for SOC 2?
SOC 2 does not name the words penetration test, but auditors expect independent testing to evidence the criteria for detecting vulnerabilities and monitoring the environment (CC7.1). A current, independent test report is standard evidence for a Type I or Type II. We deliver that test with a CREST-certified team, independent of the engineers who built the system, and map each finding to the control in play. Our penetration testing for compliance service covers the report, letter of attestation and retest in detail.
How long does SOC 2 readiness take?
It depends on how much of the control set already exists. A team with SSO, infrastructure-as-code and reviewed deploys already has a head start; a team starting from manual access and ad-hoc changes has more to build. Gap analysis is usually a couple of weeks, remediation runs from a few weeks to a few months, and then a Type II observation window (commonly three months or longer) runs before the audit. We give a ranked, honest plan after the gap analysis rather than a fixed number up front, because a promise of readiness in a fortnight is a red flag, not a feature.
Facing a SOC 2 deadline?
Start with the readiness scorecard, or book a free 30-minute architecture call. A senior engineer reviews your controls against the Trust Services Criteria and returns a ranked, honest readiness plan.