Vulnerability management is the ongoing work of finding weaknesses in your systems and ranking them. It also covers fixing or reducing them, and checking that the fix worked. The question “what is vulnerability management?” comes up when the scans keep running and the findings list stays long. The NCSC’s guidance describes it as a process to validate, and where necessary fix, how well your update and security configuration controls are working.
Last reviewed 2026-11-01 by Manish Sharma.
This guide is for IT managers, IT heads and owners at firms of roughly 250 to 2,000 people in India or the GCC. They run scans but want the list to shrink. It gives a short definition, six reasons flaws stay open, what closes each one, and a four-question test. What an assessment is has its own page: vulnerability assessment. The NCSC is the UK’s national cyber security body, while NIST and CISA are US bodies. This guide makes no claim about Indian or GCC rules.
What Is Vulnerability Management? The Short Answer
It is a process, not a scan. Every system has weaknesses. The NCSC names three kinds: configuration issues, defects in vendor products, and flaws the vendor doesn’t yet know exist. The NCSC’s “Understanding vulnerabilities” page calls the last kind zero-days, and the glossary covers them as zero-day exploits. Your job is to keep finding them, then decide what to do about each one and prove the result.
NIST SP 800-40 Revision 4 (April 2022) is a publication of the US standards body NIST. It is written for CIOs, CISOs and others who manage organisational risk from software, and it supersedes Revision 3. In our words, its cycle is to know when a new flaw affects your assets and to plan the response. Then you carry it out by preparing, implementing, verifying and monitoring. NIST lists four responses, not one: accept, mitigate, transfer or avoid. Patching is also one way to mitigate.
In our framing, an assessment finds and lists flaws, and management is what happens to the list afterwards. The NCSC adds that a scan also shows where you aren’t installing updates. It also suggests third-party penetration tests as one way to check that the process works.
Key Takeaway Vulnerability management is a process that ends with a verified fix or a recorded decision, not a list of findings.
Why Vulnerability Management Stalls: Six Reasons Flaws Stay Open
The six reasons below are Signisys’ reading of the NCSC and NIST, and they are not a standard. Each one pairs with the decision or record that closes it. If one fits your firm, start there.
| Reason | What it looks like | What closes it |
|---|---|---|
| Unknown assets | The NCSC says knowing what systems you run is fundamental, and that an attacker will enter through any route, including shadow IT. | A current asset list with an owner for each. |
| No named owner | The NCSC says it is just as important to know who is responsible for each system, and NIST describes a divide between owners and security managers. | An owner per system and an agreed way to report and fix findings. |
| Fear of breaking systems | The NCSC says some organisations don’t update by default, for fear updates may “break” systems. | A staged rollout with a pause or roll-back. |
| No fix to apply | The vendor may offer no update, or the product may be at end of life. | A dated mitigation or isolation, or a plan to migrate. |
| More findings than people | The NCSC says that where no organisation-wide scan has run before, the first report will probably contain “hundreds or even thousands” of vulnerabilities. | Grouping and triage into fix, acknowledge or investigate. |
| Ranking by one score | The NCSC says not to base decisions purely on a single severity score such as CVSS. | Known-exploited and internet-facing flaws first, then the rest. |
Vulnerability management stalls when one of these goes unanswered, and the next sections take them in turn.
Unknown Assets and No Owner: The Gaps Before Any Scan
You can’t fix what you don’t know you run, and vulnerability management starts with that asset list. The NCSC guidance sets out numbered principles, and principle 3 also says to identify systems, services, cloud infrastructure, mobile devices, hardware and software. Principle 2 says the NCSC has worked with organisations that had security incidents on systems their security and IT teams didn’t know about. It adds that a response must cover shadow IT. NIST section 3.2 is candid. A comprehensive inventory of all assets may be impossible to achieve, but a realistic goal is a close-to-comprehensive one, kept current by automation. What attackers can reach is your attack surface, and the asset list is where mapping it starts.
Ownership is the second gap. Principle 3 asks you to agree what the security and IT maintainers each do. That includes how maintainers report findings and how much time they give to fixing. The NCSC says knowing who is responsible for a system is just as important as knowing it exists.
The record that closes it. A one-page asset list with a named owner and a fix cadence for each system. This is our reading of the sources. The honest limit: an asset list goes out of date, so it needs a check on a schedule.
Old products. The NCSC says a product on extended support may not receive fixes for all known vulnerabilities. It recommends moving to a supported version instead. That leads straight into reason 4.
Fear of Breaking Systems, and Fixes That Do Not Exist
The NCSC’s guidance says some organisations may view this work as a distraction from building new systems or solving pressing user needs. It also says not all organisations update by default, because of concerns that updates may “break” systems. NIST’s executive summary adds that business owners may believe patching hurts productivity, since it needs scheduled downtime. In its section 3, NIST says disruptions from patching are largely controllable, while disruptions from incidents are largely uncontrollable.
Patching is part of vulnerability management. NIST section 3.3 says routine patching “is often postponed and neglected”. That leaves windows of opportunity for attackers and makes later emergency patching harder, because earlier patches must go in first.
NCSC principle 1 points to testing on your own systems and to a phased or canary rollout. It also points to the ability to pause or roll back.
When there is no fix. NIST describes “unpatchable assets”. The vendor provides no patches, the asset is at end of life, or it must run uninterrupted. NIST says these need isolation or other methods to mitigate the risk. It adds that a new flaw in such an asset might change the method needed.
Verify the result. NCSC principle 6 says to check that the vulnerability is no longer present when a fix comes from reconfiguration or mitigation. If the mitigation is only a temporary workaround, you will need to keep monitoring it. The NCSC gives three reasons. Another vulnerability may emerge that compromises it, or a flaw may make it ineffective. A vendor may also release an update to install in its place.
Ranking Flaws: Known-Exploited First in Vulnerability Management
NCSC principle 4 groups similar findings first, then sorts them into fix, acknowledge or investigate. Investigate is a temporary state. Internet-facing services and the largest impact if exploited come first, and each fix gets a date.
The NCSC adds that a tool’s severity rating, such as CVSS, is not the whole picture. It is essential to consider business impact and risk for your organisation.
The Known Exploited Vulnerabilities (KEV) catalog is CISA’s list of flaws that attackers are known to have exploited in the wild. CISA also says organisations should use it as an input to their vulnerability management prioritisation framework. It is a list kept by a US agency, but not a UK or Indian rule. The NCSC’s caveat in principle 2 is that such sources report only exploitation that has already occurred. Agency notifications also cover widely deployed software, and you may run more niche software they don’t mention.
A US federal directive, BOD 22-01 (3 November 2021), set up CISA’s catalog. It binds federal executive branch agencies. CISA’s page for it now marks the directive as revoked, and BOD 26-04 supersedes it.
Our ranking rule for a mid-size firm is our own reading. Known-exploited and internet-facing flaws come first, then the largest impact, then the rest. It is a ranking aid, not a promise that flaws off the list are safe.
Accepting a Flaw on Purpose: The Decision and the Record
Vulnerability management also includes the choice to leave a flaw open. NCSC principle 5 says who makes that call: the decision not to fix is, at root, a senior-level business risk decision, not an IT problem. You will probably find more issues than you have resources to fix. After the decision, record the reasons. Then make sure your risk management framework, for example a risk register, covers the remaining risk. The business owns the risk, not the security team, and senior leaders should be able to see it.
NCSC principle 4 adds the detail for an “acknowledged” flaw: a recorded reason and a review date. The rationale should be enough to justify the decision if attackers exploit the flaw later.
NIST section 2.1 also frames accepting risk as one of its four responses. In our words, an organisation that doesn’t decide has accepted the risk by default, but accepting it on purpose means writing it down.
Here is an illustration, not a client story, based on an example in NCSC principle 4. The organisation will decommission a system shortly, and the flaw in it is hard to reach and hard to exploit. The NCSC calls not updating in that case perfectly rational, with sensible controls such as making sure the decommissioning continues. In our reading, the record names who decided, the reason, the retirement date and the review date. If nobody keeps that record, the same choice becomes an unmanaged gap.
Key Takeaway A flaw left open on purpose needs a named decider, a reason and a review date.
Four Questions to Test Your Own Vulnerability Management
This test is Signisys’ own, and it isn’t a standard or an assessment of your firm. Use it to see how far your vulnerability management has got, one sentence per answer.
- Assets: can you list every system and service you run, including ones IT did not buy? Who owns each? (NCSC principles 2 and 3).
- Fear: what exactly were you afraid of when you delayed your last update? What test, staged rollout or roll-back would have removed that fear? (NCSC principle 1).
- Ranking: which flaws on your list appear in CISA’s catalog, and which can anyone reach from the internet? (CISA’s catalog and NCSC principle 4).
- Decision: for each flaw you chose to leave open, who decided, why, and when is it next reviewed? (NCSC principles 4 and 5).
Four questions on paper don’t replace a scan, but the answers show where the gaps are, not how bad the findings are.
What This Article Does Not Cover
This is an explainer. It doesn’t walk the process stage by stage, give a checklist, compare assessment with penetration testing, or choose a tool. For a specific case, see why a firewall stays unpatched. For wider reviews, there are also checklists for a network security audit and an IT risk assessment. The NCSC is a UK body and NIST a US one, and their timescales aren’t Indian or GCC rules. It isn’t legal advice. If you are facing a backlog of open security findings, the box below is the next step.
Signisys provides cybersecurity services for growing firms. Our VAPT and Cybersecurity Risk Assessment solution and our Cybersecurity Services page set them out. The decisions on each flaw stay with your own team.
Vulnerability Management FAQ
What is vulnerability management beyond a scan?
Who decides that a flaw can stay open?
Does patching alone count as vulnerability management?
What does the NCSC say about how regularly to assess?
Where should an IT team start?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.