Table of Contents
Author
James Westlake
James Westlake
Former British Army officer, trained in surveillance and target acquisition, and Bain and Company engagement manager, with more than a decade of experience working in consulting, private equity and venture capital across Western Europe.
Most companies don't build their own infrastructure anymore — they rent it, subscribe to it, and outsource it across dozens of vendors, each with its own access to systems, data, or operations. Third-party risk management is the discipline of tracking what that exposure actually looks like, from the moment a vendor is selected to the day the relationship ends, and it has moved from a compliance afterthought to one of the more consequential risk functions a company runs.
Third-party risk management is the process of identifying, assessing, monitoring, and reducing the risk that comes from any external party with access to a company's systems, data, or operations — vendors, suppliers, contractors, consultants, staffing agencies, resellers, and service providers of every kind. The moment an organisation grants a login, ships data to a subprocessor, or plugs a piece of outsourced infrastructure into its own, it has taken on a share of that third party's risk as its own, whether or not anyone signed off on that transfer explicitly.
The scale of this exposure is easy to underestimate. A mid-size company can easily run on somewhere close to a hundred IT vendors once every SaaS subscription, cloud service, and outsourced function is counted, and large enterprises routinely run well past that. Each one is a separate point of failure that sits partly outside the company's direct control — which is exactly what makes TPRM different from ordinary internal risk management: the organisation is accountable for exposure it doesn't fully own, can't directly patch, and often can't even fully see.
It's worth being precise about what counts as a "third party" in this context, because the category is broader than the word "vendor" suggests. A cloud hosting provider is a third party. So is a payroll processor, a marketing agency with access to the customer list, a law firm holding sensitive contracts, a staffing agency placing contractors inside the building, and a franchisee operating under the company's brand. Anyone with a standing relationship to the company's systems, data, brand, or operations belongs inside the TPRM program's scope — narrowing that scope to "software vendors" is one of the more common ways a program ends up with blind spots it doesn't know it has.
TPRM is also distinct from general enterprise risk management in one specific way: an internal risk owner can usually fix what they find. A CISO who discovers an unpatched server patches it. A TPRM lead who discovers the same gap at a vendor has to ask, escalate, or in the worst case walk away from the relationship — the fix is never entirely in their own hands, and that dependency is the reason the discipline needs its own dedicated process rather than folding into a general risk register.
It's also worth distinguishing TPRM from corporate due diligence, a related but broader discipline: corporate due diligence typically applies to a one-off event — an acquisition, an investment, a major partnership — while TPRM is the ongoing program that keeps assessing the same vendor relationships for as long as they exist. In practice, the two overlap constantly: a company running due diligence ahead of a deal often finds itself inheriting the target's entire vendor risk profile along with everything else in the transaction.
Some of the most consequential breaches of the last decade didn't start with the victim company at all. A large US retailer's payment systems were compromised after attackers stole network credentials from its HVAC contractor — a vendor with no obvious reason to touch payment infrastructure, but with just enough network access to become the entry point for tens of millions of stolen card numbers. A widely used network-monitoring platform was turned into a delivery mechanism for a nation-state supply chain attack after its software build process was quietly compromised, spreading a backdoor to thousands of downstream customers who had no way of knowing their trusted update had been tampered with. A remote-management tool used by managed service providers was exploited through a previously unknown vulnerability to push ransomware simultaneously to hundreds of the providers' client organisations in a single coordinated campaign. None of these companies were breached through their own front door — in each case, the actual point of failure sat one or two steps removed from the organisation that ultimately absorbed the damage.
That pattern — the entry point sitting outside the company's own perimeter, the damage landing squarely inside it — is why third-party risk gets treated as a board-level issue rather than a procurement footnote. It's also why regulation has moved decisively in the same direction over the past several years. GDPR holds a data controller responsible for how its processors handle personal data, regardless of whose systems actually mishandled it. HIPAA extends liability to business associates handling protected health information, closing the loophole where a hospital's vendor could mishandle patient records without the hospital sharing the exposure. The EU's DORA regulation requires financial institutions to map, classify, and stress-test their ICT third-party dependencies as a formal, auditable obligation, not a best-effort exercise. NIS2 pushes an equivalent expectation into a much wider set of critical-infrastructure sectors across the EU. PCI DSS requires merchants to produce evidence — not just assurance — that any service provider touching card data meets the same security bar the merchant itself is held to.
None of these frameworks treat "our vendor did it" as a defence, and that's the underlying shift TPRM programs have had to absorb: the contracting organisation carries the accountability regardless of where the technical failure actually occurred, which means the quality of a company's vendor oversight is now something a regulator, an auditor, or a plaintiff's lawyer can and will ask to see documented.
It's also worth being clear about what "documented" actually means in this context, because it's the detail that trips up programs that otherwise look reasonable on paper. It isn't enough to have assessed a vendor once; a regulator investigating an incident will typically want to see the assessment history, the criticality tier the vendor was assigned and why, what was found, what remediation was required, whether that remediation was actually verified as complete, and what the monitoring cadence was between the assessment and the incident. A program that can produce that trail moves through a regulatory inquiry very differently than one that can only say "we ran a questionnaire when we onboarded them in 2021."
A mature TPRM program isn't a single review — it's five phases that repeat and overlap across the life of every vendor relationship, and skipping any one of them tends to be where the program's actual failures happen.
1. Due diligence and onboarding. Before a contract is signed, the vendor gets evaluated on security certifications (SOC 2 reports, ISO 27001 certification, penetration test results where available), financial stability, compliance history, insurance coverage, and — critically — the specific scope of access it will actually need once live. This is also the stage where vendor verification work matters most, since a document that looks complete and a vendor that's actually operating as described aren't automatically the same thing. This is also where access boundaries get set: the goal is giving a vendor exactly the permissions its role requires, not the broadest access that happens to be convenient to configure on day one and gets forgotten about afterward. A vendor onboarded with more access than its job requires is a liability the company created for itself, not one the vendor introduced.
2. Risk assessment. Once onboarded, a vendor gets scored against a structured framework — typically a mix of standardised questionnaires, independent security ratings, and compliance mapping against the regulations relevant to what the vendor actually touches — and sorted by criticality. A payroll processor with access to financial systems and a stock-photo vendor with no system access at all are not the same risk category, and treating them identically doesn't make the program more thorough; it just spends review capacity on the vendor that didn't need it while the critical vendor gets the same shallow pass.
3. Remediation and mitigation. When an assessment turns up a gap — an expired certificate, a missing multi-factor authentication requirement, an unpatched system, a subcontractor that was never disclosed — the fix works best as a collaborative process with a clear deadline and a defined owner, not a one-way ultimatum delivered by email. Technical controls get implemented (MFA enforcement, encryption at rest and in transit, a documented patch cadence), and the deadline gets tracked the same way an internal remediation item would be. Most vendor relationships survive a remediation cycle intact; the ones that don't are usually the ones where the gap got flagged and then ignored by both sides rather than fixed.
4. Continuous monitoring. A vendor that passed its assessment in January can look completely different by June — a breach disclosed publicly, a ransomware incident that never made the news, a leadership change that shifts the company's risk appetite, a new subprocessor quietly added without notice. Continuous monitoring is what closes that gap between assessments: automated security ratings that update as a vendor's external posture changes, periodic re-assessment on a cadence matched to criticality, review of any incident the vendor discloses, and — where the contract allows for it — visibility into the vendor's own vendors, the fourth and fifth parties a company never directly contracted with but still depends on indirectly. The distinction between screening a vendor once and monitoring it continuously matters here specifically: a clean result at a single point in time answers a different question than an ongoing watch for what changes afterward.
5. Offboarding. Ending a vendor relationship needs the same rigour as starting one, and it's the phase most programs treat as an afterthought. Access gets revoked everywhere it was granted — not just the primary system, but every integration, API key, and shared credential that accumulated over the life of the relationship. Data gets recovered or verifiably destroyed, with confirmation in writing rather than assumed. And every internal team that touched the relationship — IT, finance, the business unit that actually used the service — gets notified so nothing keeps quietly running on old access after the contract has formally ended. A surprising share of breach post-mortems trace back to exactly this: a vendor relationship that ended on paper but never actually got shut down in the systems.
Vendor risk isn't one thing — it's several distinct categories that happen to travel through the same relationship, and a program that only screens for one tends to miss the others entirely. A security team running the assessment naturally gravitates toward the cybersecurity column and can genuinely miss a financial-stability or geopolitical problem sitting in plain sight in the same vendor file, simply because it wasn't the question they were trained to ask.
Responsibility for third-party risk rarely sits with one team, and that's usually by necessity rather than poor design. IT evaluates the technical access and controls a vendor actually needs. Procurement negotiates the contract terms that determine what's enforceable later — a security requirement that never made it into the contract is a request, not an obligation. Compliance maps the vendor against the regulatory frameworks relevant to what it touches. Security runs the technical assessments and monitoring. And the business unit that actually wants the vendor owns the day-to-day relationship, which is often where the pressure to skip a step originates, since that team is usually the one most motivated to get the vendor live quickly.
Organisations with a mature program usually name someone — a dedicated TPRM lead, a cross-functional vendor risk committee, sometimes a standalone function reporting into risk or security — whose job is specifically making sure those pieces don't fall through the gaps between departments. Without that ownership, it's common for a vendor to get security-reviewed by one team, contractually approved by another, and never actually reconciled between the two.
A simple responsibility split that tends to hold up in practice: the business unit that wants the vendor initiates the request and owns the ongoing working relationship; procurement owns the contract terms and makes sure security and compliance requirements actually land in the signed agreement rather than a separate email that gets forgotten; security and compliance own the assessment itself, sign-off, and monitoring cadence; and the TPRM lead or committee owns the process as a whole — making sure a vendor doesn't go live without every one of those steps having actually happened, in order, with a record of it.
Board-level attention has grown here too, largely because regulators now expect it explicitly. A framework like DORA doesn't just ask whether a financial institution assessed its critical ICT vendors — it asks whether the board can demonstrate it oversaw that process, with documentation to match. That's a materially different standard than "someone in IT ran a questionnaire once," and it's pushing TPRM further up the org chart than it historically sat, with board risk committees now routinely reviewing vendor concentration and critical-vendor exposure as a standing agenda item.
The financial case for TPRM is easiest to see in reverse: what a weak program actually costs once something goes wrong. The direct costs are the obvious ones — incident response, forensic investigation, regulatory fines where a breach notification obligation was triggered, and the legal spend that follows almost any breach involving customer data. Those numbers are usually large enough on their own to justify a program that catches the problem earlier.
The indirect costs tend to run longer and are harder to put a single number on. Customer churn after a publicised vendor-related breach rarely shows up immediately — it shows up over the following renewal cycle, as customers who had other options quietly don't renew. Deal friction is another: a company with a documented, defensible TPRM program moves through an acquirer's or major customer's own due diligence process faster than one that has to reconstruct its vendor history from scratch under time pressure. And the opportunity cost of a reactive program — one that only ever assesses a vendor after something has already gone wrong with it — is the incidents that never happened to get investigated because the program didn't know to look, which is by definition the hardest cost of all to measure.
A handful of reference frameworks keep TPRM programs from being reinvented from scratch at every company, and using the right one saves both sides of the relationship real time. ISO 27036 sets out information-security requirements specifically for supplier relationships, giving both buyer and vendor a shared reference point. NIST SP 800-161 gives a detailed playbook for cyber supply chain risk management, originally written for US federal contractors but now widely adopted well beyond that original audience because it's simply thorough. SOC 2 reports, produced by an independent auditor against the AICPA's Trust Services Criteria, have become close to a baseline expectation for any vendor handling sensitive data, and a vendor that can't produce one is worth asking why.
On the questionnaire side, the Standardized Information Gathering (SIG) questionnaire and the Cloud Security Alliance's CAIQ give assessors a common, comparable format instead of every company writing its own from scratch — useful for the assessor, and just as often a relief for the vendor filling out the fifth nearly-identical custom questionnaire that quarter. The Shared Assessments program, which maintains the SIG, also runs a broader membership community built around exactly this problem — too many buyers asking the same vendor slightly different versions of the same questions. NIST's Cybersecurity Framework (CSF), while not written specifically for third parties, gets used constantly as the shared taxonomy that lets a buyer's internal risk categories and a vendor's own security program describe the same controls in compatible language. A growing number of programs now supplement or replace parts of this manual process with AI-assisted questionnaire review, which speeds up the first pass without replacing the judgement needed on anything the automated read flags as ambiguous.
None of these frameworks replace judgement, and none of them were built to. They standardise the questions and give both sides a shared vocabulary; they don't answer whether a specific vendor's specific answer is actually good enough for a specific relationship, at a specific level of access, at this specific company. That judgement call is still where the actual risk decision gets made.
Not every vendor deserves the same depth of review, and most mature programs formalise that into three or four tiers rather than leaving it to whoever happens to run the assessment that week.
A typical structure runs something like this:
Tier 1 (critical) covers vendors with access to sensitive data, core systems, or operations the company can't function without — a cloud infrastructure provider, a payment processor, a core banking platform. These get the full lifecycle treatment: deep due diligence, continuous monitoring, annual reassessment at minimum, and board visibility if the relationship is critical enough.
Tier 2 (significant) covers vendors with meaningful but bounded access — a marketing platform with customer email addresses, an HR system with employee records. These warrant a real assessment and periodic monitoring, but not the same intensity as Tier 1.
Tier 3 (limited) covers vendors with minimal or no system access — an office supplies vendor, a catering service — where a lightweight check at onboarding is usually sufficient, and ongoing monitoring adds cost without adding much protection.
The tiering decision itself is where a surprising number of programs go wrong. It's tempting to tier by contract value, since that's the number everyone already has on hand, but contract value and risk don't reliably track each other — a nearly-free open-source library embedded in production code can carry more risk than an expensive but access-limited consulting engagement. The right tiering questions are about access and dependency, not spend: what data can this vendor reach, what happens operationally if this vendor disappears tomorrow, and how hard would it be to replace them on short notice — the same distinction our KYB vs KYC piece draws between checking a person and checking the business behind them: tiering a vendor by spend checks the contract, not the actual entity holding the access.
The vendor risk questionnaire is the most familiar artifact in TPRM, and also the one most likely to be misunderstood as the whole assessment rather than one input into it. A questionnaire — whether a custom internal one or a standardised format like SIG or CAIQ — asks a vendor to self-report on its security controls, data handling practices, subprocessor list, incident history, and compliance posture. That self-reported data is useful, but it's exactly that: self-reported, filled out by someone at the vendor whose job often depends on the answers looking clean.
That's why questionnaire responses hold up best when checked against something the vendor doesn't control. An independent security rating gives an outside-in view of the vendor's actual exposed infrastructure, regardless of what the questionnaire claims about patch management — the same digital risk management discipline applied specifically to a vendor's own footprint rather than the buyer's. Public records — litigation history, adverse media, corporate registry filings — surface issues a questionnaire was never designed to ask about, like an ownership change or an unresolved lawsuit. And for vendors handling genuinely sensitive access, a direct technical assessment or penetration test finds gaps no self-report ever will, because it doesn't rely on the vendor accurately describing its own weaknesses.
The practical takeaway is that a questionnaire response and a clean rating pointing the same direction is a reasonably strong signal; a questionnaire response and an independent check pointing in different directions is exactly the case that needs a human to look closer, not an automated score to average the two into something that looks fine on a dashboard.
A company standing up its first formal TPRM program doesn't need to build the full five-phase lifecycle on day one — starting with a partial version that actually runs is worth more than a fully mapped-out design that never gets implemented.
The first real step is the vendor inventory, and it's usually messier than expected: pulling together every active contract, every SaaS subscription on a corporate card, and every integration with system access, since a meaningful share of a company's actual vendor list typically isn't in the procurement system at all. From there, a rough criticality tier — even a simple high/medium/low split — lets the program focus its limited early capacity on the vendors that actually carry risk, rather than spreading a thin first pass evenly across everything at once. A standard questionnaire, even a short one, gets applied to the Tier 1 and Tier 2 list, paired with whatever independent verification is feasible at that stage — often just a free or low-cost security rating to start.
The remediation and monitoring pieces tend to come next, once the assessment backlog is under control, followed by contract language updates — adding flow-down and audit-right clauses to new contracts going forward, since retrofitting them into existing agreements is usually a slower, renewal-by-renewal process. Offboarding discipline is worth building in from the start rather than bolting on later; it's a much smaller lift to design an access-revocation checklist before the first vendor relationship ends than to reconstruct one after several have already ended quietly and incompletely.
As board-level scrutiny of third-party risk has increased, so has the expectation that a TPRM program can produce something more useful for that audience than a list of completed questionnaires. What tends to land well at board level is a small set of metrics tracked over time: the number and proportion of critical vendors currently overdue for reassessment, the count of open high-severity remediation items and how long they've been open, concentration exposure — how much of the vendor spend or critical function sits with a small number of providers — and a short narrative on any material incident or near-miss involving a third party since the last report.
What tends to land badly is the opposite: a raw count of vendors assessed, framed as a completion percentage, with no indication of whether the assessments that matter most actually got the deeper look they needed. A board doesn't need to see that 400 vendors were reviewed this quarter; it needs to know whether the five vendors that could actually hurt the company were reviewed properly, and what's still open on the ones that weren't.
A security rating tells a buyer that a vendor's external posture looks reasonable — patched systems, a clean certificate, no obvious exposed ports. It doesn't tell them whether the vendor's ownership changed hands last year to a group with undisclosed conflicts of interest, whether the vendor's "clean" compliance history has a lawsuit sitting one jurisdiction over that never made it into a database, or whether the subcontractor the vendor quietly added last quarter operates somewhere that puts the whole relationship inside a sanctions-exposed corridor.
Take a case that comes up often in our own work: a company runs a standard TPRM questionnaire and automated rating on a new logistics vendor ahead of a contract renewal, and the vendor comes back clean — certifications current, no adverse security findings, nothing flagged. But the vendor's ownership structure traces back through two holding companies to a beneficial owner who also controls a separate entity that appeared, under a different name, in a sanctions enforcement action two years earlier. No security questionnaire was ever going to surface that; it sits in corporate registries and court records, not in a vulnerability scanner. Untangling that ownership chain — checking whether the intermediate holding company is a real operating business or a shell company registered purely to obscure the ultimate beneficial owner, checking that owner against sanctions and adverse-media records, and confirming whether the connection is coincidental or disqualifying — is exactly the kind of work our third-party due diligence and sanctions screening teams do on cases like this: going past the rating and the registry into the open-source record a standard TPRM workflow doesn't reach. Our cyber security risk management work covers the parallel technical side: mapping a vendor's actual external attack surface with the same open-source method, rather than taking an automated score as the final word.
A few shifts are reshaping how TPRM programs get run, and most of them point the same direction: toward more visibility, further down the chain, faster than manual processes can keep up with. Supply chain attacks — compromising one vendor to reach hundreds or thousands of its downstream customers at once — keep proving more efficient for attackers than targeting companies one at a time, and defenders have had to respond by extending visibility past the direct vendor into the fourth and fifth parties behind it, which is a much harder problem than assessing a single first-party relationship. The attack surface itself keeps growing as cloud services, SaaS subscriptions, and connected devices multiply faster than most vendor inventories can track them, which means the inventory problem alone — simply knowing what's actually in scope — has become a genuine technical challenge rather than a spreadsheet exercise.
Regulatory enforcement has tightened in step, with DORA, NIS2, and their equivalents elsewhere turning "we assessed our vendors" from a best practice into an audit requirement with real financial penalties attached for getting it wrong or failing to document it. AI governance is emerging as its own distinct category of vendor risk, as companies embed third-party AI tools and models into their own products without always knowing what data trained them, where that data was processed, or what happens to the prompts and outputs flowing through a vendor's API. The shared-responsibility model that underlies most cloud computing keeps generating disputes about which party was actually supposed to own a given control — a gap that shows up most painfully during an incident, when both sides discover they each assumed the other had it covered.
Concentration risk is also getting more attention than it used to: when a large share of an industry runs on the same handful of cloud providers or payment processors, a single provider's outage becomes a sector-wide event rather than one company's problem, and regulators have started asking financial institutions and critical-infrastructure operators to account for that concentration explicitly rather than treating each vendor relationship as an isolated risk decision.
The core lifecycle stays the same across sectors, but what gets emphasised shifts depending on what a company is actually protecting.
Financial services carries the heaviest formal burden, between DORA in the EU, equivalent operational-resilience rules in the UK and elsewhere, and long-standing supervisory expectations around outsourcing arrangements. Concentration risk gets particular attention here, since regulators worry about an entire sector depending on the same handful of cloud or payment infrastructure providers, and a bank's third-party program typically needs to demonstrate not just that a vendor was assessed, but that the institution has a credible exit plan if that vendor fails.
Healthcare organisations live under HIPAA's business-associate framework, which means the third-party program has to track not just security posture but the specific data-handling agreements that make a vendor's access to protected health information lawful in the first place — a gap in the paperwork can be as serious a finding as a gap in the vendor's actual security controls.
Defence and critical infrastructure sit in a category where geopolitical risk carries as much weight as cybersecurity risk, sometimes more. A supplier's ownership structure and beneficial owners matter as much as its patch cadence, since a defence-sector vendor with an undisclosed ownership link to a sanctioned jurisdiction is a disqualifying finding regardless of how clean its security posture looks. Ukraine's own defence-industrial base — hundreds of private manufacturers now supplying under wartime conditions — is a live example of a sector where standard TPRM tooling alone rarely answers the ownership question, and where the corporate-registry and open-source layer of due diligence carries as much weight as the technical assessment.
Retail and e-commerce tend to carry the widest vendor sprawl relative to company size — payment processors, fulfilment partners, marketing platforms, and a long tail of smaller integrations — which makes the inventory and tiering problem, rather than the depth of any single assessment, the place where these programs most often fall short.
A few patterns show up often enough across TPRM programs that they're worth naming directly. Treating onboarding as the finish line is probably the most common — a vendor assessed once at signing and never revisited is, functionally, an unmonitored vendor within a year or two, no matter how thorough that first review was. Scoping the program to "software vendors" and missing the staffing agency, the law firm, the marketing partner, and the franchisee is a close second; risk doesn't care what department signed the contract.
Running every vendor through the same depth of review is another recurring failure — it feels rigorous and actually just spreads limited attention evenly across vendors that don't carry equal risk, leaving the genuinely critical ones under-reviewed relative to what they deserve. And relying entirely on a vendor's self-reported questionnaire answers, without any independent verification through security ratings, public records, or direct testing, tends to catch only the vendors honest enough to disclose their own gaps — which is exactly the group that needed the least catching in the first place.
A fifth pattern shows up specifically around ownership: a change-of-control clause is common in vendor contracts, but few programs actually monitor for the event it's meant to trigger. A vendor can change hands — a new majority owner, a merger, an acquisition by a company in a different jurisdiction entirely — without proactively notifying every customer, and a program that only checks ownership at onboarding has no mechanism for catching a change that happened eighteen months into the relationship. It's the same blind spot an M&A due diligence checklist is built to catch on the buy side of a deal, applied here to a vendor relationship instead of an acquisition target. The clause exists in the contract; the monitoring that would actually make it useful usually doesn't exist in the process.
In practice, the terms overlap heavily and are often used interchangeably. Where a distinction is drawn, VRM sometimes refers specifically to commercial vendors, while TPRM is used as the broader umbrella covering any external party — vendors, but also contractors, agents, and other counterparties that don't fit a narrow "vendor" definition.
Supply chain risk management typically focuses on the physical and logistical side — manufacturing, shipping, raw materials, and the resilience of that physical chain. TPRM is broader, covering any third party with access to systems or data, whether or not a physical supply chain is involved at all. The two overlap heavily for manufacturers and increasingly for software companies with complex build pipelines that blend both kinds of exposure.
It depends on criticality, not a fixed calendar. A vendor with access to sensitive data or core systems typically warrants continuous or near-continuous monitoring plus a formal reassessment at least annually; a low-risk vendor might only need a lighter periodic check every couple of years. What shouldn't happen is a one-time assessment at onboarding and nothing after — that's the single most common gap in programs that otherwise look mature on paper.
Fourth-party risk is the risk introduced by a vendor's own vendors — the subcontractors and subprocessors a company never directly contracted with but still depends on indirectly through the primary relationship. Fifth-party risk extends the same logic one layer further down the chain. Neither is visible without a contractual right to ask for disclosure, which is why flow-down clauses matter more than most companies initially budget negotiating time for.
Regulatory requirements scale with sector and exposure more than company size — a small healthcare vendor handling patient data carries real HIPAA exposure regardless of headcount. In practice, most companies below enterprise scale run a lighter version of the same five-phase lifecycle: fewer formal tools and less automation, but the same due diligence, monitoring, and offboarding discipline applied to a shorter, more manageable vendor list.
Most programs combine a few categories: questionnaire platforms for structured assessments, automated security-rating services for continuous external monitoring, compliance-mapping tools that tie vendor findings to specific regulatory requirements, and — for the parts no platform fully automates — open-source investigation into ownership, litigation, and adverse-media history that a standard security questionnaire was never designed to surface.
The risk doesn't go away — it just goes undetected until something forces it into view, usually a breach, a regulatory audit, or a customer's own due diligence process during a deal. The cost of an ad hoc approach tends to show up all at once, in the form of an incident that a documented review process would have caught months or years earlier, at a fraction of the cost of the eventual failure.
Both, typically, at different points in the lifecycle. Internal staff are usually best placed to run the standard questionnaire-and-rating process across the full vendor list, since they understand the company's own systems and risk appetite. An external specialist earns its cost on the smaller set of vendors where the internal team hits a wall it isn't built to get past — an ownership structure that needs unwinding, a jurisdiction where public records aren't easily searchable in English, or a finding that needs verification the internal team doesn't have the investigative background to run down.
On its own, no. A contract clause requiring a vendor to maintain "appropriate security measures" is enforceable in theory, but it doesn't tell anyone whether the vendor is actually meeting that bar today, six months from now, or after an ownership change nobody was told about. The clause matters — it's what makes remediation and, if necessary, termination enforceable — but it's the starting point for oversight, not a substitute for it.
01 September 2026
Molfar Intelligence has joined IT Ukraine Association, deepening its involvement in the technology community and expanding opportunities for research, knowledge exchange, and industry cooperation.
31 August 2026
Molfar Intelligence has joined the Security in Complex Environments Group, adding independent recognition of its professional standards as the firm expands across the UK and Europe.
.svg)
Let’s connect to explore how tailored intelligence can strengthen your decisions, reveal opportunities, and minimise uncertainty.
Let’s connect to explore how tailored intelligence can strengthen your decisions, reveal opportunities, and minimise uncertainty.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
Clarity. Strategy. Security.
.svg)
