Third-Party Risk Management From the Vendor Side: What Happens When Your Customer Assesses You

Last reviewed: 2 October 2026. This article describes common industry practice and, where noted, publicly available regulatory sources; it is not legal advice, and requirements vary by customer, industry, and jurisdiction.

Quick answer

Third-party risk management (TPRM) is the process a customer runs internally to identify, assess, and monitor the risk you introduce as their supplier — from initial risk classification through periodic reassessment, years into the relationship. Almost everything published about TPRM is written for the buyer running the program. From where you sit as the assessed vendor, the same lifecycle looks like: you get quietly sorted into a risk tier (rarely disclosed), asked for due-diligence documents and a security questionnaire, asked to support your answers with evidence, reviewed and scored by people you never talk to, sometimes asked to remediate a gap, approved at a level tied to your tier, bound by contract terms that reflect the assessment, possibly monitored on an ongoing basis, and re-assessed on a schedule or after a trigger event. None of this is universal — practice varies by customer, industry, and jurisdiction — and specific regulatory regimes (DORA, EBA guidelines) impose more prescriptive versions of parts of this on regulated customers, who then push those requirements down to you contractually.

Contents

• Why TPRM content is written for the wrong side of the table
• What TPRM actually is
• The 10-stage TPRM lifecycle, from the vendor's side
• Stage-by-stage detail
• Practice vs. regulation: don't conflate the two
• What you can typically prepare in advance
• Where a system of record helps
• Related reading
• FAQ

Why TPRM content is written for the wrong side of the table

Search "third party risk management" and nearly everything that ranks — vendor-risk platforms, GRC vendors, consultancies, analyst blogs — is written for the organization running the program: how to build a TPRM function, how to score inherent and residual risk, how to choose a GRC tool, how to staff a risk committee. That content is accurate and useful, but it answers a different question than the one you have if you are the company being assessed.

If you sell software or services to other businesses, TPRM is not a program you run. It is a process run on you, usually by people at your customer you will never meet, using criteria you are rarely shown, on a timeline you don't control. You experience it as a due-diligence request, a questionnaire, a stream of evidence requests, a contract redline, and then — if you're lucky — silence until next year's reassessment.

This article describes that same lifecycle, stage by stage, from your side of the table: what a customer is actually doing at each stage, what it looks like when it lands on your desk, and what you can prepare in advance. It also draws a hard line between what customers commonly do as a matter of internal practice (which varies enormously) and what a specific regulation actually requires (which does not vary — for a defined population of regulated customers).

What TPRM actually is

Third-party risk management is the ongoing set of activities an organization uses to identify, assess, contract for, monitor, and periodically re-evaluate the risk introduced by an external supplier, across the full life of the relationship — not just at onboarding.

That last part is the distinction most vendor-side guidance misses. A security questionnaire is one artifact inside TPRM, not the whole thing. TPRM as a discipline spans from before you're selected (risk classification) through years after go-live (reassessment, and eventually offboarding). Industry frameworks describe this as a lifecycle with somewhere between four and eight named phases depending on the source — identification/classification, assessment, contracting, monitoring, and termination is a common minimal version; more detailed frameworks split assessment into due diligence, evidence collection, and scoring, and split monitoring into ongoing oversight and periodic reassessment. NIST's supply-chain risk management guidance (SP 800-161) is one of the more commonly cited references behind enterprise TPRM programs, particularly its emphasis on making assessment depth and reassessment frequency proportionate to a vendor's tier rather than applying one uniform process to every supplier.

None of this terminology is specific to security vendors or SaaS. TPRM as a discipline covers any external party a company depends on — logistics providers, staffing agencies, professional services firms, cloud infrastructure, payment processors. If you sell into regulated industries — banking, payments, insurance, healthcare — you are more likely to encounter a named, formal TPRM function with its own tooling and cadence. If you sell into smaller or less regulated customers, the same activities happen, just less formally and often owned by whoever asked to buy from you in the first place.

TPRM is not the questionnaire. The questionnaire is one artifact inside a lifecycle that starts before you're picked and doesn't end when you go live.

The 10-stage TPRM lifecycle, from the vendor's side

#	Stage	What the customer is doing	What this looks like for you as the vendor	What you can typically prepare
1	Risk classification / tiering	Sorting you into a risk tier based on data access, service criticality, integration depth, and sometimes spend	Usually invisible — you're rarely told your tier, though the thoroughness of what follows is a rough proxy for it	A clear, accurate description of your service, the data you touch, and how deeply you integrate — this is often the input the customer uses to tier you
2	Due diligence	Baseline checks on legal standing, financial stability, insurance, ownership, sometimes sanctions/adverse-media screening	A request for company registration documents, insurance certificates, financial statements or evidence of solvency	See our full vendor due diligence checklist
3	Security/risk questionnaire	Structured assessment of your controls: security, privacy, business continuity, compliance, subcontractors	A spreadsheet or portal questionnaire, sometimes hundreds of questions, sometimes framework-mapped (SIG, CAIQ, custom)	See our guides to security questionnaires and answering a vendor security assessment
4	Evidence provision	Verifying your answers against supporting documentation rather than taking self-attestation at face value	Requests for policies, certifications (SOC 2, ISO 27001), pen-test summaries, subprocessor lists, incident-response plans	Keep evidence current, versioned, and mapped to which claim it supports
5	Assessment / scoring	Internal review of your questionnaire and evidence, often scored against a rubric, sometimes involving a risk committee	Largely invisible to you — you may get follow-up questions, or nothing, while this happens internally	Nothing to prepare directly; consistent, well-sourced answers reduce the follow-up volume
6	Remediation	Identifying a gap and deciding whether it blocks approval, needs a compensating control, or needs a fix-by date	A request to implement a specific control, provide a compensating measure, or commit to a remediation timeline before sign-off	A documented, credible plan (even a partial one) is usually better than silence or an unqualified "yes"
7	Approval	Formal internal sign-off, gated at an authority level tied to your risk tier (analyst-level for low risk, committee or executive sign-off for high risk)

Stage-by-stage detail

1. Risk classification / tiering

Before a customer sends you anything, someone internally has usually made a rough judgment about how much scrutiny your relationship warrants. Common inputs: what data you can access (none, low-sensitivity, regulated/personal data, financial data), how critical your service is to their operations, how deeply you integrate (a hosted dashboard vs. an API with write access to core systems), and sometimes contract value.

You are usually not told your tier explicitly. What you can often infer is roughly how thorough the process is likely to be: a two-question vendor form versus a 200-question SIG Lite versus a custom questionnaire plus a scoping call is a reasonable proxy for how the customer has classified you. Don't assume the tier is fixed forever — expanding your integration scope, adding data access, or a security incident (yours or a peer's) can move you to a higher tier mid-relationship, which resets the assessment depth.

2. Due diligence

This is the baseline "are you a real, solvent, legally sound company" check, layered on top of or ahead of the security-specific review. It can include company registration, beneficial ownership, financial statements or bank references, insurance certificates (cyber liability, E&O, general liability), and in some industries sanctions or adverse-media screening. Our vendor due diligence checklist covers this stage in full.

3. Questionnaire

The most visible artifact in the entire lifecycle, and the one most vendors mistake for the whole process. Formats vary widely — a custom spreadsheet, a portal-based tool, or a recognized framework like SIG or CAIQ. See our security questionnaire hub for the broad landscape and how to answer a vendor security assessment questionnaire for the mechanics of individual questions, evidence attachments, and exception handling.

4. Evidence provision

Answers alone rarely close out an assessment for anything above the lowest risk tier. Reviewers want to see the policy, the certificate, the pen-test summary, or the subprocessor list that backs up what you claimed. The practical failure mode here isn't lacking the documents — it's not knowing which version is current, which claim each document supports, or who last approved it internally.

5. Assessment / scoring

This happens on the customer's side and is largely opaque to you. Some programs use a formal scoring rubric (weighted by control area, mapped to your tier); others rely on an analyst's judgment call. What crosses back to you, if anything, is a follow-up question or a request to close a gap — which is the next stage.

6. Remediation

If the reviewer finds a genuine gap — no incident-response plan, an expired certificate, encryption that doesn't meet a stated bar — you'll typically get one of three outcomes: a hard blocker until it's fixed, an accepted compensating control, or a conditional approval with a committed remediation date. Vague promises tend to get more scrutiny than a specific, dated plan, even a modest one.

7. Approval

The formal internal sign-off. Higher-tier vendors often require a named approver at a specific seniority — a risk committee, a CISO, or a business-unit head — rather than an individual analyst. This stage is procedural on the customer's side; from your side, it's usually the point where you're told "you're cleared" with no visibility into who signed or what the internal debate looked like.

8. Contracting

Assessment outcomes get written into binding terms: a data processing agreement, a security addendum, service-level commitments, breach-notification windows, audit rights. This is where a control you described loosely in the questionnaire ("we monitor for anomalies") can turn into a specific contractual commitment ("notify within 72 hours of a confirmed incident"). Read contract language against what you can actually operationally deliver, not just what sounds reasonable.

9. Ongoing monitoring

This is the stage with the widest variance across customers, and it is not safe to assume it's happening — or that it isn't. Some customers do nothing between assessments. Some subscribe to third-party security-rating services that passively score your external attack surface and flag changes. Some hold contractual audit rights they rarely exercise. Some send an annual self-attestation form and call it monitoring. There is no universal standard here; treat "ongoing monitoring" as customer-specific until you know otherwise.

10. Reassessment

Most formal TPRM programs re-run some version of the assessment on a schedule — commonly annual for higher-tier vendors, longer for lower-tier ones — or trigger an off-cycle reassessment after a material change: a security incident (yours or a subprocessor's), a new subprocessor, an ownership or leadership change, a data-residency change, or a significant expansion of what you do for them. The fastest reassessments are the ones where you can precisely state what changed since the last cycle instead of re-answering everything from scratch.

Practice vs. regulation: don't conflate the two

This is the distinction most vendor-side content gets wrong, and it matters because the two categories carry very different weight.

General TPRM practice — everything described in the ten stages above — is risk-based and varies significantly by customer, industry, and jurisdiction. There is no single global standard that mandates annual reassessment, a specific questionnaire format, or a specific tiering model. A customer's TPRM program reflects its own risk appetite, resources, and internal policy, informed by voluntary frameworks and industry guidance (NIST SP 800-161, ISO 27036 concepts on supplier relationship security, and vendor-published frameworks). None of these frameworks are laws; a customer can adopt, adapt, or ignore parts of them.

Specific regulation is different: it is a binding legal requirement placed on a defined population of regulated entities, which then flows down to their vendors contractually — not because the vendor is directly regulated, but because the customer's compliance obligation requires it. Two concrete examples relevant to European financial services:

	General TPRM practice	Regulatory requirement (example)
Who it binds	Any customer, voluntarily, based on internal risk policy	A defined population of regulated entities (e.g., EU financial entities)
Basis	Internal risk appetite, industry norms, voluntary frameworks	Binding law or supervisory guideline
Consistency	Varies widely customer to customer	Prescriptive and largely consistent within scope
How it reaches you	Customer chooses what to ask for	Flows down contractually because the customer must comply
Example	Annual questionnaire refresh, informal risk tiering	DORA's ICT third-party risk requirements for EU financial entities — see DORA for ICT vendors
Example	Ad hoc due-diligence documentation request	EBA guidelines on outsourcing/third-party arrangements for non-ICT services — see EBA third-party risk guidelines

If your customer is an EU bank, insurer, investment firm, or other financial entity in scope of the Digital Operational Resilience Act (DORA), the ICT-related parts of what's described above — classification, due diligence, contracting, monitoring, and reassessment — are shaped by specific, prescriptive legal requirements, not just internal policy. For non-ICT outsourcing arrangements at EU financial institutions, EBA guidelines impose a related but distinct set of expectations. We cover both in dedicated articles rather than here, because conflating "what most customers tend to do" with "what a specific regulator requires of your specific customer" leads vendors to either over-promise (claiming compliance with something that doesn't apply to them) or under-prepare (assuming a regulated customer's request is just routine TPRM when it's actually a binding pass-through obligation).

What you can typically prepare in advance

You cannot control your customer's tiering model, scoring rubric, or approval chain. You can control how ready you are before each stage lands:

• A clear, accurate service description — what you do, what data you touch, how you integrate — since this is often the direct input to classification (stage 1).
• Current due-diligence documents: registration, insurance certificates, financial evidence, ready to share without a scramble (stage 2).
• Approved, reusable questionnaire answers, sourced to specific documents or facts rather than freehand text, so the same question from three different customers doesn't get three different answers (stage 3).
• Versioned evidence with expiry awareness — certificates and policies that are current, not the version from two renewal cycles ago (stage 4).
• A realistic remediation posture — know your actual gaps before a reviewer finds them, so you can offer a credible plan instead of an improvised one (stage 6).
• A record of what changed since your last assessment with a given customer, so reassessment doesn't start from zero (stage 10).

Where a system of record helps

Most of the friction in this lifecycle isn't any single stage — it's that vendors typically run each customer relationship as its own ad hoc thread: a folder of documents here, an email chain there, a questionnaire answered from memory because nobody can find how it was answered last time. If you're managing more than one or two active customer relationships at a time, that becomes the actual bottleneck, not the customer's process itself.

MatchAudit's Vendor Assurance workspace is built for the vendor side of exactly this lifecycle: it holds your reusable evidence documents and approved facts in one place, extracts requirement candidates from an incoming customer questionnaire for a human to review (never auto-answered), lets a reviewer answer each requirement by linking back to approved facts or documents as sources, and gives you a per-customer readiness view showing what's missing, expired, or due for review against a specific customer relationship — useful preparation ahead of due diligence, a questionnaire, or a reassessment cycle, not a live simulation of the customer's own process. Because each customer relationship is tracked as its own record, you can see where every active assessment stands without reconstructing it from email each time. Exports (JSON/CSV) are available for approved reports.

If you're juggling several customer TPRM cycles at once and losing track of who asked for what and when it's due to be refreshed, see pricing, start free, or talk to us about your specific backlog.

Related reading

• For the full onboarding sequence around this lifecycle — procurement setup, legal review, activation — see vendor onboarding: the complete guide.
• If the questionnaire stage is what's currently in front of you, see our security questionnaire hub.
• For a structured way to prepare before a due-diligence request lands, read our vendor due diligence checklist.
• If your customer is an EU financial entity citing operational resilience requirements, see DORA for ICT vendors.
• For EU financial institutions' non-ICT outsourcing obligations, see EBA third-party risk guidelines.

FAQ

Is third-party risk management the same as a security questionnaire? No. The questionnaire is one artifact inside the TPRM lifecycle, typically at stage 3. TPRM also includes risk classification before the questionnaire and contracting, monitoring, and reassessment after it.

What risk tier am I in with a given customer? You're usually not told directly. The depth and length of what they ask for — a short vendor form versus a lengthy custom questionnaire plus follow-up calls — is a reasonable, though imperfect, proxy.

Does every customer do ongoing monitoring after approval? No. This varies enormously — from nothing at all, to periodic self-attestation, to automated security-rating tools, to rarely-exercised audit rights. Don't assume either way; ask if it matters to your planning.

How often will I be reassessed? There's no universal rule. Annual reassessment for higher-tier vendors is common, but cadence depends on the customer's own policy and can also be triggered off-cycle by an incident, a scope change, or a subprocessor change on either side.

Is DORA the same thing as general TPRM practice? No. DORA is a binding EU regulation that imposes specific ICT third-party risk requirements on regulated financial entities, which then flows down to their vendors by contract. General TPRM practice is voluntary and varies by customer. See DORA for ICT vendors for specifics.

What's the difference between due diligence and a security questionnaire? Due diligence typically covers baseline legal, financial, and insurance checks. The security questionnaire is a separate, more technical assessment of your controls. They can run in parallel or sequentially depending on the customer.

What happens if a reviewer finds a gap in my controls? Outcomes vary: a hard block until it's fixed, acceptance of a compensating control, or conditional approval tied to a committed remediation date. A specific, credible remediation plan is generally received better than an unqualified "we'll handle it."

Can I see how I was scored? Rarely. Scoring and internal committee deliberation are usually not shared with the vendor. What you typically see is the outcome — approved, conditionally approved with remediation items, or declined.