SOC 1
Before SOC 1 fieldwork: the pack your examiner will ask for.
A SOC 1 examiner spends the first weeks learning how transactions move through your service and where they could go wrong for a customer's books. Everything it needs to learn that comes from documents you produce. This page lists them, says who usually owns each one, and explains what the CPA firm does with it.
Back to SOC 2 services01 · The first request
Why the first request list is so long
The firm must understand your transaction flows before it can judge a single control.
Under AT-C section 320, the service auditor has to understand the system, decide whether management's control objectives are suitable, and then plan tests. None of that can start from interviews alone. The firm wants written flows, a list of controls tied to objectives, and lists of real transactions to sample from.
Our SOC 2 preparation guide covers security evidence in general. A SOC 1 pack is different in one way that shapes everything else: it is organised around the classes of transactions that end up in your customers' financial statements, and the IT systems that process them.
Who does what
Auditify helps you assemble and test this pack. The examination itself is carried out by a licensed CPA firm, which decides what evidence it accepts and issues the report.
02 · Narratives and flowcharts
One narrative and one flowchart per transaction class
Written so a stranger could trace a transaction from input to customer report.
Take an illustrative payroll provider. Its transaction classes might be employee set-up, pay-rate changes, the payroll calculation, statutory deductions and remittance, and the journal file it sends each customer for the general ledger. Each class gets its own narrative and its own flowchart.
- Process narrative
- How a transaction is initiated, authorised, recorded, processed and reported, in plain sentences, naming the people and systems at each step and how errors are caught and corrected.
- Flowchart
- The same flow drawn as boxes and hand-offs. Mark each key control on the drawing with its matrix ID so the examiner can see where it sits.
- Key reports
- Any report a control relies on, such as an exception listing. Expect the examiner to ask what makes you sure it is complete and accurate.
- Interfaces
- Files in and out: customer uploads, bank files, ledger exports. Show what checks each file passes on arrival.
Write the narrative from what staff actually do. If the drawing shows a review that happens only when someone remembers, the walkthrough will expose it.
03 · Control matrix
The control matrix ties every control to an objective
One row per control. The examiner builds its test plan from this sheet.
| Column | What goes in it | Why the examiner needs it |
|---|---|---|
| Control objective | The objective the control supports, in management's wording | To check each objective has enough controls behind it |
| Control ID and description | What is done, by whom, on what | This text is what gets tested and later printed in the report |
| Nature | Manual or automated; preventive or detective | Automated controls are tested differently from manual ones |
| Frequency | Per transaction, daily, monthly, quarterly | Frequency sets the population and sample size |
| Owner | A named role, not a team | The owner leads the walkthrough |
| System | The application or job that runs or supports it | Pulls the system into IT general control testing |
| Evidence | The record the control leaves behind | Tells the firm what to request for each sample |
| Dependencies | Any CUEC or CSOC the control relies on | These become disclosures in the description |
Draft the control objectives before the matrix, not after. How to word them is covered in our guide on SOC 1 control objectives; what matters here is that every row points to exactly one of them.
04 · Populations
Populations: the lists every sample is drawn from
A sample is only as good as the completeness of the list behind it.
- Transaction lists. Every payroll run, rate change, new client set-up or settlement in the period, pulled from the system of record.
- Exception and rerun logs. Failed jobs, rejected files and manual corrections, with how each was resolved.
- Reconciliations. The full list of reconciliations performed, with preparer, reviewer and date.
- Access events. Users added, changed and removed on in-scope applications and databases.
- Changes. Program and configuration changes deployed to in-scope systems.
- How each list was produced. The query, report name and parameters, saved so the firm can re-run or observe it.
Expect the examiner to test completeness before it samples, for example by tying a run count to a scheduler log. Keep the extraction steps written down.
05 · Change and access
Change and access evidence for systems that touch financial data
IT general controls matter where a system calculates, stores or transmits figures that reach customers' books.
Usually in scope
- The application that performs the calculation or posting
- Its database and the server or platform under it
- The job scheduler that runs batch processing
- File transfer tools that move customer or bank files
Usually out of scope
- The marketing website
- Internal chat and email, unless a control runs through them
- Systems that never touch transaction data
- Sales and support tools with no write access to processing
The boundary is a judgment the CPA firm reviews. Write down why each system is in or out.
- Access: current user and privileged-user lists, joiner and leaver evidence, and periodic access reviews with sign-off.
- Change: tickets showing request, approval, testing and deployment, and evidence that developers cannot push to production alone.
- Operations: job monitoring, failure alerts and how failed runs were investigated and rerun.
06 · Vendors and assertion
Subservice reports and a draft management assertion
Two items teams leave until last, and both shape the description.
For each subservice organization, such as a hosting provider or a payment processor, collect its current SOC 1 report, check that its period overlaps yours, read its opinion and exceptions, and list the controls it expects of you. Keep a record of who reviewed it and when. That record is how you show the firm you monitor vendors rather than just name them.
Then draft the management assertion: the signed statement by management on three points: the description is a fair account of the system, the controls were well designed for their objectives, and, for a Type 2, those controls kept operating effectively across the period. Writing it early forces the description to say only what management is prepared to sign.
07 · Readiness table
The readiness table
Every item, its usual owner, and what the CPA firm does with it.
| Item | Who usually owns it | What the CPA firm will do with it |
|---|---|---|
| Scope memo: services, customers, systems, period | Head of operations with the finance lead | Agree the engagement terms and plan the work |
| Control objectives | Management, often the controller or COO | Judge whether they are suitable for user entities' financial reporting |
| Process narratives and flowcharts | Process owners | Walk through each flow and confirm controls exist |
| Control matrix | Compliance lead | Build the test plan and sample sizes |
| Population lists and extraction steps | Operations and engineering | Test completeness, then select samples |
| Access and change evidence | IT or platform engineering | Test IT general controls over in-scope systems |
| Subservice organization reports | Vendor manager | Decide carve-out or inclusive presentation and check monitoring |
| List of CUECs | Compliance lead with client services | Confirm they appear in the description |
| Draft system description | Compliance lead | Evaluate whether it is fairly presented |
| Draft management assertion | CEO or CFO | Attach it to the report and examine against it |
- A SOC 1 readiness checklistA working list to test your position before you engage a CPA firm.
- The SOC 1 system descriptionWhat the description must say, and how it is tested.
- SOC 2 audit preparationThe auditor's request list, complete populations, and a dry run before fieldwork.
Sources: AICPA SSAE No. 18, AT-C sections 105, 205 and 320, as amended; AICPA guide on SOC 1 examinations (reporting on an examination of controls at a service organization relevant to user entities' internal control over financial reporting); AICPA SOC suite of services pages. Examples are illustrative.
Questions about SOC 1 preparation
Do we need flowcharts if our narratives are detailed?
Most examiners find both useful.
Narratives explain the steps; flowcharts show hand-offs and where each control sits. Neither is mandated in a set format, but a drawing makes walkthroughs faster and gaps easier to spot.
Which systems need access and change evidence?
Those that process or store figures reaching customers' books.
Start from the transaction flows. Any application, database, scheduler or file transfer tool a key control depends on is a candidate. The CPA firm reviews your boundary, so record the reasoning.
What if one of our subservice organizations cannot provide a SOC 1 report?
Tell the CPA firm early.
The firm will consider how the vendor is presented and what other monitoring you do. A missing report is a scoping conversation, not something to hide until fieldwork.
Can Auditify write the management assertion for us?
We can help draft it. Management signs it.
The assertion is management's statement. We help shape the wording so it matches what the evidence supports; the responsibility for it stays with your leadership.
Walk into SOC 1 fieldwork with the pack complete.
We build and test your narratives, control matrix and populations before the CPA firm's first request arrives.