Vulnerability Management Defined in Plain Terms
Vulnerability management is the continuous practice of finding security weaknesses across your systems deciding which ones matter most and fixing or reducing them before attackers can use them. It runs as an ongoing loop of discovery, prioritisation, remediation and verification, not a single scan or a one-off audit, and it continues for as long as your systems exist.
The reason it matters has changed. For years, stolen passwords were the most common way attackers got in. That is no longer true. Verizon’s 2026 Data Breach Investigations Report which pools incident data from law enforcement, response firms and national CERTs found that exploiting a vulnerability is now the single most common way a breach begins at 31% of cases.
The supply of flaws keeps growing. NIST’s National Vulnerability Database recorded about 29,000 new CVEs in 2023 and more than 40,000 in 2024 and NIST reports that CVE submissions rose 263% between 2020 and 2025. No team can read, test and fix all of that. Vulnerability management exists to impose order on the flood so the few flaws that can actually hurt you get fixed first.
The Vulnerability Management Life Cycle
Vulnerability management is a loop that repeats for as long as your systems run. Each pass feeds the next. Most teams break it into five stages.
- Discover: Build and keep an accurate inventory of your assets, then scan them for known flaws. You cannot manage what you do not know you have.
- Prioritise: Rank the findings by real risk rather than raw severity. A flaw that is internet-facing and actively exploited matters more than a high score buried on an isolated machine.
- Remediate: Fix what matters usually by patching but also by changing a configuration, removing an exposed service or applying a temporary control while a patch is tested.
- Verify: Rescan to confirm the fix actually landed. A ticket marked done is not the same as a flaw that is gone.
- Report: Track how fast you close flaws and where the backlog sits so owners and the board can see whether the programme is winning or falling behind.
The loop never stops because new flaws appear daily and your systems change constantly. A programme that scans once a quarter and stops there is really running an audit, not managing vulnerabilities.
Common Types of Vulnerabilities
A vulnerability is any weakness an attacker can use to do something they should not. They come in a few recurring shapes and a good programme looks for all of them rather than only missing patches.
- Unpatched software: Known flaws in operating systems, applications and libraries that a vendor has already fixed but you have not yet applied. These carry a CVE identifier and are the classic target.
- Misconfigurations: Systems left in an insecure state such as default settings, open storage buckets or overly broad permissions. Nothing is broken in the code, but the setup exposes you.
- Weak or default credentials: Accounts protected by guessable or reused passwords, factory defaults or no multi-factor authentication.
- Exposed services: Databases, remote-access ports and admin panels reachable from the internet that never needed to be.
- End-of-life systems: Hardware or software the vendor no longer patches so new flaws are never fixed.
Some of the most damaging flaws hide inside components you did not know you were running. When the Log4Shell flaw hit a common Java logging library in December 2021, many organisations struggled not to patch it but to find where it ran, because it sat buried deep inside other software. You cannot fix what you cannot see which is why an accurate inventory sits at the heart of the discipline.
Security Scanners and Vulnerability Management Tools
Tooling does the heavy lifting of finding flaws at a scale no human could match. It helps to know what each type does and, just as important, what it does not.
A security scanner is software that checks your systems against a database of known flaws and reports what it finds. Scanners come in a few forms. Network scanners probe systems across the network. Agent-based scanners run on each device for a deeper, always-on view. Web application scanners test websites and APIs for flaws such as injection.
There is an important split between authenticated and unauthenticated scans. An unauthenticated scan sees only what an outside attacker sees. An authenticated scan logs in and inspects the system from the inside, which finds far more and raises fewer false alarms. For anything you own, authenticated scanning is worth the setup.
Beyond the scanner sit vulnerability management tools that pull findings together, prioritise them and track remediation and patch management tools that deploy the fixes. What no tool does is decide which flaws matter to your business or who owns the fix. A scanner that returns thousands of findings a month is not much use until someone turns that list into a short, ranked plan of action.
When choosing tools, the questions that matter are whether they cover all your asset types, whether they support authenticated scanning, whether they prioritise using real exploitation data and whether they fit how your team already tracks and closes work.
The Business Impact of Unpatched Vulnerabilities
An unmanaged vulnerability is more than an IT footnote. It is an open door with a measurable cost.
The clearest cost is a breach. Because exploited vulnerabilities are now the top way in, an unpatched internet-facing system is one of the most likely routes an attacker will take. Ransomware crews in particular favour known flaws in perimeter devices because they are reliable and quick to exploit.
The deeper problem is timing. Attackers now weaponise a new flaw within days of its disclosure sometimes within hours. The 2026 DBIR put the median time for organisations to fully fix a known-exploited flaw at 43 days, up from 32 the year before and found that only 26% of the flaws on CISA’s known-exploited list were fully remediated in 2025. The gap between how fast attackers move and how fast defenders patch is where breaches happen.
Beyond the breach itself sit the follow-on costs of operational downtime, incident response, legal and notification bills and lost trust. For regulated organisations there is now a compliance cost too, because failing to manage known risks is itself a breach of the rules whether or not an incident ever occurs.
Real-World Cases
Four incidents show the different ways vulnerability management fails and the control that would have changed each outcome.
Equifax, 2017
In 2017 the credit agency Equifax was breached through a critical flaw in Apache Struts, a web framework, tracked as CVE-2017-5638. A patch had been available for about two months. The US Government Accountability Office found the vulnerable system was missed, in part because an internal scan failed to flag it and the alert to patch never reached the right team.
Attackers reached the data of roughly 147 million people. The fix was not exotic. Applying the published patch to an internet-facing system within the disclosed window, backed by scanning accurate enough to prove the flaw was gone, would have closed the door.
WannaCry and the NHS, 2017
In May 2017 the WannaCry ransomware worm spread worldwide by exploiting a flaw in an old Windows file-sharing protocol. Microsoft had shipped the fix, MS17-010 about two months earlier. Machines that had not applied it were swept up.
The UK National Audit Office found the attack disrupted more than a third of NHS trusts in England and led to almost 20,000 cancelled appointments and operations. Two things would have blunted it, applying the critical patch on time and retiring or isolating the legacy protocol that should not have been running at all.
Log4Shell, 2021
In December 2021 a maximum-severity flaw known as Log4Shell was found in Log4j, a Java logging library used almost everywhere. CISA and its international partners warned that attackers were scanning for it within hours.
The hard part was not the patch. It was discovery. Log4j was buried inside countless applications as a dependency few teams had catalogued so many could not answer the basic question of where they were exposed. The case is the clearest argument there is for a real software inventory.
MOVEit, 2023
In mid-2023 the Cl0p group exploited a previously unknown flaw, CVE-2023-34362, in MOVEit Transfer, a file-transfer product before any patch existed. CISA and the FBI documented the campaign which stole data from an estimated 2,700 organisations and tens of millions of people.
A zero-day breaks the simple rule of patch fast because at first there is nothing to apply. What limits the damage is narrowing exposure in advance, so high-value systems like file-transfer apps are not needlessly open to the internet, then moving to emergency patching and close monitoring the moment a fix and active exploitation are confirmed.
Vulnerability Management and Compliance
For organisations in Europe and in Sweden in particular, vulnerability management is no longer optional good practice. It is written into the law and the standards you are audited against.
Under the EU NIS2 Directive, brought into Swedish law as Cybersäkerhetslagen (SFS 2025:1506, in force 15 January 2026), Article 21 requires in-scope organisations to take risk-based security measures, including continuous monitoring and vulnerability handling. Article 20 makes the board personally accountable for approving and overseeing them. Sweden’s supervisory authority, MCF (formerly MSB), can act on missing measures whether or not a breach has happened. Our guide to NIS2 in Sweden sets out the full picture.
Financial entities face DORA, whose ICT risk management framework (Article 6 onward) requires flaws to be identified and remediated on a defined cycle with ICT-related incidents managed under Article 17. Compliance is supervised by Finansinspektionen. Organisations certified to ISO 27001 must run vulnerability management as part of their information security management system and testing that the controls work is exactly what auditors check first.
Where personal data is involved, GDPR Article 32 expects appropriate technical measures and an unpatched known flaw is hard to defend as appropriate. A breach that exposes personal data starts a 72-hour reporting clock to IMY, running alongside the NIS2 cascade to MCF.
Regular testing is part of the same duty. A penetration test proves what an attacker could actually chain together which is why it sits alongside continuous scanning in most compliance regimes.
Patch Management and Vulnerability Remediation
Finding flaws is the easy half. Closing them, on a clock, is where programmes succeed or fail. A few practices separate the two.
- Know your assets first: You cannot fix what you have not found. Keep a live inventory of hardware, software and internet-facing services and scan it continuously with authenticated scans.
- Prioritise by exploitation over severity alone: Fix what attackers are actually using before you touch a high score that no one exploits. CISA’s Known Exploited Vulnerabilities list and your own business context beat a CVSS number on its own.
- Set remediation deadlines and owners: Give every class of flaw a deadline and a named owner. Critical internet-facing flaws need a clock measured in days, not the 43-day median the 2026 DBIR recorded.
- Make patch management routine: Patch management is the engine of remediation. Automate deployment where you safely can, keep a tested rollback and hold a defined emergency process for actively exploited flaws.
- Verify, then report: Rescan to confirm each fix landed, and track how fast you close flaws over time. Remediation throughput is a number the board should see because it is the number attackers care about.
None of this needs exotic technology. It needs discipline, ownership and a loop that runs without fail. Where an in-house team cannot sustain that, running vulnerability management as a managed service, from continuous scanning to prioritisation and remediation tracking, is a common way to keep the loop turning.
