Most third-party risk programs begin with a questionnaire and a spreadsheet, and most of the tooling built since is an attempt to remove one specific weakness of that starting point: the answers are self-reported, they age the moment they are submitted, and chasing them consumes the team. Each capability below targets one of those weaknesses. None of them is a complete program on its own, and several are easy to mistake for one another, so the useful question is less "which features does a platform have" and more "what does this actually observe, and what is it blind to".
What this cluster covers
Seeing the vendor
Continuous vendor monitoring is the shift from assessing a vendor once a year to watching it all the time. Vendor attack surface monitoring is its outside-in signal source: it discovers and watches a vendor's internet-facing footprint without the vendor's cooperation, and structurally cannot see anything inside the vendor's walls. The two are related but not the same thing - monitoring is the cadence, attack surface discovery is one input into it.
Judging the vendor
Automated evidence collection replaces the manual chase for a SOC 2 report, an ISO 27001 certificate, or a questionnaire response with continuous ingestion and validation, and is honest about where the automation stops and a reviewer's judgment begins. Evidence-based risk scoring then turns what was observed into a rating that can show its work, which is the property that separates a defensible score from a black-box number. The comparison of security ratings and evidence-based TPRM covers that distinction in detail.
Running the process
End-to-end TPRM automation looks at the whole vendor lifecycle, from discovery through offboarding, rather than just digitizing the questionnaire. Vendor collaboration addresses the other half of every assessment: the vendor, who is usually asked the same questions by dozens of customers and whose responsiveness often decides the cycle time. Incident response and SOAR automation covers what has to happen after a vendor alert fires, so that detection leads to a tracked response rather than an email read days later.
Doing it with agents
Agentic AI in TPRM asks whether autonomous agents can run these stages end to end, fully autonomous with a human in the loop based on preference rather than unattended, and separates a platform that is AI-native from a traditional tool with an assistant added on. It is the newest piece of the cluster and the one most worth reading skeptically: the page is explicit about what automated remediation can and cannot do.
How the capabilities fit together
A workable mental model is three layers. Signal is what you can observe about a vendor: its external footprint, its published certifications and reports, and its responses. Judgment is what you conclude from that signal: validated evidence, a score you can explain, a tier that sets how much attention the vendor gets (see vendor tiering). Action is what changes as a result: a finding opened with the vendor, an incident response triggered, a contract clause invoked, a relationship ended (see vendor offboarding). A common failure is investing heavily in one layer - a wall of monitoring alerts, say - with nothing downstream to act on them.
Outside-in monitoring and evidence validation also check each other. A vendor's certificate can be current while its exposed infrastructure says otherwise, and a clean external scan says nothing about whether the vendor's internal controls were ever audited. Each method has a blind spot the other partly covers, which is why programs that pair them get more out of both than programs that pick one.
None of this replaces the contractual and regulatory layer. Capabilities generate evidence; the obligations that decide what evidence you need - audit rights, incident-notification windows, register and reporting duties - come from the frameworks and regulations your program answers to. Two primary sources state that duty directly: the EU Digital Operational Resilience Act (DORA) on EUR-Lex requires in-scope financial entities to manage ICT third-party arrangements on an ongoing basis, and OCC Bulletin 2023-17 expects banking organizations to monitor third-party relationships commensurate with the risk of the relationship rather than treating a one-time review as enough.
Where to start
If the pain is the volume of manual chasing, start with automated evidence collection and lifecycle automation. If the pain is not knowing what changed between annual reviews, start with continuous monitoring. If you are choosing a platform rather than building a capability, the platform evaluation framework maps these capabilities to questions you can put to any vendor.
Frequently asked questions
What are the core capabilities of a modern third-party risk management platform?
The capabilities that matter most fall into four groups. Seeing the vendor: continuous monitoring and vendor attack surface monitoring, which observe a vendor's external footprint over time. Judging the vendor: automated evidence collection and evidence-based risk scoring, which validate claims and produce a rating that can be explained. Running the process: lifecycle automation, vendor collaboration, and incident-response automation, which reduce manual effort and shorten the path from alert to action. Agentic AI: autonomous agents that attempt to run several of those stages end to end, fully autonomous with a human in the loop based on preference rather than unattended. They solve different problems and fail in different ways, so a long feature list is a weaker signal than knowing what each capability actually observes and what it cannot see.
What is the difference between continuous vendor monitoring and attack surface monitoring?
Continuous monitoring describes the cadence: watching a vendor all the time instead of assessing it once a year. Attack surface monitoring describes one signal source: discovering and watching a vendor's internet-facing assets from the outside, without the vendor's cooperation. Attack surface monitoring is typically an input to continuous monitoring, alongside other signals such as certificate and report status or vendor-reported changes. Because it only sees the external footprint, it cannot tell you about internal controls, which is why it is usually paired with evidence validation rather than used alone.
Can automation replace a human reviewer in vendor risk assessment?
It can remove most of the collection and first-pass checking work, such as chasing documents, ingesting a SOC 2 report, flagging a lapsed certificate, or comparing a questionnaire answer against observable facts. It does not replace the judgment calls: deciding whether a scope exclusion matters for your use case, accepting a risk with compensating controls, or negotiating a remediation with a vendor. The practical model is automation for collection and validation, with people reserved for the decisions that carry accountability.
How do TPRM capabilities relate to regulatory requirements?
Capabilities are how a program produces evidence; regulations and frameworks decide what evidence is required. Rules such as DORA (Regulation (EU) 2022/2554) and OCC Bulletin 2023-17, the U.S. interagency guidance on third-party relationships, set expectations for inventory, due diligence, contract terms, ongoing monitoring, and incident notification. Monitoring, evidence collection, and incident automation are ways to meet those expectations at scale, but owning the tooling does not by itself satisfy a requirement. The framework and compliance pages in this knowledge base map each regime to the specific actions it implies.