SOC 1
Control objectives: the yardstick you write before anything is tested.
In a SOC 1, nobody hands you the criteria. Management drafts the control objectives, the CPA firm decides whether they are fit for purpose, and only then are controls tested against them. Weak objectives make every later step harder. This page shows how to write them, map them and defend them.
Back to SOC 2 services01 · Who writes them
Management drafts the yardstick
A SOC 2 borrows fixed AICPA criteria. A SOC 1 asks you to state what must go right.
A SOC 2 is measured against the Trust Services Criteria, a set the AICPA publishes and nobody edits. A SOC 1 has no such catalogue. Under AT-C section 320, management identifies the risks that its service creates for clients' financial statements and states, as control objectives, what its controls are meant to achieve.
That freedom cuts both ways. You can fit the objectives to the service you actually run. You also own the gaps: an objective you never wrote is a risk nobody tested, and a client's auditor will notice the hole before you do.
Objectives come first because every control in the report has to point at one. A control with no objective above it is noise; an objective with no control under it is a design gap.
02 · A sound objective
What a sound objective sounds like
It names a process, an outcome a client's books depend on, and the level of assurance.
- The process
- One class of transactions or one IT area: payroll changes, invoice generation, cash application, logical access to the billing system.
- The outcome
- The quality the client's financial statements need: authorized, complete, accurate, timely or restricted to the right people.
- The assurance level
- Objectives are framed as giving reasonable assurance, never a guarantee. That matches the examination itself.
- The boundary
- It stays inside what your service does. You cannot promise that a client's ledger is right; you can promise that what you send them is.
Illustrative wording
“Controls provide reasonable assurance that new invoices are generated only for contracted, active customers and at approved rates.” One process, two outcomes, nothing about how it is achieved. The how belongs in the controls.
03 · Objective to control
Mapping each objective to the controls beneath it
Each objective should carry enough controls to cover its outcomes, and no more.
| Control objective (illustrative) | Controls that achieve it | What kind of control |
|---|---|---|
| Payroll changes are authorized before they take effect | A client-approved change form is required for every rate or bank detail change; a second staff member checks the entry against the form | Manual, preventive |
| Payroll is calculated completely and accurately | The system applies configured tax tables; a variance report flags pay over a set threshold against the prior run and is reviewed before release | Automated plus manual, detective |
| Payroll runs in the correct period | Run calendars are locked per client; changes received after the cut-off are held for the next cycle and logged | Automated, preventive |
| Changes to payroll calculation logic are tested and approved | Code and configuration changes go through ticketed testing and a separate approver before release to production | IT general control |
| Access to payroll data and functions is restricted | Access is granted on a request approved by a manager and reviewed each quarter; leavers are removed on their exit date | IT general control |
Read the table from left to right and the logic should hold without help. If you have to explain why a control sits under an objective, it probably sits under a different one.
04 · Worked example
Illustrative: building the objectives for a payroll service
Start from what could misstate a client's payroll expense, not from the controls you already run.
- List the classes of transactions you process for clients: new hires, pay changes, regular runs, off-cycle payments, tax filings, year-end forms.
- For each, ask what could go wrong that would land in a client's books: an unapproved raise, a missed employee, a wrong tax rate, a payment in the wrong month.
- Turn each group of risks into one objective stated as an outcome.
- Add the IT objectives that protect the calculation: change management, logical access, job scheduling and data transmission to the client and the bank.
- Map the controls you run under each objective, and mark where you rely on the client or a vendor. Those become user entity controls and subservice controls.
- Ask a reviewer who does not know your system to read the objectives alone and say what a client's auditor would worry about that is missing.
05 · Common errors
Errors that weaken a set of objectives
Most are about level: too specific, too broad, or aimed at the wrong reader.
- An objective that is really a control. “A manager reviews the variance report weekly” is a control. The objective is that payroll is calculated accurately; the review is one way to get there.
- An objective too broad to test. “Information systems are secure” covers everything and therefore pins down nothing. Split it into access, change and operations.
- Objectives copied from a SOC 2. Security-flavoured statements about confidentiality or availability rarely bear on a client's financial statements, and they dilute the report.
- A process left out. Off-cycle payments or manual adjustments are often skipped because they are rare. They are also where errors hide.
- Promising the client's outcome. An objective that the client's general ledger is accurate reaches past your service. Keep to what you process and report.
06 · Suitability
How the CPA firm judges whether the objectives are suitable
Before testing a single control, the service auditor evaluates the objectives themselves.
- Relevant to clients' financial reporting. Each objective addresses a risk that could affect what clients record or disclose.
- Complete for the service described. Every significant process and IT area in the description has an objective covering it.
- Reasonable in scope. Objectives promise what the service can achieve, not more.
- Consistent with what users expect. Where an industry or a client contract sets an objective, the report includes it or says why not.
- Objectives set by others. If a regulator or user group has specified objectives for a kind of service, the auditor will expect to see them reflected.
Sources: AICPA SSAE No. 18, AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting; AICPA SOC 1 guide; AICPA SOC suite pages. All objectives, controls and the payroll scenario are illustrative.
Questions about SOC 1 control objectives
How many control objectives should a SOC 1 have?
As many as the processes need; there is no set number.
No standard fixes a count. A narrow service may need only a handful; a broad outsourcing service needs more. The test is whether every significant process and the IT areas that protect it are covered.
Can we change our objectives between reports?
Yes, with a reason a reader would accept.
Objectives should track the service. If you add a product line or retire a process, the objectives move with it. Dropping an objective because its controls failed last year is the kind of change a client's auditor will question.
Do IT objectives belong in a SOC 1?
Usually, where IT protects the numbers.
If your system calculates, stores or transmits figures that end up in clients' books, the IT general controls over that system support every business objective. Most SOC 1 reports for software-driven services include them.
Who should draft the objectives?
Management, ideally with the process owners in the room.
The people who run payroll, billing or reconciliation know where errors arise. A preparer such as Auditify can shape the wording and challenge gaps, but the objectives are management's and the CPA firm judges them independently.
Start with objectives a client's auditor would write themselves.
We help you draft and map SOC 1 control objectives to the controls you run, before the CPA firm reviews them.