Compliance guide
SOC 2 for operations teams: what it is, what auditors ask for, and how to stay ready
This is a plain-English guide maintained by ihubb for operations, HSE and compliance leads preparing for their first SOC 2 report — or trying to keep an existing one clean between audits. It's educational content, not legal, audit or certification advice.
What SOC 2 actually is
SOC 2 is a reporting framework from the American Institute of CPAs (AICPA). An independent CPA firm examines how your service organisation designs and operates controls against the AICPA's Trust Services Criteria, then issues a report your customers can rely on.
SOC 2 is not a certification and there is no pass/fail badge. The output is a written opinion — "unqualified" if the auditor is satisfied, "qualified" or worse if not.
Type 1 vs Type 2
Type 1
A point-in-time report. The auditor confirms your controls are designed appropriately as of a single date. Faster and cheaper — a common first step.
Type 2
An observation-period report, usually 3–12 months. The auditor tests that your controls actually operated effectively over the whole window. This is what most enterprise customers ask to see.
The five Trust Services Criteria
You choose which criteria are in scope for your report. Security is always included; the others are added based on what you commit to customers.
Security (required)
Systems and data are protected against unauthorised access, disclosure and damage. The only criterion every SOC 2 report must cover — often called the 'common criteria'.
Availability
Systems are available for operation and use as committed. Relevant when you offer SLAs or run customer-facing infrastructure.
Confidentiality
Information designated as confidential is protected. Relevant when you handle NDAs, customer IP or restricted business data.
Processing integrity
System processing is complete, accurate, timely and authorised. Relevant for payments, calculations and workflow platforms.
Privacy
Personal information is collected, used, retained, disclosed and disposed of per your privacy notice. Relevant when you process consumer PII.
Evidence auditors typically request
The exact list depends on your scope and auditor, but expect to be asked for most of the following. Every item needs a date and an owner.
- Signed acceptable-use, security and confidentiality policies for every employee and contractor
- Onboarding and offboarding checklists with dated approvals
- Access reviews showing who has admin rights to production systems, reviewed quarterly
- Background-check records where legally permitted
- Security-awareness training completions per person, per year
- Vendor / subprocessor list with data-processing agreements and review dates
- Change-management tickets linking code changes to approvers
- Incident response runbook and evidence of at least one tabletop test
- Backup and restore test evidence
- Vulnerability scan and patch cadence records
A realistic first-audit timeline
- Weeks 0–4 — Scope. Decide which criteria are in scope, which systems and which people. Write it down; the auditor will hold you to it.
- Weeks 4–10 — Policies and controls. Draft and approve the policies your controls will point at. Every policy needs an owner, a review cadence and a signed acknowledgement from staff.
- Weeks 10–16 — Readiness assessment. Walk through every control with your auditor, identify gaps, remediate.
- Type 1 report or start the observation window. A Type 1 report can be issued now; a Type 2 needs the observation window to elapse first.
- Observation window (3–12 months). Controls must operate continuously. This is where evidence tracking makes or breaks the report.
- Fieldwork and report. The auditor samples evidence from across the window, writes the report, issues an opinion.
Where ihubb fits in
ihubb won't write your SOC 2 report — that's your auditor's job. What it does is keep the evidence trail continuously current for the people-, supplier- and asset-related controls, so a request for evidence takes minutes instead of days.
One record per person, supplier and asset
Every certificate, policy acknowledgement and training completion is attached to the entity it belongs to — so pulling evidence for an auditor is a filter, not an archaeology dig.
Expiry tracking with dated evidence
Certificates and reviews carry issue and expiry dates. The audit log records who uploaded what, when — the timestamped trail auditors expect.
Automated supplier reviews
Annual reviews go out on a rolling schedule, escalate if suppliers don't respond, and store the returned documents against the supplier record.
Role-based access
Admin, manager, contributor and viewer roles are enforced in the database, not just the UI — evidence for the access-control controls under CC6.
Exportable audit log
Every create, update and close-out is recorded with actor and payload. Export the log for the audit window and hand it to your assessor.
Common mistakes we see
- Treating SOC 2 as a document exercise rather than an operational one. Auditors sample evidence from across the whole window — not a folder assembled the week before.
- No single owner. Every control needs a named person; "the team" is not an owner.
- Access reviews that are performed but not recorded. If it isn't dated and signed, it didn't happen.
- Subprocessor list that lags reality. Any vendor touching customer data belongs on the list, with a DPA on file.
- Waiting until fieldwork to chase expired training and expired supplier accreditations. By then the observation window has already recorded the gap.
Get audit-ready with ihubb
Start a 30-day free trial. Import your people, suppliers and assets, let ihubb read your certificates, and watch the evidence trail build itself.
This page is maintained by ihubb as educational content. It is not legal, audit or certification advice, and does not imply ihubb, your workspace, or any linked service is SOC 2 attested. Speak to a licensed CPA firm about your specific report.