SOC 2 scope emulator
Flip your promises on and off and watch the SOC 2 scope move.
Every SOC 2 scope grows out of what you have promised clients. This sandbox lets you test that on a made-up business or on your own: switch on a contract term, a kind of data or a group of people, and the panel shows which Trust Services Categories come in, which sample controls follow, and which outside rules SOC 2 leaves alone. Use the result as a sketch for a scoping meeting. It is not your scope.
Back to SOC 2 services01 · The sandbox
Try a business, then make it yours
Your switches are written into the page address, so anyone you send the link to opens the same view.
01 Start from an example business
Each example only presets the switches below. Change any of them afterwards.
02 Flip the switches
The five groups track what a system description has to account for: promises, information, people, code and hosting.
02 · Reading the output
Three things the right-hand panel tells you
Categories first, then controls, then the side notes that point outside SOC 2.
- The category list
- A tick means one of your promises brought that category in. Security carries a Required tag because the common criteria sit in every report, whatever else you pick.
- The control groups
- Sample controls filed under the criteria series they usually support, from CC1 through the Privacy series. Open a group to see each control with its criteria reference.
- The side notes
- Short warnings that appear when a switch drags in something SOC 2 does not settle, such as card numbers and PCI DSS, or medical records and HIPAA.
The figure at the top counts categories and controls. A bigger number is not a worse result. It mostly reflects how many promises you have made and how many routes people have into the system.
03 · The rules
Why one switch adds a category and another only adds controls
Only the first group moves categories. The other four shape the controls.
| Category | Switch that brings it in | Contract wording that usually signals it |
|---|---|---|
| Security | None: present in every report | Any undertaking to protect the service at all |
| Confidentiality | Secrecy terms covering client material | A clause defining a client's confidential information and how you must keep it |
| Privacy | A privacy notice given to end users | A notice telling individuals what you collect, why, and when you delete it |
| Processing Integrity | Results clients act on | Accuracy or timeliness undertakings on payouts, totals or reports you generate |
| Availability | A published availability target | An uptime percentage, service credits or a public status page |
Information, people, code and hosting follow the parts of a system that a system description must account for under the AICPA description criteria. On their own they never add a category. They add the controls an auditor would look for in that setup: a check that one client cannot read another's records when tenants share a database, or laptop encryption when staff work from home.
Medical records do not switch on Privacy, and card numbers do not switch on Processing Integrity. The commitment decides, never the data type. A ticketing site that stores card numbers but promises nothing about its calculations stays outside Processing Integrity.
04 · Worked example
Illustrative: the invoice and payout platform, switch by switch
One of the example businesses, read the way a scoping meeting would read it.
- Picking the example turns on secrecy terms, payout results and an availability target, so Confidentiality, Processing Integrity and Availability join Security.
- Ledgers and card numbers are on. Card numbers raise a PCI DSS note, because a SOC 2 opinion is silent on card-industry rules.
- Engineers with owner rights add a control for requesting elevated rights task by task, a pattern auditors often pick for testing.
- Switching off the payout promise drops Processing Integrity and its two reconciliation controls, even though ledgers stay on. That is the commitment rule at work.
What a real scoping session adds
The sandbox cannot read your contracts. In readiness, someone goes through the order forms, the master agreement and any public status page, lists each promise and the category it lands in, and settles disagreements before the CPA firm sees a draft system description.
05 · Limits
What the sandbox will not tell you
Five gaps to keep in mind before quoting its output to anyone.
- Treating its controls as a standard. The AICPA publishes criteria and points of focus. Controls are yours to design, so the list here is one set of examples among many workable ones.
- Assuming it knows your boundary. It cannot tell which products, regions or teams you leave out. Those choices live in the description and change what gets tested.
- Skipping the subservice decision. A cloud host shows up as a note, but whether it is carved out or included is agreed with the CPA firm.
- Reading the notes as legal views. The HIPAA and PCI notes flag that another regime applies. They do not say how it applies to you.
- Mistaking it for readiness. No record is checked. Whether a control actually runs is only known once its evidence is looked at.
Sources: AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022); AICPA, DC 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report; AICPA SOC suite of services pages. The controls in the sandbox are Auditify's own examples.
Using the sandbox
Does the sandbox keep what I enter?
Only in the address bar of your own browser.
Nothing leaves your device. The chosen example and every switch are written into the page address, so a bookmark or a shared link reproduces the view. Close the tab without keeping the link and the setup is gone.
Why does Security show as required with every switch off?
The common criteria belong to every SOC 2.
The common criteria, CC1 to CC9, make up the Security category, and every SOC 2 examination covers them. The other four categories are layered on top, one at a time, as your promises call for them.
Can I hand this output to our auditor?
Use it to open a conversation, not as a deliverable.
The CPA firm forms its own view from your system description and management's assertion. A screenshot can help a first scoping call by showing which promises you believe you make, but it carries no weight as evidence.
Where do the criteria references next to each control come from?
The 2017 Trust Services Criteria.
Each sample control shows the criterion it most often supports, such as CC6.1 for logical access. Real mappings vary: one control can support several criteria, and a firm may map yours differently.
Ready to swap the sketch for a real scope?
A SOC 2 readiness assessment reads your contracts and system, settles each category and maps your own controls to the criteria.