Policy template · ISO 27001 / Cyber Essentials
Vulnerability management policy template
Remediation timescales your team can meet, and evidence an auditor can trace. A ready-to-edit Word vulnerability management policy that meets ISO 27001 A.8.8 and the Cyber Essentials 14-day rule, written for a UK firm of 25 to 250 people.
Key takeaways
A vulnerability management policy sets how your organisation finds weaknesses, prioritises them and fixes them within a stated time. ISO 27001 control A.8.8 requires you to evaluate your exposure to technical vulnerabilities and act on it, and Cyber Essentials requires critical and high-risk updates within 14 days. This Word template is written for UK firms of 25 to 250 staff.
- Required by
- ISO 27001:2022 control A.8.8. Cyber Essentials tests the outcome, not a policy
- Approved by
- Top management; senior risk owners accept overdue findings by priority
- Review cycle
- Policy annually; scans at least monthly; results reported monthly
- Format
- Word, about 13 pages, with a severity ladder and risk acceptance form
Your largest prospect's security questionnaire asks two questions: how quickly do you fix critical vulnerabilities, and can you show it? The honest answer is "when someone gets to it", and the scanner report nobody has opened since March says the same. A vulnerability management policy turns that into a timescale you can meet and evidence. This template gives a UK firm of 25 to 250 staff a ready-to-edit vulnerability management policy in Word, mapped to ISO 27001 control A.8.8 and the Cyber Essentials 14-day rule, with severity-based remediation timescales and a risk acceptance route already written in.
What's in the template
One Word document, about 13 pages, version 1.0. It has four parts.
- The vulnerability management policy. Scope (endpoints, servers, network devices and their firmware, cloud platforms, SaaS settings and your own code), roles, how vulnerabilities are found, how they are prioritised, remediation timescales by severity, exceptions and risk acceptance, verification, unsupported software, suppliers, reporting, and the hand-off to incident management.
- Ready-to-use appendices. A severity and remediation timescales table, a scanning schedule and coverage register, a risk acceptance form, and a one-page monthly vulnerability report.
- A getting-started guide and next steps. Which sections to tailor first, how to choose between the options, and where this policy ends and your patch management policy begins.
- A policy management checklist. Approval, named owners, the first full scan cycle and the first report to management: the records an auditor asks to see alongside the policy.
Every placeholder is in square brackets. Where firms genuinely differ (scanning frequency, the timescale for each severity, how long a risk acceptance can last) the template gives worded options to choose from. Pick one, delete the rest, and the policy is ready for management approval.
What is a vulnerability management policy?
A vulnerability management policy is the document that sets how your organisation finds security weaknesses in its systems, decides which matter most, and fixes them within a stated time. It covers the whole loop: discovery, prioritisation, remediation, risk acceptance and verification. It's written for the people who run that loop: IT, engineering, system owners, and your managed service provider if you have one.
A vulnerability management policy isn't a patch management policy. This policy sets the clocks: what counts as critical, how fast each severity is fixed, and who can say "not yet". A patch management policy, a separate template, covers how updates are tested, scheduled and rolled out. At 25 staff the two can share a document. By 250 they usually separate.
Customers ask for it because a breach through a known flaw with a fix available is the hardest kind to explain. A questionnaire that asks "what is your remediation timescale for critical vulnerabilities?" is asking for this policy, and for the evidence that you meet it.
Which standards require one
ISO 27001 asks you to manage technical vulnerabilities, and control A.5.1 sets the rules for topic-specific policies like this one. Cyber Essentials doesn't ask for a policy document, but it tests the outcome a good policy produces.
| Standard or source | What it asks for |
|---|---|
| ISO 27001:2022, control A.8.8 | Information about technical vulnerabilities in the information systems you use must be obtained, your exposure to them evaluated, and appropriate measures taken. |
| ISO 27001:2022, control A.5.1 | Topic-specific policies must be defined, approved, communicated and reviewed. A vulnerability management policy is one of these topic-specific policies. |
| Cyber Essentials (security update management) | No policy document is required. All software on in-scope devices must be licensed and supported, removed when it becomes unsupported (or isolated in a sub-set with no internet traffic), set to update automatically where possible, and updated within 14 days of release where the update fixes vulnerabilities the vendor rates critical or high risk, scores 7 or above on CVSS v3, or comes with no severity details at all. It applies to servers, computers, mobile devices, firewalls, routers, IaaS, PaaS and SaaS, and "software" includes firewall and router firmware. |
| NCSC vulnerability management guidance | Put in place a policy to update by default. Best-practice timescales are 5 days for internet-facing services, 7 days for operating systems and applications, and 14 days for internal or air-gapped systems. Assess the entire estate for vulnerabilities at least monthly. |
| Customer due diligence | Security questionnaires commonly ask how often you scan, your remediation timescales by severity, and when your last penetration test was done. |
For the control detail, see the ISO 27001 A.8.8 technical vulnerability management guide, which covers advisory feeds, triage and building a continuous remediation pipeline. Vulnerability management leans on its neighbours: A.8.7 protection against malware, A.8.9 configuration management for the misconfigurations scanners find, A.8.19 installation of software on operational systems for keeping unapproved and unsupported software off your estate, and A.5.24 incident management planning for when a flaw has already been exploited.
How to create your vulnerability management policy with this template
With the groundwork in place, writing the policy takes about a day plus one management meeting. The first full scan cycle takes longer, and it's the part that makes the policy true. Without the groundwork, the policy will promise timescales for systems you can't see, so check that first.
Before you start
A vulnerability management policy is only as good as your view of what you run. Check you have:
- An asset inventory. You can only scan, and set timescales for, what you know you have, including network devices, cloud accounts and the SaaS tools you configure. No inventory yet? Build one first: the A.5.9 guide shows how. The policy's scope will point to it.
- A way to find vulnerabilities. A scanning tool, the vulnerability reporting built into your endpoint management or cloud platform, or a managed service. No scanning yet? Write the policy anyway, but run a first scan before approval, because the results will test every timescale you set.
- Named owners, and someone with authority to accept risk. Whoever runs scanning and chases fixes, whoever owns each system, and a senior person who can decide that a flaw stays open. Nobody senior willing to sign? Settle that first: NCSC guidance is plain that not fixing is a business risk decision, not an IT one.
- An information security policy. This policy sits beneath it and should use the same scope and owner. No top-level policy yet? Start with the information security policy template.
If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.
1. Set the scope and the owners (about an hour)
- Do this: list the asset types the policy covers, taken from your inventory, and put a name against each role: the policy owner, the person who runs scanning and tracks fixes, system owners, and who may accept risk at each severity.
- The template: lists the asset classes firms most often leave out, including firewall and router firmware, cloud platforms, SaaS settings, your own code and its third-party libraries, and systems your managed service provider looks after.
- Watch for: a scope that stops at laptops and servers. Cyber Essentials counts firewall and router firmware as software, and its update rules reach cloud services. For SaaS the provider usually does the patching; for IaaS and PaaS the work is shared, and your half is easy to miss.
2. Choose how you'll find vulnerabilities, and how often (about an hour)
Next, decide your discovery sources and a cadence for each. For a firm of this size that usually means authenticated scans of internal systems at least monthly, external scans of everything internet-facing at least as often, advisories checked every working day (vendor bulletins, NCSC alerts and a known-exploited list such as the CISA Known Exploited Vulnerabilities catalogue), dependency scanning on every build if you write software, an annual penetration test, and a published route for outsiders to report a flaw to you. The template lists these sources with cadence options and a coverage register to record what each scan reaches.
A clean scan of half the estate isn't a clean estate.
3. Set severity and remediation timescales (1 to 2 hours)
- Do this: decide how severity is set and how fast each level is fixed. Start from the CVSS score, then raise the priority when a flaw is known to be exploited or the system is reachable from the internet.
- The template: includes a severity ladder with worded options for each timescale, and the Cyber Essentials 14-day rule written in as the ceiling for critical and high-risk updates.
- Watch for: timescales copied from an enterprise policy. A 24-hour deadline for every critical finding sounds strong and fails at the first audit sample. Choose timescales your team can meet in a bad month, measure them, then tighten.
A starting ladder for a firm of 25 to 250 staff looks like this.
| Priority | How it's set | Fix or mitigate within |
|---|---|---|
| Emergency | Known to be exploited (on a known-exploited list, or named in an NCSC or vendor alert) and reachable from the internet | 48 hours, through your emergency change route |
| Critical | CVSS v3 9.0 to 10.0 | 5 days if internet-facing, 7 days elsewhere |
| High | CVSS v3 7.0 to 8.9, rated critical or high by the vendor, or released with no severity rating | 14 days at most |
| Medium | CVSS v3 4.0 to 6.9 | 30 days |
| Low | CVSS v3 below 4.0 | The next scheduled maintenance window, or 90 days |
The high row matters most for Cyber Essentials. An update the vendor hasn't rated counts as critical or high, and so does a single bundled update that fixes even one critical or high issue among many lower ones.
Fourteen days is the Cyber Essentials ceiling, not the target.
4. Decide what happens when you can't fix in time (about an hour)
Then write the exception route. Some flaws have no fix yet, and some fixes would break a system the business depends on. The policy should say who may accept the risk at each severity, what mitigation is expected meanwhile (disabling the feature, filtering at the firewall, closer monitoring), and when the decision expires. NCSC's guidance is direct: the decision not to fix is a senior-level business risk decision, not an IT problem. If there's any sign a flaw has already been exploited, the policy hands over to incident management. The template includes a risk acceptance form and that escalation route.
5. Approve, run the first cycle and report (one management meeting, then the first month)
- Do this: take the policy to management for approval. Then run a full scan cycle against the scope, triage the results against your ladder, and send the first one-page report: open findings by priority, anything past its timescale, and risk acceptances due for review.
- The template: includes a monthly vulnerability report and a policy management checklist covering approval, the first scan cycle and the next review date.
- Watch for: tickets closed without a rescan, and timescales nobody measures. Both are covered in How to use it so it holds up at audit.
A remediation timescale nobody measures is a wish with a number in it.
Do it yourself, or have us do it with you
| Do it yourself with the template | Do it with GRCMANA | |
|---|---|---|
| What you end up with | An approved vulnerability management policy, and a first month of scan results triaged against it | This policy, set up and then run for you as a managed service: exposure management that finds, prioritises and tracks vulnerabilities across your estate against your timescales, with managed detection and response watching for exploitation of what can't be fixed yet |
| Your time | About a day plus a meeting, if the groundwork is in place, then a few hours each month to run it. Considerably more if it isn't | Agreed at scoping, depending on your estate and how much of the work we run for you |
| Best if | You have an inventory and a scanner, and someone has time every month to chase fixes and keep the evidence | Nobody has time to chase findings every month, a client questionnaire wants your remediation timescales and the evidence behind them, a Cyber Essentials or ISO 27001 date is fixed, or you want the work run, not just written |
Prefer the second column? Talk to us about managed exposure management.
What does a good vulnerability management policy look like?
Most vulnerability management policies promise to fix vulnerabilities promptly, according to risk. The good ones give a number for each severity, an owner for each decision and a record for each fix.
Weak and strong, side by side
| Clause | Weak | Strong | Why the strong one passes |
|---|---|---|---|
| Scope | "All systems are scanned regularly." | "This policy covers every asset in the [asset inventory], including network device firmware, cloud accounts and code we write. Scan coverage is reconciled against the inventory every [quarter]." | It can be tested against the inventory, and it names the assets scans usually miss. |
| Discovery | "Vulnerability scans are performed periodically." | "Internal systems receive authenticated scans at least monthly, and internet-facing systems at least [weekly]. [Owner] checks [advisory sources], including a known-exploited list, every working day." | A cadence and an owner can be sampled. "Periodically" can't. |
| Timescales | "Critical vulnerabilities are remediated as soon as possible." | "Timescales are set by priority in [Appendix A]. Critical and high-risk updates are applied within 14 days of release at the latest, and known-exploited internet-facing flaws within [48 hours]." | It gives a clock an auditor can measure, and it meets the Cyber Essentials rule. |
| Exceptions | "Exceptions may be approved by IT." | "A vulnerability may stay open past its timescale only with a risk acceptance in [Appendix C], signed by [role] for critical and high findings, stating the mitigation and an expiry no more than [90] days away." | The business accepts the risk at a defined level, and every acceptance ends. |
| Verification | "Vulnerabilities are closed once patched." | "A finding is closed only when a rescan or a recorded check confirms the fix. Closure dates are reported monthly against the timescales." | Closure rests on evidence, and the timescales are measured. |
What an auditor checks in the first five minutes
Before reading the detail, most auditors check that:
- It's current. It has a version, an approval date and a review date that hasn't passed.
- The scope matches the inventory. Scans cover what the inventory lists, including network devices and cloud accounts.
- Timescales are numbers. Every priority has one, and if you hold or are seeking Cyber Essentials, none is looser than 14 days for critical and high-risk updates.
- The evidence runs over time. There are scan reports from several months, not just last week.
- Findings close with proof. A sampled finding traces from detection to fix to rescan, within its timescale.
- Exceptions are decisions. Every overdue finding has a signed risk acceptance with an expiry.
If all six hold, the auditor moves on with confidence. If one fails, they tend to sample harder.
What good looks like at 25 staff and at 250
| Feature | Around 25 staff | Around 250 staff |
|---|---|---|
| Length | Five to seven pages, with patch management folded in | Eight to twelve pages, with a separate patch management policy |
| Discovery | The vulnerability reporting built into endpoint management or the cloud platform, plus a monthly external scan | Dedicated authenticated scanning, continuous monitoring of the external attack surface, and dependency scanning in every pipeline |
| Prioritisation | CVSS plus a known-exploited list, applied by one person | CVSS, known exploitation and asset criticality, applied automatically as tickets are raised |
| Owner | A director or IT lead alongside their main role, often with a managed service provider doing the patching | A named security lead, with system owners accountable for their own timescales |
| Risk acceptance | The managing director signs every overdue critical and high finding | Approval by priority: the system owner for medium, the security lead for high, an executive for critical |
| Reporting | A one-page monthly summary to the management team | A dashboard of time to remediate and overdue findings, reported to the management review |
The common mistake at 25 staff is assuming the managed service provider has it covered: they patch what's in their contract, and nobody checks what sits outside it. The common mistake at 250 is drowning in findings, with so many lows on the list that the criticals wait in the same queue.
How to use it so it holds up at audit
The policy is only half the evidence. An auditor tests whether it operates, and these are the records they usually ask for:
- The approval record: who approved this version, and when.
- Scan reports over time: several months of results, with coverage you can reconcile against the asset inventory.
- Remediation records: tickets that trace a sampled finding from detection to fix to rescan, with dates set against the timescale.
- Risk acceptances: each signed at the right level, with a mitigation, an owner and an expiry that hasn't passed.
- Management reporting: the monthly reports, showing performance against the timescales and every overdue finding.
- The latest penetration test: and the remediation plan that followed it, held to the same timescales as scanner findings.
The most common reasons this policy fails audit:
- Scans cover part of the estate, and nobody has compared coverage with the inventory.
- Critical findings have been open for months with no fix and no recorded decision.
- Tickets are closed when the patch is deployed, with no rescan to confirm it.
- The policy's timescales are tighter than anything the evidence shows the team achieving.
- Unsupported software is still running, with no isolation and no risk acceptance.
- The managed service provider patches, but nothing shows anyone checks it happened.
Each of these is cheaper to fix now than to explain in the audit room.
Vulnerability management policy questions
Its scope, roles, how vulnerabilities are found and how often, how severity is set, the remediation timescale for each severity, how exceptions and risk acceptance work, how fixes are verified, what happens to unsupported software, what suppliers are responsible for, how results are reported, and the route to incident management when a flaw has already been exploited.
At least monthly across the whole estate, which is what NCSC recommends, and more often for internet-facing systems. Check advisories and a known-exploited list every working day, scan software dependencies on every build if you write code, and add an annual penetration test to confirm the process works.
Set them by severity and exposure. A common ladder for firms of 25 to 250 staff fixes known-exploited internet-facing flaws within 48 hours, critical findings within 5 to 7 days, high within 14 days, medium within 30 days, and low in the normal maintenance cycle. Cyber Essentials sets 14 days as the maximum for critical and high-risk updates.
Vulnerability management is the whole loop: finding weaknesses, deciding which matter, fixing them in time and accepting the risk when you can't. Patch management is one way of fixing them: testing, scheduling and deploying updates. Many vulnerabilities need a configuration change rather than a patch, which is why the two are worth keeping distinct, even when they share a document.
Someone senior enough to own the business consequence, not the person who would otherwise do the fix. Set approval levels by severity, record the mitigation in place meanwhile, and give every acceptance an expiry date so the decision comes back for review.
Get the template
Start from a policy that already has a severity ladder, the Cyber Essentials 14-day rule and a risk acceptance route written in, at a scale that fits a firm your size. Download the Word template, set your timescales, and run your first full scan cycle in the month it's approved.
This template is a starting point to adapt to your organisation, not legal advice.
