How to Get Third-Party Risk Management: A Step-by-Step Guide

If you sell to enterprise customers or you're working toward a SOC 2 report, 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.

Designing a questionnaire vendors will actually complete

The default failure of step three is sending a 200-question spreadsheet to a twelve-person vendor and waiting six weeks for silence. Response rate is a design problem. A questionnaire that takes a vendor thirty minutes comes back; one that takes their engineering lead two days goes to the bottom of a queue and stays there.

Build two versions. The short one, for moderate-tier vendors and for critical vendors who already have a SOC 2 you can read, is about fifteen questions: where the data is hosted and in which regions, whether data is encrypted in transit and at rest, how employee access to customer data is granted and removed, whether MFA is enforced on administrative access, whether they have had a security incident affecting customer data in the last 24 months, who their subprocessors are, how long they retain data after termination, whether they run penetration tests and how often, and who to contact in an incident. Ask for the incident contact as a role and a monitored address, not a person's name, because people leave.

The long version only goes to critical vendors with no third-party attestation at all. Even then, tell them up front that a current SOC 2 Type II or ISO 27001 certificate replaces the questionnaire entirely. Half of them will produce one they simply had not thought to send.

Two mechanical details raise completion sharply. Send it with a deadline and a named internal owner rather than a shared inbox, and offer a 20-minute call as an alternative to writing answers, then transcribe the call yourself. Vendors who will not fill in a form will often talk for twenty minutes, and your notes from that call are legitimate evidence as long as you record the date, the participants, and what was said.

What to do when a vendor gives you nothing

You will hit vendors who have no report, no certificate, and no intention of answering. The wrong responses are to drop it silently or to block the purchase on principle. The right response is a documented decision.

Start by asking what you can verify without their cooperation. Their public trust page, their status page history, their published subprocessor list, whether they have had a disclosed breach, whether their authentication supports SSO and MFA, and what permissions their integration actually requests. That last one is often the most informative and nobody checks it. An analytics tool asking for full read access to your production database is a bigger finding than any questionnaire answer.

Then decide what compensating controls reduce the exposure. Limiting the data the vendor receives, scoping their API token to the minimum, putting their integration behind a service account you can revoke in one action, or agreeing not to send certain fields at all. Write the residual risk down with the reason, the compensating controls, the person who accepted it, and a review date. An auditor is not looking for a program where every vendor is perfect. They are looking for evidence that risks were identified, evaluated, and accepted by someone with the authority to accept them.

The evidence an auditor will ask you to produce

Teams often build a reasonable program and still get a finding, because they cannot evidence that it operated. Auditors test populations and samples, so think in those terms from day one.

Expect to be asked for a complete list of vendors onboarded during the audit period, from which the auditor will select a sample and ask for the assessment record of each. If your register only holds current vendors and quietly drops the ones you stopped using, you cannot produce that population and the test fails before it starts. Keep terminated vendors in the register with an end date.

For each sampled vendor expect a dated assessment artifact, evidence of who approved onboarding, and the contract showing the security terms. For the monitoring control expect the population of critical vendors and evidence that the scheduled review actually happened, meaning a dated record rather than a calendar invite. For offboarding expect proof that access was revoked, ideally a ticket or a system log with a timestamp, and confirmation of data deletion where the contract required it.

The cheapest way to pass these tests is to make the record a byproduct of doing the work rather than something you assemble later. Any ticketing system will do this if every vendor assessment is a ticket with the artifacts attached. Our Workspace is free and does the same job with the register, the documents, and the review dates in one place, which matters mainly because it timestamps things you would otherwise have to reconstruct.

Closing the shadow IT gap without becoming the department of no

Step one finds the vendors that exist today. The harder problem is the twelve new tools that will appear over the next year, signed up on a corporate card by people who are not trying to cause a problem. A procurement gate that requires security approval before purchase works only if it is faster than going around it.

What works in practice is a lightweight intake form owned by whoever handles the corporate card, with a hard rule that new spend without a completed form does not get reimbursed. Finance enforcement is more reliable than security enforcement because the incentive is immediate. Keep the form to five fields: what the tool is, what data it will hold, whether it needs access to production or customer systems, who owns it, and what it replaces. That last field is worth having because a surprising share of requests turn out to duplicate something you already pay for.

Route only the requests that touch customer data or production into a real assessment. Everything else gets recorded and approved the same day. If security review becomes a two-week wait for a design tool, people will route around it and your inventory decays again within a quarter.

Running it with a fraction of a person

Most companies do not have a GRC hire and will not for a while. A program that assumes one will fail. Sized correctly, an established program for fifty to a hundred vendors takes roughly two to four hours a week, concentrated in bursts.

The workload has a shape worth planning around. New vendor intake is a few requests a month, each fifteen minutes for low risk and two to four hours for critical. Annual reviews for critical vendors should be spread across the calendar rather than stacked into one month, because a program that reviews twenty vendors every January reviews zero of them in the year somebody is on leave in January. Certificate expiry tracking is automatic if you diary each report's period end when you file it. The one thing you cannot spread out is the response to a vendor incident, which is why the owner should be someone with the standing to pull other people in on short notice.

The AI vendors your tiering model does not handle

Standard tiering asks what data a vendor holds. AI tooling breaks that question, because the data often passes through rather than being stored, and the risk sits in what happens to it in transit. Add three questions to your assessment for any vendor with a model in the path. Is customer data used for training or fine-tuning, and can that be disabled contractually rather than by a settings toggle someone can flip back. What is the retention period for prompts and outputs, since a thirty-day abuse-monitoring retention is common and is still your customer data sitting somewhere. And which underlying model providers sit behind the product, because a wrapper around a foundation model gives you a subprocessor you did not evaluate.

Also check who inside your company is already using AI tools with customer data through a personal account. That is the same shadow IT problem as above, arriving faster.

When you should not bring in outside help

There are three situations where paying for this is a poor decision, and we say so on scoping calls.

You have under twenty vendors and a willing owner. The whole program is a week of focused effort and then a couple of hours a week. Buying it done removes the institutional knowledge that makes the ongoing work fast, and you will pay again next year to have someone re-learn your stack.

You already bought a GRC platform and have not used it. Most platforms include vendor register, questionnaire distribution, and expiry alerts. If you are paying for that and running a spreadsheet anyway, the fix is two days of configuration, not a consulting engagement. Ask your platform's support team first. They do this for free.

Your problem is upstream of vendor risk. If you do not know who has access to production, do not have SSO, or cannot produce an accurate employee access list, vendor management is not your binding constraint. Fix identity first. Every vendor assessment you do before then rests on an inventory you cannot trust.

Where outside help genuinely earns its cost is volume and judgment under a deadline: reading thirty attestation reports properly, chasing unresponsive vendors, and having someone who has seen how auditors test this control decide what is worth escalating. If that is the position you are in, a retainer that covers the reviews on a fixed cadence usually costs less than the internal time it replaces, and it keeps the program running in the months when your team is busy shipping.