SOC 1 explained properly — control objectives, CUECs, CSOCs and carve-outs

If your service touches your customers' financial statements — payroll, billing, revenue recognition, claims, payments, fund administration — their external auditors will eventually ask for a SOC 1 report. It sounds like a sibling of SOC 2, and the controls overlap heavily, but SOC 1 works differently in three ways that matter: you write the objectives, you state what your customers must do, and you state what your own vendors are assumed to do.

This post explains each, with wording you can adapt, using a fictional payroll platform as the example.

What SOC 1 is for

A SOC 1 report (performed under SSAE 18, attestation standard AT-C 320) covers controls at a service organization that are relevant to its customers' internal control over financial reporting (ICFR). The readers are your customers' controllers and their auditors. They are not asking "is this company secure?" — they are asking "can we rely on the numbers this service produces, and what do we still have to do?"

That changes the shape of the report:

Control objectives: you write them

A control objective states what the controls achieve, not what they are: "Controls provide reasonable assurance that …". The auditor then opines on whether the controls you describe achieve the objectives you wrote.

InsightAssure ships a template set that most technology service organizations start from — 13 objectives in two groups:

• IT general controls: CO-01 logical access, CO-02 change management, CO-03 system development, CO-04 computer operations and job processing, CO-05 backup and recovery, CO-06 physical and environmental security, CO-07 data transmission and network security, CO-08 incident management, CO-09 subservice organization monitoring.
• Business process controls: CO-10 client onboarding and master data, CO-11 transaction input, CO-12 transaction processing, CO-13 output and reporting.

The business-process objectives must be rewritten around your transaction flow. For a payroll platform, CO-12 might become:

Controls provide reasonable assurance that payroll calculations are processed completely, accurately and timely in accordance with client-approved pay rates, deductions and tax configurations, and that processing exceptions are identified and resolved.

Because the objectives are the organization's own rows once adopted, you can rename, rewrite, add or exclude them, and each still maps to unified controls — PI-01 input validation, PI-02 processing monitoring, PI-03 output reconciliation, GOV-09 segregation of duties, and so on.

app.insightassure.com/frameworks/soc1

The three parties

CUECs — what your customers must do

Complementary user entity controls are controls you assume your customers operate, without which your control objectives would not be achieved. They appear in your system description, and your customers' auditors test them at the customer.

Write them as responsibilities, specific enough to be tested, and link each to the objective it complements. InsightAssure's defaults (editable) read like this:

For the payroll platform, a business-specific CUEC is often the most important one: "User entities are responsible for approving employee pay rates, deductions and changes to them before payroll is processed."

Two mistakes to avoid: CUECs that shift your own responsibility to the customer ("customers are responsible for the security of their data"), and vague CUECs no auditor can test.

CSOCs — what your vendors are assumed to do

When you rely on a vendor whose controls are necessary for your objectives — your cloud provider for physical security, a payment processor, a print-and-mail house — that vendor is a subservice organization. You have two ways to treat it:

• Carve-out (the norm for hyperscale clouds): the vendor's controls are excluded from your testing. Your report names the vendor, describes what it does, and lists the complementary subservice organization controls (CSOCs) you assume it operates.
• Inclusive: the vendor's controls are described and tested as part of your report. Rare, because it needs the vendor's cooperation.

Carve-out does not mean "ignore". Your report must show how you monitor the vendor — normally an annual review of its own SOC report — which is why the template includes objective CO-09 and the unified controls VND-03 (annual review of critical vendors) and VND-05 (subservice organization monitoring).

A well-worded CSOC is specific about the vendor and the objective it supports:

The cloud hosting provider is responsible for restricting physical access to data center facilities, backup media and other system components to authorized personnel. (CO-06)

The cloud hosting provider is responsible for the availability and integrity of the managed database and storage services' underlying replication and snapshot mechanisms. (CO-05)

Monitoring subservice organizations in practice

In InsightAssure a subservice organization is a vendor flagged is_subservice, with its method (carve_out or inclusive) and its CSOCs. Each year you add a review of kind soc_report: record the report type, the period end, the opinion, any exceptions — and the CUECs that vendor's report places on you, each mapped to one of your controls. That last step is what auditors look for and most programs skip: AWS's report assumes you manage your IAM users and enable MFA, which is your IAM-02.

app.insightassure.com/vendors/aws

Two monitors keep this honest:

• vendors.soc_reports_current fails when a subservice organization's SOC report has expired (InsightAssure sets expiry to the report's period end plus twelve months) or none is on file.
• vendors.reviewed fails when a critical or high-risk vendor has not been reviewed in twelve months.

A qualified or adverse opinion, or noted exceptions, opens an issue automatically so the follow-up is tracked.

The system description

Section III of a SOC 1 report is management's description of the system, and it is where CUECs, CSOCs and subservice organizations are written down. InsightAssure keeps it per framework with these sections: company overview, services, principal commitments, components (infrastructure, software, people, data, procedures), boundaries, subservice organizations, CUECs, CSOCs, significant changes and incidents during the period.

Draft with AI fills it from what the program already knows — connected systems, the cloud resources in the inventory, headcount by department, the subservice vendors and their CSOCs — and a model (if configured) improves the prose without adding facts. Without a model, the same draft is assembled by rule. Either way, you edit and approve it; it is management's assertion, not the tool's.

Testing: the same ITGCs, a different lens

Most SOC 1 ITGC objectives are tested with the same evidence as SOC 2: access provisioning and removal (IAM-04, IAM-07, HR-07), quarterly access reviews (IAM-05), peer-reviewed changes (CHG-02), backups and restore tests (BCP-01, BCP-02). That is why one unified control set serves both reports — test once, report twice. See One control, many frameworks.

The business-process objectives are different: they are tested by tracing transactions. An auditor may pick 25 payroll runs and check the input approvals, the reconciliation of output totals to input totals (PI-03), and the resolution of exceptions (PI-02). In InsightAssure those become a population — uploaded as CSV if the transactions live outside the integrations — sampled with a recorded seed, one request per sample.

app.insightassure.com/audits/soc2-type2/matrix

A payroll platform's first SOC 1, in outline

1. Adopt SOC 1 (and SOC 2, if security questions are also coming). Rewrite CO-10 to CO-13 around the payroll flow; delete what does not apply and record why.
2. Record AWS (and the tax-filing partner, if you rely on one) as subservice organizations, with CSOCs.
3. Write payroll-specific CUECs: rate approvals, timely changes, report reviews.
4. Close the ITGC gaps the monitors find, and set up the business-process evidence: reconciliation reports, exception logs, approval records.
5. Draft and approve the system description.
6. Type 1 if a customer's auditor needs something quickly; then a Type 2 period aligned with your customers' fiscal years — many SOC 1 readers want a period ending near their own year end.

← All posts   Request a demo