Third Party Risk Monitoring: Watching the Vendors You Can’t Control

Most serious breaches in the last few years did not start with someone kicking down the front door of the victim. They started with a supplier, a software library, a managed service provider, or a billing contractor who had a quiet trusted connection into the target. The attacker walked in through a door the victim had propped open for a partner. That is the uncomfortable truth behind third party risk: your security posture is only as strong as the weakest organization you have chosen to trust, and you usually have far less visibility into them than into yourself.

Third party risk monitoring is the practice of continuously watching the security and operational health of those external organizations, rather than assessing them once at onboarding and assuming nothing changes. A vendor that passed a questionnaire in January can be compromised in June, let a certificate expire, leak credentials on GitHub, or quietly move your data to a subprocessor in a jurisdiction you never approved. Monitoring is what turns a static snapshot into a live signal.

Why a Point-in-Time Assessment Is Not Enough

The traditional model of vendor risk management is a spreadsheet and a questionnaire. You send a supplier a list of 200 questions, they self-attest, you file the answers, and you move on. The problem is obvious once you say it out loud: the answers reflect a single moment, they are self-reported, and nobody re-checks them until the annual renewal — if then.

Real risk is dynamic. Consider what can change between assessments:

• A vendor gets breached and does not tell you promptly (or at all).
• Their public-facing infrastructure develops new vulnerabilities as CVEs are disclosed.
• They acquire a smaller company with weaker hygiene and inherit its exposure.
• An employee posts an internal API key to a public repository.
• Their TLS certificates expire or fall back to weak ciphers.
• A fourth party — your vendor’s vendor — is the actual source of compromise.

Monitoring exists to catch these shifts close to when they happen, so you can act while the window still matters.

What You Actually Monitor

Effective programs blend several data sources rather than relying on any single score. Broadly, the signals fall into a few buckets:

• External attack surface. What does the vendor look like from the internet? Open ports, exposed admin panels, outdated web servers, misconfigured cloud storage, and expired or weak certificates. This is essentially continuous outside-in reconnaissance.
• Breach and credential exposure. Appearances in breach dumps, credentials for sale on criminal forums, and mentions in ransomware leak sites.
• Reputation and threat intelligence. IPs and domains showing up on blocklists, hosting malware, or participating in botnet traffic.
• Business and compliance health. Changes in certifications (SOC 2, ISO 27001), financial distress, ownership changes, or negative regulatory findings.
• Fourth-party and dependency mapping. The subprocessors and software dependencies your vendor relies on, so a compromise two hops away does not blindside you.

Some of this you can gather yourself with open-source tooling. A lightweight, ethical, outside-in check of a vendor’s public footprint might use standard reconnaissance utilities:

# Enumerate a vendor's public subdomains from certificate transparency logs
curl -s "https://crt.sh/?q=%25.vendor.com&output=json" | \
  jq -r '.[].name_value' | sort -u

# Check the TLS posture of a discovered host: protocol versions, cert expiry, weak ciphers
nmap --script ssl-enum-ciphers,ssl-cert -p 443 app.vendor.com

The crt.sh query pulls hostnames a vendor has requested certificates for, which quickly reveals forgotten or shadow assets. The nmap SSL scripts report the negotiated protocols, cipher strength, and certificate validity — a stale certificate or a lingering TLSv1.0 endpoint is a small but telling hygiene signal.

You can also gauge exposure passively, without touching the vendor’s systems directly, by querying an internet-wide scan index such as Shodan:

# Find internet-exposed services attributed to a vendor's org, without scanning them yourself
shodan search "org:\"Vendor Inc\" port:3389" --fields ip_str,port,product

Here an exposed RDP service (port 3389) on a vendor’s network is worth a question. The point is not to run intrusive tests — always stay within contractual and legal scope — but to see roughly what an attacker sees.

Building a Program, Not Just Buying a Tool

Monitoring only creates value if it feeds decisions. A dashboard full of red flags nobody acts on is theater. A workable program tends to move through a few stages:

1. Inventory and tier your vendors. You cannot watch everyone equally. Rank suppliers by the sensitivity of the data they touch and how deeply they are integrated. A payroll processor holding employee PII and a stationery supplier are not the same risk.
2. Set expectations in the contract. Right-to-audit clauses, breach-notification timelines (e.g. 72 hours), required security controls, and approval for subprocessors give your monitoring teeth. A signal is only useful if you have the contractual standing to demand a fix.
3. Establish a baseline. Capture each critical vendor’s current posture so you can detect change, which is often more meaningful than an absolute score.
4. Define thresholds and ownership. Decide in advance what severity triggers what response, and name the human who owns each vendor relationship.
5. Wire monitoring to a workflow. Route findings into ticketing and your incident process. Close the loop by confirming remediation, not just logging the alert.

Getting the Signal-to-Noise Ratio Right

The single biggest failure mode of these programs is alert fatigue. Outside-in scanners generate a lot of findings, and many are cosmetic or attributed to the wrong company. A few practices keep the program credible:

• Validate attribution. Confirm that flagged assets actually belong to the vendor before you escalate. Shared hosting and cloud IP ranges cause frequent misattribution.
• Weight by materiality. A missing security header on a marketing microsite is not the same as leaked admin credentials for the system holding your customer data. Prioritize by what the vendor can actually reach in your environment.
• Prefer trends over point scores. A vendor sliding from good to poor over a quarter is a stronger warning than a mediocre absolute grade.
• Talk to your vendors. Monitoring works best as a collaborative conversation, not a gotcha. Give them the finding, a reasonable timeline, and a way to dispute false positives.
• Don’t over-trust a single number. Security ratings are a useful triage input, but they are estimates built on external data, not ground truth about internal controls.

Where Regulation Pushes This

Continuous third party oversight is increasingly not optional. Financial regulators and data-protection regimes now expect it explicitly. The EU’s DORA framework requires financial entities to manage and monitor ICT third party risk, including concentration risk from over-reliance on a few critical providers. GDPR makes you accountable for the processors handling personal data on your behalf. Sector rules like the NYDFS cybersecurity regulation, and frameworks such as NIST SP 800-161 for supply chain risk and ISO 27036 for supplier relationships, all point in the same direction: know your suppliers, set requirements, and keep watching. Treating monitoring as a compliance-driven baseline rather than a nice-to-have is now the safer bet.

The Takeaway

Third party risk monitoring is really an admission that trust and verification have to coexist. You will always depend on outside organizations, and you can never fully control them — but you can refuse to be surprised by them. The organizations that handle this well are not the ones with the most impressive scanning tools; they are the ones who tier their vendors honestly, write real requirements into contracts, watch for meaningful change rather than drowning in noise, and have a named person ready to pick up the phone when a signal goes red. Do that consistently, and the supplier who gets breached next quarter becomes a managed incident instead of your breach.