A cybersecurity risk assessment answers one question: what could go wrong here that would matter, and which of those things is worth spending money on first. Everything else in the method exists to make that answer defensible.
Assessments have a poor reputation in some organizations, and usually for a fair reason. A report was produced, it contained a great many findings, nothing changed, and the same findings appeared again the following year. This article describes how the work is done and, more importantly, what has to be true afterwards for it to have been worth doing.
Why the assessment comes first
Security spending without an assessment tends to follow the shape of the market rather than the shape of the risk. Organizations buy what they have recently read about, or what a previous employer used, or what the incident in the news suggested. The result is a portfolio of controls with unexamined coverage and unexamined gaps.
An assessment replaces that with an ordered list. It is the identify function of the NIST Cybersecurity Framework, whose core organizes cybersecurity outcomes at their highest level so that protection can be decided against known exposure rather than assumption.
Step one: asset identification
You cannot assess risk to something you have not listed. Asset identification covers systems, applications, data stores, network infrastructure, cloud tenancies, identities and the third parties with access to any of them.
The step that is routinely underdone is data. Organizations can usually list their servers and struggle to say where regulated data actually lives, which matters because the obligations follow the data rather than the hardware. The other routine gap is the shadow estate: departmental cloud subscriptions, a supplier portal somebody signed up for, a legacy system kept alive for one report.
The output is an inventory with an owner recorded against each entry. Ownership is what makes every later step actionable, because a risk with no owner cannot be accepted, and a remediation with no owner does not happen.
Step two: threat identification
Threats are what might act against those assets. For most organizations the realistic set is short and unglamorous: credential theft through phishing, ransomware deployed after an initial foothold, exploitation of an unpatched internet facing service, misconfiguration of a cloud resource, insider error, and supplier compromise.
Exotic threats are worth considering only where an organization has a specific profile that attracts them. Spending assessment time on nation state capability while the multifactor authentication rollout is half finished is a misallocation, and a good assessor will say so.
Step three: vulnerabilities and existing controls, together
These two belong in the same step because neither means anything alone. A vulnerability behind three compensating controls is a different proposition from the same vulnerability on an internet facing host with no monitoring.
So the assessment records what is weak and what is already in place: the technical weaknesses from scanning and configuration review, and the controls that currently mitigate them, with an honest judgment about whether each control is actually operating. That last qualifier is where assessments earn their fee. A control that exists in a policy, is configured in a console and is bypassed in practice is a finding, not a mitigation.
The prioritization input most often missing is real world exploitation. A severity score describes how bad a vulnerability would be if used. It does not say whether anyone is using it. CISA maintains a catalog of vulnerabilities known to be exploited in the wild and advises that organizations should use the KEV catalog as an input to their vulnerability management prioritization framework. The ongoing form of this work is covered in vulnerability management.
Step four: likelihood and impact
Risk is conventionally expressed as the combination of how likely something is and how much it would hurt. Both halves are estimates, and pretending otherwise is the most common failure in assessment reporting.
Impact is the more tractable of the two, because a business can usually describe what a week without a given system would cost, what a disclosure of a given data set would trigger, and what a contractual failure would mean. Those conversations belong with the business rather than with the security team.
Likelihood is harder and more often faked. A numeric likelihood derived from a workshop is a stated opinion wearing a decimal point. It is more honest, and more useful, to band it coarsely and to be explicit about the reasoning: this is likely because it requires no privileged access and is routinely attempted, or this is unlikely because it needs physical presence in a controlled space.
What matters is that the ordering that comes out is one the organization recognizes and can defend, not that the arithmetic looks precise.
Step five: prioritization and the remediation plan
The deliverable that makes an assessment worth commissioning is not the finding list. It is the sequenced plan: what to fix now, what to fix this year, what to accept, and what to monitor because it may change.
A usable plan states, for each item, the owner, the expected effort, the dependency, and the decision if it is not fixed. Findings that are accepted are recorded as accepted, with a named person and a review date, which converts a gap into a decision. Findings that are deferred carry the reason.
NIST SP 800-53 supplies the control vocabulary many organizations use to express these fixes, and it is deliberately not a fixed prescription: the controls are flexible and customizable and implemented as part of an organization-wide process to manage risk. Choosing which apply is part of the work, not a step you can skip by adopting the catalog wholesale. That catalog is covered in NIST SP 800-53 security controls, and the framework that organizes it in the NIST Cybersecurity Framework.
What has to happen next, or it was shelfware
The assessment is the beginning of the work and is frequently treated as the end of it. Three things determine whether it mattered.
First, the plan has to be owned by somebody with a budget. An assessment handed to a team without the authority to act produces frustration and a repeat assessment.
Second, remediation has to be tracked to closure rather than to activity. An item is not complete because a change was made. It is complete when the change has been verified, which usually means rescanning or retesting.
Third, the state has to be maintained afterwards, because the environment moves. That is the operational discipline covered in continuous security and compliance monitoring, and the continuing service that carries it in the managed cybersecurity lifecycle.
Scoping, and the assessment that answers the wrong question
Most disappointing assessments were scoped badly rather than executed badly. Three scoping decisions do most of the damage.
The first is scoping to a system when the risk is organizational. An assessment of one application will not surface the fact that every administrator shares a password vault with no review, because that was not in scope. If the question you actually have is how exposed the organization is, the scope has to be the organization.
The second is scoping to a framework when the question is practical. An assessment against a control catalog produces a compliance gap list, which is a genuinely useful artifact and is not the same as a prioritized risk list. A control can be absent and unimportant, or present and ineffective. Decide which artifact you want before commissioning, because they read similarly and lead to different spending.
The third is excluding the parts nobody wants examined. Legacy systems, the supplier with the remote access, the department that runs its own tenancy. Those exclusions are where risk concentrates, precisely because they have been left alone. An exclusion is defensible when it is recorded and deliberate, and corrosive when it is quietly arranged.
A well scoped assessment states plainly what it did not look at. That sentence is worth more to a reader than another page of findings, because it tells them what their remaining uncertainty is.
How often to reassess
Annual is the common answer and is reasonable for a full assessment in a stable environment. It is the wrong answer in two situations. A material change, a cloud migration, an acquisition, a new regulated data set, a significant architectural change, warrants an assessment of the changed area regardless of the calendar. And a serious incident always warrants a reassessment, because the incident has just told you something your model did not.
Between full assessments, the useful posture is continuous rather than periodic: vulnerability data refreshed, exceptions reviewed, and the inventory maintained rather than rebuilt.
Where LABUSA fits
LABUSA delivers assessments as an engagement through cybersecurity and risk management, and operates the resulting controls as a continuing service through LABUSA managed cybersecurity services. Where an assessment has to be evidenced against a specific framework or contractual obligation, that work is security assessments and compliance.
The reason those are separate pages is that they are separate commitments. An assessment tells you what is wrong. A managed service is what stops it being wrong again next year.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.
- CISA, Known Exploited Vulnerabilities Catalog.