Every time I try to simplify another part of GRC, I ask the same question: Why did we make this so complicated?
Third-party risk management is a good example. Over time, many TPRM programs have become organized around a familiar sequence of activities. A vendor completes an intake form, receives a questionnaire, provides evidence, receives a score, and returns for another assessment at renewal. Each step has a purpose, but the sequence can obscure the decision the program exists to support.
The real question is not whether the questionnaire has been completed. It is whether the organization understands the relationship well enough to decide whether to proceed, under what conditions, and with what level of ongoing oversight.
That is why TPRM is not primarily a questionnaire problem. It is a connect-the-dots problem.
The relationship comes before the assessment
A third party exists within an organization’s operating model for a reason. It provides a product, service, capability, or form of expertise that enables the organization to accomplish a business objective. The assessment should begin with that relationship rather than with a standard list of security questions.
Why is the organization using the vendor? Which business process depends on it? Who owns the relationship? What data, systems, people, or facilities may be exposed? How difficult would it be to replace the service? What would happen if it became unavailable?
These are not preliminary administrative questions. They are part of the risk assessment itself.
An office-supply vendor, a payroll provider, a marketing platform, and a cloud infrastructure provider should not enter the same assessment workflow simply because each is a third party. Their business purpose, access, operational importance, and potential impact are different. The process should respond to those differences.
Business impact and continuity information also belong in this discussion. A vendor can create material operational risk even when it does not process highly sensitive data. If a critical business service cannot operate without the third party, the organization needs to understand recovery expectations, alternatives, concentration risk, and what its Business Impact Analysis and Business Continuity Plan say about that dependency.
Fragmented context produces fragile decisions
A recurring operational problem in TPRM is that decision-making information lives in different places.
The vendor’s risk tier may sit in the TPRM platform. Business impact information may be maintained in a continuity system. Contracts may live with Legal or Procurement. A document repository may store evidence. Spreadsheets or tickets may track findings and remediation actions. The business owner’s original rationale may remain in an intake form that no one reviews again.
Each system can contain accurate information while the organization still lacks one current picture of the relationship. That gap shows up in the data. KPMG’s 2026 Global Third-Party Risk Management Survey of 851 organizations found that only 53% of TPRM programs are “mostly integrated” with enterprise risk management, and just 18% are “fully integrated.” Only 15% of risk leaders say they have high confidence in the data underpinning their TPRM program.
This fragmentation makes it difficult to answer basic questions. Why was the vendor assigned this tier? Which factors drove the decision? What evidence was reviewed? Which risks remain unresolved? Who accepted an exception? Has the relationship changed since approval?
When you don't preserve the reasoning behind the decision, the tier becomes a label and the score becomes an output. Neither explains the risk on its own.
The distinction between business criticality, inherent risk, and residual risk matters most. A critical vendor does not become noncritical because it has strong controls or a clean independent report. Strong assurance may reduce the remaining risk, but it does not eliminate the organization’s dependency on the service.
A useful operating model keeps these concepts connected without treating them as interchangeable.
The questionnaire is one input, not the operating model
Questionnaires can provide useful information. The problem begins when the questionnaire becomes the default front door to every assessment.
A full questionnaire often asks the vendor to restate information already available through policies, attestations, certifications, audit reports, testing summaries, privacy documentation, and a trust portal. The reviewing organization must then evaluate every response, even when much of the underlying information already exists elsewhere.
Automating this process does not automatically improve it. Using AI to generate, answer, or review many unnecessary questions may speed up the existing workflow, but it does not address why those questions were required in the first place.
A stronger model begins with the evidence already available. The organization identifies which requirements apply to the relationship, reviews the vendor’s approved assurance material, and maps that evidence to its own needs. The remaining gaps become focused questions for the vendor.
This is evidence-first, gap-driven due diligence.
It is not less rigorous. It directs attention toward the information that is incomplete, stale, contradictory, or missing instead of treating every vendor as though nothing is known.
AI should connect context, not preserve complexity
AI's opportunity in TPRM is broader than placing a chatbot beside a vendor record. That opportunity is still mostly unrealized. More than half of organizations are already exploring AI in TPRM, according to KPMG’s 2026 survey, but only 22% call it “very effective” so far; a sign that most are pointing automation at the same fragmented, checklist-driven workflow instead of fixing the underlying disconnection first.
Specialized GRC agents can support bounded work within the operating process. They can help organize relationship context, analyze approved evidence, compare information with defined requirements, identify gaps, prepare targeted follow-up, and summarize changes for review.
They can also help explain which factors contributed to a recommended risk tier or why a relationship may need reassessment. The supporting source and rationale should remain visible so that a qualified reviewer can challenge, modify, or reject the recommendation.
The value comes from connecting historically fragmented information. AI should not create another isolated layer of analysis or a separate version of the truth. Its outputs should become durable, reviewable parts of the vendor record.
The human role remains essential. A person accountable for the decision must determine whether the tier is appropriate, whether the evidence is sufficient, whether an exception is acceptable, and whether the organization can proceed with the relationship.
The objective is not autonomous risk management. It is a more complete and current basis for human judgment.
TPRM should help the business move responsibly
Security and Compliance should not be defined by how often they say no. A mature TPRM program should help the organization understand how a relationship can proceed responsibly.
That means answering practical questions. Which safeguards are required? Which risks need remediation or acceptance? Who must approve the relationship? What should be monitored? What change would cause the organization to reconsider its decision?
When business context, exposure, dependency, evidence, findings, and decisions remain connected, TPRM becomes more than an assessment function. It becomes a business-enablement function.
Trustero’s approach to AI-native GRC is grounded in organizational context, guardrails, specialized GRC agents, evidence-supported outputs, and explicit human decision rights. Applied to third-party risk, those principles can help reduce repetitive preparation, surface gaps earlier, and give accountable people a more current basis for deciding how a relationship should proceed.
TPRM doesn't need another layer of automation on a fragmented process.
It needs the dots to remain connected.
Explore Trustero’s approach to third-party risk and AI-native GRC: trustero.com/use-cases/managing-third-party-risk