Integrating Risk Assessments: One Assessment, Many Consumers

Category: Enterprise Risk Author: Cody Swidler Tags: risk assessment, integrated risk, ERM, taxonomy, control library, assessment fatigue

Walk into most mid-to-large organizations and count the risk assessments running in parallel. There's an enterprise risk assessment, an IT risk assessment, a third-party risk assessment, a SOC 2 readiness assessment, a business impact analysis, a privacy assessment, maybe a resilience or DR assessment. Each has its own owner, its own spreadsheet, its own scale, and its own definition of what "high" means.

They're all asking versions of the same question — what could hurt us and how badly — to overlapping sets of people, and producing answers that can't be reconciled. That's not rigor. That's redundancy that exhausts the business and produces a fragmented picture no one can roll up.

The Cost of Disconnected Assessments

The obvious cost is fatigue. The same control owner gets surveyed four times a year by four teams asking nearly identical questions in slightly different words. By the third questionnaire, the answers get less thoughtful, not more. You're degrading your own data quality through sheer volume.

The deeper cost is that nothing aggregates. When the IT risk assessment rates something "moderate" on a 1–5 scale and the ERM assessment rates a related exposure "elevated" on a red/amber/green scale, leadership can't tell whether those are the same risk, related risks, or contradictions. The enterprise view — the entire point of ERM — never materializes because the inputs don't share a language.

What Integration Actually Means

Integration is not one giant assessment that tries to cover everything. That collapses under its own weight. It's a shared foundation that lets specialized assessments interoperate. Three things have to be common.

A shared risk taxonomy. One agreed-upon way to name and categorize risks across the organization. If third-party risk, IT risk, and ERM all map their findings to the same taxonomy, a vendor concentration risk identified in a TPRM review and an availability risk identified in a resilience assessment can finally be seen as connected. Without a common taxonomy, every assessment is an island.

A common scoring scale and method. The same definitions of likelihood and impact, the same thresholds, the same approach to combining them — the discipline I covered in the data-driven risk assessment. Specialized assessments can collect different evidence, but they have to express the answer in the same currency, or you can't add them up.

A shared control library. This is the structural piece that makes "assess once" possible. When every assessment references the same set of controls, a single control test result feeds every assessment that depends on that control. You test access management once and it satisfies the SOC 2 view, the IT risk view, and the ERM view simultaneously. This is exactly the leverage a unified control library is built to deliver.

Assess Once, Serve Many

The operating principle is to collect each piece of evidence a single time and let multiple consumers draw on it. A business impact analysis produces criticality ratings, dependencies, and recovery objectives. Those same outputs should feed the resilience program, the third-party risk program (which vendors support your most critical processes?), and the enterprise risk register — not get re-gathered by each. A well-structured BIA is one of the highest-leverage inputs you have precisely because so many downstream assessments need what it produces.

The shift is from each team owning an assessment to the organization owning a body of risk evidence that assessments query. The assessment becomes a lens on shared data, not a fresh data-collection campaign every time.

This Is an Operating Model Problem

You cannot integrate assessments by buying a tool and importing everyone's spreadsheets. The reason assessments are fragmented is that ownership is fragmented — each function built its own to serve its own mandate, and no one was accountable for the seams. Integration requires deciding who owns the shared taxonomy, who governs the scoring method, who maintains the control library, and how the specialized teams feed and draw from it.

That's an operating model decision, not a technology decision. The tool can enforce the model once you've defined it, but it can't define it for you. Organizations that skip the operating model step end up with an expensive integrated-risk platform that contains the same disconnected assessments they had before, now in one database.

Where to Start

Don't try to merge everything at once. Pick the two assessments with the most overlap — usually IT risk and ERM, or third-party risk and resilience — and align just those two on a shared taxonomy and scale. Prove the rollup works, show leadership a view they've never been able to see, and use that as the case for bringing the next assessment onto the foundation.

The goal isn't fewer assessments. It's assessments that add up. When they share a language, the enterprise picture assembles itself — and the business stops being surveyed to death to produce it.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.