SOC 2,
continuous evidence.

Build a SOC 2 programme around the service customers actually use

A useful SOC 2 preparation starts with a boundary decision: which service, infrastructure, people and operating processes will the report cover? An ambitious control catalogue cannot compensate for a system description that leaves out a critical dependency. Start with the customer commitment, trace how it is delivered, and make the examination scope understandable to both engineers and procurement teams.

Who needs a SOC 2 report?

SOC 2 is relevant to service organisations whose customers need assurance about outsourced systems and information. Software publishers, cloud service providers and managed service businesses are common examples. It is not limited to US organisations, and there is no general statutory employee or revenue threshold that makes it compulsory.

The trigger is usually commercial: a buyer requests independent assurance, a contract requires a report, or an existing customer reviews supplier risk. Ask which service and report period the buyer expects before committing to a delivery date. A report for another product or an outdated operating period may not answer the request.

SOC 2 is an independent attestation examination, not a regulatory certification or a guarantee that incidents cannot happen. Management remains responsible for its system description, commitments and controls. An independent CPA firm performs the examination and issues the report.

Translate the criteria into operating requirements

The AICPA Trust Services Criteria address security, availability, processing integrity, confidentiality and privacy. Select categories against actual service commitments rather than treating every category as an obligatory badge. Availability matters where uptime commitments are material; processing integrity concerns whether processing is complete, valid, accurate, timely and authorised, not simply whether software is secure.

The preparation work should connect each relevant criterion to a control, an accountable owner, an operating frequency and retrievable evidence. Focus on how work happens:

• Access: authorisation, privileged accounts, periodic reviews and timely removal.
• Changes: approval, testing, release records and emergency procedures.
• Operations: monitoring, incident handling, vulnerability treatment and recovery exercises.
• Governance: risk decisions, supplier oversight, personnel responsibilities and communication.
• Information: handling rules, retention and disposal consistent with commitments.

Evidence must show execution, not just intent. A policy requiring access reviews does not establish that reviews occurred. Keep the reviewed population, reviewer, date, findings and resulting removals. Where nothing required correction, preserve the review decision rather than leaving an empty record.

Use the AICPA SOC 2 resources to distinguish the Trust Services Criteria from the separate description criteria used for management’s system description.

Plan the Type I and Type II timeline backwards

A Type I examination addresses the description and suitability of control design at a specified date. Preparation therefore needs to reach a defensible state by that date: controls implemented, responsibilities assigned and the system description aligned with reality.

A Type II examination additionally addresses operating effectiveness over a specified period. Its schedule has separate stages: readiness work, the examination period, and the auditor’s completion and reporting work. Agree the period and evidence expectations with the auditor. There is no universal preparation duration that every organisation can safely promise.

Type I is not a mandatory prerequisite for Type II. Choose the route according to customer expectations and control maturity. A Type I date cannot substitute for operating history where a customer needs a Type II report.

Do not begin the observation period while essential recurring controls exist only on paper. If a quarterly review is introduced halfway through, earlier activity cannot be manufactured afterwards. Discuss control changes, missing records and exceptions promptly with the auditor rather than silently replacing evidence.

Understand the commercial stakes

SOC 2 itself does not impose a statutory fine for lacking a report. The consequences instead arise from contracts, procurement requirements and the actual security failures that weak controls may permit. Separate legal obligations can still apply to an incident or misleading representation.

An examination can identify exceptions or result in a modified opinion. Neither should be reduced to a simplistic pass-or-fail label. Read the affected control, testing result, period and management response, then assess the implications for customer commitments.

Control report distribution deliberately. SOC 2 reports contain sensitive system and control information and are intended for specified, knowledgeable users rather than unrestricted public circulation. Establish who may receive a copy and how requests are approved.

A practical route from scope to report

1. Confirm the customer requirement. Record the service, categories, report type, expected period and intended recipients. Resolve discrepancies between sales promises and what the examination will cover.
2. Describe the system boundary. Identify infrastructure, software, people, procedures and data. Explain critical suppliers, excluded services and responsibilities that remain with customers.
3. Assess design gaps. Compare existing practices with relevant criteria and service commitments. Prioritise gaps that could prevent controls from operating throughout the intended period.
4. Assign executable controls. State who performs each activity, when it happens, how exceptions escalate and which record demonstrates completion. Avoid controls nobody can realistically maintain.
5. Rehearse evidence collection. Retrieve an access review, a release approval and an incident record. Check completeness and timestamps before relying on the collection process for the examination.
6. Run and monitor the programme. Track missed activities and remediate weaknesses. Keep historical records when systems, owners or suppliers change; document the transition rather than overwriting it.
7. Support examination and follow-through. Provide requested evidence, answer population questions and review the final report carefully. Convert findings into owned actions and establish the next reporting cycle.

Keep complementary customer controls visible. If customers must configure authentication or approve their own users, explain that responsibility clearly. Similarly, understand how outsourced infrastructure is treated in the report instead of assuming the supplier’s assurance automatically covers your application.

How Domyno supports the work

Domyno combines a SaaS platform with a dedicated human expert: agents prepare work and a human validates it. Its Controls & compliance module provides one control library across 28+ frameworks, with evidence and action plans. Teams can organise shared controls without pretending that different assurance requirements are identical.

The documentation module supports policies and version history, while supplier management and asset mapping help maintain the operational context. More than 300 connectors, including on-premises Active Directory, support connections to existing environments. Deployment can be in any cloud, any region or on premises.

Use that structure to keep ownership, evidence and remediation coordinated. Domyno supports preparation and ongoing governance; the independent auditor retains responsibility for examination procedures and the opinion. No platform can retroactively create operating effectiveness or guarantee an unmodified report.

Bring your proposed service boundary and customer requirements to a Domyno demo to discuss a practical preparation plan.