If you sell to enterprise customers or you're working toward SOC 2 certification, someone is going to ask how you manage the security of your vendors. Third-party risk management (TPRM) is no longer a nice-to-have. It's a control area that SOC 2 auditors test directly, and it's increasingly a line item in enterprise security questionnaires before a deal closes.
The problem is that most companies don't have a program. They have a spreadsheet nobody updates, a folder of vendor contracts nobody reads, and a vague sense that "IT handles that." Building a real third-party risk management program from zero doesn't have to take months, but it does need to happen in order. Here's how.
Step 1: Inventory every vendor that touches your data
You can't manage risk you haven't identified. Start by listing every third party with access to your systems, your customer data, or your network. This includes obvious ones like your cloud provider and payment processor, but also the tools people forget: the analytics platform, the recruiting software, the contractor who has a VPN login, the SaaS app a team signed up for without telling IT.
Pull this list from a few sources at once: your finance system (anyone you pay monthly or annually is a candidate), your single sign-on provider (anyone with an SSO integration), and a short survey to department heads asking what tools their team uses. Cross-reference all three. You will find vendors in one list that don't appear in the others, and that gap is exactly where risk hides.
Realistic timeline: one to two weeks for a company under 100 employees, longer if procurement is decentralized.
Step 2: Tier vendors by the risk they actually pose
Not every vendor needs the same scrutiny. A vendor that stores or processes customer data, has access to production systems, or could take you down if they go offline deserves a deep review. A vendor that only has your marketing team's email address does not need the same treatment.
A simple three-tier model works for most companies:
- Critical: access to customer data, production infrastructure, or systems in your SOC 2 scope
- Moderate: access to internal but non-sensitive data, or a service that would cause real disruption if it failed
- Low: everything else, no data access, easily replaced
This tiering decides how much work each vendor gets in the next steps. Trying to run the same deep assessment on every vendor is how TPRM programs die under their own weight, and it's the single most common mistake we see companies make when they build this in-house for the first time.
Step 3: Assess before you sign, not after
For critical and moderate vendors, request evidence of their security posture before the contract is signed. In practice that means asking for a SOC 2 report, an ISO 27001 certificate, or, if the vendor is smaller and doesn't have either, a completed security questionnaire covering encryption, access controls, incident history, and subprocessors.
Read what you get. A SOC 2 Type II report with exceptions noted in the auditor's opinion is different from a clean one, and the "complementary user entity controls" section tells you what you're responsible for on your end. Don't just file the PDF, actually review it against your risk tier.
If a vendor can't produce anything, that's a data point, not necessarily a dealbreaker. Small or early-stage vendors sometimes just haven't built the paperwork yet. Weigh that against how critical the access is.
Step 4: Put the risk in writing and get contractual coverage
Once you've assessed a vendor, document the risk level and any gaps you're accepting. For critical vendors, your contract should include data processing terms, breach notification timelines, and the right to request evidence of ongoing compliance. This is also where legal and security need to actually talk to each other, which is where a lot of programs quietly fall apart.
Step 5: Monitor, don't just assess once
A vendor's security posture on the day you signed the contract is not their security posture two years later. Ongoing monitoring is what separates a real program from a compliance checkbox exercise, and it's exactly what SOC 2 auditors expect to see evidence of: annual reassessments for critical vendors, tracking when a vendor's SOC 2 or ISO certificate expires, and a process for reacting when a vendor discloses a breach.
At minimum, set a calendar reminder to re-request evidence annually for critical vendors and check in on moderate ones every 18 to 24 months. If you're using a GRC platform, most of this can be automated with expiry alerts.
Step 6: Have an offboarding process
When you stop using a vendor, access needs to be revoked and data deletion needs to be confirmed, not assumed. This step gets skipped constantly, and it's an easy finding for an auditor to catch: a login that still works six months after the contract ended is exactly the kind of gap SOC 2 testing surfaces.
Realistic timelines
For a company with 50 to 150 vendors and no existing program, expect four to eight weeks to get inventory, tiering, and initial assessments for critical vendors done. A full program with monitoring cadences and documented processes in place typically takes two to three months. Companies trying to do this alongside a SOC 2 audit timeline should start TPRM work in parallel, not after, since auditors will ask for evidence of an operating process, not just a policy document.
Where a partner helps
The steps above are straightforward individually. What actually eats time is the volume: reading dozens of SOC 2 reports, chasing vendors who don't respond to questionnaires, and keeping the whole thing current while running the rest of the business. This is where teams either burn weeks of internal time or bring in outside help to run the assessments and keep the program current.
If TPRM is one piece of a broader push toward SOC 2 or a wider compliance program, it's worth looking at it as part of that bigger picture rather than a standalone project. Our compliance advisory work covers third-party risk alongside the rest of the controls an auditor will test, so vendor assessments don't end up as a disconnected side project.
If you're building a third-party risk management program and want a second set of eyes on your approach, or you'd rather hand off the assessment work entirely, get in touch and we'll walk through where your program stands and what's realistic for your timeline.