TPRM — Third-Party Cybersecurity Risk Management: How to Assess and Monitor Your Vendors

What TPRM Is and Why Third Parties Are Now the Biggest Breach Vector

TPRM (Third-Party Risk Management) is the discipline of identifying, assessing, treating, and monitoring the cybersecurity, operational, compliance, and continuity risks that vendors, partners, integrators, and service providers introduce into an organization. From an information security standpoint, the focus falls on every third party that processes, stores, transmits, or accesses your data and systems — from a KYC provider and a payment gateway to an HR SaaS or a messaging queue.

Third parties are now the biggest breach vector because the attack surface has moved beyond your own perimeter and into the digital supply chain. A typical fintech integrates dozens of APIs (custody, anti-fraud, open finance, communications), and each integration inherits the vendor's security maturity, not yours. The attacker doesn't need to break your WAF: they only need to compromise the weakest link with legitimate access to your data or environment.

Verizon's Data Breach Investigations Report (DBIR 2024) found that 15% of breaches involved a third party — a 68% increase over the prior year — spanning software compromise, data hosting, and partners. Cases like SolarWinds (2020), Kaseya (2021), and MOVEit (2023) showed that a single compromised vendor propagates impact to thousands of organizations at once. In Brazil, the LGPD holds the controller liable for incidents caused by processors (third parties), making TPRM a legal requirement, not just a technical one.

The difference between TPRM and traditional vendor management is scope: vendor management optimizes cost, commercial SLA, and delivery; TPRM measures and reduces the risk that vendor poses to the confidentiality, integrity, and availability of your assets — and it does so continuously, not just at the moment of contracting.

The Third-Party Risk Lifecycle: From Onboarding to Offboarding

An effective TPRM program treats vendor risk as a lifecycle with distinct phases, each with its own triggers and evidence. Skipping any phase creates blind spots — most supply chain incidents exploit vendors that went through an initial due diligence and were never reassessed again.

Onboarding and due diligence: before any data flows, the vendor undergoes an assessment proportional to its risk. You collect an inventory of access, data flows, certifications (ISO 27001, SOC 2 Type II), a security questionnaire, and supporting evidence. The outcome is a go/no-go — or go-with-conditions — decision, with an agreed remediation plan for critical gaps.

Criticality tiering: not every vendor deserves the same scrutiny. Classify them into tiers (Tier 1 to 3, or Critical/High/Medium/Low) based on objective variables: the volume and sensitivity of the data accessed (PII, financial data, credentials), the level of access to production systems, operational dependency, and regulatory exposure. The tier defines the depth of assessment, the frequency of reassessment, and the strictness of the contractual clauses.

Contractual clauses: the contract is the instrument that makes security enforceable. Include the right to audit and pentest, an obligation to notify incidents within a fixed window (24–72h), minimum control requirements (MFA, encryption, segregation), a subcontracting clause (fourth party), a DPA compliant with the LGPD, and the right to terminate for a security failure. Without this, monitoring has no enforcement power.

Continuous monitoring: a vendor's security posture changes between one assessment and the next — an exposed RDP port, an expired certificate, a credential leak on the dark web. Continuous monitoring (detailed below) replaces the annual snapshot with a real-time feed, generating actionable alerts.

Offboarding: termination is the most neglected phase and one of the riskiest. Revoke access and API keys, confirm the destruction or return of data (with attestation), remove active integrations, and update the inventory. Credentials and tokens from decommissioned vendors are a recurring vector for unauthorized access months after a contract ends.

How to Assess a Vendor: SIG Questionnaires, Evidence, Cyber Ratings, and Pentesting

Assessing a vendor combines three layers that validate one another: what the vendor declares (the questionnaire), what it can prove (evidence and certifications), and what you observe from the outside or test directly (cyber rating and pentest). Relying on a single layer produces fragile assessments — questionnaires alone measure declarative honesty, not real posture.

Standardized questionnaires: the SIG (Standardized Information Gathering), maintained by Shared Assessments, is the market's reference questionnaire. The SIG Core covers roughly 19 risk domains (security, privacy, continuity, cloud, AI), while the SIG Lite offers a streamlined version for lower-criticality vendors. Alternatives include the CAIQ (Cloud Security Alliance, for cloud providers) and questionnaires derived from ISO 27001 or the NIST CSF. The value of a questionnaire lies in standardizing and comparing — not in replacing proof.

Evidence and certifications: declarations need backing. Request the SOC 2 Type II report (not just Type I), the ISO 27001 certificate and Statement of Applicability, results of a recent pentest (executive summary), security policies, and, where applicable, PCI-DSS attestations. Evaluate the date and scope: a SOC 2 from two years ago, or one that excludes the system you use, has limited value.

Cyber rating (security rating): platforms like SecurityScorecard, BitSight, and UpGuard generate an external, non-intrusive score of a vendor's security posture — analyzing IP reputation, TLS certificates, patching, headers, port exposure, and signs of compromise. It is a continuous and objective measure, useful for triage and monitoring, but it measures the external surface: it does not see internal controls or application security in depth.

Third-party pentesting: for Tier 1 vendors and critical integrations, the most conclusive assessment is an authorized penetration test of the service the vendor delivers to you — APIs, portals, integrations. It reveals real flaws (IDOR, broken authentication, injection, cross-tenant data exposure) that questionnaires and ratings will never catch. At Decripte, we implement TPRM programs and run third-party pentests under formal scope and authorization, turning contractual assumptions into technical evidence.

Continuous Monitoring: Attack Surface, Dark Web, and Sanctions

A point-in-time assessment answers 'how is the vendor today'; continuous monitoring answers 'what changed since yesterday'. It is the component that separates a mature TPRM program from an annual checklist, and it operates across three complementary fronts.

External attack surface monitoring (EASM): continuously maps and observes the vendor's internet-facing assets — domains, subdomains, certificates, services, open ports, outdated software, and insecure configurations. Relevant changes (a new VPN without MFA, an exposed bucket, an expired certificate, a critical CVE in a public-facing service) trigger alerts that anticipate risk before exploitation.

Dark web and leak monitoring: tracks forums, marketplaces, Telegram channels, and dumps in search of the vendor's corporate credentials, data it holds on your behalf, or mentions of an imminent or already-occurred compromise. Leaked credentials from a vendor with access to your environment are one of the most actionable signals of supply chain risk.

Sanctions, reputation, and business-health monitoring: checks restrictive lists (OFAC, UN, national lists), sanctions exposure, relevant litigation, and signs of financial instability that affect service continuity. A critical vendor in operational collapse is a availability risk as severe as any technical failure.

Continuous monitoring only creates value when integrated into the process: alerts need an owner, a severity, a response SLA, and a reassessment trigger. At Decripte, we feed third-party monitoring with our own OSINT intelligence and attack-surface correlation, connected to our SLA for containing a critical incident within 1 hour — because detecting a vendor's risk without the capacity to respond merely documents the breach.

Reference Frameworks: ISO 27036, NIST SP 800-161, NIST 800-53, and CIS

Building a TPRM program on recognized frameworks ensures coverage, auditability, and a common language with auditors and clients. Four references underpin most mature programs, and they complement rather than compete with one another.

ISO/IEC 27036 — 'Information security for supplier relationships': this is the standard dedicated to the topic. Part 1 provides an overview and concepts; Part 2 defines security requirements in the supplier relationship; Part 3 addresses ICT supply chain security specifically; and Part 4 covers cloud services. It connects directly to controls A.5.19–A.5.22 of ISO 27001:2022, which require managing security in supplier relationships.

NIST SP 800-161 Rev. 1 — 'Cybersecurity Supply Chain Risk Management (C-SCRM)': the deepest guide for cyber supply chain risk. It defines practices for integrating C-SCRM at the strategic, mission, and operational levels, with controls, risk profiles, and an extensive set of safeguards for third and fourth parties. It is the unavoidable reference for organizations with a complex supply chain or a regulatory mandate.

NIST SP 800-53 Rev. 5: the catalog of security and privacy controls includes the SR (Supply Chain Risk Management) family, with controls such as SR-3 (supply chain protections), SR-5 (acquisition strategies), SR-6 (supplier assessment), and SR-11 (component authenticity). It provides the control vocabulary that operationalizes 800-161.

CIS Controls v8: includes Control 15 ('Service Provider Management'), with practical, prioritized safeguards — inventory providers, classify them, require security requirements in contracts, monitor them, and decommission them securely. It is the most accessible starting point for startups and early-stage companies before adopting denser standards. In practice, we recommend anchoring governance in ISO 27036/27001, deepening the critical supply chain with NIST 800-161, and using CIS Control 15 as an operational implementation checklist.

How to Choose a TPRM Platform

TPRM platforms automate inventory, questionnaires, the assessment workflow, cyber ratings, and continuous monitoring. The wrong choice yields a repository of PDFs no one reads; the right one turns TPRM into a living process. Evaluate platforms against concrete criteria, not marketing promises.

Automated inventory and tiering: the platform should discover and centralize every vendor (including shadow IT, via integration with spend and SSO) and support criticality tiering with customizable criteria. Without a complete inventory, everything else assesses only the visible portion.

Evidence-based assessment, not just questionnaires: prioritize platforms that combine questionnaire libraries (SIG, CAIQ), evidence collection and validation, and native or integrated continuous cyber ratings. The ability to map responses to multiple frameworks (ISO 27036, NIST, SOC 2) avoids rework at every audit.

Real continuous monitoring: confirm coverage of external attack surface, dark web, and sanctions, with alerts configurable by severity and owner. Check the update frequency and the false-positive rate — a rating that fires irrelevant alerts is abandoned within weeks.

Workflow, integration, and governance: the platform needs an approval workflow, an audit trail, remediation management with SLAs, and API integration with GRC, ticketing, and SSO. Also evaluate the responding vendor's experience: hostile portals reduce response rates and data quality.

Final decision criteria: fourth-party scope (sub-suppliers), data residency and LGPD compliance, a pricing model based on the number of vendors monitored, and support for board and client reporting. A platform is a means, not an end: Decripte helps select and deploy the right tool for each client's size and supply chain, and to operate the program — because software without process and without response capacity merely organizes risk without reducing it.

Passo a passo

1. Inventory all third parties: identify every vendor, partner, and integration that processes, stores, transmits, or accesses your data and systems, including shadow IT via spend and SSO logs.
2. Tier by criticality: assign risk levels based on the sensitivity and volume of data accessed, the level of production access, operational dependency, and regulatory exposure.
3. Define the assessment standard per tier: set the required depth by level — SIG Lite and cyber rating for low risk; SIG Core, SOC 2 Type II, and pentesting for critical vendors.
4. Embed security in contracts: enforce the right to audit and pentest, incident notification within a fixed window, minimum controls (MFA, encryption), a subcontracting clause, an LGPD-compliant DPA, and termination for a security failure.
5. Run due diligence and decide go/no-go: apply the questionnaire, collect and validate evidence, run a cyber rating and, for Tier 1, a pentest; log gaps with a remediation plan and deadline.
6. Activate continuous monitoring: track external attack surface, dark web, and sanctions, with alerts by severity, owner, and response SLA, plus event-driven reassessment triggers.
7. Standardize offboarding and measure the program: revoke access and keys, confirm data destruction with attestation, update the inventory, and report KPIs (coverage, assessment time, open gaps) to the board.

Perguntas frequentes