Vendor Risk Aggregation

A financial technology company's TPRM programme managed forty-seven vendor relationships. Each vendor had been individually assessed, risk-scored, and managed through the programme's standard processes. Thirty-two of the forty-seven were rated low or medium risk. When a regulatory examiner asked the TPRM lead to describe the portfolio's aggregate risk exposure, the lead summarised the distribution: six high-risk, nine medium-risk, and thirty-two low-to-medium-risk vendors. The examiner asked a follow-up question: of the thirty-two low-to-medium-risk vendors, how many use AWS as their primary cloud infrastructure? The answer was nineteen. The examiner then asked how many of the nineteen had access to the same core customer transaction data. The answer was eleven. The examiner noted that eleven vendors independently assessed as low to medium risk, all sharing AWS infrastructure and all with access to the same transaction dataset, represented a correlated risk concentration that the individual assessments did not capture , a single AWS availability event would affect all eleven simultaneously, and a compromise of the transaction dataset at any one of the eleven would affect the dataset across all eleven access pathways. The portfolio's aggregate exposure to AWS availability and transaction dataset compromise was significantly higher than the distribution of individual risk scores suggested.

What is the Vendor Risk Aggregation Problem, Really?

Vendor risk aggregation is the analysis of portfolio-level risk exposures that emerge from the combination of individually-assessed vendor relationships , specifically, the correlated risks created by shared infrastructure dependencies, shared data access, and shared operational pathways that make multiple individually-low-risk vendors behave as a single concentrated risk when the shared dependency fails or is compromised. Individual risk assessment evaluates each vendor in isolation. Risk aggregation evaluates the portfolio as a system of interdependent relationships.

The correlation problem is the core challenge in vendor risk aggregation. Modern risk portfolio theory, developed for financial assets, distinguishes between diversified risk , risk that is reduced when held in a portfolio because the risks are uncorrelated , and correlated risk , risk that concentrates in a portfolio because the underlying exposures are correlated. A portfolio of nineteen vendors, each independently low-risk, that all use the same cloud infrastructure has correlated risk from that shared dependency , the AWS availability scenario affects all nineteen simultaneously. The individual low-risk scores do not capture this correlation because individual assessments evaluate each vendor's own security posture, not the portfolio's dependency structure.

The shared dataset access problem creates a different type of correlated risk. When multiple vendors have independent access to the same sensitive dataset , each through their own integration pathway, each assessed individually , the dataset's effective exposure is the aggregate of all access pathways. A dataset accessed by eleven vendors through eleven independent pathways has eleven potential compromise routes, regardless of whether each individual vendor's security posture is low risk. Individual risk scores describe the probability and impact of a single-vendor compromise. The aggregate exposure describes the probability that at least one of the eleven pathways is compromised , a materially higher probability than any individual assessment captures.

• Individual risk scores not reflecting shared dependencies , low-risk individual scores masking correlated portfolio risk
• Infrastructure concentration not analysed , multiple vendors using the same cloud provider or infrastructure not identified as a concentration
• Shared dataset access not aggregated , multiple vendors with concurrent dataset access not analysed for combined exposure
• No correlated failure scenario modelling , how simultaneous vendor failures from shared dependencies would affect the organisation
• Portfolio-level analysis absent , risk management stopping at individual assessments without portfolio synthesis

Why this matters

Vendor risk aggregation matters for TPRM because boards and regulators increasingly expect organisations to understand their aggregate risk exposure from vendor relationships , not just the distribution of individual risk scores, but the concentration risks that shared dependencies create. The FFIEC guidance on third-party risk management specifically notes that organisations should assess 'the aggregate impact of third-party relationships' , including concentrations that could result in systemic risk. A TPRM programme that accurately assesses individual vendors but does not analyse portfolio-level concentration provides one dimension of the risk picture while missing the other.

The systemic risk scenario is the most consequential aggregation risk. A shared cloud infrastructure provider failure , a major AWS, Azure, or GCP outage , affecting all vendors that depend on that infrastructure simultaneously is not a theoretical risk: major cloud outages have occurred and have affected organisations whose vendor portfolios were concentrated on the affected provider without anyone having explicitly decided to accept that concentration. The decision to use AWS-dependent vendors was made vendor-by-vendor, each decision made on its own merit, without anyone aggregating the portfolio's AWS dependency.

Where most teams get this wrong

The most consistent failure is treating individual assessment results as the complete picture of portfolio risk without conducting the portfolio-level analysis that identifies concentration and correlation. Individual assessments are necessary. They are not sufficient for portfolio-level risk management.

• Treating individual assessments as complete risk picture
• No infrastructure dependency mapping across the vendor portfolio
• No shared dataset access aggregation
• No correlated failure scenario analysis
• Portfolio risk described by risk score distribution rather than concentration analysis

What good looks like

Mature vendor risk aggregation programmes conduct portfolio-level dependency mapping , identifying shared infrastructure, shared datasets, and shared operational pathways , and analyse the correlated risk that those shared dependencies create alongside the individual vendor risk assessments.

• Infrastructure dependency mapping , which cloud providers, data centres, and infrastructure services the vendor portfolio uses
• Shared dataset access mapping , which vendors have concurrent access to the same sensitive datasets
• Concentration threshold analysis , portfolio exposure to any single infrastructure provider or data pathway
• Correlated failure scenario analysis , impact modelling for simultaneous vendor failures from shared dependencies
• Portfolio-level reporting , concentration risk presented alongside individual risk score distribution

Tooling

Supply Chain Intelligence , Interos, Coupa Risk

Supply chain intelligence platforms map the extended supply chain dependencies across the vendor portfolio , identifying shared cloud providers, common sub-service providers, and geographic concentrations. For TPRM practitioners, using supply chain intelligence for portfolio-level dependency mapping provides the concentration visibility that individual assessments cannot.

Business Intelligence on TPRM Data , Power BI, Tableau

BI tooling applied to TPRM data enables portfolio-level aggregation analysis , identifying vendor clusters by infrastructure provider, data access overlap, and geographic concentration. For TPRM practitioners, building portfolio-level aggregation views on top of individual assessment data provides the concentration analysis that GRC platform standard reporting does not.

Governance challenges

The governance challenge with vendor risk aggregation is the data availability problem. Identifying which vendors share which infrastructure requires either vendors disclosing their infrastructure providers (which many do not proactively) or using supply chain intelligence platforms that map these dependencies externally. The governance resolution is a combination of vendor disclosure requirements for infrastructure dependencies and intelligence tooling for the gaps.

• Require infrastructure provider disclosure , ask each vendor which cloud provider they use
• Map shared dataset access , identify which vendors have access to each sensitive dataset
• Conduct annual concentration risk analysis , aggregate the infrastructure dependency data
• Define concentration thresholds , maximum acceptable exposure to any single infrastructure provider
• Report portfolio concentration risk to board alongside individual risk distribution

If you are a small team

Ask every Tier 1 and Tier 2 vendor one question: which cloud infrastructure provider do you primarily use for the services you provide to us? Aggregate the answers. If more than thirty percent of your critical vendor relationships use the same provider, you have a concentration risk worth presenting to the board. That one question, asked of your highest-risk vendors, maps the infrastructure concentration that individual risk scores cannot reveal. The individual scores are accurate. The concentration is the additional dimension they do not capture.

• Ask every Tier 1 and Tier 2 vendor which cloud infrastructure provider they use
• Aggregate the answers to identify concentration
• Map which vendors have access to the same sensitive datasets
• Present concentration risk alongside individual risk distribution in board reporting

What to require

Ask directly:

"Which cloud infrastructure provider do you primarily use for the services you provide to our organisation , and are there any other critical sub-service providers whose availability is required for you to deliver your services to us?"

Expect as evidence

• Primary cloud infrastructure provider disclosure
• Critical sub-service provider list
• Business continuity plan for infrastructure provider availability events
• Alternative infrastructure or failover capability

A vendor that provides a low risk score should also be asked about their infrastructure provider. The risk score describes their individual security posture. The infrastructure provider answer enables the aggregation analysis that reveals whether their individual low risk is part of a correlated portfolio concentration.

How to evidence it

Key Takeaway

Three low-risk vendors sharing the same cloud infrastructure, the same customer dataset, and the same production access pathways are not a low-risk portfolio. They are a concentrated risk that looks diversified when examined vendor by vendor and reveals itself when examined portfolio wide. The individual risk scores are accurate. The correlation is the additional dimension the individual scores do not capture. Portfolio-level dependency mapping reveals the concentration. Infrastructure provider disclosure enables it. Supply chain intelligence automates it. The individual assessments are the necessary foundation. The portfolio analysis is the dimension that makes the foundation sufficient for understanding actual risk.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations