SOC 2 Type 1 vendor management: inventory, tiers and review design

For a SOC 2 Type 1, the auditor looks at whether your vendor risk controls are suitably designed as of a date. That means a written policy, a complete vendor inventory, risk tiers, an onboarding check, contract expectations, a review rule per tier and an offboarding step, with at least one real example of each in use.

What does the criterion ask?

CC9.2 states that the entity assesses and manages risks associated with vendors and business partners. Its points of focus list six habits: establish requirements for vendor and partner engagements, identify vulnerabilities arising from vendors, assess vendor risks by inventorying and tiering, assign responsibility and accountability, set communication protocols, and handle exceptions.

A Type 1 report contains no opinion on operating effectiveness, so you are not yet proving a year of reviews. You are proving the design is sound and that it exists. Build it so that it can carry into a Type 2 period without rework.

How do you build the inventory?

Merge three sources: accounts payable (everything you pay), the identity provider (every app with sign in) and engineering (cloud services, package registries, build and monitoring tools). Add free tools that touch data, since price is no guide to risk.

For each vendor record: name, what it does for you, owner, data it can see, system access it has, contract date and renewal, and whether it is a subservice dependency of your product. Keep this in a spreadsheet or tool with change history.

How do you tier vendors?

Keep it to three tiers and write the rule in one paragraph.

• Tier 1, critical: holds customer data or production access, or an outage stops your service.
• Tier 2, important: holds internal confidential data or supports key business functions, replaceable with effort.
• Tier 3, standard: no sensitive data, easy to replace.

Record the tier and the reason. Tiering drives everything else, so an auditor reading your policy will check that the drivers are clear.

What should onboarding and contracts include?

Before a vendor gets data or access, require an owner to complete a short intake: purpose, data types, access needed, alternatives considered. Then match diligence to tier.

• Tier 1: obtain assurance evidence such as a SOC 2 report, ISO certificate with scope, or a recent penetration test summary, plus a security questionnaire if the evidence is thin. Review it and write a short memo.
• Tier 2: collect a questionnaire or public security documentation.
• Tier 3: check the terms of service and privacy terms.

Contract terms to look for: confidentiality, security obligations, breach notice timing, sub-processor transparency, data return and deletion at exit, and audit or assurance rights where proportionate. If you handle personal data as a processor, your own customers may require flow down terms.

When a vendor cannot meet a requirement, record an exception: the gap, compensating controls, approver, expiry date. Exception handling is one of the points of focus.

How often do you review?

Write a rule per tier, for example Tier 1 yearly, Tier 2 every two years, Tier 3 at renewal. The AICPA does not prescribe frequencies, so choose ones you will actually keep. Add triggers: a vendor incident, an acquisition, a major scope change.

What about offboarding?

On exit: revoke access and keys, confirm data return or deletion in writing, remove the vendor from the inventory with a date and reason. Many programs forget this, and it is an easy design point to get right.

What does the auditor look at in a Type 1?

Typically: the vendor management policy, the inventory, the tier definitions, a completed onboarding intake for a recent vendor, a vendor assurance review memo, a template contract or the clauses, an exception record or the exception procedure, and a statement of who owns the program. Have one concrete example per step ready, because a design that has never been used is hard to show as suitable.

What mistakes should you avoid?

• An inventory built from memory, which misses free tools and engineering services.
• Tiers defined by spend rather than data and access.
• A policy that promises reviews you cannot staff.
• No named owner. CC9.2 expects assigned responsibility.
• Collecting SOC 2 reports without reading the scope, exceptions or user entity controls.
• Treating a vendor's certificate as a replacement for your own risk judgement.

What to do

1. Write a one to two page vendor policy covering inventory, tiers, onboarding, contracts, reviews, exceptions and offboarding.
2. Build the merged inventory and mark tiers.
3. Assign an owner and a backup.
4. Create the intake form and run it on two recent vendors to produce examples.
5. Review your Tier 1 vendors' assurance reports and write memos.
6. Add vendor clauses to your contract checklist.
7. Calendar the review cycle so the process runs into your Type 2 period.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, leaving the team time for other work. For software vendors and open source dependencies, technical evidence comes from your real code: scans, SBOMs and reachability show which third party components you rely on and which findings are reachable. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. The independent auditor issues the report. Book a call.

Sources

• AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criterion CC9.2 and the Type 1 description. Paraphrased, copyright AICPA.

Last reviewed: 18 October 2026.