Vulnerability Management Process: Find, Prioritise, Fix

Managing vulnerabilities means finding weaknesses in your systems, ranking them and deciding what to do about each one. This guide is for IT managers and IT heads in India or the GCC, especially if you hold scan results and a backlog. The vulnerability management process is that cycle with a record at every stage. It also gives seven stages, a ranking rule, a decision rule for the fix and an exception record. Run well, the vulnerability management lifecycle starts again after each assessment. If you want to know how an assessment itself runs, see vulnerability assessment. NIST and CISA are US bodies and the NCSC is a UK one, so this guide makes no claim about Indian or GCC rules.

Vulnerability Management Process: The Short Answer

It is seven stages, and each one ends in a record. They are Signisys’ own method, drawn from NIST, NCSC and CISA statements, but not a standard.

NIST SP 800-40 Revision 4 (April 2022) is a US publication for CIOs, CISOs, cybersecurity directors and managers, and it supersedes Revision 3. In our words, its life cycle is to know when a flaw affects your assets, plan the response, then carry it out and verify it. The table shows who owns each step of the vulnerability management process and what it leaves behind when the step ends.

An assessment is a point-in-time list, while management is what happens to the list afterwards. The NCSC’s guidance is also from a UK body (version 2.1).

Vulnerability Management Process, Stage 1: Scope and Owners

Start with a list of what you run and who answers for each system. The NCSC’s third principle says to identify systems, services, cloud infrastructure, mobile devices, hardware and software. Its guidance adds that knowing who is responsible for a system matters just as much as knowing it exists. Principle 2 warns that, if shadow IT exists, an organisation may not know it runs the affected software at all.

NIST section 3.2 says a complete inventory may be impossible, but a close-to-comprehensive one, kept current by automation, is the realistic goal. NIST also describes maintenance groups, where each asset joins a set of similar assets that shares a maintenance plan. When you ask what attackers can reach, that is your attack surface, and this list is its inventory.

Then agree who reports findings and how much time maintainers give to fixing (NCSC principle 3). Also agree who signs off exceptions, a senior-level decision in the NCSC’s principle 5.

The record this stage leaves is an asset list with a named owner and a patch routine for each system. That is our reading of the sources. NIST says to keep inventories up to date, so check the list on a schedule.

The stage sets up the vulnerability management lifecycle, since each finding needs an owner to receive it.

Stage 2: Find What Is Open, and What the Scan Missed

Run the scan against the scope from Stage 1, then check what it did not reach. The NCSC says to assess the whole estate at least every month. It also says to keep a way to assess at any time when a flaw is a concern. If you use built-in cloud tools, follow the provider’s own cadence.

The NCSC says that for an organisation that has never run an organisation-wide scan, the first report will probably contain hundreds or even thousands of findings, so plan for the size of the first list. The NCSC also adds that scanning doesn’t need an external partner, and that staff shouldn’t require special training.

Finding is one stage of the vulnerability management process. The full set of checks belongs in a separate guide, and this one names no tool.

The record this stage leaves is the scope, the date and the coverage, including any host the scan missed.

The NCSC also suggests third-party penetration tests as one way to check that the process works. How testing differs from assessment is a separate question.

Stage 3: Rank Findings in the Vulnerability Management Process

Rank by where a flaw sits and what it can do, not by a score alone. NCSC principle 4 says to group findings that share a fix. It then puts internet-facing services first, together with the findings of largest impact if exploited. The tool’s severity rating, such as CVSS, isn’t enough alone; the NCSC says 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 prioritisation framework. It is kept by a US agency, but NIST notes that organisations outside the federal agencies may use it voluntarily. The NCSC’s principle 2 recommends monitoring the catalog, and cautions that exploitation reports cover only what has already occurred. An organisation may also run niche software that the catalog does not cover.

Our ranking rule has three steps.

The record is the ranked list, including the reason each item sits where it does.

Stage 4: Decide, Then Fix or Reduce the Risk

Choosing the response to each finding is the core of the vulnerability management process. NIST section 2.1 lists four risk responses: accept, mitigate, transfer or avoid. Patching is also one way to mitigate. If an organisation doesn’t decide, it has accepted the risk of the software it runs by default. The NCSC sorts findings into fix, acknowledge or investigate, and investigate is only a temporary state.

Choose the Response: Patch, Mitigate or Accept

Each row below pairs a situation with a response, then with the record it leaves.

NIST also calls the third row “unpatchable assets”, a maintenance-plan scenario, and points to isolation or other mitigation.

Plan the Change Window and the Rollout

NIST lists change-management scheduling and testing the patch among its preparation steps. It also suggests a phased rollout starting with a small canary group, and a grace period before installation is forced. NCSC principle 1 adds a staged rollout, including the ability to pause or roll back.

The NCSC, a UK body, publishes a table of “update completed within” times (as of November 2026). They are 5 days for internet-facing services and software, 7 days for operating system and applications, and 14 days for internal or air-gapped services and software. The NCSC says these are business-as-usual times, but that they are too long when exploitation is rife. It also says to balance them against availability for business-critical systems. This guide does not present them as an Indian or GCC rule.

Record an Exception

When a flaw is acknowledged, the NCSC says it gets a recorded reason and a review date. If the risk is high, it also goes to the risk register. Accepting is a senior-level business risk decision (NCSC principle 5), and NIST says to track and review exceptions.

Our record has five fields: what the flaw is, why it stays, who decided, the compensating step and the review date. An exception stays inside the vulnerability management lifecycle, as the review date brings the flaw back to the table.

Stages 5 to 7 of the Vulnerability Management Process: Verify, Report, Repeat

Verify: Recheck the system after the fix, since a closed ticket is not proof. NIST sections 2.3.3 and 2.3.4 ask you to confirm the patch is installed and has taken effect, and then that it stays in place, not uninstalled and not restored from a backup. NCSC principle 6 says to verify that a mitigation worked. It also says to keep monitoring any temporary workaround. The record is the closing check and its date.

Report: Leaders need the open risks and the accepted ones, while each owner needs their own list, and that split is our reading. NCSC principle 5 says the business owns the risk, not the security team, and that the accepted risk should be visible to senior leaders.

Repeat: The cycle restarts on a schedule, such as the NCSC’s monthly assessment. It also restarts on a trigger, such as a flaw of concern, a new system or a change. The vulnerability management lifecycle closes by feeding the next scan, and each lap should shorten the list of systems with no owner.

NCSC principle 6 also asks for regular review of the process itself. After a failed fix, reviewing the way the work gets done, not only the one system, is our reading.

One Finding, Start to Finish (a Worked Example)

The vulnerability management lifecycle is easier to follow on a single finding. This example is illustrative and hypothetical, not a client story, and it holds no dates, counts or costs. An internet-facing server has a flaw that appears in the known-exploited list.

What This Article Does Not Cover

This guide covers the vulnerability management process around the findings. It doesn’t define the term, list assessment checks, compare assessment with penetration testing, or choose a tool. For a specific case, see why a firewall stays unpatched. For wider reviews, there are checklists for a network security audit and an IT risk assessment. NIST and CISA are US bodies and the NCSC is a UK one, and this guide does not present their timescales as Indian or GCC rules, nor is it 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, as set out in our VAPT and Cybersecurity Risk Assessment solution and our Cybersecurity Services page. Even so, the decisions on each flaw stay with your own team.

Vulnerability Management Process FAQ