For SOC 2 Type 1, build two things: an inventory of every system, data store and vendor in scope with an owner and data classification, and a data flow diagram showing how customer data enters, moves, rests and leaves. They support criterion CC6.1 and the system description the auditor reads.
Why do auditors ask for these?
A Type 1 report describes the design of controls at a point in time and gives no opinion on operating effectiveness over a period. Even so, the auditor has to know what system the controls protect. Criterion CC6.1 includes a point of focus that the entity identifies, inventories, classifies and manages information assets such as infrastructure, software and data. The same criterion points to restricting logical access and using network segmentation, which are hard to show without a map. CC3.2 adds risk identification across the entity, which needs the same inventory as input.
The 2017 Trust Services Criteria with 2022 points of focus are the source here, paraphrased.
What goes in the asset inventory?
Use one table. Columns that earn their place:
- Name and type. Production database, source repository, laptop fleet, identity provider, payment processor.
- Owner. A named person, not a team alias.
- Environment. Production, staging, corporate.
- Data classification. Public, internal, confidential or restricted, with what the system holds.
- Location. Cloud account and region, or SaaS vendor.
- Access method. Single sign-on, key, shared login. Shared logins are findings in waiting.
- In scope for SOC 2. Yes or no, with the reason.
- Vendor and assurance. For third parties, the report you hold and its date, which feeds CC9.2 on vendor risk.
Generate what you can from sources of truth: cloud account listings, the identity provider's application list, the device management console and repository lists. A hand typed inventory goes stale in a month. Add a quarterly review step, with a signed date.
How do you draw the data flow diagram?
Draw one diagram at the level an outsider can follow. Start with the customer, then trace the data.
- Entry points. Web app, API, integrations, file uploads, support tooling.
- Processing. Services, queues, workers, and any third party processors such as an email or analytics provider.
- Storage. Databases, object storage, backups, logs, which often hold customer data without anyone remembering.
- Exit points. Exports, webhooks, support attachments, subprocessors.
- Boundaries. Draw the network and trust boundaries as boxes, and mark encryption on each arrow.
Number each flow and attach a short table: what data, how protected in transit and at rest, who can access. Keep a separate corporate diagram for staff access paths if the scope includes them.
Create it in a diagramming tool with version history, and export a dated PDF for the auditor. A diagram that shows what you plan, rather than what runs, will be caught when the auditor walks through a real request.
What mistakes do teams make?
- Leaving out logs, backups and analytics copies of customer data.
- Missing the build pipeline and source control, which hold secrets and code.
- Marking systems out of scope while they can reach in scope ones.
- Letting the diagram and the inventory disagree on names.
- No owner on the diagram, so nobody updates it after architecture changes.
What to do
- Pull system lists from cloud, identity, device and repository sources.
- Fill the table above and assign an owner to every row.
- Classify data per system and mark scope with reasons.
- Draw the data flow with numbered flows, boundaries and encryption marks.
- Walk one real customer request through the diagram with an engineer.
- Store both as dated documents and review them each quarter.
Quick check
Is an asset inventory required for SOC 2 Type 1?
The criteria do not name a spreadsheet, but CC6.1 includes identifying and inventorying information assets, and auditors ask for the evidence.
Does a Type 1 report cover a period?
No. It covers design at a point in time. A Type 2 report covers a period and includes tests of operating effectiveness.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. The software part of your inventory can be built from your real repositories and dependencies through scans and SBOMs instead of typed by hand, and monitoring keeps it current between audits, which saves the team time. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose the categories that run automatically and the approval level. The report is issued by an independent auditor. Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo
Sources
- AICPA 2017 Trust Services Criteria with 2022 points of focus, criteria CC6.1, CC3.2 and CC9.2, read from the AICPA publication
Last reviewed: 18 October 2026.