CyberWave

SOC 2

SOC 2 is an opinion someone signs, not a certificate you hang up.

SOC 2 is an attestation engagement. A licensed CPA firm examines the system you describe, tests the controls you designed against the Trust Services Criteria, and issues a report with an opinion in it that you share with customers under a confidentiality agreement. Security is mandatory. The other four criteria categories are a scoping decision with real cost attached. Sentinel is where the criteria mapping, the controls, the owners and the evidence live while the observation window runs.

Book a walkthroughCompare the frameworks

Self-service signup opens shortly — we will set you up in the meantime

FrameworksSentinel interface, reproduced

SOC 2 (Trust Services)

In scope
  • SOC 2 (Trust Services Criteria)71% ready
    45 criteria in the catalogue
Criteria
45
mapped to controls
Register
26
controls, four frameworks
Needs evidence
6
controls

Criteria mapped onto your own controls, each with an owner, a status and attached evidence. Figures are from the example workspace used throughout this site; Northstar Manufacturing Ltd. is fictional, and 71% ready is a readiness position rather than an audit opinion.

45
Trust Services Criteria mapped onto one control register
5
Criteria categories. Security is the common criteria and is mandatory
4 of 5
Report sections written by you, not by the auditor
71%
Criteria ready in the example workspace — readiness, not an opinion

The deliverable

What is actually in the document, and who writes each part.

Worth knowing before you buy one, because four of the five sections are written by you rather than by the auditor — and the section that separates Type I from Type II is a section that either exists or does not.

I
Independent service auditor’s reportCPA firm
The opinion, on the CPA firm’s letterhead, two or three pages long. It names the criteria in scope, the type of examination, and — for a Type II — the exact period covered. This is the part your customer’s security reviewer reads first and sometimes only.
II
Management’s assertionYou
Your own written statement that the system description is accurate and the controls were suitably designed, and for a Type II that they operated effectively. You sign this. It is the reason a SOC 2 is an attestation rather than an inspection.
III
The system descriptionYou
Written by you, against the AICPA description criteria. Infrastructure, software, people, procedures and data; the boundary; the criteria in scope; subservice organisations and how they are treated; and the complementary user entity controls your customers have to operate at their end. Usually the longest section and the one that takes the most drafting.
IV
Tests of controls and results — Type II onlyCPA firm
The auditor’s procedures, control by control, with the result of each test and any deviations written out. A Type I has no Section IV at all, which is the whole difference in one line.
V
Other information provided by managementYou, unaudited
Optional, and not covered by the opinion. This is where a management response to a deviation or a roadmap commitment goes. Reviewers know it is unaudited.

Structure

Five criteria categories, and only one is compulsory.

The Trust Services Criteria describe outcomes. They do not hand you a control list, which is the single biggest difference from ISO 27001 Annex A or the CIS Safeguards — and the reason two companies with the same report can look nothing alike.

  • CCRequired

    Security

    The common criteria, and the only category you cannot leave out. Nine groupings: control environment, communication and information, risk assessment, monitoring activities and control activities — the five that align to the COSO components — then logical and physical access, system operations, change management, and risk mitigation.

  • A1Common addition

    Availability

    Whether the system is available for operation and use as committed. Capacity management, environmental threats, and backup and recovery that has actually been tested. Add it when you have uptime commitments in a contract, which most software companies do.

  • C1Common addition

    Confidentiality

    Whether information designated as confidential is identified, protected while retained, and disposed of when it should be. Cheaper to add than most teams expect, because much of the underlying work is already in the common criteria access controls.

  • PI1Situational

    Processing Integrity

    Whether processing is complete, valid, accurate, timely and authorised. Genuinely relevant if you process transactions, payroll, claims or calculations on a customer’s behalf. Mostly noise if you do not — and it puts your product logic in audit scope.

  • P1–P8Heaviest

    Privacy

    Notice, choice and consent, collection, use and retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement — applied to personal information. The largest addition by a wide margin, and it commits you to operating a privacy programme, not just protecting a database. Include it when a customer or a regulator has actually asked, and not to look thorough.

Each criterion is accompanied by points of focus — considerations that help you decide whether a control addresses it. Points of focus are guidance, not requirements, and treating them as a checklist is how a scope quietly doubles.

A SOC 2 report is a description of your controls that somebody independent was willing to sign their name under. The description is yours. The signature is not.

Which is why the description is where readiness work actually lands. You write the boundary, you design the controls, you argue they address the criteria — and an independent firm decides whether it will put its name to that.

The choice

Type I and Type II differ by one section.

Everything else people say about the two follows from that. Section IV is the auditor’s testing, control by control, across a period — and a Type I does not have one.

Type II
What the opinion covers
All of that, plus whether the controls operated effectively throughout a stated period.
Section IV — tests of controls
Present: the auditor’s procedures, control by control, with any deviations written out.
Observation window
Three months is a common first window; annual cycles usually cover twelve.
Time to produce
The window, then fieldwork, then several weeks to a signed report.
What a reviewer concludes
The controls were operated. This is the report almost every vendor security review is asking for.
Where it earns its keep
Everywhere else, and every year after that.
The trap
A control that started working in week ten produces deviations for weeks one to nine.
Type I
What the opinion covers
Whether the description is fairly presented and the controls are suitably designed, as at one specified date.
Section IV — tests of controls
Absent. That absence is the whole difference.
Observation window
None.
Time to produce
Weeks, once the control design is finished.
What a reviewer concludes
The controls exist and are built sensibly. Nothing about whether anyone ran them.
Where it earns its keep
One named buyer who has said it will unblock the contract while the Type II window runs.
The trap
Increasingly treated as insufficient on its own by enterprise security teams.

Reports cover a closed period, so there is always a gap between the period end date and the day a customer asks. That gap is normally covered by a bridge letter from management confirming no material change since the report — a letter, not an audited document.

Readiness path

Six steps, and step four sets the date everything else hangs off.

Readiness is the work before the examination: the description written, the criteria mapped to controls that exist, the owners named, and the evidence habit established. The examination is what happens to a programme that is already running.

  1. 01

    Decide the criteria and the boundary

    Which categories beyond Security, and which system. Ask the customer who triggered this what their vendor policy names — adding Privacy because it sounded thorough is the most expensive unforced error on this page.

  2. 02

    Write the system description

    Draft Section III early, not the week before fieldwork. Writing the boundary honestly is what surfaces the subservice organisations, the shared administrative accounts and the legacy environment nobody wanted to mention.

  3. 03

    Map the criteria to your own controls

    SOC 2 gives you criteria, not controls. You write the control, name the owner, and argue it addresses the criterion. That freedom is why readiness work here is design work rather than a shopping list.

  4. 04

    Close the design gaps, then set the window start

    A control that does not exist yet cannot be tested. Fix first, then pick the date the observation window opens — because from that date forward, every gap is a deviation with evidence attached.

  5. 05

    Operate through the observation window

    Access reviews performed on schedule, changes ticketed and approved, incidents logged and closed, training completed, vendors reviewed. Collect as you go. Reconstructing three months of evidence at the end is how deviations get written up.

  6. 06

    Fieldwork, then the report

    The CPA firm requests populations, samples them, tests, and raises queries. Expect weeks between the window closing and the signed report, then annual periods after that with a bridge letter to cover the gap when a customer asks mid-cycle.

See the readiness workflow, end to end

In Sentinel

Where the observation window is survived.

The hard part of a Type II is not the audit. It is month two of the window, when the access review was due last Friday and nobody has noticed.

Criteria mapping

Criteria you did not write, mapped to controls you did.

The common criteria and any additional categories you selected become requirements pointing at your own controls, each with a named owner. SOC 2 gives you outcomes; the control that satisfies one is a design decision, and it belongs in a register rather than in a document.

  • 45 criteria — mapped onto a register of 26 controls shared with ISO 27001, NIST CSF 2.0 and CIS v8.1
  • Named owners — 24 of 26 assigned, and the unowned ones visible instead of averaged away
  • Test schedule and findings — the date a control was last checked, which is what a population request is asking about

See the control register

ControlsSentinel interface, reproduced
Control LibraryFramework ReadinessTest ScheduleTest HistoryFindings
Operating
18
Needs evidence
6
Not implemented
2
Owners assigned
24/26
  • A.5.1Policies for information security
    Owner
    Priya Raman
    Status
    Passed
    Evidence
    Accepted
    Last tested
    28 Jul 2026
  • A.5.18Access rights
    Owner
    Priya Raman
    Status
    Passed
    Evidence
    Accepted
    Last tested
    26 Jun 2026
  • A.8.5Secure authentication
    Owner
    Priya Raman
    Status
    Passed
    Evidence
    Accepted
    Last tested
    14 Aug 2026
  • + 5 more in the workspace

Evidence

Sampling is why retrofitting fails.

The auditor picks dates across the whole window, so a quarter you skipped is visible from the outside. Evidence carries a status and an expiry date here, so a missed review shows up as expired in week six rather than as a deviation in Section IV.

  • Status and expiry — on every item: Accepted, Under Review, Pending, Expired, Missing
  • 1 expired, 1 missing — surfaced continuously in the example workspace, not reconstructed at the end
  • Contemporaneous by default — attached the day the control operated, which is the only kind of evidence sampling accepts

See evidence workflows

EvidenceSentinel interface, reproduced

Evidence status

26 controls
  • Accepted41
  • Needs Review2
  • Pending1
  • Expired1
  • Missing1

Register

Expiring first
  • Backup restore test report — Q3 2026
    Control
    A.8.13
    Owner
    Jordan Blake
    Status
    Missing
    Validity
    Due 30 Sep 2026
  • Penetration test report — external (2025)
    Control
    A.8.8
    Owner
    Priya Raman
    Status
    Expired
    Validity
    Expired 20 Jul 2026
  • Privileged account inventory
    Control
    A.8.2
    Owner
    Priya Raman
    Status
    Needs Review
    Validity
    Uploaded 4 Sep 2026
  • + 3 more in the workspace

Design gaps

A gap with a date is what lets you choose a window start.

Design gaps become assigned work in the product’s own horizons. That is what makes the window-start conversation a plan rather than a hope — you can see what is finished, what is in flight and what will not be ready.

  • Critical Now → Strategic Projects — the product’s real horizons, not a flat backlog
  • Owner and due date on every row — so the design gap and its closure sit in the same place
  • Audit engagement workspace — somewhere to keep requests, populations and the artefacts you handed over, so next year starts from a record

See executive reporting

Action centreSentinel interface, reproduced
Critical Now2Next 30 Days3Next Quarter3Quick Wins3Strategic Projects2
  • Run and document the Q3 backup restore test
    Module
    Audit
    Owner
    Jordan Blake
    Priority
    Critical
    Due
    30 Sep 2026
    Status
    Not started
  • Deploy privileged access management for shared admin accounts
    Module
    Risk
    Owner
    Priya Raman
    Priority
    Critical
    Due
    15 Oct 2026
    Status
    In progress
  • Obtain SOC 2 report from Great Lakes Logistics
    Module
    Vendors
    Owner
    Elena Kowalski
    Priority
    High
    Due
    05 Oct 2026
    Status
    In progress
  • + 2 more in the workspace

Evidence

What fieldwork asks you for.

Not exhaustive, and your control design decides the rest. But these come up in nearly every examination — and the rows marked Recurring are where sampling bites, because the auditor picks dates across the whole window rather than the ones you would choose.

EvidenceCadenceWhat fieldwork does with it
System description and boundaryFoundationalApproved by management, and matching what the environment actually looks like.
Policies, approved and communicatedFoundationalWith evidence of acknowledgement, not just a file with a version number.
Risk assessment, including fraud riskFoundationalThe common criteria ask for fraud explicitly. Most first drafts omit it.
Organisation chart and role definitionsFoundationalWho reports to whom, and who has authority over security decisions.
Onboarding and offboarding recordsRecurringAccess granted on a request, and revoked with a date you can point at.
User access reviews, production and administrativeRecurringReviewer, population, date, and what changed as a result.
Change management recordsRecurringChanges tied to an approval and a review, sampled across the whole window.
Vulnerability scanning and remediation trackingRecurringScan output plus the ticket that closed the finding.
Vendor and subservice organisation reviewsRecurringWhich providers are carved out, and what you assessed for the rest.
Backup restoration test resultsEvent-drivenOnly if Availability is in scope — and then a real restore, with a date.
Incident records and post-incident reviewEvent-drivenAn incident handled well reads better than an empty log.
Security awareness training completionTime-boundBy person and date, covering everyone who was employed during the window.
Background check recordsTime-boundFor hires inside the window, subject to what local law permits.
Management or board oversight minutesTime-boundEvidence that someone with authority reviewed security, on a cadence.

See how the evidence library handles expiry

Straight answers

Honest limitations.

Four things worth understanding before the budget is approved, and one about us.

The scope is yours to draw
You define the system boundary and select the criteria. A report can legitimately cover one product and exclude the rest of the business, so a careful reviewer reads Section III before the opinion.
It is a period, not a state
A Type II describes a window that has already closed. It says nothing about today, which is what bridge letters exist to paper over and what reviewers are right to probe.
Your customers inherit work
Complementary user entity controls are the things your customers must do for your controls to function. They are listed in the description, and they are frequently ignored by both sides.
Readiness is not an outcome
Being ready means the description is written, the controls exist with owners, and the evidence is current. The opinion remains the CPA firm’s judgement, and deviations happen.

Questions

Asked on nearly every first call.

Timelines, scope creep, exceptions, and what you are allowed to say on your website afterwards.

How long until we can hand a customer a Type II report?
Two clocks run in sequence and only the second one is negotiable. First you close design gaps, which for a small software company with reasonable engineering hygiene is commonly two to four months. Then the observation window runs — three months is the usual first window, six or twelve for a mature cycle — and only then does fieldwork begin, with several more weeks before the report is issued. Six to nine months from a standing start to a signed first Type II is a realistic plan. Anyone promising materially faster is either shortening the window to the point where buyers discount it, or has not counted fieldwork.
Is a Type I worth paying for, or should we go straight to Type II?
A Type I tests design as at a single date, so it can be produced quickly and it proves that the controls exist and are sensibly built. It does not prove they were operated, and a lot of enterprise security teams now treat it as insufficient on its own. It earns its keep in two situations: a buyer who has explicitly said a Type I will unblock the contract while the Type II window runs, and a first-time programme that wants an independent read on its control design before committing to an observation period. If neither applies, the money is usually better spent shortening your path to Type II.
Which criteria should we include beyond Security?
Start from the commitments you have already made in writing. An uptime commitment in a master services agreement argues for Availability. Contractual confidentiality obligations argue for Confidentiality, which is comparatively inexpensive to add because it leans on access controls you need anyway. Processing Integrity belongs in scope when you compute or transform something on a customer’s behalf and they rely on the result. Privacy is a programme commitment covering notice, consent, retention, access and disposal — include it when a customer or a regulator has actually asked, and not to look thorough.
Our report has exceptions in Section IV. Did we fail?
Not necessarily. Deviations are recorded factually, and the auditor forms an opinion on whether the controls were suitably designed and operated effectively overall. An unqualified opinion can coexist with recorded deviations; a qualified or adverse opinion, or a disclaimer, is a different matter. What matters commercially is how a reviewer reads the pattern: one missed access review with a documented cause and a correction is a normal artefact of an honest examination. Twelve deviations across access, change and monitoring tells a reviewer the programme is not being operated.
Can we describe ourselves as SOC 2 certified?
No, and reviewers notice. There is no SOC 2 certificate and no certifying body — the deliverable is an attestation report containing an opinion, issued to you and shared with customers under a confidentiality agreement because it describes your controls in detail. The accurate phrasing is that you have a SOC 2 Type II report covering a named period and named criteria. If you need something you can publish openly, a SOC 3 report is the general-use version of the same examination, without the detailed testing section.
Can CyberWave perform our SOC 2 examination?
No. A SOC 2 examination is performed by an independent licensed CPA firm, and CyberWave is not one. We also could not be your examiner for a programme we helped you build — independence is the reason the report carries weight with your buyers in the first place. What Sentinel does is hold the criteria-to-control mapping, the owners and the evidence through the observation window, so that when fieldwork starts the population requests are answered from a register rather than from six people’s inboxes.

Map the criteria before you book the window.

A first honest pass over the common criteria takes an afternoon and usually moves the window start date — which is cheaper to discover now than in Section IV.

Book a walkthrough

Self-service signup opens shortly — we will set you up in the meantime

  • Published pricing — no quote-on-request tier
  • No credit card required for the trial
  • No automatic charge when a trial ends
  • Tenant-isolated architecture, data stored in Canada
  • Clear data-processing terms
  • No compliance guarantee — human judgement still required