SOC 1
Your controls, seen from a client's financial statements.
A client's auditor cares about your service for one reason: some of the numbers in the client's books pass through your hands. That makes parts of your operation part of their internal control over financial reporting (ICFR). This page explains which of your controls that pulls in, and which it leaves alone.
Back to SOC 2 services01 · ICFR in plain words
What internal control over financial reporting means
The checks a company relies on so that its accounts can be trusted.
Every company that publishes accounts relies on routines that stop errors getting in and catch the ones that do: approvals, reconciliations, reviews, system rules. Together these are its ICFR. The goal is not perfect books, it is books free of material misstatement, meaning errors large enough to change a reader's view.
For US-listed companies, section 404 of the Sarbanes-Oxley Act makes ICFR a reporting duty: management assesses it each year and, for larger filers, the external auditor reports on it too. Private companies face a lighter version through their financial statement audit, but the questions about outsourced processing are much the same.
02 · Why the auditor looks at you
Why a client's auditor looks past the client to you
If you process their transactions, your controls sit inside their control system.
When a client outsources payroll, billing, investment custody or loan servicing, the routines that protect those figures run at the service organization, not at the client. The client's auditor still has to understand and, often, rely on them.
The auditing standards for user auditors, AU-C 402 for most private-company audits and the PCAOB's AS 2601 for audits of public companies, direct the auditor to understand how a service organization affects the client's controls. A SOC 1 Type 2 report is the usual way to give them that evidence without each auditor visiting you.
03 · Follow the transaction
Follow one transaction from start to ledger
The controls that matter sit wherever a number can go wrong on its way through you.
- Initiation. A client sends an instruction: a new employee, a sales order, a trade. Is it genuine and approved?
- Input. Someone or something records it in your system. Is every instruction captured, once, correctly?
- Processing. Your system calculates: gross to net pay, interest, fees. Is the logic right and unchanged?
- Output. You send a report, a file or a payment. Does it match what was processed, for the right period?
- Recording. The client posts it to the ledger. That step is theirs, and often relies on a check they run on your output.
04 · Assertion to control
From assertion to control
Auditors think in assertions: claims the accounts implicitly make. Each one points at a kind of control.
| Assertion | What could go wrong at the provider | Illustrative provider control |
|---|---|---|
| Occurrence and authorization | A payment or charge is processed that the client never approved | Instructions accepted only from authorized client contacts through an authenticated channel |
| Completeness | A valid transaction is dropped or a file is partly loaded | Record counts and control totals compared between the received file and the processed batch |
| Accuracy | Rates, tax tables or formulas produce wrong amounts | Rate table changes approved and checked; automated recalculation test on a sample of outputs |
| Cut-off | A transaction lands in the wrong month or year | Period calendars locked per client; late items held and logged for the next period |
| Classification | An amount is coded to the wrong account or category | Mapping tables maintained under change control and reconciled after updates |
| Integrity of the calculation | Program logic is changed without testing | Change management with testing and separate approval before release |
05 · IT general controls
The IT general controls that protect the calculation
If the system does the arithmetic, the auditor needs reasons to trust the system.
- ITGC.1Change managementChanges to code, configuration and rate tables are requested, tested, approved by someone other than the developer, and traceable to a ticket.
- ITGC.2Logical accessAccess to the application and its database is approved, limited to roles that need it, reviewed periodically and removed promptly.
- ITGC.3Privileged accessAdministrator and database rights are few, named and logged, so nobody can quietly alter data or logic.
- ITGC.4Job scheduling and operationsBatch jobs run when scheduled, failures are detected and resolved, and reruns do not duplicate transactions.
- ITGC.5Data transmissionFiles to and from clients and banks arrive complete and unaltered, with failures followed up.
- ITGC.6Backup of financial recordsRecords needed to reconstruct a period can be restored, so a failure does not lose transactions.
06 · What counts
Which controls matter, and which seldom do
The test is always the same: could a failure here misstate a client's accounts?
Usually relevant
- Authorization of client instructions
- Input completeness checks and reconciliations
- Calculation logic and rate table changes
- Period cut-off and run calendars
- Access to the application and its data
- Reports you send clients for their own reviews
Seldom relevant on their own
- A penetration test result, unless a finding exposed financial data to change
- Uptime of a marketing website
- Office physical security, where no financial records are kept
- Privacy notices and consent handling
- Security awareness training as a stand-alone item
Seldom does not mean never. A security weakness that let someone alter payroll data would matter a great deal. The question is the path from the control to the numbers.
Sources: AICPA SSAE No. 18, AT-C section 320; AICPA SOC 1 guide and SOC suite pages; Sarbanes-Oxley Act of 2002, section 404; AICPA AU-C section 402, Audit Considerations Relating to an Entity Using a Service Organization; PCAOB AS 2601, Consideration of an Entity's Use of a Service Organization. Controls and scenarios are illustrative.
Questions about ICFR and SOC 1
Do we need to know accounting to run a SOC 1?
You need to know where your service touches the numbers.
You do not have to be an accountant. You do need to trace which figures in clients' books depend on your work, and what could make them wrong. Your process owners usually know this better than anyone.
Our clients are private companies. Does ICFR still apply?
Yes, through their financial statement audit.
SOX section 404 applies to US public companies, but any audited company has controls over financial reporting and an auditor who needs to understand them. A private client's auditor still applies a user auditor standard to your service.
Should our SOC 1 include security controls at all?
Those that protect financial data and logic, yes.
Access, change and operations controls protect the integrity of what you process, so they belong. Broader security topics with no path to the numbers belong in a SOC 2 instead.
Will a client's auditor test our controls themselves?
Sometimes, if no suitable SOC 1 exists.
Without a SOC 1, an auditor may ask to perform procedures at your premises or rely on other evidence, and each client's auditor may ask separately. A Type 2 report lets many auditors use one examination.
Trace your service to your clients' numbers.
We map your processes to financial statement assertions and the controls that protect them, ready for a CPA firm's SOC 1.