Your Cybersecurity Gap Assessment Is Finished. Now What?

The assessment is complete, the findings have been presented, and everybody agrees there is work to do. Three months later, the high-risk items are still open. Some have new owners, a few have revised due dates, and the rest are waiting for money that was never really committed. I've seen enough security programs to know that the hardest part of a gap assessment often begins after the assessors leave. The report can be technically correct and still accomplish remarkably little.

The question I care about is not whether a control was found missing. It's whether the organization has made a defensible decision about the risk that control was supposed to manage. Those are different things. The NIST Cybersecurity Framework (CSF) 2.0 provides a useful vocabulary for outcomes and governance, but it deliberately does not prescribe one implementation for every organization (Pascoe et al., 2024). That distinction matters when somebody tries to turn a framework score into a purchase order.

Imagine an assessment identifies incomplete multifactor authentication coverage, insufficient security logging, and an incident response plan that hasn't been exercised. All three findings may be valid. They do not automatically deserve equal funding, identical deadlines, or the same executive attention. One might expose a privileged production environment; another might concern a low-impact administrative workflow; the third could affect whether leadership can authorize containment at all.

I would begin by separating four questions. What asset, process, or decision is exposed? What failure could plausibly occur? What controls already reduce the likelihood or impact? And who has the authority to accept the remaining risk? The framework is a way to organize those questions, not a substitute for answering them. NIST SP 800-53 Rev. 5 supplies a broad catalog of security and privacy controls, while NIST SP 800-160 Vol. 1 Rev. 1 emphasizes engineering security in relation to the system and its operating environment (Ross, 2020; Ross et al., 2022).

A missing control is not always the same as an exploitable weakness. Conversely, a control can exist on paper and fail under pressure. Both possibilities deserve attention. If the report calls a system “compliant” because the policy requires log review, I still want to know whether the logs arrive, whether somebody reads them, and whether the right person can act when the evidence points to an incident.

Many remediation programs fail because the work is assigned to a department instead of a person who can change the system. “IT will fix logging” is not an owner. Neither is “Security will improve governance.” A useful remediation record names the accountable decision-maker, the engineering owner, the dependency, the expected outcome, the evidence needed to close the item, and the date on which that evidence will be reviewed.

Suppose the finding concerns privileged access. The engineering work may involve identity integration, session controls, service-account inventory, emergency access, and application changes. The decision to retire a legacy authentication path may belong to an executive who owns the application. The security team can advise, test, and challenge; it cannot necessarily make every operational tradeoff. NIST's zero trust guidance is explicit that access decisions should focus on users, devices, and resources rather than implicit trust based on network location (Rose et al., 2020). Implementing that principle still requires somebody to resolve the messy exceptions.

I prefer remediation plans that state what will change in the real environment. “Implement zero trust” tells me almost nothing. “Remove standing administrator access to the production finance application, require an approved elevation path, and retain evidence of emergency access use” is at least a decision someone can inspect.

I'd group remediation by the consequence of failure, the practical dependencies, and the ability to reduce risk in a useful timeframe. Some changes are relatively inexpensive and remove obvious exposure. Others require architectural work, staffing, procurement, or service interruption. A single foundational dependency can unlock several findings. Identity modernization, for instance, may improve access control, auditability, incident response, and contractor offboarding at the same time.