Vendor risk management: best practices

Vendor risk management works when you classify each third party by criticality, require evidence proportional to that risk and monitor security posture between assessments. The problem is not a lack of questionnaires. It is relying on spreadsheets that go stale, treating every vendor the same way and discovering the exposure only after the incident.

This guide walks through the practical stages of a third-party risk program: why this vector has grown so much, how to structure the cycle end to end, how to classify and monitor by criticality, the role of questionnaires and evidence, and where GRC automation takes manual work out of the way.

Why third-party risk is one of the biggest incident vectors

In the 2026 edition of its Data Breach Investigations Report (DBIR), released in May, Verizon reports that breaches involving a third party reached 48% of the total, up 60% (Verizon, 2026 Data Breach Investigations Report). In the 2025 edition, that share had already doubled to 30% (Verizon, 2025 Data Breach Investigations Report). When a vendor is compromised, the attacker inherits the access, the integrations and the trust you granted it.

The reasoning is straightforward. Your company may have mature controls, but the attack surface extends to every partner that touches your data, systems or operations. A software provider, an outsourced payroll firm, a payment API: every connection is a door.

This risk grows by accumulation. In 2025, 48,185 CVEs were published, 20.6% more than in 2024 (Jerry Gamblin, 2025 CVE Data Review), and every vendor brings its own software and its own patch backlog. With growing dependence on outsourced, cloud and SaaS services, exposure tends to grow faster than most teams can track manually.

The business consequence is concrete: operational disruption, leaks of customer data, sanctions under the LGPD (Brazil’s General Data Protection Law) and reputational damage. That is why third-party risk is no longer a purely technical matter and now appears on the enterprise risk and board agendas.

Stages of a vendor risk management program

An effective program follows a lifecycle, from first contact to contract termination. A study by the Ponemon Institute with Imprivata, released in February 2025 and based on 1,942 IT and IT security practitioners, shows why the effort pays off: 47% of organizations had experienced, in the previous 12 months, a data breach or cyberattack that involved a third party accessing their network (Imprivata and Ponemon Institute, The State of Third-Party Access in Cybersecurity, 2025).

NIST CSF 2.0 organizes this cycle in the Cybersecurity Supply Chain Risk Management (GV.SC) category of the Govern function: it runs from prioritizing suppliers by criticality (GV.SC-04) and contract requirements (GV.SC-05) to due diligence (GV.SC-06), monitoring over the course of the relationship (GV.SC-07), including third parties in incident response (GV.SC-08) and what happens after the agreement ends (GV.SC-10) (NIST CSWP 29, The NIST Cybersecurity Framework 2.0). See the full picture in the six functions of NIST CSF 2.0.

The essential stages are:

Inventory and discovery. List every vendor, including those hired by business units without going through security. What is not in the inventory is not managed.
Criticality classification. Rank third parties by the risk they represent, considering data access, technical integration and operational dependence.
Due diligence and assessment. Send questionnaires and collect evidence consistent with the criticality level.
Contracting and clauses. Put security, data protection, incident notification, subcontracting and audit-right obligations in the contract. For institutions regulated by the Central Bank of Brazil, CMN Resolution No. 4,893/2021 (CMN is Brazil’s National Monetary Council) lists mandatory clauses for data processing, storage and cloud services; see the guide to third-party risk under CMN Resolution 4,893.
Continuous monitoring. Track the vendor’s posture throughout the relationship, not just at onboarding.
Response and offboarding. Define how to react to vendor incidents and how to revoke access and return or delete data when the contract ends.

Every stage generates records. Keeping that traceability in one place is what lets you answer auditors and regulators without a last-minute scramble. If you are designing the broader risk program, combine this view with a well-calibrated 5x5 risk matrix to prioritize threats consistently.

How to classify and monitor vendors by criticality

Classifying by criticality means measuring each vendor’s risk before deciding how much control to apply. Treating everyone the same wastes effort on the irrelevant ones and leaves little attention for those that really matter. Proportional classification is the starting point of every mature program.

Assess each third party along three dimensions:

Data sensitivity. Does the vendor handle personal, financial or strategic data?
Access level. Does it have privileged access to systems, networks or credentials?
Operational impact. If the service goes down, how much of your operation stops with it?

Based on those answers, group vendors into tiers, for example critical, high, medium and low. A cloud provider hosting customer data is critical. An office supplies vendor is low. The depth of the assessment and the reassessment frequency follow the tier.

In ISO/IEC 27001:2022, Annex A controls 5.19 to 5.23 cover this relationship: information security in supplier relationships, requirements in supplier agreements, the ICT supply chain, monitoring and change management of supplier services, and the use of cloud services (ISO/IEC 27001:2022). The ISO 27001 Annex A checklist shows where they fit.

Monitoring is the part most programs neglect. An assessment done at onboarding describes the vendor on that day. Months later, reality has changed: certificates expire, vulnerabilities appear, security teams are cut. Continuous monitoring fills that gap, flagging when a third party’s posture deteriorates before it turns into an incident.

Questionnaires, evidence and continuous monitoring

Questionnaires collect the vendor’s self-attestation; evidence proves the control exists and works; continuous monitoring shows whether it keeps working. The three are complementary, and relying on only one creates blind spots. The expectation of things getting worse reinforces the urgency: in the same study, 64% of respondents said third-party breaches will either increase or remain at alarmingly high levels over the following 12 to 24 months (Imprivata and Ponemon Institute, 2025).

Team analyzing risk dashboards and security indicators in a corporate setting

Use questionnaires proportionally. A critical vendor answers a robust questionnaire based on recognized frameworks. A low-risk vendor gets a lean version. Standardizing on references such as ISO/IEC 27001, SOC 2 and NIST CSF avoids reinventing questions and makes it easier to compare third parties.

Ask for evidence to back up the highest-risk answers:

SOC 2 Type II reports and valid ISO/IEC 27001 certificates, checking the scope covered and the expiry date.
Security policies, incident response plans and continuity plans.
Recent penetration test and vulnerability scan results.
Data protection clauses in the contract when personal data is processed. The LGPD does not prescribe a contract template, but the processor must process data according to the controller’s instructions (art. 39) and both must adopt security measures (art. 46) (Law No. 13,709/2018); the contract is the natural place to record this. See also the LGPD compliance checklist.

Continuous monitoring closes the loop. It watches external security posture signals and relevant changes between formal assessments, turning an annual snapshot into a living view of the relationship.

Automating third-party assessment with GRC

GRC automation reduces the manual work of collecting, cross-checking and updating vendor information, freeing the team to analyze risk instead of chasing emails. Spreadsheet-based processes tend not to scale once the third-party portfolio goes beyond a few dozen, and rework across frameworks eats the time that should go into decisions.

A GRC platform brings vendors into a single inventory and links each assessment to the corresponding controls, evidence and risk. The practical gain is reuse: the same control, with its evidence, can be mapped to requirements in ISO/IEC 27001, the LGPD, SOC 2 and NIST CSF, without restarting the assessment for each standard.

The Third-Party Risk module of Futture’s Eagle was designed for this cycle: vendor registry, assessments and criticality classification, risks, contracts and periodic reviews, risk signals, monitoring and action plans, linking supply chain risk to enterprise risk. AI supports classification and prioritization in a human-in-the-loop model, and the final decision stays with the analyst.

In practice, this changes the dynamics of assessment. Instead of opening a spreadsheet for each vendor, the team sees which third parties changed risk, which evidence has expired and where to act first. To go deeper on choosing a tool, review how to choose GRC software before you decide.

Conclusion

Start with what you cannot see: build the complete vendor inventory and classify each one by criticality. That list, however imperfect at first, is what turns third-party risk from a surprise into a manageable decision. From there, apply proportional questionnaires and evidence, turn on continuous monitoring for critical vendors and assess which stages can be automated on a GRC platform. The next third-party incident will not warn you before it arrives; the diligence you do now determines whether it becomes a controlled event or a crisis.

Further reading: AI Due Diligence Software for Third Parties; Risk Matrix: How to Build It and Prioritise Threats.

Frequently asked questions

What is vendor risk management?

It is the process of identifying, classifying, assessing and monitoring the risks that suppliers and service providers bring to your operations, data and compliance, from onboarding to contract termination.

How often should a critical vendor be reassessed?

A common practice is to formally reassess critical vendors at least once a year, and also whenever the service changes materially or an incident occurs, complemented by continuous monitoring that flags changes in security posture between cycles.

Does a security questionnaire replace evidence?

No. The questionnaire captures the vendor’s self-attestation. Evidence such as SOC 2 Type II reports, valid ISO/IEC 27001 certificates and test results shows that the control exists and, in the case of SOC 2 Type II, that it operated over a period of time.

How does the LGPD affect vendor management?

Under the LGPD, Brazil’s General Data Protection Law, a company that hires a processor (operador) to handle personal data on its behalf remains the controller: decisions about the processing are its own (art. 5, VI), the processor must follow its instructions (art. 39) and both must adopt security measures (art. 46). That is why it makes sense to assess the vendor’s security, put instructions and data protection clauses in the contract and keep a record of that due diligence.

Vendor Risk Management: Best Practices