Third-Party Risk
Model your vendor network and Active Directory as a dependency graph to find the single point of failure that tiers and questionnaires miss.
The problem with one-at-a-time tiers
Most vendor risk programs rate each vendor on its own: critical, high, medium, low. Active Directory is often reviewed the same way, one account or group at a time. Neither answers the question that matters in an incident: which single failure breaks the most things at once?
Dependencies are transitive. A database that two services read directly is relied upon by every service that depends on those two. A shared authentication gateway, a small vendor with a modest contract, or a service account nested several groups deep can sit on the path of nearly everything, and appear in no risk register as critical.
What we do differently
We model your relationships as a graph, then measure what the structure tells us.
- Build the graph. Vendors, fourth parties, systems, and data flows for third-party risk. Users, groups, service accounts, trusts, and permissions for Active Directory.
- Measure centrality. Betweenness, eigenvector, and PageRank scores show different kinds of structural importance. Where they agree, the finding is robust. Where they disagree, the disagreement itself tells us why a node matters.
- Validate by removal. We simulate removing each top candidate and measure what becomes unreachable. A centrality score is a hypothesis. The removal test is the evidence.
- Translate to business impact. Each critical node is mapped to the functions, revenue, and customers that depend on it.
- Prioritize remediation. Fixes are ranked by blast radius, so effort goes where it removes the most risk.
What you receive
- A ranked map of your most structurally critical vendors, accounts, and dependencies
- A blast-radius analysis for each top node, showing what fails if it fails
- Fourth-party and concentration exposure that your current register does not show
- A prioritized remediation list, with the reasoning behind the ranking
- For firms subject to DORA, output organized to support the register of information and critical third-party provider analysis
Where it applies
- Vendor and fourth-party concentration: where many of your vendors quietly depend on the same provider
- Active Directory exposure: privilege paths and nested group memberships that give broad reach from a narrow starting point
- Resilience and exit planning: knowing which dependencies need a tested alternative
- Post-incident review: understanding why an incident spread as far as it did
Typical engagements
| Engagement | Typical duration | What it covers |
|---|---|---|
| Blast radius assessment | 3 weeks | One environment (vendor network or Active Directory), centrality ranking, removal validation, top-node impact |
| Full dependency graph | 4 to 8 weeks | Vendors, fourth parties, and systems modeled together, with business impact mapping |
| Ongoing monitoring | Quarterly | Re-run the analysis as contracts, systems, and permissions change |
Questions we hear
Is this a replacement for BloodHound or our vendor risk platform? No. Those tools collect and display relationships. We interpret them: what the structure means, which nodes matter most, and what to do first. We can use their exports as inputs.
Do you need access to production systems? Usually not. Exports and read-only data are typically enough, and we work under NDA with minimal data handling.
How is this different from a penetration test? A penetration test tries to break in. This analysis maps what would break, and how far the damage would spread, if a given component failed or were compromised.
The outcome
You find your single point of failure in a report on a Tuesday afternoon, not in an incident review after it has already cost you.