SOC 2 · TSC-MAPPED ASSESSMENT

SOC 2 Risk Assessment Services

If your SOC 2 audit is coming up in the next two or three months, you’re past the awareness stage. Your CPA firm is already engaged, or nearly so. The question now isn’t whether you need SOC 2; it’s whether your controls are documented, tested, and evidenced the way an assessor expects, or whether you’ll be pulling screenshots at 11pm the week before fieldwork starts.

Our SOC 2 risk assessment and readiness service maps your environment against the Trust Services Criteria, identifies control gaps, and builds an audit-ready evidence package your assessor can work with directly. We’ve run these engagements across SaaS platforms, FinTech companies, and healthtech teams preparing for both Type I and Type II. The pattern is consistent: organisations that arrive with a structured evidence package close their audits faster, with fewer findings.

SOC 2 risk assessments start from $4,500+. Pricing depends on TSC criteria in scope, environment complexity, vendor program maturity, and current evidence maturity. All engagements are fixed-price.

finding-excerpt.md SAMPLE
## Risk Register Excerpt — SOC 2 Readiness
# Scope: app.target.com · identity provider · vendor inventory

CRITICAL Admin Console Reachable Without MFA
CC6.6 CC6.1 SOC 2 Type II
HIGH No Documented Risk Assessment Methodology
CC3.2 SOC 2 Common Criteria
HIGH No Alerting on Anomalous Login Patterns
CC7.1 System Operations
MEDIUM Vendor Risk Register Incomplete
CC9.2 Risk Mitigation
LOW Change Management Tickets Missing Approval Trail
CC8.1 Change Management
MEDIUM Access Logs Not Retained Past 30 Days
CC6.1 CC7.2 Logging & Monitoring

What SOC 2 requires from a security assessment

SOC 2 doesn’t prescribe specific technical tests the way PCI DSS does. What it requires is documented evidence that your organisation has identified risks, designed controls to address them, and for Type II, operated those controls consistently over a defined period.

The Trust Services Criteria that drive security testing requirements are CC3 (Risk Assessment), CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC9 (Risk Mitigation). CC3.2 requires a documented risk assessment process with identifiable methodology. CC6.6 requires evidence that logical access is controlled and monitored. CC7.1 requires that threats from outside the system boundary are actively detected and evaluated. CC9.2 requires documented vendor risk management.

None of these are satisfied by running a scanner and saving the output. They require analyst judgment, policy review, control testing, and a traceable remediation record.

Why a vulnerability scanner does not satisfy SOC 2

A scanner produces a ranked list of CVEs. That’s useful for patch prioritization but it isn’t a risk assessment under SOC 2’s terms. A CPA firm examiner reviewing your evidence file will look for: a defined scope and system boundary, a documented assessment methodology, control testing that extends beyond surface-level detection, and a risk register showing deliberate decisions about identified gaps.

Our web application penetration testing and internal network assessments use manual testing techniques that automated tools won’t surface; business logic flaws, authentication bypass paths, misconfigured SSO configurations, and privilege escalation routes that exist between your documented controls and how they behave in production. That distinction matters to your assessor. It also matters to enterprise procurement teams reviewing your SOC 2 report who know what “automated scan only” means in a controls narrative.

How the assessment works

We begin with a scoping call to define the TSC criteria in scope, the system boundary, your primary third-party vendors, and your current evidence maturity. This runs 60–90 minutes and produces a written scope confirmation before any billable work starts.

From there, we review your policy and procedure documentation against the applicable criteria, test technical controls across identity and access management, logging, encryption, change management, and endpoint configuration, and build a risk register that maps findings to TSC criteria with severity ratings, remediation ownership, and target dates.

If penetration testing is in scope, either as a standalone pentest engagement or integrated into the readiness assessment, those findings feed directly into the risk register and evidence catalog, so you’re not managing two separate deliverables.

The final readout covers where you stand against Type I requirements today and what the Type II observation window needs to look like operationally.

What your SOC 2 auditor will actually look for

CPA firms conducting SOC 2 examinations; Schellman, Coalfire, A-LIGN, or your regional firm, verify two things: that your controls are designed appropriately (Type I) and that they’re operating effectively over a defined period (Type II). Specifically, your examiner will want:

Written policies that clearly reference each applicable TSC criterion, not generic “we have a security policy” documentation, but criteria-mapped controls with defined ownership and review cadence. System-generated logs showing controls are active, not just described. A risk register demonstrating that identified issues were addressed or formally accepted with documented rationale. Evidence that changes moved through an auditable change management process.

What examiners are not looking for is perfect security. They’re verifying documented intent, consistent operation, and traceable decision-making. That’s exactly what a structured risk assessment produces, and what an undocumented scanner output doesn’t.

SOC 2 evidence package: what you receive

Every engagement delivers the following named artifacts.

DELIVERABLE

SOC 2 risk assessment report

Executive summary plus technical findings section, written to be handed directly to your CPA firm. Includes methodology, scoping rationale, and findings narrative with remediation recommendations. Typically 30–60 pages depending on scope.

DELIVERABLE

TSC control matrix

Your controls mapped to CC3, CC6, CC7, and CC9 (plus Availability, Confidentiality, or Privacy criteria if in scope), with current design status, evidence reference, and gap identification for each criterion. Delivered as a structured spreadsheet compatible with common GRC platforms.

DELIVERABLE

Risk register

Each identified risk with severity classification, assigned owner, remediation recommendation, and target completion date. Format aligns with what your auditor will expect to cross-reference during fieldwork.

DELIVERABLE

Evidence catalog

A curated inventory of what your auditor needs and where to retrieve it: access control screenshots, MFA enforcement logs, change management tickets, vendor agreements, encryption configuration exports, and incident response logs. Each item includes format requirements and source instructions.

DELIVERABLE

Gap remediation roadmap

Prioritised by audit impact, with Type I design milestones clearly separated from Type II operational requirements. Links to our Remediation services if implementation support is needed.

DELIVERABLE

Type II observation plan

If you’re heading toward Type II, this documents which controls need to be monitored, at what cadence, and what evidence needs to be collected during the observation window. Most CPA firms require a six to twelve-month window.

You can review a sample report before committing to scope.

Timeline expectations

A Starter engagement, gap review through risk register, delivers in two to three weeks from scoping call to final report. Professional engagements that include technical control testing run three to five weeks depending on environment complexity and your team’s availability for the evidence review sessions.

For Type I, starting eight to twelve weeks before your target report date gives you enough runway to address high-priority gaps before fieldwork. For Type II, the observation period typically runs six to twelve months, so earlier starts mean earlier certification. If your audit is already scheduled within eight weeks, contact us first, we’ll assess what’s realistic and prioritise the evidence gaps most likely to generate findings during fieldwork.

Pricing

TierStarting priceBest forKey inclusions
StarterFrom $4,500+Early SOC 2 planning and clear gap identificationTSC mapping and gap analysis (defined criteria scope) · control and evidence checklist · risk register with severity ratings and remediation roadmap · security questionnaire support notes · executive summary
ProfessionalFrom $8,500+Type I readiness outputs and complete evidence workflowsEverything in Starter, plus: technical controls review; SSO/MFA, logging, SDLC pipelines, endpoint (defined scope) · policy alignment documentation · evidence workflow and collection guidance · one follow-up readiness call prior to fieldwork
EnterpriseFrom $14,000Complex environments or Type II programs requiring full program planningEverything in Professional, plus: expanded vendor risk and incident response review · Type II evidence planning covering the agreed observation period · stakeholder-ready reporting package · optional monthly check-ins during observation window

Note for early-stage teams: a SOC 2 Readiness Sprint is available from $3,500+ for organisations at early planning stage with limited evidence maturity. See Pricing for full scope details.

Frequently asked questions

Do I need penetration testing for SOC 2?

SOC 2 doesn’t mandate penetration testing the way PCI DSS Requirement 11 does. However, CC7.1 requires evidence of threat detection from outside the system boundary, and many CPA examiners expect to see manual security testing that goes beyond automated scanning, particularly for organisations pursuing Type II with Availability or Confidentiality criteria in scope. If your environment processes sensitive customer data, a penetration test materially strengthens your evidence package and removes a common auditor query before it’s asked.

What’s the difference between a SOC 2 risk assessment and a readiness assessment?

A risk assessment evaluates your environment against the TSC and produces a risk register identifying gaps and their severity. A readiness assessment evaluates whether you’re prepared for the audit itself, meaning controls are documented, evidence exists in the right format, and no critical gaps remain. In practice we combine both: you get the risk output and the readiness verdict in a single engagement, so you’re not paying for two separate scoping exercises.

How far in advance should I start?

For Type I, eight to twelve weeks before your target report date gives enough runway to close high-priority gaps before your CPA firm begins fieldwork. For Type II, the observation period itself takes six to twelve months, the sooner you establish operating controls and start collecting evidence, the sooner you can certify. If your audit is already imminent, reach out directly; we’ll tell you what’s achievable in your timeframe.

Can we leverage our existing ISO 27001 or HIPAA controls?

Often yes. There’s significant overlap between SOC 2’s CC6 and ISO 27001 Annex A access controls, and HIPAA’s Technical Safeguards align closely with the Security criterion. We document what carries over, what needs to be reformatted for SOC 2 evidence, and what genuine gaps remain. Cross-framework leverage typically reduces both scope and cost.

What does the deliverable actually look like?

The risk assessment report is 30–60 pages with findings written in plain language that a non-technical stakeholder can follow and a CPA firm can work with directly. The TSC control matrix is a structured spreadsheet. Evidence catalog items are individually itemised with retrieval instructions. The risk register is formatted for import into GRC tools. You can review a sample report before making any commitment.

Tell us where you are in your SOC 2 cycle

Whether you’re preparing for your first Type I or already running the observation window toward Type II, we’ll scope what’s needed and quote it without the back-and-forth.

Looking to fix gaps? Visit SOC 2 Remediation Services.

Scroll to Top
Pentest_Testing_Corp_Logo
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.