The risk assessment that should come first
Nothing can be protected by someone who does not know what threatens it. That sounds obvious enough to skip past, and it is the step most often skipped.
Years ago, at a client site, an executive one level below the chief executive found Kenneth and said, "I want to be secure." The reply was straightforward: happy to help—so tell me what you are protecting, and what the threats against it are. The executive could answer neither question. He wanted security as a property of the company, the way a roof is weatherproof, without reference to what was underneath it or who might want to get in.
That conversation is more common than it should be, and it is not a criticism of the executive. Wanting to be secure is the correct instinct. It simply is not yet a specification, and nobody can act on it. Spending against it produces purchases rather than protection, because there is no standard by which to judge whether any given purchase helped.
The risk assessment is what converts the instinct into something actionable: these are the assets, these are the people who would want them, this is what they would attempt, and this is what currently stands in the way. Most security governance activities take that knowledge for granted. The risk assessment is where it is supposed to come from, and it is frequently the document produced last, when it should be the one produced first.
What it is required to be
The requirement is not optional for most organizations with obligations. NIST SP 800-53 carries the parent control as RA-3, and NIST SP 800-171 states it in Revision 3 as 03.11.01: assess the risk, including supply chain risk, of unauthorized disclosure resulting from the processing, storage, or transmission of controlled unclassified information, and update that assessment at an organization-defined frequency. Revision 3 maps it to RA-3, RA-3(1), and SR-6, so the supply chain clause is not decoration. For defense contractors the department has already set the frequency, as parameter 03.11.01.b: at least every 12 months, or when there are significant incidents or significant changes to risks. CMMC inherits the requirement along with the rest of 800-171, and other frameworks state it in their own vocabulary.
Read 03.11.01 closely, though, and it is narrower than it first appears. It asks about unauthorized disclosure—which is deliberate, because 800-171 exists to protect the confidentiality of CUI, not to run the contractor's security program. Nothing in it obliges anyone to consider what happens when that same data is altered or cannot be reached. Those risks belong to the organization regardless, and an assessment scoped only to the compliance requirement will not find them.
What the requirement does not do is say the assessment must be elaborate. A risk assessment proportionate to a thirty-person manufacturer is not the document a defense prime would produce, and an assessment padded to look substantial is worse than a short one that is actually used.
Who should do it
The method matters less than the person applying it, and what that person needs is unusual: a working understanding of how the business actually operates, a current picture of what threatens organizations like it, and enough discipline to keep both up to date.
Either half alone fails predictably. Someone who knows the technology but not the business produces a document that is technically defensible and ranks everything wrongly, because nothing in a network diagram indicates which system the company cannot trade without, which customer relationship would not survive a disclosure, or which three days of the year an outage would be ruinous. Someone who knows the business but not the current threat landscape assesses this year's operations against last decade's attacks, and writes controls for the attacker they read about rather than the one presently working through their sector.
Staying current is the part that gets underestimated, because both halves move. Attacker behavior changes—techniques become commodity, a criminal business model appears and displaces another, a class of target becomes fashionable. The business changes at least as fast: a new product line, an acquisition, a department that quietly started using a service, a supplier that became load-bearing.
That combination is why the assessment is not a form for whoever has capacity this quarter. It also does not have to be an outsider. Someone inside the organization who genuinely holds both halves is usually better placed than a consultant holding one, since they know where the awkward workflows are. What an outsider brings is a different thing entirely: no stake in the conclusion, and recent sight of how other organizations in the same position actually got into trouble.
Choosing a method
Several established frameworks exist, and they are not competitors so much as tools shaped for different jobs. Picking one matters less than picking one deliberately, but the differences are real.
NIST SP 800-30, Guide for Conducting Risk Assessments. The default for anyone in the federal orbit. It is qualitative, works at the organization, mission, and system levels, and sits alongside SP 800-39 for organization-wide risk management and SP 800-37 for the Risk Management Framework. Best where: an assessor will read the result, since it is the vocabulary they expect and it maps directly to 800-53 controls. It is also free. Against it: it is long, and its qualitative high/moderate/low scales can feel arbitrary without discipline about what the words mean.
ISO/IEC 27005. Guidance on managing information security risks, built to support an ISO 27001 management system. Process-oriented—identify, analyze, evaluate, treat—and notably firm that risk owners approve treatment plans and accept residual risk. Best where: the organization is pursuing or holds ISO 27001, since the two are designed to fit. Against it: the standard costs money, and it is deliberately non-prescriptive about method, which is freedom if you want it and a blank page if you do not.
ISACA's Risk IT, within COBIT. Frames technology risk as enterprise risk, in the language of business objectives and governance rather than systems. Best where: the audience is a board, an audit committee, or an enterprise risk function that already thinks in those terms. Against it: it is built for scale, and a small organization adopting it wholesale will spend more on the framework than on the risk.
Open FAIR, from The Open Group. Quantitative. It decomposes risk into frequency and magnitude and expresses the result as probable loss in money, using the Risk Taxonomy and Risk Analysis standards. Best where: choices have to be compared or defended financially—which control to fund, whether a mitigation costs less than the loss it avoids, how to answer a chief financial officer. Against it: it needs data and calibrated estimation, and confident numbers derived from weak inputs are more dangerous than an honest qualitative scale.
OCTAVE Allegro, from Carnegie Mellon's Software Engineering Institute. Asset-driven and workshop-based, designed explicitly so an organization can run it itself with a small team and limited time. Best where: a smaller organization wants to conduct its own assessment rather than buy one. Against it: it dates from 2007 and is no longer actively developed, so the method is sound but the examples show their age.
CIS RAM. Ties risk analysis to the CIS Controls and, unusually, to the question of whether a safeguard is reasonable—balancing the burden of a control against the harm it prevents. Best where: the organization needs to show due care to a regulator, an insurer, or a court, since that balancing is the test those audiences apply. Against it: it is bound to the CIS Controls.
Two things that are not risk assessment frameworks are worth having beside whichever one is chosen. MITRE ATT&CK catalogues what attackers actually do once inside, which is the difference between naming a threat and describing one. And threat modeling methods operate a level down, on a single system or design, answering how a particular thing could be attacked rather than what the organization's risks are.
For most small and medium organizations with a compliance obligation, 800-30 qualitatively is the pragmatic answer, with FAIR reserved for the two or three decisions large enough that a number would change what gets funded.
Start from who would attack, and why
A risk assessment that begins with a list of controls and asks which are missing is a gap assessment wearing the wrong label. A risk assessment begins with who would attack this organization and, just as importantly, what they would want.
The second question is the one usually skipped, and it determines everything downstream. Someone who wants money behaves differently from someone who wants a specific document, and both behave differently from someone who wants the organization to stop functioning. The same intrusion, by attackers with different objectives, produces different damage and calls for different defenses.
The common classes are few enough to list.
- Criminals want money. That shapes their behavior more than any technical preference: they take the cheapest path to a payment, prefer targets that pay, and move on when a target proves expensive. Ransomware, payment fraud, and business email compromise are business models rather than vendettas.
- Industrial spies and competitors want trade secrets, designs, pricing, customer lists, and negotiating positions. Unlike criminals, they want the intrusion never to be discovered, because the value evaporates once the target knows what was taken.
- Nation-states want data or effects that serve geopolitical goals: intelligence, positioning inside infrastructure, leverage. They also sometimes want commercial advantage for their own industries, which organizations outside the defense sector tend to discount. It is not a new practice—a 1992 GAO testimony to Congress laid out economic espionage against U.S. industry by allied governments, France's among them, whose first intelligence director was later candid that in economics the two countries were competitors rather than allies.
- Political activists want to advance a cause, which usually means visibility. Defacement, leaks timed for maximum attention, and disruption of something symbolically connected to the grievance.
- Terrorists want fear. The target is chosen for what its disruption signifies rather than for what it holds.
- Insiders want a range of things—money, revenge, advantage at a new employer, or nothing at all. They matter as a separate class not because their motives are unusual but because their position is: they already hold credentials, they know where the valuable material is, and their activity looks like work. Most insider damage is not malicious at all. It is a person doing their job through a shortcut that was easier than the approved path.
- Opportunists want whatever is reachable. Mass scanning, credential stuffing, and commodity malware are aimed at no one in particular, and account for a great deal of the actual damage done.
Two organizations rarely face the same mix, and the differences are larger than most expect. A defense subcontractor holding design data has a plausible nation-state interest that a regional accounting firm does not. That accounting firm has a criminal-monetization problem the subcontractor may worry about less. A municipality has both, plus a disruption risk with political motivation attached. All three have insiders, and all three are reachable by opportunists who have never heard of them.
Perspective matters as much as the answer, because the question has an implied subject: an attacker of whom?
Kenneth used to teach an introductory security course at a major IT manufacturer, where the class would build a threat model for a mobile phone. Deliberately a simple phone—one that made calls and, with T9, sent text messages—because a smartphone's threat model is far too large to hold in a classroom.
The instructive part was that the model changed entirely depending on whose it was. The manufacturer worried about counterfeits, warranty fraud, and firmware being replaced. The carrier worried about handsets leaving its network and about revenue leaking away. The owner worried about theft, about the bill, and about what was stored on the handset.
Those three were not merely different. They were opposed. In the years when carriers charged heavily for data, many locked the phone's Bluetooth and Wi-Fi transfer so that moving a photograph off the handset required the metered path. To the carrier that lock was a control protecting revenue; to the owner it was an obstacle to be routed around. Each was, from the other's seat, the attacker. The same tension survives anywhere a handset is locked to a network.
An attacker is therefore not a property of the system. The question becomes answerable only once it is clear who is asking—which is also why an assessment conducted from the wrong seat produces a document that does not fit the organization that paid for it.
Setting those attacker classes and motivations against the organization's existing policies, procedures, and controls gives a first view of where risk actually sits and what already mitigates it.
Disclosure is only one of three questions
Risk conversations drift toward confidentiality. It is the failure that breach-notification laws attach to, it is what reaches the news, and it is what most people mean when they say security incident. For a great many organizations it is also not the failure that would hurt most.
Every asset is worth three separate questions. What happens if this is disclosed? What happens if it is wrong? What happens if it cannot be reached? The answers rank differently, and an assessment that asks only the first will protect the wrong things well.
FIPS 199 builds federal categorization on exactly that structure: a system's security category is three separate judgments, one each for confidentiality, integrity, and availability. Borrowing the structure is useful mainly because it forces the two neglected questions to be asked aloud.
Integrity. The risk is not that someone reads the data but that someone changes it—or that it changes by accident and nobody notices.
Payment fraud is the everyday version. An attacker who alters the bank details on an outgoing payment has disclosed nothing and has taken the money. In engineering and manufacturing the same failure is quieter and worse: a tolerance, a material specification, or a machine toolpath altered slightly produces parts that pass inspection and fail in service, and the discovery arrives years later from the field rather than from a security tool. A municipality's exposure is in its records, since permits, assessments, utility billing, and court dockets are authoritative precisely because people trust they have not been edited.
Integrity failures share an unpleasant property. A confidentiality breach is usually discovered eventually, because the data surfaces somewhere. An integrity breach may never be discovered at all, and the organization goes on operating with the altered data. That is also why backup and log integrity deserve more attention than their dull reputation attracts: a silently corrupted backup is not a backup, and logs an attacker can edit will not explain what happened.
Availability. The question is what the organization cannot do while something is missing, and how long that remains survivable.
Ransomware is the obvious case, and it is worth naming what the damage actually is—almost always an availability loss rather than a disclosure one. The extortion over stolen copies came later and remains secondary to the fact that nothing runs. A manufacturer whose line has stopped is losing money by the hour whether or not a single file left the building. For a municipality the impact is not financial at all: dispatch, water treatment, and the court calendar do not have a revenue figure attached.
Availability risk also has a calendar, which assessments routinely miss. An accounting firm offline for three days in June has a problem. The same firm offline for the same three days in April has a different one. When a loss would land is part of how large it is.
The judgment of what an outage costs belongs in the inventory, recorded once against each system rather than reconstructed during the incident. It also varies far more than a system list suggests. A virtualization host carrying thirty workloads takes all thirty down with it. A DNS server that is replicated, has a secondary already answering queries, and is one of several is an inconvenience whose loss may go unnoticed until the second one fails. Both are servers, both appear on the same inventory line by default, and only one of them stops the company.
The attacker classes map onto the three unevenly, which is worth checking against the list above. Industrial spies want confidentiality to fail and nothing else. Criminals are largely indifferent and take whichever pays: ransomware for availability, payment fraud for integrity, stolen records for confidentiality. Activists and terrorists mostly want availability, because disruption is visible in a way that quiet theft is not. Insiders can reach all three, and the negligent ones damage integrity or availability without intending anything at all.
Refine against how the organization really works
The first pass is built from documents. The refinement comes from working through the ways the organization genuinely uses technology, rather than the ways an inventory or an architecture diagram says it does.
This is where the interesting findings appear: the data that leaves the protected environment because a workflow requires it, the administrative access a vendor holds because a support contract required it three years ago, the process that depends on one person's judgment and has no documented alternative.
Following the data is the most productive version of that exercise, and it leads directly to documenting sensitive data flows: where the data originates, every system it passes through, everyone who can see it on the way, where it comes to rest, and how it is eventually disposed of.
The reason this belongs in a risk assessment rather than in a diagramming exercise is that the flow determines the threat. A company that moves data between sites on write-once optical media has a set of risks involving couriers, physical custody, and media that cannot be revoked once it leaves the building. A company that moves the same data through a cloud service has an entirely different set involving an account that can be phished, an administrator at the provider, a misconfigured share, and a copy that persists after the contract ends. Both are defensible arrangements. Neither is safe in the way the other is, and no generic control list will tell an organization which risks it has actually chosen.
The requirement to document those flows is not unusual, either. NIST SP 800-171 expects the system security plan to describe the boundary, the operating environment, and how CUI moves through and beyond it, which is a data flow by another name. PCI DSS is explicit at requirement 1.2.4 in version 4.0, calling for an accurate data-flow diagram showing all account data flows across systems and networks, updated as the environment changes. The CIS Controls devote safeguard 3.8 to documenting data flows, including those of service providers, reviewed annually or when significant enterprise changes occur. And the NIST Cybersecurity Framework asks under ID.AM-03 that representations of internal and external network data flows be maintained.
What it produces, and what consumes it
The deliverable is usually a risk register: a list of identified risks, each with the mitigations the organization has actually implemented against it, and the residual risk that remains once those mitigations are accounted for. That last column is the one most often left out, and it is the one that carries the meaning. A risk with a control in front of it has not gone away; it has been reduced by some amount, and the organization should be able to say roughly how much and what is left.
The register also has to record the risks nobody is mitigating. Some have been accepted deliberately, which is a legitimate decision when it is made by someone with the authority to make it and is written down with a reason. Others have been transferred, most often to an insurer or by contract to a supplier, which moves the financial consequence without moving the operational one—the outage still happens.
Then there is the residue. Any risk left unmitigated has been accepted, whether or not the organization intended to accept it. Nothing about the absence of a decision makes the exposure smaller. The only difference between deliberate acceptance and accidental acceptance is that in the first case someone can explain the reasoning, and in the second the organization discovers its position after something has already happened. Writing the unmitigated risks down converts the second into the first, which is most of what a register is for.
Its value, beyond that, is measured by what it feeds.
The policy review is one consumer. A policy review informed by a current risk assessment can ask whether the policy addresses the risks the organization actually has; without one, it can only ask whether the document is internally consistent. The sequencing therefore matters, and the assessment should be completed first.
Accepted risks are another. An organization that has accepted a risk should be able to point to where that risk is described, what accepting it costs, and who decided. Exceptions granted against policy are the same category viewed through a different document.
Remediation planning is the third, and it is where most of the register's output goes. Anything that cannot be fixed immediately becomes a plan of action and milestones: the deficiency stated plainly, a named owner, a date chosen because it is achievable, and the interim risk in the meantime. An assessment that identifies work and does not deposit it somewhere it will be tracked has ended at the document, which is the same failure as a policy nobody can verify.
Deciding what to do first
A good risk assessment finds more risks than the organization can address at once. That is the normal result rather than a defect, and it makes prioritization part of the deliverable rather than a step someone improvises afterward.
The workable method is the simple one. Rate each risk twice: on impact, meaning what it costs if it happens, and on likelihood, meaning how probable it is within a stated period. Three levels for each are enough—low, moderate, high—and the federal scheme already uses those three for impact under FIPS 199, so an organization categorizing systems that way has the vocabulary and should rate confidentiality, integrity, and availability separately.
Setting the two against each other produces an order that survives argument.
- High impact, high likelihood. These come first, and anything here that cannot be fixed quickly needs an interim compensating measure rather than a place in a queue. If the register has several, that is the finding.
- High impact, low likelihood. The ones that end organizations. They are easy to defer precisely because they are improbable, and improbable is not the same as impossible. Their answer is often continuity planning, insurance, or a tested recovery path rather than a preventive control.
- Low impact, high likelihood. The steady nuisances. Frequently the cheapest to fix, and worth fixing when the fix can be automated, because the aggregate cost is real and because people stop reporting things that happen constantly.
- Low impact, low likelihood. Document, accept explicitly, revisit at the next assessment.
Two cautions keep this from becoming theater.
The ratings are judgments, and what makes them defensible is deciding what each level means before rating anything. "High likelihood" needs a definition—more probable than not within a year, say—rather than being a feeling that varies with who is in the room. The same applies to impact, which should be expressed in whatever the organization actually measures: money, downtime, safety, or obligation.
And the ordering ranks risks, not remediations. A moderate risk with a half-day fix should usually be done before a high risk that needs a six-month project, because the first reduces exposure now. The honest sequencing question is how much risk each unit of effort removes, which is why prioritization has to reflect real budgets rather than an abstract severity score.
Impact, likelihood, and the resulting priority all belong in the register beside the mitigation and the residual risk. That is what turns it from a record of what is wrong into an answer to what happens next—and rerunning the ratings after the work is done is how the organization confirms the residual risk actually moved.
The annual cadence, and the trigger
Annual is the usual interval, and like the policy review it should carry an event trigger alongside it. A new line of business, an acquisition, a significant architecture change, or a serious incident all change the answer enough to justify revisiting it before the anniversary.
An assessment that is repeated annually and reaches the same conclusions without examination is not being repeated; it is being reprinted. The test is whether this year's version reflects anything that changed.
Kenneth Ingham Consulting performs risk assessments that start from who would attack an organization and why, and produce mitigations an organization can actually operate.