From Policy To Practice: Navigating the Cybersecurity Recommendations in RAND's Identifying Critical IT Products & Services Report

An inventory of vulnerabilities is not yet a security strategy. Decision-makers also need to know which dependencies matter, what failure would interrupt, and who can act. The value of RAND’s Identifying Critical IT Products and Services lies in connecting technical questions with those wider consequences.

The report was published in July 2022. It examines ways to identify critical IT products and services using software and business risk, with attention to National Critical Functions. It should be read as a research approach with data and methodological limits, not a current catalogue of every critical dependency.¹

My concern is what happens after such an assessment arrives. Organisations can agree that a dependency is important while disagreeing about ownership, funding or feasible remediation. Moving from policy to practice requires decisions about those responsibilities, rather than another assertion that cybersecurity is urgent.

A score needs context

RAND’s approach brings together different dimensions of risk. A technical vulnerability and the business consequences of a supplier problem do not describe the same thing. Mapping them to critical functions helps ask why a particular dependency matters.¹

For implementation, I would keep the dimensions visible rather than collapse everything into a single unexplained rank. The official responsible for a service needs to know whether concern arises from a software weakness, a difficult-to-replace supplier, an operational dependency or several factors together. Different causes may require different responses.

Severity should also not be confused with demonstrated exploitation. A serious weakness may deserve action before an incident; that does not establish that every deployment is equally exposed. Conversely, a modest technical defect can become consequential where a fragile workflow has no fallback. Those are reasons to investigate context, not to disregard technical findings.

Start with a bounded pilot

My proposed first step is a small pilot around one important service. Map the products, suppliers and maintainers it depends on; identify the people responsible for decisions; and record what would happen if each dependency failed. Document uncertainty rather than fill the gaps with confident scores.

An initial ninety-day exercise could establish the inventory and decision process. That is a proposed planning interval, not a guarantee of complete discovery or a timeline demonstrated by RAND. The purpose is to reveal whether the organisation can turn a finding into an action before extending the method across a larger system.

Include the teams that operate the service and the people responsible for procurement and continuity. A technically attractive mitigation may be impractical if the organisation cannot test an update, obtain vendor support or tolerate an interruption. Those constraints should be part of the decision record, not excuses discovered after approval.

Match assistance to the actual constraint

Critical dependencies can include small suppliers and open-source projects. Their importance does not imply that their maintainers possess the resources of a major enterprise. Nor does a maintainer’s nationality establish the security of a product.

I recommend identifying the constraint before choosing support: testing capacity, maintenance time, secure release practices, documentation or the availability of a replacement. Funding should specify the work it supports and how progress will be assessed. An unrestricted demand to be more secure is difficult to fulfil or evaluate.

NIST’s Secure Software Development Framework provides a vocabulary for secure development practices. It can help structure procurement discussions, but citing it does not prove that a product is secure or make every practice automatically mandatory in every context.²

Decide who can accept the residual risk

A remediation plan should name the owner, the action, its dependency on other teams and the conditions for escalation. Where immediate remediation is impossible, record the exposure, interim safeguards and the date for reconsideration. Acceptance should be an accountable decision rather than the accidental result of a backlog.

I would review the pilot after six months using practical measures: which dependencies were verified, which actions were completed, which decisions remain blocked and whether continuity arrangements were tested. These are proposed measures, not claims that a particular programme already achieved a reduction in attacks.

Avoid relying exclusively on counts of closed tickets. A completed ticket may concern a low-consequence problem, while an unresolved dependency may threaten the service’s viability. The review should connect technical work with the function the organisation is trying to protect.

The discipline of implementation

The strongest response to critical-IT research is a repeatable process: identify dependencies, investigate consequences, assign decisions, support feasible action and revisit what remains uncertain. Research informs that process; it cannot supply organisational authority on its own.

Security policy becomes credible when someone can explain what changed, why it changed and who remains responsible. That is the bridge from policy to practice this report should help us build.

Sources and notes

1. Romanosky et al., Identifying Critical IT Products and Services, RAND RRA923-2 (July 6, 2022), summary and software-risk / critical-function mapping discussion. Historical research, not a present-day asset inventory. ↩ ↩
2. NIST, Secure Software Development Framework Version 1.1, SP 800-218 (February 2022). Recommendations and vocabulary for development practices. ↩