SOC 2 is not a certification you pass on a given day. A Type II report is an opinion on whether your controls operated effectively across a window of time — usually three to twelve months. That single fact reshapes how you should prepare: the expensive mistakes are the ones baked in before the window even starts, and the way you avoid them is a gap analysis first, a penetration test early, and remediation in between.
This post walks through how a SOC 2 gap analysis and a penetration test fit together, the gaps we see most often, and how Lorikeet runs both.
Type I vs. Type II, quickly: a Type I opinion covers whether controls are designed appropriately at a point in time; a Type II covers whether they operated effectively over a period. Enterprise buyers want Type II. Everything below assumes you are heading for one.
Where a penetration test fits in SOC 2
A common misconception is that SOC 2 does not require a penetration test. Strictly, the Trust Services Criteria do not contain a line that says "perform a pentest." But three criteria effectively demand the evidence a pentest produces:
- CC3.x — Risk Assessment. You must identify and analyze risks to the achievement of your objectives. A penetration test is direct evidence that you actively look for those risks in your real environment, not just on paper.
- CC4.1 — Monitoring. You must evaluate whether controls are operating. Independent security testing is one of the strongest forms of that evaluation.
- CC7.1 — Vulnerability detection. You must detect and act on vulnerabilities. A pentest, plus a vulnerability-management process that demonstrably fixes what it finds, is the textbook answer.
Beyond the auditor, there is the buyer. When an enterprise security team reviews your SOC 2, the very next question is almost always "can we see your latest penetration test?" A SOC 2 without a current, independent pentest behind it stalls in procurement. So while the pentest is technically discretionary, in practice it is part of being SOC 2-ready.
The SOC 2 gap analysis: what it examines
A SOC 2 gap analysis maps your current state to the applicable Trust Services Criteria and tells you, control by control, where you stand. Done properly it covers four things:
1. Scope and criteria selection
Security (the Common Criteria) is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional and should be chosen based on what you actually sell and what your contracts require. The gap analysis is where you decide the system boundary — which products, environments, and supporting infrastructure are in scope — and this decision drives everything downstream, including the pentest scope.
2. Control design
For each in-scope criterion, do you have a control that would satisfy it? Access provisioning and de-provisioning, logical access reviews, change management, SDLC, encryption in transit and at rest, logging and monitoring, incident response, vendor management, risk assessment, business continuity. The gap analysis flags the criteria with no matching control — the structural holes.
3. Evidence readiness
This is where most teams lose weeks. A control that operates but produces no retrievable artifact will fail sampling. For every control, the gap analysis asks: if an auditor picks three dates at random from your window, can you produce the ticket, the approval, the log, the review record? Fixing evidence generation before the window means the artifacts accumulate automatically instead of being reconstructed under pressure.
4. Technical reality
Policies drift from production. The gap analysis validates the environment against the paperwork: is MFA actually enforced everywhere it is claimed, are S3 buckets actually private, is the patch cadence the policy promises actually happening? This is the seam between the gap analysis and the penetration test — and where the two become one workflow.
The most common SOC 2 gaps we find: no formal access-review cadence, offboarding that misses SaaS accounts, change management that lives entirely in people's heads, logging that exists but is never reviewed, a vendor list with no risk ratings, and a "we patch quickly" policy contradicted by the first vulnerability scan. None of these are hard to fix — but each is an exception if the auditor finds it first.
How the gap analysis and the pentest sequence together
The order matters, and it is the same order every time:
- Gap analysis — fix scope, map controls, test evidence readiness, and identify the structural and technical gaps. This defines the system boundary.
- Remediate the structural gaps — stand up the missing processes and evidence generation before the observation window opens, so they operate cleanly for the full period.
- Penetration test, early in the window — scoped to the systems inside the SOC 2 boundary. Running it early means any findings can be remediated and re-tested while the window is still open, so the report the auditor sees shows both the finding and its fix.
- Observation window — controls operate, evidence accumulates, monitoring runs.
- Audit — the auditor samples evidence, references the pentest as monitoring/vulnerability-management evidence, and issues the opinion.
Run the pentest at the end instead, and a serious finding becomes a vulnerability that existed, unremediated, during your reporting period — exactly the kind of thing that turns into an exception or an awkward footnote.
How Lorikeet does the gap analysis
Our SOC 2 gap analysis maps your environment to the Trust Services Criteria and grades each control on design, operation, and — the part most readiness vendors skip — evidence. We use our Attack Surface Management to inventory what you actually run (not what the asset spreadsheet claims), so the "technical reality" layer is grounded in your real, discovered footprint. You get one prioritized remediation plan: what to build, who owns it, what evidence to start generating now, and the earliest honest audit date.
How Lorikeet does the penetration test
The technical half runs on our PTaaS platform. Lory, our autonomous AI penetration tester, authenticates to your application, enumerates the surface that actually exists, sends real authenticated requests, and chains findings into attack paths — web apps, APIs, cloud accounts (AWS/Azure/GCP), mobile builds, network, and source. Every finding is countersigned by a human Lorikeet pentester before it lands in your report, with CVSS scoring and reproduction steps. The result is an independent penetration test report an auditor accepts as CC4.1/CC7.1 evidence and an enterprise buyer accepts in diligence.
Because the same team runs your gap analysis and your pentest, the two are scoped against the same system boundary and delivered as one plan — the paperwork gaps and the technical gaps closed together, with the evidence ready before the auditor asks.
If you already hold a SOC 2 that was issued through a questionable audit mill, the same workflow applies in reverse: a gap analysis to see whether your controls survive real scrutiny, and an independent pentest to replace testing whose independence is in doubt. See our writeups on how to spot a fake SOC 2 report if that is your situation.
The bottom line
SOC 2 rewards preparation and punishes improvisation, because it grades a window of time you cannot re-run. A gap analysis first tells you what to fix while fixing is still cheap and private. A penetration test early proves your technical controls actually hold — to the auditor and to the customer reading the report. Do them in that order, together, and the audit stops being a gamble.
Get SOC 2-Ready — Gap Analysis + Pentest in One Engagement
Lorikeet Security runs your SOC 2 gap analysis against the Trust Services Criteria and delivers an independent, auditor-accepted penetration test — Lory's autonomous testing countersigned by a human pentester — so both halves of your readiness land in a single coordinated plan.
