Modern Third-Party Risk Management: Broken or Outcome-Oriented?

A vendor states in March that critical security patches are deployed within 30 days. The answer is logged, scored and filed. Every subsequent report treats it as current.

In September, the vendor restructures its infrastructure team. Ownership of patching becomes unclear, and remediation slows. Nothing in the third-party risk management (TPRM) program detects the change until the questionnaire is issued again the following March.

For a CISO accountable to the board for third-party exposure, that six-month gap is where the real risk lies.

An outcome-oriented TPRM program does more than collect answers. It continuously compares what vendors say about their controls with observable changes in their external security posture, then turns meaningful findings into timely action.

Why traditional TPRM programs fall short

Many third-party risk programs still depend on spreadsheets, email attachments and periodic questionnaires.

The vendor inventory may sit in one workbook, tiering decisions in another, and supporting evidence in folders of PDFs. Reminders are managed through calendar entries, while questionnaire responses are manually transferred into tracking documents.

This approach creates three problems:

• Assessments become outdated soon after completion.
• Reviews cannot scale consistently across hundreds of suppliers.
• Answering urgent exposure questions requires manual investigation.

A small team may be able to conduct detailed reviews of several dozen critical vendors. The longer tail of lower-tier suppliers often receives a lighter assessment or none at all.

The weakness becomes clear when a new vulnerability is disclosed. If leadership asks which vendors use the affected technology, the answer should take minutes. In a spreadsheet-led program, it may take days or weeks of emails, file searches and follow-ups.

What changes between vendor assessments?

Vendors do not remain static after submitting a questionnaire.

They launch new services, expose development environments, change hosting providers, allow certificates to expire or continue running technologies affected by newly disclosed vulnerabilities. Lookalike domains may appear, and credentials associated with vendor employees may surface in criminal marketplaces.

Many of these developments can be identified through external monitoring and threat intelligence.

External monitoring can provide visibility into:

• Internet-facing assets
• Observable technologies and versions
• Exposed services
• Certificate and DNS changes
• Potential misconfigurations
• Data breaches and threat actor claims
• Lookalike or typosquatted domains
• Exposed credentials and dark web mentions

These signals do not replace a vendor assessment. They provide a reason to ask a more specific question before the next scheduled review.

An expired certificate, for example, may indicate a weakness in renewal ownership. An exposed development environment may suggest that a deployment bypassed normal review. A lookalike domain could create a fraud risk for employees who process that vendor’s invoices.

Questionnaires and external monitoring work better together

Questionnaires reveal controls that cannot be reliably observed from outside the organization, including identity and access management, backup procedures, staff training, business continuity and incident response.

External monitoring provides a separate view of the vendor’s observable security posture.

The greatest value comes from comparing the two.

If a vendor states that critical vulnerabilities are remediated within 30 days, but an internet-facing system appears to be running a vulnerable technology, the reviewer has a specific issue to raise.

The observation does not automatically prove that the vendor’s answer is false. Service banners can be inaccurate, and some fixes do not change the visible version string. The finding should therefore be validated and presented as a question, supported by the affected asset, observation date and relevant technical evidence.

This produces a more useful conversation than simply asking the vendor to reconfirm its patching policy.

The comparison also works in the other direction. When the observable attack surface shows no material issues, the assessment can focus on controls that external monitoring cannot evaluate.

What does outcome-oriented TPRM look like?

Outcome-oriented TPRM focuses on reducing exposure and improving vendor accountability, rather than simply completing assessments.

‍

The questionnaire remains important, but it becomes one source of evidence within a broader decision-making process.

Tier vendors by business impact

Monitoring every vendor at the same intensity creates more alerts than most teams can investigate.

A tiered approach helps security teams focus resources where failure would have the greatest business impact. Tiering should consider:

• The sensitivity of the data the vendor processes
• The vendor’s access to systems and production environments
• The operational impact of a disruption
• The difficulty of replacing the vendor at short notice
• Regulatory, financial or reputational exposure

Contract value alone is not an adequate measure of criticality. A small supplier with administrative access to production systems may create more risk than a larger vendor that only submits invoices.

Each tier should also have a defined response expectation. A serious finding affecting a critical vendor might require same-day triage, while lower-risk findings could be reviewed through a weekly or monthly summary. The precise service level should reflect the organization’s risk appetite and operational capacity.

Use technology data to understand concentration risk

A tiered vendor inventory becomes more useful when it includes the technologies observed across vendors’ internet-facing systems.

Following disclosure of a widely exploited vulnerability, teams can identify which vendors may use the affected technology and prioritize follow-up accordingly.

This aggregated view can also reveal concentration risk. Several vendors relying on the same vulnerable technology, hosting provider or managed service provider may create a material exposure even when each individual finding appears minor.

The objective is not to treat every detected technology as a confirmed vulnerability. It is to identify where further validation and vendor engagement are most urgent.

Trigger reviews when risk changes

Annual or quarterly reviews should be supplemented by event-driven reassessments.

Events that may justify an early review include:

• A breach affecting the vendor or a key supplier
• A material change in ownership
• A change in the services provided
• New access to sensitive data or production systems
• A significant deterioration in external security posture
• An exposed service that could affect customer or business data
• A critical vulnerability affecting an observed technology

Organizations should define these triggers in advance, together with who can initiate a review and what level of evidence is required.

When continuous monitoring and questionnaires operate within the same process, reassessment begins because the risk has changed, not simply because the calendar says it is time.

Turn findings into remediation

The vulnerable system belongs to the vendor, so remediation depends on structured engagement.

Every critical vendor should have a named security contact who is separate from the commercial account representative. Contracts should also define security notification, evidence and remediation obligations wherever appropriate. Adding these provisions during contract negotiation or renewal is usually easier than trying to establish them during an incident.

Ownership must be clear internally as well:

• Security validates and explains the finding.
• Procurement manages the contractual relationship.
• The business owner determines the operational response and acceptable level of vendor friction.

Without named owners and deadlines, findings are easily acknowledged and then left unresolved.

Vendors may dispute legitimate findings, particularly when reports lack sufficient evidence. Before contacting the vendor, validate the observation and provide the affected asset, date, technology or configuration, and enough detail for its security team to investigate.

A recorded history of findings, responses and remediation decisions also gives leadership a stronger basis for deciding whether a vendor should retain access to organizational data or systems.

Where CTM360 RiskHub fits

CTM360 RiskHub brings external third-party monitoring and security assessments into a centralized workflow.

RiskHub maps third-party attack surfaces, identifies technologies visible across internet-facing assets and provides aggregate analysis across vendor portfolios. This helps teams identify vendors that may share a vulnerable technology and prioritize investigation based on criticality.

Its questionnaire capabilities support the creation, distribution and tracking of assessments, including evidence collection. CTM360’s published product information describes a library of more than 1,700 control questions with mappings to more than 200 global standards and regulatory frameworks.

As part of CTM360’s consolidated external cybersecurity platform, RiskHub helps organizations move from periodic vendor administration towards continuous, evidence-led third-party risk management.

Request a demo to see how RiskHub can support monitoring and assessments across your vendor ecosystem.

FAQs

What is third-party risk management?

Third-party risk management is the process of identifying, assessing, monitoring and addressing risks introduced by vendors, suppliers, partners and service providers. It covers cybersecurity as well as operational, compliance, financial and reputational risk.

Why are annual vendor questionnaires not enough?

Annual questionnaires provide a point-in-time assessment. A vendor’s systems, technologies, ownership and security posture can change before the next review, leaving organizations unaware of new exposure between assessment cycles.

What is continuous third-party risk monitoring?

Continuous third-party risk monitoring tracks observable changes in a vendor’s external security posture. It may identify exposed services, vulnerable technologies, certificate or DNS changes, threat actor claims, data breaches and other risk signals that require investigation.

Does external monitoring prove that a vendor is vulnerable?

No. External observations can contain incomplete or misleading information. Findings should be validated and used to support targeted vendor engagement rather than treated as definitive proof of a control failure.

How should organizations tier their vendors?

Vendor tiering should reflect the sensitivity of the data handled, access to organizational systems, operational dependency, replacement difficulty and the potential financial, regulatory or reputational impact of disruption.

What should trigger an early vendor reassessment?

Common triggers include a breach, ownership change, material service change, new access to sensitive systems, a serious external security finding or a critical vulnerability affecting technology associated with the vendor.

How can organizations measure TPRM outcomes?

Useful measures include remediation time, overdue critical findings, vendor response time, repeat findings, unresolved risk exceptions and changes in exposure across the vendor portfolio. Questionnaire completion alone does not demonstrate that risk has been reduced.