A Type II engagement, from scope to bridge letter.
Define the system and its boundaries, map the Trust Services Criteria to your controls, test them across the observation period and hand the service auditor a complete package, with the registers behind the controls kept once in your ISMS.
Supported in
- Book with Jakarta (WhatsApp)
Indonesia · Whitesec ID, Jakarta
For Indonesian service organisations whose customers ask for a SOC 2 report.
- Book with Perth (WhatsApp)
Australia · Whitesec AU, Perth
For Australian and New Zealand service organisations whose customers ask for a SOC 2 report.
About the standard
A SOC 2 report is an independent service auditor's attestation on the controls at a service organisation, measured against the AICPA Trust Services Criteria. Security, the Common Criteria, is always in scope; availability, confidentiality, processing integrity and privacy are added when your commitments to customers require them.
A Type I report looks at the design of controls at a point in time. A Type II report also tests whether they operated effectively across an observation period, and that is where most of the work lies: sampling, exceptions, management responses and the evidence behind each.
What the workspace does
Readiness in eight stages
System description, risk assessment, control design, evidence, observation period, operating effectiveness, PBC requests and complementary controls, each Ready, Gaps or Not started with its next step, and pacing that warns when testing falls behind the period.
System description in DC 200 order
Versioned sections for services, commitments, system boundaries and components, incidents, criteria not relevant and significant changes, with the DC5 to DC7 counts drawn from scope and complementary controls, approved by a second person.
Control matrix with coverage
Controls mapped to criteria with their owner, run frequency, test procedure and design conclusion, and a coverage grid that flags any criterion with no control behind it.
Sampling from the control's frequency
Sample sizes are planned from how often a control runs, from one sample for an annual control to 30 for a daily one at moderate reliance. Every sample must fall inside the period, and the sizes are planning defaults to agree with your service auditor.
Exceptions with management responses
Every exception carries management's response and can raise a corrective action on the shared register, with a readout of the unremediated exceptions and the criteria they affect.
Fieldwork and bridge letters
PBC requests with owners, due dates and a note thread that the Auditor role accepts or rejects; complementary user entity controls and subservice organisations, carve-out or inclusive; and bridge letters that show how many days are uncovered today.
How the workspace runs it
Group by group, in the order the application presents them, with the pages each group contains.
- 01
Engagement
Report type and engagement mode, the categories in scope, the system description in DC 200 order, and the data flow, network, organisation and process diagrams behind it.
- Scope and categories
- System description
- System diagrams
- 02
Criteria and controls
Each criterion with its status, owner and the points of focus your organisation writes, the control matrix, and the evidence library measured against the Common Criteria.
- Trust Services Criteria
- Control matrix
- Evidence
- 03
Type II testing
Observation periods, samples by method (random, systematic, haphazard, judgmental or full population) and the exceptions they produce.
- Testing and sampling
- Exceptions
- 04
Shared registers
Risk assessment, vendors, security incidents, policies, access reviews and change management, read from the ISO 27001 registers and mapped to the criteria they evidence.
- Risk assessment
- Vendors
- Security incidents
- Policies and procedures
- Access reviews
- Change management
- 05
Audit
Service auditor engagements and their opinion, PBC requests, complementary controls, bridge letters, and a management working package with the assertion, system description, controls, tests and exceptions.
- Service auditor engagements
- PBC requests
- Complementary controls
- Bridge letters
- Reports
Controls built into the workspace
Rules the application enforces, so the records stand up when an auditor tests them.
- A second person approves each system description and every bridge letter before it is issued.
- A sample's reviewer must differ from its tester, and every sample must fall inside its observation period.
- Only one observation period can be active at a time.
- Security criteria always stay in scope; excluding any other criterion needs a written reason, disclosed under DC8.
- The Auditor role can change only the status and notes of PBC requests.
What you hand the auditor
- System description (DC 200) and diagrams
- Control matrix and criteria coverage
- Samples and test results by period
- Exceptions with management responses
- PBC request list
- Bridge letters
- Management working package
Shared with the other workspaces
Risk assessment, vendors, security incidents, policies, access reviews and change management are read from the organisation's own ISO 27001 registers and mapped to the criteria, so nothing is kept twice.
Questions about SOC 2
Does it cover Type I as well as Type II?
Yes. For Type I the period is a single date and the control matrix records the design conclusion, with no sampling.
Are the AICPA criteria and points of focus included?
The 61 criteria are identified by their AICPA references with short titles. The AICPA's own wording and points of focus are not reproduced; you write your points of focus against each criterion.
Does Whitesec One produce the SOC 2 report?
No. The report and its opinion come from your service auditor. The package Whitesec One prepares is a management working paper, with the auditor's report left as a placeholder.
See your own registers in Whitesec One.
We walk through the workspaces for the frameworks you need, with the team in Jakarta or Perth.