How Do We Build a Third-Party Risk Management Program That Actually Works?
A third-party risk management program should help the organization understand which vendors create meaningful risk, evaluate that risk appropriately, make informed decisions and continue monitoring important relationships over time.
It should not require every vendor to complete the same 300-question questionnaire, create mountains of paperwork nobody uses, or turn procurement into an obstacle course.
Hotman Group helps organizations design, implement, remediate and operate third-party risk management programs that connect vendor risk to cybersecurity, privacy, business impact, contractual requirements, governance and the broader Cyber GRC program.
The objective is not to assess the most vendors. It is to identify and manage the third-party risks that actually matter.
What Is Third-Party Risk Management?
Third-party risk management, often called TPRM, is the process of identifying, assessing, managing and monitoring risks created by vendors, service providers, suppliers and other external parties.
Third-party relationships can create risks involving:
- Cybersecurity.
- Data protection.
- Privacy.
- Business continuity.
- Operational resilience.
- Regulatory obligations.
- Contractual commitments.
- Fourth parties and subcontractors.
- Financial dependency.
- Reputation.
A practical TPRM program focuses effort according to the significance of the relationship and the risk it creates.
Why Do Third-Party Risk Programs Become So Burdensome?
Many programs begin with a simple idea: assess vendors before doing business with them.
Over time, the process accumulates:
- Long questionnaires.
- Multiple approval steps.
- Different assessment templates.
- Separate privacy and cybersecurity reviews.
- Manual evidence collection.
- Repeated reassessments.
- Spreadsheets.
- Email-based workflows.
- Exceptions nobody revisits.
- Monitoring tools that generate more alerts than decisions.
The process can eventually consume substantial effort without creating proportional risk visibility.
What Should a Good TPRM Program Actually Accomplish?
A functioning third-party risk program should help the organization answer:
- Which third parties matter most?
- What risks do they create?
- What information do we need before making a decision?
- What controls or contractual protections are appropriate?
- Who owns the business relationship?
- Who can accept the residual risk?
- What issues need remediation?
- Which vendors require ongoing monitoring?
- When should vendors be reassessed?
- What happens when a significant vendor changes or fails?
The program should support business decisions rather than simply produce completed questionnaires.
Should Every Vendor Go Through the Same Security Assessment?
No.
A vendor providing office supplies does not create the same cybersecurity risk as a cloud provider hosting sensitive information or operating a critical business system.
Assessment depth should reflect factors such as:
- Access to sensitive data.
- Access to systems or networks.
- Criticality to business operations.
- Ability to disrupt important services.
- Regulatory implications.
- Customer commitments.
- Geographic or jurisdictional considerations.
- Use of subcontractors.
- Concentration risk.
Risk tiering helps the organization apply the right level of diligence to the right relationships.
What Is Third-Party Risk Tiering?
Risk tiering classifies vendors according to the potential risk or criticality of the relationship.
A higher-risk vendor may require:
- More detailed security review.
- Additional evidence.
- Contractual security requirements.
- Risk-owner approval.
- More frequent reassessment.
- Continuous monitoring.
A lower-risk vendor may require much less.
The purpose of tiering is to direct effort where it creates the most value.
What Questions Should We Ask When Tiering a Vendor?
Useful questions may include:
- What service does the vendor provide?
- What business process depends on it?
- What data can the vendor access, process, store or transmit?
- Does the vendor connect to our systems?
- Would a vendor outage materially disrupt operations?
- Could a vendor compromise customers or regulated information?
- Does the relationship create contractual or regulatory obligations?
- How easily could the service be replaced?
- Does the vendor rely on important subcontractors?
Tiering should be based on the relationship, not merely the vendor's size or reputation.
Who Should Own Third-Party Risk?
Third-party risk is usually cross-functional.
Cybersecurity may evaluate security risk.
Privacy may evaluate personal-data implications.
Legal may address contractual protections.
Procurement may coordinate the vendor lifecycle.
The business sponsor understands why the vendor is needed and how important the service is.
Cyber GRC may coordinate the risk process.
The organization should still identify who has authority to own and accept the residual business risk associated with the relationship.
See who should own cyber risk in an organization.
Should Procurement Own TPRM?
Procurement may be well positioned to coordinate intake and ensure vendors enter the required review process.
But procurement should not be expected to independently make cybersecurity, privacy or business-risk decisions outside its expertise or authority.
A good operating model connects procurement with the appropriate subject-matter experts and business risk owners.
Should Cybersecurity Own TPRM?
Cybersecurity may own or coordinate the security-risk component, but third-party risk often extends beyond cybersecurity.
The organization should avoid making the cybersecurity team responsible for every contractual, operational, privacy and business decision associated with the vendor.
The program should define responsibilities clearly.
What Should Happen Before a New Vendor Is Approved?
The organization should first understand the relationship and determine the required level of review.
Depending on risk, that may include:
- Vendor intake.
- Risk tiering.
- Security assessment.
- Privacy review.
- Legal review.
- Contractual protections.
- Business continuity considerations.
- Risk-owner approval.
- Required remediation.
The process should be proportionate to the relationship rather than forcing every vendor through the same path.
Do We Need a Security Questionnaire for Every Vendor?
No.
Questionnaires can be useful, but they are only one source of assurance.
Depending on the vendor and relationship, the organization may also evaluate:
- SOC reports.
- ISO certifications.
- Independent assessments.
- Penetration-testing information.
- Security documentation.
- Contractual commitments.
- Architecture information.
- Incident history.
- External monitoring.
The objective is to obtain enough information to make the risk decision, not to maximize the amount of documentation collected.
Why Are Vendor Security Questionnaires So Inefficient?
Questionnaires become inefficient when every vendor receives the same questions regardless of risk or when reviewers treat every answer as equally important.
They can also create significant work for both parties while still failing to answer the most important risk questions.
A strong TPRM program uses questionnaires selectively and interprets responses in the context of the actual relationship.
Can We Accept a SOC 2 Report Instead of a Questionnaire?
Sometimes.
A SOC 2 report may provide substantial assurance about relevant controls, but the organization still needs to understand:
- The scope of the report.
- The services covered.
- The period covered.
- Relevant exceptions.
- Complementary user-entity controls.
- Whether important risks fall outside the report.
The existence of a SOC 2 report should reduce unnecessary duplication where it provides the assurance needed, but it should not automatically end the analysis.
Does ISO 27001 Certification Mean We Do Not Need to Assess the Vendor?
Not necessarily.
ISO 27001 certification can provide useful assurance about an information security management system within a defined scope.
The organization still needs to determine whether that scope and assurance address the risks relevant to the specific relationship.
What If a Vendor Refuses to Complete Our Questionnaire?
Do not automatically reject the vendor.
Determine whether sufficient alternative assurance is available.
The vendor may provide certifications, audit reports, security documentation or other evidence that answers the important risk questions more effectively than the questionnaire.
If the vendor cannot provide sufficient assurance for a material risk, the issue should be escalated for an informed decision.
How Do We Evaluate Vendor Security Evidence?
Evaluate whether the evidence addresses the risks relevant to the relationship.
Consider:
- Scope.
- Recency.
- Independence.
- Exceptions or findings.
- Applicability to the service being purchased.
- Important controls not covered.
Collecting a certification or report is not the same as reviewing what it actually tells the organization.
What Should We Do When a Vendor Has Security Findings?
Determine whether the findings create meaningful risk for the relationship.
Consider:
- Severity.
- Scope.
- Potential business impact.
- Existing compensating controls.
- Vendor remediation plans.
- Timeline.
- Contractual protections.
- Whether the vendor is replaceable.
The organization may require remediation, accept the residual risk, implement internal protections or decide not to proceed.
Who Should Accept Vendor Risk?
The appropriate business risk owner should participate in the decision.
Cybersecurity can explain the security exposure and recommend treatment.
Procurement and legal can address commercial and contractual considerations.
But a material business decision should be made by someone with authority over the potential impact and relationship.
Should Vendors Be Reassessed Every Year?
Not necessarily every vendor and not necessarily on the same schedule.
Reassessment frequency should reflect risk.
Higher-risk relationships may require more frequent review.
Lower-risk relationships may require less.
Changes can also trigger reassessment outside the normal schedule.
What Changes Should Trigger Vendor Reassessment?
Potential triggers include:
- A significant cybersecurity incident.
- A change in the service.
- New access to sensitive data.
- New system integrations.
- Major subcontractor changes.
- Acquisition of the vendor.
- Material control findings.
- Major regulatory changes.
- Significant business dependency changes.
The vendor's risk profile should reflect the current relationship rather than only the state that existed during onboarding.
What Is Continuous Third-Party Monitoring?
Continuous monitoring uses ongoing information to identify changes in vendor risk between formal assessments.
It may include:
- External security ratings.
- Breach and incident information.
- Threat intelligence.
- Financial information.
- Certification changes.
- Service availability.
- Other relevant external signals.
Monitoring should produce decisions, not merely alerts.
The organization needs to define what information is meaningful and what should happen when a material change is detected.
Do Security Ratings Tell Us Whether a Vendor Is Secure?
No.
External security ratings can provide useful signals, but they observe a limited portion of a vendor's environment and may not reflect the specific service or controls relevant to the relationship.
They should be one input into risk analysis rather than a substitute for it.
How Do We Manage Fourth-Party Risk?
Organizations often depend indirectly on subcontractors, cloud providers and other parties used by their vendors.
Fourth-party risk can be important when those dependencies support critical services or sensitive data.
The organization should understand significant downstream dependencies where they materially affect the relationship.
It is not practical to directly assess every company in every vendor's supply chain.
The depth of analysis should reflect the risk.
How Do We Manage Concentration Risk?
Concentration risk occurs when too much of the organization's operation depends on the same provider, technology, geography or other common dependency.
For example, several critical vendors may depend on the same cloud provider.
Individual vendor reviews may look acceptable while the combined dependency creates a larger enterprise risk.
TPRM should therefore consider important portfolio-level dependencies, not only individual vendor scores.
How Do We Handle Critical Vendors Differently?
Critical vendors may require stronger governance because failure could materially disrupt the business.
That may include:
- Deeper due diligence.
- Executive risk ownership.
- Business-continuity planning.
- Stronger contractual protections.
- More frequent monitoring.
- Incident-notification requirements.
- Exit or contingency planning.
Criticality should influence the program even when the vendor's cybersecurity controls appear strong.
Should TPRM Include Business Continuity and Resilience?
Yes, when availability of the third party is important to the organization.
A vendor may have strong cybersecurity controls but still represent substantial operational risk if the business cannot function without its service.
The organization should consider what happens if the vendor is unavailable, compromised or no longer able to provide the service.
What Role Do Contracts Play in Third-Party Risk?
Contracts can establish important risk protections, including requirements involving:
- Security controls.
- Incident notification.
- Data protection.
- Subcontractors.
- Audit rights.
- Insurance.
- Business continuity.
- Data return or destruction.
- Termination.
Contractual language does not eliminate risk, but it can clarify expectations and remedies.
Should Every Vendor Have the Same Cybersecurity Contract Language?
Not necessarily.
Contract requirements should reflect the relationship and risk.
A highly critical vendor handling sensitive information may require stronger provisions than a low-risk vendor with no access to systems or data.
Standard language can improve consistency while allowing risk-based variation when appropriate.
What Happens When a Vendor Cannot Meet Our Security Requirements?
The organization should understand the gap and decide what to do with it.
Options may include:
- Require remediation.
- Implement internal compensating controls.
- Modify the service or scope.
- Negotiate contractual protections.
- Accept residual risk.
- Select another vendor.
The decision should reflect the business need and risk rather than automatically blocking or approving the vendor.
How Should Vendor Exceptions Be Managed?
Exceptions should be documented, owned, approved and revisited.
An exception should identify:
- The requirement not being met.
- The resulting risk.
- Any compensating controls.
- The risk owner.
- The approval.
- The review or expiration date.
Exceptions should not become permanent simply because the original decision is forgotten.
How Should TPRM Connect to the Cyber Risk Register?
Significant third-party risks should inform the organization's broader understanding of cyber risk.
Not every vendor finding belongs on the enterprise risk register.
But material vendor dependencies, systemic weaknesses or significant accepted risks may need leadership visibility.
See how to build a cyber risk register leadership can actually use.
How Should TPRM Connect to the Cyber GRC Operating Model?
The operating model should define:
- How vendors enter the process.
- How risk tiering works.
- Who performs assessments.
- Who owns findings.
- Who can accept risk.
- How reassessments occur.
- How significant issues are escalated.
- How leadership receives information.
See how to build a Cyber GRC operating model.
Can We Manage TPRM in Spreadsheets?
Yes, for a relatively small or simple program.
Spreadsheets become difficult when the organization needs to manage large vendor inventories, tiering, assessments, evidence, findings, approvals, reassessments and reporting.
The right technology depends on program complexity.
See what to do when a GRC program is running on spreadsheets.
Do We Need a GRC or TPRM Platform?
Maybe.
Technology can help manage vendor inventories, workflows, questionnaires, evidence, risk decisions, findings and monitoring.
But technology should support a defined program.
See whether the organization actually needs a GRC platform and how to choose the right GRC platform.
Can We Automate Third-Party Risk Management?
Many parts of the process can be automated.
Potential opportunities include:
- Vendor intake.
- Risk tiering.
- Questionnaire distribution.
- Evidence requests.
- Reminders.
- Approval workflows.
- Reassessment scheduling.
- External monitoring.
- Reporting.
But automation should not eliminate judgment from material risk decisions.
See how to automate compliance without automating bad processes.
Can AI Help With Third-Party Risk Management?
Yes.
AI can help review questionnaires, summarize assurance reports, compare vendor responses, identify potential concerns, draft risk observations and process large amounts of vendor information.
Human review remains important where conclusions affect significant vendor or risk decisions.
The organization should also govern how confidential vendor information is processed through AI systems.
What If Our TPRM Team Is Overwhelmed?
Do not assume more people are the first solution.
Evaluate whether:
- Too many vendors receive high-effort reviews.
- Questionnaires are unnecessarily long.
- Evidence is reviewed repeatedly.
- Processes are too manual.
- Risk tiering is ineffective.
- Low-risk vendors consume disproportionate effort.
- Technology is poorly implemented.
- Work can be outsourced selectively.
See what cybersecurity and GRC work should be outsourced when the team is overwhelmed.
Can Third-Party Risk Management Be Outsourced?
Yes, portions of the operating work can be supported externally.
External support may include:
- Vendor intake.
- Risk tiering.
- Assessment coordination.
- Evidence review.
- Risk analysis.
- Finding management.
- Reassessment.
- Program reporting.
- Technology administration.
Internal business leaders should still retain appropriate ownership of vendor relationships and material risk decisions.
How Does Customer Security Assurance Relate to TPRM?
They are opposite sides of a similar process.
Your organization evaluates vendors because you want assurance about their cybersecurity.
Your customers evaluate your organization for the same reason.
Understanding what provides meaningful assurance can therefore improve both TPRM and customer questionnaire processes.
See why customer security questionnaires become so painful and how to fix the underlying problem.
How Do Multiple Frameworks Affect Third-Party Risk Management?
Different cybersecurity frameworks may contain overlapping third-party or supply-chain requirements.
The organization should avoid building separate vendor-risk processes for every framework when one risk-based TPRM process can support several requirements.
See how to build one cybersecurity program across multiple frameworks.
How Do We Know Whether Our TPRM Program Is Working?
Ask whether the program improves decisions and visibility.
A functioning program should make it easier to understand:
- Which vendors create the most significant risk.
- Why they create that risk.
- Whether appropriate assurance exists.
- What material findings remain.
- Who owns residual risk.
- Which vendors require ongoing attention.
- Where concentration or dependency risk exists.
Completing more questionnaires is not by itself evidence of a mature TPRM program.
What Are Signs Our TPRM Program Is Not Working?
Warning signs include:
- Every vendor receives the same assessment.
- High-risk vendors are not clearly identifiable.
- Questionnaires accumulate without meaningful review.
- Vendor findings remain open indefinitely.
- Risk acceptance is informal.
- Business sponsors do not understand vendor risk decisions.
- Reassessments are missed.
- Monitoring creates alerts nobody acts on.
- Vendor information is scattered across spreadsheets and email.
- The program is measured primarily by assessment volume.
These may indicate the need for process redesign rather than simply more activity.
How Does Hotman Group Help Build and Operate Third-Party Risk Management Programs?
Hotman Group helps organizations design and mature TPRM programs around actual business and cybersecurity risk.
HG can help with vendor inventories, risk tiering, governance, assessment methodology, questionnaires, evidence review, risk ownership, remediation, exception processes, ongoing monitoring, GRC technology, automation and program reporting.
Hotman Group can also provide operating support when organizations need ongoing TPRM capacity rather than only program design.
The work connects third-party risk to the broader Cyber GRC environment rather than creating another isolated compliance function.
The objective is a TPRM program that protects the organization while remaining proportionate, usable and sustainable.
What If We Know Our Vendor Risk Program Is Broken but Do Not Know Whether the Problem Is Process, Technology or Capacity?
You do not need to diagnose the solution before asking for help.
The underlying issue may involve risk tiering, ownership, assessment design, workflow, technology, staffing or several of these together.
If the broader need remains unclear, see how to approach cybersecurity and GRC problems when you do not know what kind of help you need.
About Hotman Group
Hotman Group is a cybersecurity and Cyber GRC professional services firm that helps organizations solve complex cybersecurity, risk, governance and compliance problems. Hotman Group designs, builds, implements, remediates, operates and matures cybersecurity and GRC programs.
Learn more about Hotman Group's approach to solving complex cybersecurity and Cyber GRC problems.

