For a small payroll provider, SOC 1 starts with the payroll work customers rely on. Can you explain how authorized information becomes complete and accurate payroll output? Can you show how errors are found and resolved?
Build the control program around that cycle. Security matters, but a collection of security policies will not explain whether payroll processing works.
Start with the right report and service boundary
SOC 1 addresses controls relevant to customers’ financial reporting. It is different from SOC 2 and its Trust Services Criteria. A payroll provider may need both, but one report does not automatically cover the other’s purpose.
Describe exactly what your service does. Some firms calculate payroll and send reports. Others also submit payments or handle tax filings. Do not imply that the report covers activities you do not perform.
- Identify the products and customer arrangements included.
- Trace inputs through calculation and output.
- Identify the systems and outside providers involved.
- Explain which checks remain with the customer.
- Agree the proposed scope and reporting period with the CPA firm.
Management is responsible for the control objectives and the controls used to achieve them. The CPA firm evaluates the report’s subject matter; it does not take over management’s job. The examples below help structure your thinking rather than supply a standard set of objectives for every payroll business.
Give each part of the cycle an owner
Name a person responsible for payroll operations and a backup who can cover critical steps. Assign the technology controls to someone with the necessary skills. Have management review unresolved issues and recurring errors.
Where possible, separate preparing a sensitive change from approving it. If your team cannot separate every duty, identify the specific risk and arrange meaningful alternative oversight. A second person signing without checking is not a useful control.
1. Accept authorized customer instructions
Know who may submit changes for each customer and how you verify their authority. Define the information needed for processing and the cutoff for receiving it.
- Control example: Operations checks incoming changes against the customer’s authorized submission process before processing.
- Evidence: The approved submission and the result of input checks. Record rejected or incomplete instructions and their resolution.
A correctly calculated payment can still be wrong if the starting rate or bank details were unauthorized. Document where the customer must verify inputs and what your team checks independently.
2. Control standing data and calculation rules
Pay rates and deduction settings can affect more than one run. Restrict who can change them. Review changes to calculation rules and system configuration before relying on them.
- Control example: An authorized reviewer checks a sensitive setup change against its supporting instruction.
- Evidence: The change record, review and effective date. For software changes, link the test result to the release.
Test representative results when a rule changes. Include the cases that matter to your service. Do not assume that a vendor update needs no review merely because someone else supplied it.
3. Account for the records processed
Reconcile what you received with what the system accepted and produced. Define the checks needed for completeness and accuracy. Counts and totals are useful, but neither proves every field is correct.
- Control example: The operator reviews batch results and investigates unexplained differences before releasing affected output.
- Evidence: The batch reference, comparison and follow-up on exceptions.
A rejected item needs an owner. A retry needs a check for duplicates. Keep corrections connected to the original run so another person can follow what happened.
4. Review and release the right output
Decide which results need customer approval and which your team approves. If you transmit payment instructions, distinguish approval of the payroll figures from authorization to release the payment file.
- Control example: Output is reviewed and released by authorized people under the agreed customer process.
- Evidence: The reviewed version, approval and delivery or submission result.
When payments are part of your service, check returns and rejected submissions. Sending a file does not establish that every payment settled. When tax filing is part of the service, include the relevant submission and exception process. Tailor these controls to your actual responsibilities.
5. Maintain the systems behind the cycle
The processing checks depend on trustworthy systems. Include the supporting technology controls that matter to the financial-reporting objectives.
- Limit access to payroll data and administrative functions.
- Remove access when it is no longer needed.
- Review and test relevant system changes.
- Monitor failures that could interrupt or alter processing.
- Protect records and test recovery of the required payroll service.
Keep access records and change evidence alongside their normal workflows. A recovery test should establish whether the next payroll run can be completed, not merely whether a server starts.
6. Manage outside providers and customer responsibilities
Your software host or payment partner may perform important work. Identify those dependencies and the controls your service relies on. Review relevant provider evidence and follow up on gaps.
Be explicit about the customer’s part. For example, the customer may need to approve employee information before submission. Tell customers how to perform those steps and how to report problems.
Discuss how outside services will be described in the report with your CPA firm. Do not suggest that your examination tested a provider’s controls when it did not.
7. Keep the program running between audits
- Each run: Complete the input, processing and release checks. Resolve exceptions.
- When something changes: Reassess a new product, provider or processing method.
- At defined review intervals: Check access, recurring errors and overdue corrective work.
- Before the next report: Confirm that the system description still matches operations.
Set review timing around processing risks and commitments. There is no single schedule that fits every payroll provider.
Use a short control list: objective, owner, procedure, timing and evidence location. Preserve enough records for the agreed examination period. Keep sensitive payroll data in protected storage rather than duplicating it into a general compliance tracker.
Prepare for examination without rebuilding the operation
Agree whether a Type 1 or Type 2 report meets the need. Type 1 addresses design at a specified date. Type 2 also addresses operating effectiveness over a period. Keep contemporaneous evidence instead of recreating approvals later.
Report control failures honestly. Record their effect and the corrective action. A successful rerun does not erase the original error or demonstrate that the underlying problem was fixed.
The reporting framework is explained in AICPA AT-C section 320. The operating examples here are not a complete audit checklist or tax-compliance manual. Your objectives need to fit the service and the customers’ financial-reporting needs.
For one specific part of the cycle, see checking bank-detail changes. For help defining the broader program, discuss your SOC reporting needs.