How to Run a Third-Party Risk Assessment (2026 Guide)
By ScruteX Published
In August 2025, attackers stole OAuth tokens belonging to a chatbot integration and used them to reach the CRM and email environments of more than 700 organisations. Most of those organisations had assessed the vendor. Almost none had assessed the token.
That gap is the subject of this guide. A third-party risk assessment fails in two predictable ways: it accepts what the vendor says without checking anything independently, and it treats the result as permanent. Both are fixable, and neither requires a large team.
A third-party risk assessment is a structured evaluation of whether a vendor can be trusted with your data, systems or customers. It runs in five stages: scope the vendor by blast radius, gather and grade evidence, evaluate across control domains, score and document the decision, then monitor for drift. The output is a defensible decision and an audit trail, not a filled-in form.
This guide covers each stage, maps them to the frameworks your auditor will ask about, and sets out the version that works when you are the only person doing security.
What is a third-party risk assessment?
A third-party risk assessment evaluates a single vendor at a point in time and produces a decision: approve, approve with conditions, or reject. It is an event with a beginning and an end.
Four adjacent terms get used interchangeably, which causes real confusion in audits. They are not the same thing.
| Term | What it actually means |
|---|---|
| Third-party risk assessment | The evaluation event for one vendor, producing a documented decision |
| Vendor risk assessment | The same thing. Used more often when the third party is a supplier rather than a partner or agent |
| Due diligence | The pre-contract subset of the assessment, done before you sign |
| TPRM | The programme that runs assessments, monitoring, contracts and offboarding across the whole vendor population |
If you are building the programme rather than assessing one vendor, start with our guide to third-party risk management and come back here for the method.
Why third-party risk assessment is now a regulated obligation
The strongest reason to do this properly is no longer a breach statistic. It is that supervisors now ask to see the artefact.
NIST rewrote its Cybersecurity Framework in 2024 and put supply chain risk into the new Govern function as GV.SC. At ten subcategories, it is the largest category in the framework. Four of them describe this exact process: suppliers known and prioritised by criticality (GV.SC-04), due diligence performed before entering the relationship (GV.SC-06), risks assessed and monitored across the course of the relationship (GV.SC-07), and provisions for what happens after the relationship ends (GV.SC-10).
Regulators went further and made it filable. Under the EU's Digital Operational Resilience Act, financial entities maintain a Register of Information covering every ICT third-party contractual arrangement and report on it at least yearly, with mandatory contract clauses for arrangements supporting critical or important functions. The register is not just a compliance artefact: the European Supervisory Authorities used the collected registers to designate the first set of critical ICT third-party providers for direct oversight in November 2025.
Three other regimes matter depending on where you operate:
- Australia. APRA's CPS 230 commenced on 1 July 2025. Pre-existing material service provider arrangements had to be brought into line by the earlier of their next renewal or 1 July 2026, a deadline that passed last month. Entities also submit a material service provider register to APRA.
- EU, beyond financial services. NIS2 Article 21(2)(d) puts supply chain security in the baseline risk-management measures. Article 21(3) adds the specific instruction that entities take into account the vulnerabilities of each direct supplier and the quality of their cybersecurity practices, including their secure development procedures.
- India. SEBI's Cybersecurity and Cyber Resilience Framework sets vendor risk expectations for regulated entities in the securities market, including vendor inventories, criticality-based classification, contractual security clauses and periodic review.
The common shape across all of them: know your vendors, rank them by criticality, check before you sign, keep checking, and be able to show the evidence. That is the five-step process below.
Step 1: Scope the vendor by blast radius, not by spend
Tiering decides how much scrutiny a vendor gets. Most programmes tier on contract value or on a single question about whether the vendor touches personal data. Both under-assess the vendors that actually get you breached.
Score three inputs instead:
Data sensitivity. What classification of data does the vendor hold, process or transit, and at what volume.
Integration privilege. This is the one that gets skipped. What can the vendor's software reach inside your environment without a human involved? OAuth scopes, refresh tokens, API keys, delegated administrator rights, SSO trust, webhook targets, and any agent or connector installed in your tenant. A tool with a persistent read token across your CRM has more privilege than a contractor with a laptop.
Operational dependency. What stops working if the vendor goes dark for a week, and is there a substitute.
| Tier | Trigger | Assessment depth | Reassessment |
|---|---|---|---|
| Tier 1 | Sensitive data at volume, or broad integration privilege, or no substitute | Full seven-domain assessment, evidence required in every domain | Annual, with continuous external monitoring |
| Tier 2 | Limited data, scoped integration, replaceable | Seven domains, evidence in the four that carry the risk | Every 18 to 24 months |
| Tier 3 | No sensitive data, no integration, easily replaced | Short-form check and a contract review | On renewal or on trigger |
Score integration privilege independently of the other two, and let it promote a vendor on its own. That single rule would have moved a lot of chatbots into Tier 1 in 2025.
You cannot tier what you have not inventoried, which is why both DORA and CPS 230 begin with a register rather than a questionnaire.
Step 2: Gather evidence, not answers
Here is the part most guides skip. Not all evidence is worth the same, and a defensible assessment states which kind is backing each conclusion. Use three tiers.
Tier 1: Assertion
Questionnaire responses, policy PDFs, the vendor's trust page. Someone at the vendor wrote it down.
Assertions are worth collecting. They create a contractual record, they force the vendor to answer in writing, and they often expose internal confusion about what you are actually buying. They are not verification. The person completing a security questionnaire is frequently in sales, and has never seen the environment they are describing.
Tier 2: Attestation
SOC 2 Type II reports, ISO/IEC 27001 certificates, penetration test summaries. An independent party looked.
This is where scope reading beats logo collection. For a SOC 2 report, check five things:
- The period covered, and how much time has passed since it ended. If the gap is material, ask for a bridge letter.
- The scope, meaning whether the product you are buying is actually named in the system description.
- Subservice organisation treatment. Under the carve-out method, the vendor's own critical providers sit outside the testing entirely and appear only as complementary subservice organisation controls, which are disclosed but not tested. Under the inclusive method they are tested. Carve-out is far more common, and it means part of the assurance you think you are buying is a reference to someone else's report.
- Complementary user entity controls. These are the controls the report assumes you will operate. If you are not doing them, the report's conclusions do not hold for your deployment.
- The exceptions section. Read it. An unqualified opinion can still carry exceptions that matter to your use case.
For ISO/IEC 27001, read the certificate scope and the statement of applicability. A certificate covering the vendor's corporate IT tells you nothing about the product.
Tier 3: Observation
What you can see from outside, without the vendor's cooperation and without waiting for them to reply.
Exposed services and administrative interfaces. Certificate expiry and TLS configuration. Dangling subdomains. Software versions that stopped receiving patches. Credentials belonging to the vendor's domain appearing in breach corpora and infostealer logs. Domains typosquatting the vendor, which tell you whether their customers are already being phished.
Observation has real limits, and any honest guide says so. It sees the internet-facing estate only. It says nothing about internal segmentation, key management or staff vetting. Asset attribution is imperfect, especially with shared hosting and CDN edges. A clean external picture is not proof of a healthy security programme.
What observation does uniquely well is two things: it is independent of vendor cooperation, and it can run continuously, which makes it the only tier that catches drift after the assessment is signed.
The rule to apply: no Tier 1 vendor should have any control domain resting on assertion alone.
Step 3: Evaluate across seven control domains
Seven domains cover a full assessment. Score each one separately. A single composite number hides the pattern that matters, which is that a vendor is usually strong in some places and weak in exactly one.
| # | Domain | What you are testing | Minimum evidence tier (Tier 1 vendor) |
|---|---|---|---|
| 1 | Governance and compliance | Who owns security, which certifications are live and in scope, what regulatory obligations apply | Attestation |
| 2 | Data protection | Classification, encryption, retention, deletion, and where data physically sits | Attestation |
| 3 | Access control | Identity management, MFA coverage, privileged access, joiner-mover-leaver | Attestation |
| 4 | Infrastructure security | Patch cadence, configuration, segmentation, and external exposure | Observation |
| 5 | Application security | Secure development, testing cadence, vulnerability disclosure and handling | Attestation plus observation |
| 6 | Incident response | The plan, notification timelines owed to you in the contract, and breach history | Assertion plus contract |
| 7 | Fourth-party and integration risk | Sub-processor list, and the scopes and tokens the vendor's software holds in your tenant | Observation, from your side |
Domain 7 is the one most programmes fake. Ask for the sub-processor list and for notice of changes to it. Then do the part the vendor cannot do for you: open your own identity provider and SaaS admin consoles and list what this vendor's application can currently reach. That is a five-minute check that most assessments never perform.
Mapping the process to the frameworks
If you need to show an auditor or a client where this method comes from, the mapping is direct.
| Step | NIST CSF 2.0 | ISO/IEC 27001:2022 | DORA | APRA CPS 230 |
|---|---|---|---|---|
| 1. Scope and tier | GV.SC-04 | A.5.19 | Register of Information, Art. 28 | Material service provider identification and register |
| 2. Gather evidence | GV.SC-06 | A.5.19 | Pre-contract due diligence, Art. 28 | Service provider due diligence |
| 3. Evaluate domains | GV.SC-05, GV.SC-08 | A.5.20, A.5.21, A.5.23 | Contractual provisions, Art. 30 | Service provider agreements |
| 4. Decide and document | GV.SC-01, GV.SC-03 | A.5.19 | Board reporting and register accuracy | Service provider management policy |
| 5. Monitor and offboard | GV.SC-07, GV.SC-09, GV.SC-10 | A.5.22 | Ongoing monitoring and exit strategies | Ongoing monitoring and notification |
Step 4: Score, decide and document
Score each domain, weight the scores by tier, and record the domain profile alongside the overall rating. Then pick one of four outcomes.
Most guides list three. The fourth is the useful one.
- Approve. Evidence supports the risk.
- Approve with vendor conditions. They fix named gaps by a named date, and you verify.
- Approve with compensating controls on your side. You cannot make the vendor change, so you reduce what they can reach: scope the OAuth grant down, restrict the API key, allowlist source IPs, minimise the data sent to the integration, or move them into a separate tenant. This outcome is what makes a realistic assessment possible when you have no bargaining power.
- Reject.
The record needs six fields: the decision, the basis, the evidence tier behind each domain score, the conditions and their dates, the internal owner, and the review date. That record is your audit trail and your remediation map. Under DORA and CPS 230 it is also the artefact a supervisor traces from the register through to the contract clauses and board reporting.
Step 5: Monitor, because the assessment decays
An assessment describes a state. States change. The vendor that passed in April can expose a new admin interface in June, lose a certification in August, and be acquired in October.
Calendar cadence alone is too slow. Define refresh triggers as well:
- A certificate lapses or its scope changes
- The sub-processor list changes
- Ownership, funding or leadership changes
- A new integration scope or token is granted
- The vendor discloses an incident
- External observation shows drift: a new exposed service, an expired certificate, credentials from their domain surfacing in a leak
To keep this from becoming noise, apply one escalation rule: monitor everything, escalate only what would change the tier or the decision. An expired certificate on a marketing microsite is a note. An exposed administrative interface on the platform holding your data is a reassessment.
The integration nobody assessed
The August 2025 Salesloft Drift compromise is the clearest illustration of why tiering on integration privilege matters.
FINRA's alert to member firms sets out what happened. Attackers, tracked as UNC6395, obtained valid OAuth and refresh tokens for the Drift chatbot integration, most likely through earlier phishing. Holding valid tokens let them impersonate the trusted application, which bypassed multi-factor authentication entirely. They then queried and exported data from Salesforce, Google Workspace and in some cases Slack across more than 700 organisations, deleting query jobs behind them. The data included business contact records and support case contents, and in some cases API keys, cloud credentials, database tokens and passwords that customers had pasted into support tickets.
Three things are worth taking from it.
The compromised vendor was a marketing chatbot. On data sensitivity and contract value it scores low almost everywhere. On integration privilege it held persistent, MFA-independent access to the systems where the sensitive data actually lived.
No questionnaire would have caught it. The vendor could truthfully have answered yes to every question about MFA, encryption and secure development. The exposure sat in the token lifecycle, not in the control set.
The recommended actions were access-shaped rather than paperwork-shaped: disconnect the integrations, rotate credentials, review logs for the 8 to 18 August window, and going forward apply least privilege to third-party applications and monitor SaaS integrations. Those are Step 1 and Step 5 of this process.
Attribution beyond the tracked cluster remains preliminary, and the relevant MITRE ATT&CK behaviours are T1199 (Trusted Relationship) and T1550.001 (Application Access Token), with T1195 (Supply Chain Compromise) as the wider pattern.
The zero-budget version
If you are the whole security team, this is the version that is still defensible.
One page per vendor. Tier decision with the three inputs scored. The seven domains in a spreadsheet, scored one to five, with a column recording which evidence tier backs each score. Certificates read for scope, not filed on sight. One external check of the vendor's internet-facing estate and leaked credential exposure, repeated quarterly for Tier 1 vendors. A signed decision note with a review date. An email folder is not evidence storage: use a shared drive with a consistent naming convention so the next person can find it.
That takes about ninety minutes per Tier 1 vendor after the first one. It is not a mature programme. It is a defensible one, and it beats a 200-question form nobody reads.
Common failure modes
- Reading the certificate logo instead of the certificate scope
- Tiering on contract value rather than blast radius
- Collapsing seven domain scores into one number
- No refresh trigger, only an annual calendar reminder
- Sub-processors never listed, never notified when they change
- Integration tokens granted at onboarding and never scoped down
- Procurement owning the assessment with no security sign-off
- Evidence stored in an email thread
How ScruteX fits
The hardest tier to gather is observation, because it is the one the vendor cannot hand you. That is where ScruteX Vendor Insights is built to help: continuous vendor posture scoring, questionnaire automation, an evidence repository and AI-assisted review, running on the same external discovery that maps your own estate. Point it at a vendor's domain and it returns exposed services, expired certificates, dangling subdomains and outdated technologies, prioritised by real-world exploitability rather than raw CVSS, with leaked credential exposure covered by Data Exposure Insights. It is agentless, starts from a domain and a set of keywords, and there is a free tier on primary domains with no card required.
Two honest caveats. This supplies the observation tier and the drift monitoring. It does not replace reading the SOC 2 or checking your own OAuth grants. And if you run a large TPRM function with dedicated analysts, best-of-breed ratings platforms will give you depth in scoring that a connected platform trades for breadth. The case for a single view is strongest for smaller teams who need vendor evidence and their own exposure evidence in one place, without a second tool and a second budget line.
Key takeaways
- Tier vendors by blast radius: data sensitivity, integration privilege and operational dependency. Let integration privilege promote a vendor on its own.
- Grade evidence in three tiers: assertion, attestation, observation. No Tier 1 vendor should rest a domain on assertion alone.
- Read certificate scope, report period, subservice treatment and complementary user entity controls. The logo tells you nothing.
- Score all seven domains separately and keep the profile. Add a fourth decision outcome: approve with compensating controls on your side.
- Define refresh triggers, not just a cadence, and escalate only what would change the tier or the decision.
FAQ
Q: What is a third-party risk assessment?
A: It is a structured evaluation of whether a vendor can be trusted with your data, systems or customers. It scores the vendor across control domains, produces a documented decision (approve, approve with conditions, or reject), and creates the audit trail a regulator or client can trace.
Q: What should a third-party risk assessment include?
A: Tiering by blast radius, evidence gathering across three tiers, evaluation of seven control domains (governance, data protection, access control, infrastructure, application security, incident response, and fourth-party and integration risk), a documented decision with the evidence tier recorded against each score, and ongoing monitoring.
Q: What is the difference between a third-party risk assessment and vendor risk management?
A: The assessment is a single evaluation event that ends in a decision. Vendor risk management is the ongoing discipline that runs those assessments, monitors vendors between them, manages contracts and handles offboarding.
Q: How often should you reassess a vendor?
A: By tier, plus on trigger. Reassess Tier 1 vendors annually with continuous external monitoring in between, Tier 2 every 18 to 24 months, and Tier 3 on renewal. Reassess any vendor immediately when a trigger fires, such as a certification lapse, a sub-processor change or a new integration scope.
Q: How do you verify a vendor's answers without their cooperation?
A: Through external observation. Exposed services, certificate hygiene, dangling subdomains, outdated software versions and leaked credentials tied to the vendor's domain are all visible from outside. This corroborates or contradicts what the questionnaire claims, though it cannot see internal controls, so treat it as one evidence tier rather than a verdict.