Information Security Risk Management: What the Frameworks Say & What Auditors Actually See

The risk register is usually the easiest document to get during fieldwork. It arrives the same day I ask; it is formatted well, every row carries a likelihood rating and an impact rating, and someone has approved it. Then I check the modification history and find that nothing in it has changed since the day it was created. The document exists. The program behind the document does not.

Information security risk management is the process an organization uses to identify, assess, respond to, and monitor the risks that threaten its information assets. The definition is not new, but the ground it has to cover has grown since this article was first written: the governance function that the National Institute of Standards and Technology (NIST) added to its Cybersecurity Framework (CSF) in 2024, the cloud services that most risk registers still do not cover, the concentration of critical operations inside a handful of vendors, and the artificial intelligence (AI) tools that staff adopted faster than anyone assessed them. This article covers what the frameworks say about information security risk management and what I see when I review these programs.

Information Security Risk Management: The Short Answers

Before getting into the process itself, here are quick answers to the four questions I hear most often when a team starts building or revisiting a risk management program. The sections that follow expand on each one.

What Is Information Security Risk Management (ISRM)?

Information security risk management, sometimes called cyber risk management, is the ongoing process of identifying threats to your information assets, evaluating how likely they are to occur and how much damage they would do, deciding what to do about each one, and watching whether those decisions still hold. A documented information security policy sits underneath it.

Why Does Risk Management Matter So Much in Information Security?

No organization can fix everything at once, and risk management is how it decides what comes first, where its people focus, and where to allocate budget. When I review an organizational risk management program, the question underneath is whether the controls in place trace back to a risk somebody identified.

How Is Risk Calculated in Information Security?

Two ways…Qualitative analysis rates likelihood and impact on a scale, usually high, medium, and low, and most organizations use it. Quantitative analysis expresses risk in financial terms using mathematical models. Qualitative is easier to keep running and is perfectly defensible in an audit, while quantitative tends to land better with a board; the methodology section below covers when each fits.

Who Owns Risk?

Each risk needs a named owner with the authority to accept it, not a department or a committee. When nobody owns a risk, no one decides what to do about it, and the register simply records that it exists. Clear information security roles and responsibilities are what make a risk register something other than a list.

The Four Key Steps of the Risk Management Process

The four steps are the same as in the original version of this guide; most of what has changed is what goes into each one.

1. Identify & Categorize Your Assets

Most organizations start with an inventory of what they own, call the task complete, and move on. Categorization is the part that matters… What each asset does, who depends on it, what data moves through it, and what happens to the business if it goes away.

Where inventories fall short now is coverage. Lists built around owned hardware miss the cloud platforms, software-as-a-service applications, and application programming interfaces that now carry most of the workload. If your asset list would not tell a new hire where your customer data security obligations live, it is incomplete. Or if your asset inventory consists of listing resources directly out of your infrastructure provider’s site, then you simply have a dashboard that is useless when you truly need it (yes, it happens).

2. Assess the Risk

With your assets now categorized, identify the threats and vulnerabilities attached to each one, then rate the likelihood of exploitation and the impact if it occurs. This is where you find out which risks deserve real money.

It is rare, but I have had clients submit a vulnerability scan when I asked for their risk assessment. A vulnerability assessment tool tells you what is technically exposed on a given day, and that is useful. It is one input into the risk assessment, but only one of many. The assessment is where that exposure gets weighed against what it means to the business, how likely someone is to act on it, and what you intend to do about it.

3. Respond to & Mitigate the Risk

Any risk has four possible responses: accept, transfer, mitigate, or avoid. The right one depends on the organization’s risk appetite, and that appetite has to be written down and approved by someone with the assigned authority before “accept” counts as a decision. Where it is undocumented, acceptance is what happens by default to every risk nobody gets around to treating, and afterward there is no way to tell a deliberate acceptance from a forgotten one.

Take an internally hosted system that runs without multifactor authentication (MFA), or with lax encryption, because it can only be reached from inside the network. On the day that risk is accepted, the reasoning may hold up. When no one owns the risk, though, no one notices when the conditions behind it change. A cloud migration, a new remote access path, or a new integration can turn a contained risk into a real exposure, and the original acceptance still sits in the file as if nothing changed.

4. Monitor, Report, & Revisit

Risks live in a register that gets reviewed on a scheduled basis and reassessed whenever something material changes in the business or its vendors.

This step is where I find one of the most common gaps. During an audit, we learn about the significant events an organization went through during the period: a system migration, a major transaction, a concern raised about a key vendor. Then we open the risk register to see how those events were assessed, and there is nothing to be found. The business changed in ways that plainly carried risk, and the register was never touched.

An annual review is the minimum. The strongest programs pair the register with continuous monitoring so changes surface between formal cycles. If mitigation tasks are tracked within the risk register, those should be updated as needed, as well.

Four Risks Missing from Most Risk Registers

Most registers I review were built from a template that predates the current threat landscape, and they tend to miss the same four areas.

Cloud Services & Shared Responsibility

When workloads moved to cloud infrastructure , a large part of the control environment moved with them, and part stayed behind. The risks you inherited from your providers belong in your risk register even though you do not operate the controls, which is the whole point of complementary subservice organization controls. Organizations preparing for cloud compliance audits often find this gap for the first time during the audit itself.

A common version of this… A company moves its databases to a major cloud provider and assumes backups come with the service. During the audit, we ask for evidence of backup configuration(s) and restore testing, and the team sends over the provider’s SOC 2 report. That report covers the provider’s own infrastructure, and it lists configuring and testing backups of data as the customer’s responsibility. Nobody had read that section, and nobody had ever tested a restore.

Vendor Concentration

Nearly every organization can produce a vendor list, but few can say how much of the business sits with one provider, or what happens if that provider has a bad week. Concentration is a distinct risk from vendor quality, and it rarely shows up as its own register entry.

Ransomware as a Continuity Risk

Ransomware usually gets filed under security alone. The measurable exposure is recovery time, and recovery time belongs in the register with a number attached. That makes it as much a business continuity planning question as a security one. NIST SP 800-61 Revision 3 is a useful reference for the response side of that entry.

Artificial Intelligence, Sanctioned & Otherwise

This area usually needs two entries. The first covers the AI capabilities your organization deliberately adopted, including the vendors behind them, which is a specific form of AI as a supply chain risk. The second covers shadow AI, the tools staff started using on their own. It is harder to assess precisely because nobody approved it, which is why it warrants a register entry rather than a policy line.

Choosing an Information Security Risk Management Methodology

A defined methodology is what makes risk comparable across the business. An internal method works as long as it is built on an established framework and applied consistently. The table below compares the options I see most often.

The most consequential change here is governance. According to the NIST Cybersecurity Framework 2.0, released in February 2024, a sixth function called Govern joined the original five, and it addresses how risk decisions get made, who makes them, and how they connect to business strategy. That is a direct response to a familiar pattern: capable technical controls with no traceable accountability above them, which is why information security governance deserves its own attention.

On qualitative versus quantitative: according to the FAIR Institute, the FAIR standard reached version 3.0 in January 2025, and quantification has become more approachable, though it remains more demanding than most organizations can sustain across a full register. For most organizations, a qualitative program that keeps running is more useful than a quantitative one that never gets past the pilot.

Whichever you choose, NIST SP 800-30 Rev. 1 is the practical reference for conducting assessments, and ISO/IEC 27005:2022 is the companion guidance for organizations working inside an ISO 27001 management system.

Vendor & Third-Party Risk Deserves Its Own Assessment

This is another of the most common gaps I find: organizations that assess internal risk thoroughly and have no real vendor risk component at all.

Reviewing a vendor is not the same as assessing the risk of depending on one. A completed security questionnaire describes the vendor’s controls, but it says nothing about what breaks on your side if that vendor goes down or gets acquired. Whether a provider is a vendor or a subservice organization also changes what you need from them.

Vendors need periodic review, and more frequent review when the services you depend on change materially. Treating vendor and third-party risk management as an annual questionnaire rather than an ongoing discipline is how the concentration problem described earlier goes unnoticed, and it is often a surprise for  organizations new to System and Organization Controls (SOC) 2 vendor management.

The gap usually shows up in how organizations handle their vendors’ SOC reports. They collect the reports, file them, and skip the two parts that matter most: the complementary user entity controls (CUECs) that the vendor is relying on them to perform, and the exceptions the vendor’s auditor reported. Those are the pieces that tell you what risk you are actually carrying. If vendor reviews are not built into your risk management program, you are flying blind and hoping nothing goes wrong. You are also ignoring controls the vendor has specifically documented as your responsibility.

What Auditors Look For in a Risk Management Program

When we review a risk management program, the register’s history usually tells us more than its contents. In a mature program, entries carry different dates and show that someone has revisited them. Each risk has a named owner, treatment decisions trace back to a person with the authority to make them, and the record shows the register changed what the business did, such as a project funded or a vendor replaced because of it.

Weaker programs often look better at first glance. Their registers are complete and neatly formatted, with every field filled in, but there is no modification history, no named owner, no recurring status updates, and nothing connecting an entry to anything that happened afterward. The register was produced for the review rather than used to drive decisions.

Two problems come up repeatedly in the programs that fall short. The first is the annual cycle that never closes. The risk assessment gets opened once a year, the same risks carry forward with little progress, and some of the risks the organization intended to address are simply forgotten by the next review.

The second is scope, and it is another common finding. Many registers list only specific technology risks: unpatched systems, weak passwords, malware. Technology risk is a primary component of what we look for during an audit, but it is only one component, and it is shaped by forces outside the technology itself.

According to the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria used in a SOC 2 examination, the risk assessment is expected to consider:

• Internal and external factors across the entity (CC3.2)
• The potential for fraud (CC3.3)
• Significant changes to the business model, leadership, and vendor relationships (CC3.4)
• Risks arising from potential business disruptions (CC9.1)

A complete register therefore addresses fraud, business continuity, environmental events such as natural disasters or the loss of a facility, regulatory change, and the departure of key personnel. When those entries are missing, the register does not meet what the criteria expect, no matter how thorough its technical entries are. Security maturity models offer a structured way to gauge where your program sits, and the SOC 2 risk assessment criteria post walks through each criterion in detail.

More Information Security Risk Management Questions, Answered

These are some of the most common questions we get from clients regarding information security risk management.

Is NIST 800-53 a Risk Management Framework?

No. NIST SP 800-53 is a catalog of security and privacy controls, not a risk methodology. It lists controls, but it does not tell you how to identify or rate risk. The NIST risk methodology lives in SP 800-37 Rev. 2, the Risk Management Framework, with assessment detail in SP 800-30 Rev. 1.

For currency, SP 800-53 reached Release 5.2.0 on August 27, 2025, adding controls covering logging syntax, root cause analysis, and design for cyber resiliency.

What Is an ISMS in Information Security?

An information security management system, or ISMS, is the documented set of policies, processes, and controls an organization uses to manage information security. ISO/IEC 27001 defines what an ISMS must contain, is certifiable, and makes risk assessment and risk treatment core requirements.

How Often Should a Risk Assessment Be Updated?

At least once a year, and again whenever something material changes, regardless of where you are in the annual cycle. Typical triggers include a new system implementation, a significant new vendor or vendor change, an acquisition, a reorganization, or a notable incident.

How Is a Risk Assessment Different from a Vulnerability Scan?

A vulnerability scan is an automated check for known technical weaknesses at a point in time. A risk assessment weighs threats, likelihood, impact, and treatment across people, processes, technology, and vendors. A scan is one of the inputs a risk assessment draws on.

Is Your Risk Register Doing Its Job?

The frameworks are good at describing what a risk management program should contain and less useful for telling you whether yours is working. One practical test… Open your register and look for a decision the organization made because of something written in it. If you can find one, the program is doing its job. If you cannot, the register has become documentation, and it is worth looking at how the process runs between reviews.

An independent look at how your risk program operates in practice can show where the register and the business have drifted apart. To learn more about how Linford & Company evaluates risk management as part of its audits, or about the audit services we provide, please don’t hesitate to contact us.

This post was originally published on 1/17/2017, updated on 1/29/2020, and updated again on 10/7/2026.