Top-Down vs Bottom-Up Cyber Risk Assessment: Choosing, Combining and Closing the Gaps

Most cyber risk programmes run two assessments that never meet: a board-level list of a dozen enterprise scenarios, and thousands of asset and control findings in system registers, with no reliable link between them. A top-down assessment starts from business objectives, critical services and the losses the organisation cannot accept, and works down to the systems that matter. A bottom-up assessment starts from assets, components, vulnerabilities and control gaps, and rolls results up. Each answers a different question, has different inputs and effort, and fails in its own predictable way. This guide compares the two by inputs, effort, outputs and failure modes, shows how NIST and the UK NCSC describe them, and sets out a practical way to run both so they reconcile. It is written for risk managers, CISOs, GRC leads and internal auditors. For how to express the results in words or money, see Quantitative vs Qualitative Cyber Risk Guide; this page is about direction, not scoring.

Key takeaways

• Direction, not scale. Top-down and bottom-up describe where analysis starts (objectives and losses, or components and weaknesses). Either can be scored qualitatively or quantitatively.
• Top-down finds what matters; bottom-up finds what is broken. The NCSC suggests using a top-down approach to identify critical areas and a bottom-up analysis to examine them in detail.
• Each has a blind spot. Top-down misses specific weaknesses that turn a scenario from unlikely to imminent; bottom-up misses failures that emerge from how components interact and drowns leaders in findings.
• Reconciliation is the real work. NIST IR 8286 Rev. 1 and SP 800-221 describe rolling system-level risk registers up to an enterprise risk profile; that only works if bottom-up findings are tagged to top-down scenarios.
• Effort profiles differ sharply. A top-down pass takes weeks of senior time; bottom-up is continuous, tool-fed and labour-intensive. Most organisations under-invest in the first and over-produce the second.

The short answer

Run top-down first, at least annually and after major business change, to agree a short list of loss scenarios tied to critical services and risk appetite. Run bottom-up continuously, scoped and prioritised by those scenarios, so that every significant asset finding or control gap is linked to the scenario it makes more likely or more severe. Report upward through the scenarios, not through finding counts. If you can only afford one, a small organisation should start top-down, because it tells you where the limited bottom-up effort should go.

How the standards describe the two directions

NCSC: system-driven and component-driven

The UK NCSC's risk management collection uses top-down and bottom-up as alternative labels. Component-driven (bottom-up) techniques describe risk in terms of the component parts of a system and help with exposure to known technical vulnerabilities. System-driven (top-down) techniques focus on the whole system, starting from its purpose and the losses that must not happen, and suit large, complex systems where failures come from interactions rather than a single point. The NCSC is explicit that neither is better and that they can be used alongside each other. It lists ISO/IEC 27005, ISF IRAM2, NIST SP 800-30, OCTAVE Allegro and COBIT 5 for Risk among component-driven methods, and STPA (from the STAMP family), TOGAF and SABSA among system-driven ones.

NIST: tiers and analysis approaches

NIST SP 800-30 Rev. 1 places assessments at three tiers: Tier 1 organisation, Tier 2 mission and business process, Tier 3 information system. It states that results at lower tiers serve as inputs to higher tiers, and that Tier 1 and Tier 2 results are communicated down to guide Tier 3, which is the two-way flow this guide recommends. Its three analysis approaches map onto the directions: a threat-oriented approach starts with threat sources and events, an asset/impact-oriented approach starts with impacts of concern and critical assets, and a vulnerability-oriented approach starts with predisposing conditions or exploitable weaknesses. The first two support top-down work; the third is the classic bottom-up start. See the NIST SP 800-30 Risk Assessment Guide.

NIST enterprise risk integration

NIST IR 8286 Rev. 1 (December 2025) and SP 800-221 (November 2023) describe the bottom-up roll-up: risk registers at system and organisation level feed an enterprise risk profile. IR 8286A Rev. 1 adds the top-down context, documenting scenarios of how threats and vulnerabilities could affect enterprise assets within stated risk appetite and tolerance. See the NIST IR 8286 Cybersecurity and ERM Integration Guide.

ISO/IEC 27005:2022

The current fourth edition (October 2022) describes an event-based approach, which works from risk sources and strategic scenarios, and an asset-based approach, which works from assets, threats and vulnerabilities. They correspond closely to top-down and bottom-up. See the ISO/IEC 27005 Information Security Risk Guide.

Top-down assessment in depth

Threat model: top-down asks which outcomes would seriously harm the organisation (loss of a critical service for days, theft of regulated data at scale, fraudulent payments, safety impact) and which actors and paths could cause them. It is outcome-first, so it naturally captures losses that come from several small failures together.

How it runs:

1. Confirm objectives, critical services and risk appetite with executives. See the Cyber Risk Appetite Statement Template.
2. Use business impact analysis to set impact thresholds per service: maximum tolerable downtime, data volumes, regulatory triggers. See the Business Impact Analysis Template.
3. Identify crown jewels: the systems, data and identities those services depend on. See Crown jewels analysis.
4. Draft loss scenarios from threat intelligence and sector incidents, each stated as actor, path, asset and consequence. The Cyber Risk Scenario Library Guide gives starting points.
5. Estimate likelihood and impact in workshops, record assumptions and the controls each estimate relies on, and assign an executive owner.

Failure modes:

• Generic scenarios: "ransomware" or "data breach" with no path or asset gives nothing to test or fund.
• Assumed controls: workshops rate likelihood low because "we have MFA", without checking coverage.
• Anchoring on last year: the same scenarios are re-scored with no new evidence.
• Missing dependencies: suppliers, SaaS and machine identities are left out because nobody in the room owns them.

Bottom-up assessment in depth

Threat model: bottom-up asks what is weak in each asset or component and what could exploit it. It is evidence-first, which makes it precise and auditable, but it scores a weakness by its local effect unless something tells it which business outcome the asset supports.

How it runs:

1. Build or reconcile the asset inventory, including identities and integrations. See the Asset Inventory and CMDB Security Guide.
2. Collect weaknesses: vulnerability scans, configuration benchmark drift, penetration test results, control test exceptions and audit findings.
3. Assess each finding's likelihood and local impact, typically against a control catalogue such as NIST SP 800-53 or CIS Controls v8.1. CIS RAM v2.2 is published in editions for each CIS Controls v8.1 Implementation Group.
4. Record entries in system risk registers with owner, treatment and due date. See the Risk Register Template.
5. Aggregate upward by system, business unit and enterprise.

Failure modes:

• Volume without priority: thousands of "high" findings scored on technical severity, none linked to a service.
• Aggregation by counting: reporting "412 open high risks" to the board, which conveys anxiety, not exposure.
• Missing emergent risk: each component looks acceptable, but the combination (shared admin account, flat network, backups on the same domain) produces a catastrophic path.
• Inventory gaps: what is not in the CMDB is never assessed, and unmanaged assets are often where attackers enter.

Inputs, effort and outputs compared

Combining both: a reconciliation model

The two directions only produce one picture if they share a join key. Use the top-down scenario as that key.

1. Agree scenarios first. Publish the enterprise scenario list with IDs, each naming the critical service, crown jewel assets and the controls its likelihood estimate assumes.
2. Tag assets to scenarios. In the CMDB or GRC platform, link every crown jewel asset and its dependencies (identity provider, backup platform, integration accounts) to the scenario IDs it supports.
3. Tag findings through assets. Each bottom-up finding inherits the scenario IDs of the asset it affects; findings on untagged assets go to a triage queue to check whether a scenario is missing.
4. Test the assumed controls. For each scenario, check that the controls it relies on exist and work (MFA coverage, segmentation, backup isolation). A failed assumption raises the scenario's likelihood immediately.
5. Report through scenarios. The board sees each scenario's rating, trend, the open findings that drive it and the funded treatments. Engineers see their findings ranked by the scenarios they affect.
6. Feed back both ways. A cluster of bottom-up findings with no scenario suggests a missing scenario; a top-down scenario with no linked assets suggests an inventory or scoping gap.

Small organisations: one half-day top-down workshop producing eight to twelve scenarios, plus a bottom-up assessment limited to the systems those scenarios name, is a proportionate programme. CIS RAM's Implementation Group editions give a ready-made bottom-up structure.

Large organisations: run top-down at enterprise and business unit level, bottom-up per system through the authorisation or assurance process, and reconcile quarterly in the GRC platform. Quantify the top scenarios where decisions involve material spend; see the FAIR Model and Open FAIR Standard Guide.

Where identity fits

Identity is where the two directions most often fail to meet. Top-down scenarios name "privileged account compromise" but rarely list which accounts; bottom-up assessments assess servers and applications but treat service accounts, API keys and OAuth integrations as attributes of a system rather than assets with their own exposure. Make machine identities explicit assets in the inventory and tag them to scenarios, because a single integration account often spans several crown jewels. See the NIST SP 800-221 ICT Enterprise Risk Guide for how enterprise ICT risk is consolidated.

Worked scenario

A healthcare payments processor runs a strong bottom-up programme: every system has a register, scans run weekly and 380 high findings are tracked. Its top-down register has one line, "cyber attack disrupts operations", rated medium. In the reconciliation exercise the risk team writes a specific scenario: an attacker uses a stolen credential on an internet-facing remote access service, moves laterally and deploys ransomware, stopping claims processing for more than five days. The scenario assumes MFA on all external access. Tagging assets shows a legacy remote access gateway supporting claims operations that was never in the CMDB, so the bottom-up programme had never assessed it, and it has no MFA. The scenario's likelihood moves to high on the day the assumption fails, the gateway is fixed within a week, and the board sees one scenario with a clear cause instead of 380 findings. The pattern matches the Change Healthcare breach, where a remote access portal without MFA led to weeks of disruption to claims and pharmacy payments.

Detection and measurement

• Scenario linkage: percentage of high and critical bottom-up findings linked to at least one enterprise scenario. Low linkage means scenarios are too abstract or the inventory is not tagged.
• Crown jewel coverage: percentage of assets tagged to a scenario that had a bottom-up assessment in the last 12 months.
• Assumption validation: percentage of controls assumed by top-down scenarios that have been tested in the period, and the number that failed.
• Orphan findings: count of findings on assets with no scenario tag, reviewed monthly for missing scenarios.
• Scenario freshness: age of each scenario's last evidence-based review against the agreed cycle.

Common failure patterns

• Two registers, two teams: enterprise risk and security keep separate registers with no shared identifiers, so neither can explain the other.
• Bottom-up reported as top-down: finding counts and heat maps of technical severity presented to the board as enterprise risk.
• Top-down with no evidence: scenarios rated by opinion, with assumed controls never tested.
• Scoping by inventory: bottom-up covers only what the CMDB lists, so the riskiest unmanaged assets are invisible.
• Ignoring interactions: no system-driven review of how shared identities, networks and backups combine; the NCSC notes component views can miss system-wide issues.
• One-off exercise: a consultant-led top-down assessment is never refreshed and drifts from reality within a year.

Framework mapping

Practitioner checklist

• Agree a short list of enterprise loss scenarios with IDs, owners and named critical services.
• Record the controls each scenario's likelihood assumes, and test them.
• Tag crown jewel assets, including machine identities and integrations, to scenario IDs.
• Make every bottom-up finding inherit scenario tags from its asset; triage orphans monthly.
• Report to the board through scenarios, with the findings that drive each one.
• Scope bottom-up effort by scenario first, then breadth.
• Run a system-driven review of shared dependencies at least annually.
• Refresh top-down scenarios annually and after major business or threat change.
• Track linkage, coverage and assumption validation metrics quarterly.

Standards and references

• NCSC: Introducing system-driven and component-driven risk management approaches
• NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
• NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management
• NIST: IR 8286A Rev. 1 Identifying and Estimating Cybersecurity Risk for ERM
• NIST: SP 800-221 Enterprise Impact of ICT Risk
• ISO: ISO/IEC 27005:2022 Information security risk management guidance
• NCSC: System-driven risk management methods
• CIS: CIS Risk Assessment Method (RAM)

Related NHI Mgmt Group resources: Quantitative vs Qualitative Cyber Risk Guide · NIST SP 800-30 Risk Assessment Guide · ISO/IEC 27005 Information Security Risk Guide · Cyber Risk Scenario Library Guide · Threat Modelling Guide