.svg){kind=logo}
Someone on your team ran a vulnerability scan last month. The results came back: 47 findings, including three rated critical. Two weeks later, nothing has changed. Not because no one cared, but because there was no policy saying who owns remediation, what “fix it urgently” means in actual days, or what happens when a legacy system cannot be patched.
A vulnerability management policy is the document that closes that gap.
It defines how your organisation identifies vulnerabilities in its systems and infrastructure, how findings are rated by severity, who owns remediation, and what the required timelines are. It covers what to do when something genuinely cannot be patched, how exceptions get approved and tracked, and what evidence shows auditors the programme is working.
The policy matters for compliance too. SOC 2, ISO 27001, NIST, and PCI DSS all require controls for identifying and responding to vulnerabilities, and a written, approved policy is the standard way to demonstrate those controls exist.
By the end of this guide, you will know exactly what to include in a vulnerability management policy, how to write one that fits your stage, and what auditors will look for when they review it.
Here is what I will cover:
- What a vulnerability management policy is and how it relates to patch management
- What the policy should include, section by section, with a real template you can use today
- Framework requirements for SOC 2, ISO 27001, NIST, and PCI DSS
- The evidence auditors expect to see
- Common mistakes that get companies caught in audits
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Vulnerability Management Policy, Defined
Most companies already scan for vulnerabilities. The problem is not the scanning. It is everything after.
Key insight
A vulnerability management policy isn't just about patching. Misconfigurations, weak credentials, and end-of-life systems with no available patches all need to be in scope. A policy that only covers patch deployment will fail a SOC 2 or ISO 27001 audit.
A vulnerability management policy is a formal document that governs how your organisation discovers, assesses, prioritises, and remediates weaknesses in its technology environment. It sets the rules the team agrees to follow, not just the activity they happen to do.
The scope typically includes: internal servers and cloud infrastructure, applications and APIs, developer workstations and endpoints, SaaS tools with access to company data, CI/CD pipelines, and third-party integrations.
Policy owner: At most companies, this is the CISO, Head of Security, or, at smaller startups, the Engineering Lead or CTO. What matters is that there is a named person accountable for the programme, not just the person who runs the scanner.
Who it applies to: Security and engineering teams most directly, but also IT, DevOps, and any team that deploys or manages systems. Everyone in scope needs to know what the policy requires of them.
Vulnerability and Patch Management Policy: What’s the Difference?
This question comes up often, and it is worth being precise.
Vulnerability management is the full lifecycle: discover a weakness, assess how serious it is, prioritise it against everything else, remediate it (or formally accept the risk), and verify the fix worked.
Patch management is one specific remediation action within that lifecycle: applying software patches to close a known flaw.
Many organisations combine the two into a single vulnerability and patch management policy, which is perfectly reasonable when a single team owns both functions.
The distinction matters because not every vulnerability gets fixed with a patch. Misconfigurations need to be corrected. Weak credentials need to be rotated. End-of-life systems with no available patches need compensating controls and formal risk acceptance. A vulnerability management policy has to cover all of these cases, not just the patching scenario. (For the patch-specific procedures, see our patch management policy guide.)
Vulnerability Management Policy and Procedures: How They Work Together
The policy and the procedures are not the same document, and auditors will notice if you treat them as one.
The vulnerability management policy is the governance layer: who is responsible, what the SLAs are, how exceptions get approved, how often the programme is reviewed. It is the document the CISO or Engineering Lead signs.
The vulnerability management policy and procedures together are what make the control real: the policy sets the standard, and the procedures tell the team exactly how to execute it, how to run a scan in your specific tooling, what to do with the results, how a finding becomes a ticket, how remediation gets verified.
A good audit trail shows both: the policy as evidence the control exists, and procedure documentation as evidence it is being followed.
Why Vulnerability Management Can’t Be Left to Chance
Here is what ad hoc vulnerability management looks like in practice. The scanner flags a critical CVE. Someone mentions it in a Slack message. The right engineer is not tagged. The thread goes quiet. Three weeks later, someone else finds the same finding in the next report and wonders if it was ever fixed. It was not.
Free Demo
Most breaches exploit known vulnerabilities that had patches available
ComplyJet automates the evidence trail for your vulnerability management programme — scan records, remediation SLAs, exception approvals, and control mapping all in one place.
Without a policy, there is no agreement on what “fix it” means in time, in ownership, or in verification. Three reasons this matters:
Security risk. Unpatched vulnerabilities are one of the most consistent entry points for ransomware and data breaches. CISA’s Known Exploited Vulnerabilities catalog tracks hundreds of flaws being actively weaponised right now, most of which have patches available that were never applied. A policy does not eliminate vulnerabilities, but it ensures findings above a certain severity get closed before attackers have time to exploit them.
Compliance. SOC 2 auditors reviewing CC7.1 and CC7.2 want to see that you have a defined process for detecting and responding to vulnerabilities, not just a scanning tool running in the background. A scan report without SLAs, ownership, or evidence of remediation is not a control. The policy is what turns the scanner output into something auditable.
Operational clarity. Without severity tiers and SLAs, every finding is either equally urgent or equally ignorable. Engineers get buried in scanner noise and learn to tune it out. A policy forces prioritisation: critical findings get immediate attention, informational findings do not. That is how a security team stays effective rather than overwhelmed.
Which Companies Need a Vulnerability Management Policy?
If your company runs any kind of technology infrastructure and handles data belonging to customers, clients, or partners, you need one. More specifically:
Why it matters
SOC 2 CC7.1 and ISO 27001 A.8.8 both require a documented vulnerability management programme. Without a formal policy, individual scan reports have no programmatic context — and auditors will notice.
SOC 2 candidates. SOC 2 trust service criteria CC7.1 and CC7.2 require controls for detecting vulnerabilities and responding to them. Any company going through a SOC 2 audit, Type I or Type II, needs a written vulnerability management policy to satisfy those criteria.
ISO 27001 candidates. Annex A control 8.8, “Management of technical vulnerabilities,” is a required control in the standard. You cannot achieve ISO 27001 certification without it implemented and evidenced.
PCI DSS environments. Requirements 6.3 and 11.3 require vulnerability scanning and patch management. Requirement 11.4 requires annual penetration testing. A written policy is the governing document for all of those activities.
B2B SaaS companies. Enterprise buyers increasingly include security questionnaires in their procurement process. “Do you have a documented vulnerability management policy?” is a standard question. The answer needs to be yes before the deal closes.
Healthcare and fintech. The HIPAA Security Rule expects a technical safeguard programme that includes identifying and addressing vulnerabilities. Financial regulators have similar expectations. Regulated industries have less room for “we scan things but have no written programme.”
Do Small Startups Need One?
Yes. Even a five-person team with a single cloud environment has vulnerabilities. AWS Inspector or Snyk will find them.
The question is not whether vulnerabilities exist. It is whether there is a defined process for closing the critical ones before they become an incident. A one-page policy with clear SLAs and a named owner answers that question.
I have spoken to founders who delayed writing this until two weeks before their SOC 2 audit. That works, technically, but it means a year of scanning activity with no documentation of how findings were handled. The retrospective is painful. Write the policy when you start scanning, not when you have to prove you were scanning.
What Your Vulnerability Management Policy Should Cover
A policy without structure is a narrative document without authority. These are the sections every vulnerability management policy needs:
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists and which risk or compliance requirement it addresses |
| Scope | Which systems, environments, people, and third parties are covered |
| Roles and responsibilities | Who owns scanning, who owns remediation, who approves exceptions |
| Vulnerability identification | Which tools are used, how often scans run, what qualifies as a scan |
| Risk rating and prioritisation | How findings are scored (CVSS or internal system), how severity tiers are defined |
| Remediation SLAs | Required fix timelines by severity, in days |
| Exception handling | How exceptions are requested, what must be documented, who approves, review cadence |
| Verification and retesting | How remediation is confirmed before a finding is closed |
| Reporting and metrics | What gets reported, to whom, how often |
| Enforcement | Consequences for non-compliance |
| Review cadence | Annual minimum, plus trigger events for out-of-cycle review |
Remediation SLA Table
This is the part of the policy that does the most work. Without defined SLAs, findings sit open indefinitely. These are the industry-standard starting points:
| Severity | CVSS score | Remediation SLA |
|---|---|---|
| Critical | 9.0–10.0 | 7 days |
| High | 7.0–8.9 | 30 days |
| Medium | 4.0–6.9 | 90 days |
| Low | 0.1–3.9 | 180 days or next release cycle |
| Informational | N/A | Review only, no required remediation |
Adjust these based on your environment, risk appetite, and specific framework requirements. PCI DSS has its own defined timelines for certain vulnerability types. SOC 2 does not prescribe specific numbers, but auditors will assess whether your SLAs are reasonable given the severity of findings.
Free Vulnerability Management Policy Template
This template is written for a SaaS or technology company. Use it as a vulnerability management policy example you can adapt for your own environment: replace the bracketed placeholders with your specifics, adjust the SLAs to match your risk appetite, and add the tools your team actually uses.
It works as a sample vulnerability management policy for a small-to-mid-size team. Larger organisations may need to expand the reporting and escalation sections.
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Vulnerability and Patch Management Policy Template Variations
If your organisation combines vulnerability and patch management into one document, use this template as the base and add a dedicated “Patch Management” section covering: the patch approval process, testing requirements before production deployment, deployment cadence, and rollback procedures.
A vulnerability and patch management policy template structured this way is appropriate when a single owner, typically the Engineering Lead or IT Manager, is responsible for both functions. Combined policies are common at companies with fewer than 50 engineers.
Vulnerability Management Policy
[Company Name]
Version: 1.0 | Effective Date: [Date] | Owner: [CISO / Head of Security / Engineering Lead] | Review Date: [Annual]
1. Purpose
This policy establishes requirements for identifying, assessing, prioritising, and remediating technical vulnerabilities across [Company Name]’s systems and infrastructure. The goal is to protect the confidentiality, integrity, and availability of company and customer data by ensuring known vulnerabilities are addressed in a timely, risk-based manner.
This policy supports compliance with SOC 2 (CC7.1, CC7.2), ISO 27001 (Annex A 8.8), and applicable regulatory requirements including PCI DSS and HIPAA where relevant.
2. Scope
This policy applies to all systems, environments, and personnel listed below.
| Category | In scope |
|---|---|
| Production cloud infrastructure | Yes |
| Staging and development environments | Yes |
| On-premises servers | Yes |
| Developer workstations and endpoints | Yes |
| SaaS applications with access to company or customer data | Yes |
| CI/CD pipelines and build infrastructure | Yes |
| Third-party integrations with access to production systems | Yes |
All employees, contractors, and third parties with access to in-scope systems are required to comply with this policy.
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Security Lead / CISO | Policy owner. Approves exceptions. Reviews vulnerability metrics. Escalates unresolved critical findings. |
| IT / DevOps | Runs vulnerability scans. Triages findings. Manages infrastructure patching. |
| Engineering teams | Remediates application-layer vulnerabilities within defined SLAs. |
| Engineering managers | Ensures findings are assigned and closed within SLA. Escalates blockers. |
| Management | Approves formal risk acceptances for exception requests. |
4. Vulnerability Identification
Vulnerability scans must be performed at the following minimum frequencies:
| Environment | Scan frequency | Method |
|---|---|---|
| Production infrastructure | Weekly | Automated (e.g. AWS Inspector, Tenable, Qualys) |
| Production applications | On every major release, and monthly | Automated DAST or SCA (e.g. Snyk, OWASP ZAP) |
| Developer dependencies | Continuous (CI/CD integrated) | SCA tool (e.g. Snyk, Dependabot) |
| Non-production environments | Monthly | Automated |
| External perimeter | Quarterly | Automated external scan |
Penetration testing must be performed at minimum once per year by a qualified third party. New systems must be scanned before promotion to production.
Tools currently in use: [e.g. AWS Inspector, Snyk, Dependabot, Tenable, Qualys]
5. Risk Rating and Prioritisation
All findings must be rated using CVSS (Common Vulnerability Scoring System) v3.1 or higher. The following severity tiers apply:
| Severity | CVSS range | Initial response | Remediation SLA |
|---|---|---|---|
| Critical | 9.0–10.0 | Immediate escalation to Security Lead within 4 hours | 7 calendar days |
| High | 7.0–8.9 | Engineering ticket created within 24 hours | 30 calendar days |
| Medium | 4.0–6.9 | Engineering ticket created within 5 business days | 90 calendar days |
| Low | 0.1–3.9 | Logged in vulnerability backlog | 180 calendar days or next planned release |
| Informational | N/A | Reviewed and logged; no remediation required | N/A |
6. Remediation and Verification
Each finding must be assigned a ticket with a named owner and a due date matching the SLA above.
Remediation options include: applying a patch, correcting a misconfiguration, rotating credentials, applying a compensating control, or formally accepting the risk via the exception process.
Before a finding is closed, remediation must be verified by one of: re-scanning the affected system, functional testing that confirms the vulnerability is no longer present, or Security Lead sign-off on a documented compensating control.
Critical and High findings require Security Lead approval upon closure.
7. Exception Handling
A formal exception is required when a vulnerability cannot be remediated within SLA due to a documented business or technical constraint.
Each exception must include:
| Field | Required content |
|---|---|
| Vulnerability | CVE or internal finding ID, description, severity |
| Reason | Why it cannot be remediated within SLA (e.g. vendor has not released a patch, fix breaks production functionality) |
| Compensating controls | What mitigations are in place during the exception period |
| Risk owner | Named individual accepting responsibility |
| Expiry date | Maximum 90 days; must be reviewed before expiry |
| Approver | [CISO / Engineering Lead / Management] |
Exceptions must be logged in [vulnerability exception register / GRC platform]. All open exceptions are reviewed quarterly by the Security Lead.
8. Reporting and Metrics
The Security Lead reviews vulnerability programme metrics at minimum monthly. The following metrics must be tracked:
| Metric | Description |
|---|---|
| Open findings by severity | Total open Critical, High, Medium, Low findings |
| Mean time to remediate (MTTR) | Average days from finding to closure, by severity |
| SLA breach rate | Percentage of findings not remediated within SLA |
| Open exceptions | Count of active formal exceptions by severity |
| Scan coverage | Percentage of in-scope systems scanned in the current period |
Critical or High findings open beyond SLA must be escalated to [executive / board level] with a remediation plan.
9. Enforcement
Non-compliance with this policy may result in disciplinary action, up to and including termination. Significant violations include: deploying a system with known unmitigated Critical vulnerabilities, failing to disclose a known vulnerability to the Security Lead, or deliberately circumventing the scanning or exception processes.
Systems with unresolved Critical vulnerabilities may be taken offline or restricted from production access at the Security Lead’s discretion.
10. Review Cadence
This policy must be reviewed annually, or when any of the following occur:
| Trigger | Action |
|---|---|
| Significant security incident | Review within 30 days of resolution |
| Major infrastructure change (cloud migration, new environment, acquisition) | Review before change goes live |
| New or updated framework requirement (SOC 2, ISO 27001, PCI DSS) | Review within 60 days of update |
| Change in policy owner | Review within 30 days of ownership transfer |
11. Version History
| Version | Date | Author | Summary of changes |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial policy |
For informational purposes only · complyjet.com
How to Write and Roll Out a Vulnerability Management Policy
Writing the policy is the straightforward part. Getting it into the organisation is where most companies lose momentum. Here is the full sequence:
Free Demo
Get your vulnerability management policy audit-ready in one session
ComplyJet generates a policy matched to your framework requirements, builds in your SLA tiers, and tracks remediation evidence automatically so you're never scrambling before an audit.
- Assign a policy owner. Name a specific person: CISO, Security Lead, or Engineering Manager. Whoever it is, they are responsible for the programme, not just the document.
- Define your scope. List every system category, environment, and team that needs to be covered. If it is not in scope, it is not protected.
- Confirm your scanning tools are operational. The policy is pointless if scanning is not actually running. Set this up first if you have not already.
- Set severity tiers and SLAs. Use the CVSS table above as a starting point, then adjust for your environment and risk appetite. Get agreement from engineering leads before locking these in.
- Define the exception process. Who can request an exception, who approves, what documentation is required, and how long exceptions last. Without this, every hard-to-fix finding becomes an indefinitely open ticket.
- Draft the policy using the template above. Customise the scope, tools, and thresholds. Keep it as simple as your environment allows.
- Review with legal or compliance if required. Necessary for healthcare, financial services, or any regulated environment.
- Get executive sign-off and version the document. A policy without an approval signature is not a control.
- Brief the team. A kickoff meeting, not just an email. Engineering and DevOps teams need to understand what the SLAs require of them specifically.
- Collect acknowledgements. Required as SOC 2 evidence. Document who confirmed they read and understood the policy.
- Map to framework controls. Link the policy to SOC 2 CC7.1/CC7.2, ISO 27001 A.8.8, PCI DSS 6.3/11.3. Your GRC platform should make this a single step.
- Collect your first evidence cycle. Scan reports, remediation tickets, SLA metrics. Start from day one, not from audit prep time.
- Set a review reminder. Annual minimum. Put it in the calendar now.
Vulnerability Management Policy and Compliance: SOC 2, ISO 27001, NIST, PCI DSS
| Framework | Relevant control | What it requires |
|---|---|---|
| SOC 2 | CC7.1, CC7.2 | Detect vulnerabilities; respond to identified vulnerabilities; monitor and evaluate controls |
| ISO 27001 | Annex A 8.8 | Timely identification and management of technical vulnerabilities; assess exposure; take appropriate action |
| NIST CSF | ID.RA-1, RS.MI-3 | Asset vulnerabilities are identified and documented; newly identified vulnerabilities are mitigated or documented as accepted risks |
| PCI DSS | Requirements 6.3, 11.3, 11.4 | Quarterly internal and external vulnerability scans; annual penetration testing; critical patches within defined timeframes |
ISO 27001 Vulnerability Management Policy Requirements
If you are writing an ISO 27001 vulnerability management policy, the primary control to satisfy is Annex A 8.8, titled “Management of technical vulnerabilities.” It requires organisations to maintain an asset inventory, identify vulnerabilities affecting those assets in a timely manner, assess the organisation’s exposure, and take action: patching, applying a compensating control, or formally accepting the risk.
The written policy is the primary evidence that A.8.8 is implemented as a control. Clause 6.1 (risk treatment) also applies: unpatched vulnerabilities are risks, and every open exception must be formally accepted and documented, not quietly carried forward. This connects directly to your information security risk management policy, which governs how risks are assessed and treated at the programme level.
Certification auditors will ask to see the policy, a sample of scan reports from the audit period, and evidence that findings were closed within your stated SLAs. The paper trail matters as much as the policy itself.
NIST Vulnerability Management Policy Framework
NIST provides two relevant reference documents for building a NIST vulnerability management policy framework.
The NIST Cybersecurity Framework maps vulnerability management to ID.RA-1 (asset vulnerabilities are identified and documented) and RS.MI-3 (newly identified vulnerabilities are mitigated or documented as accepted risks).
NIST Special Publication 800-40 is the dedicated guide for enterprise vulnerability and patch management. If you are looking for procedural guidance to accompany your policy, that is the right reference.
For federal environments or FedRAMP, NIST 800-53 applies. The relevant controls are SI-2 (flaw remediation) and RA-5 (vulnerability monitoring and scanning).
PCI DSS Vulnerability Management Policy Requirements
PCI DSS is the most prescriptive of the frameworks on vulnerability management.
Requirement 6.3: All system components must be protected from vulnerabilities by installing applicable security patches within one month of release for critical patches.
Requirement 11.3: Internal and external vulnerability scans must be performed at minimum quarterly and after any significant change in the network.
Requirement 11.4: External and internal penetration tests must be performed at minimum annually and after any significant infrastructure or application change.
The full PCI DSS requirements are documented by the PCI Security Standards Council. Your PCI DSS vulnerability management policy is the document that ties all of this together and demonstrates programme ownership to your QSA (qualified security assessor). Without a governing policy, the individual scan reports have no programmatic context.
Evidence Auditors Expect for Vulnerability Management
Passing an audit is not just about having the policy. It is about showing the policy is being followed. These are the records auditors will ask for:
| Record type | What it looks like |
|---|---|
| Approved, signed policy | Policy document with version number, effective date, owner name, and approver signature |
| Scan reports | Regular scan output retained for the full audit period, not just the most recent run |
| Remediation tickets | Engineering tickets with finding severity, owner, due date, and closure date |
| SLA compliance metrics | Report showing percentage of findings closed within SLA by severity, per month |
| Exception log | Documented risk acceptances with approvals, compensating controls, and expiry dates |
| Penetration test report | Annual pen test report and evidence that identified findings were triaged and remediated |
| Policy acknowledgements | Signed or logged confirmations from relevant team members that they have read and understood the policy |
| Policy review record | Evidence the policy was reviewed annually: date, reviewer, and summary of any changes made |
The most common gap I see is not missing records: it is records that exist but are not retained for long enough. SOC 2 Type II covers a 12-month period. You need scan reports and remediation evidence from the full window, not just the last quarter.
Vulnerability Management Policy Mistakes That Get Companies Caught
These are the patterns I see repeatedly. None of them are exotic. All of them create problems in audits.
Watch out
Tracking findings in a spreadsheet is the most common vulnerability management failure in audits. If there's no audit trail showing when each finding was opened, triaged, remediated or formally accepted, your programme isn't evidenced — even if vulnerabilities are actually being fixed.
No defined SLAs. Scans run, findings are logged, and nothing specifies when they must be fixed. Auditors look for SLAs immediately. “We try to fix critical things quickly” is not a control.
Scope gaps. The policy covers production servers but not developer laptops, SaaS tools with production data access, or the CI/CD pipeline. Attackers do not observe your scope definitions. Auditors are not much more forgiving.
Scans without remediation ownership. The security team produces a scan report, emails it to engineering, and assumes action will follow. It does not, because there is no ticket, no assigned owner, and no deadline. Scanning and remediating are not the same activity.
No exception process. Legacy systems, vendor-constrained environments, and end-of-life software sometimes cannot be patched within SLA. That is a legitimate business reality. Without a documented exception process, those findings sit open indefinitely and appear to auditors as non-compliance, not pragmatism.
Treating all findings as equally urgent. Teams that try to remediate every low and informational finding burn out and start ignoring everything. Teams that only focus on critical findings let medium-severity issues accumulate into real risk over time. The severity tiers exist for a reason: use them.
No pre-production scanning gate. A new service goes live with known vulnerabilities because scans only run on existing production systems. The policy must explicitly require that new systems are scanned and findings are triaged before promotion to production.
Annual-only policy review. The policy was written when the company had six engineers and one cloud account. Eighteen months later, there are forty engineers across three environments. The policy has not changed. The gap between what the document says and what the organisation actually does is itself an audit finding.
Right-Sizing Your Vulnerability Management Policy by Company Stage
The policy that works for a 500-person enterprise will create unnecessary overhead for a ten-person startup. Here is how to calibrate it.
Quick tip
At under 20 people: run monthly scans with a free tool (Trivy for containers, OpenVAS for infrastructure), set a 30-day remediation SLA for critical findings, and document every exception. That's enough for a SOC 2 Type 1 and most ISO 27001 stage 1 audits.
Early-Stage Startups (1–15 employees)
Keep it to one or two pages. Complexity at this stage kills compliance: if the policy is too heavy, the team will treat it as a checkbox and ignore it.
One named owner, one scanning tool, one SLA table. AWS Inspector, Snyk, or Dependabot is sufficient tooling to start. Monthly manual review of open findings is enough at this scale. Exceptions can be logged in a spreadsheet and approved by the CTO.
The most important thing at this stage is not having a perfect policy. It is having a policy that is written, approved, communicated, and actually followed. A simple, real policy beats a sophisticated document that no one has read.
Growing Companies (15–100 employees)
As the team grows, the informal coordination that made the simple version work starts to break down. This is when you need to expand.
Add scope for SaaS tools with production data access, developer workstations, and CI/CD pipelines. Integrate your scanning tool with your ticketing system (Jira, Linear) so findings automatically become assigned tickets. Introduce quarterly SLA compliance metrics and monthly reporting to the security lead.
If you have not started annual penetration testing, start now. It is required for SOC 2 Type II, PCI DSS, and ISO 27001, and it will surface things your automated scanners miss.
Larger Enterprises (100+ employees)
At this scale, vulnerability management becomes a programme, not just a policy.
Dedicated tooling such as Tenable, Qualys, or Rapid7 integrated into a SIEM. A dedicated security team or security engineering function. Formal risk committee review of open exceptions. SLAs often tighten: many enterprise environments target Critical findings within 24 to 48 hours rather than seven days.
Consider a formal vulnerability disclosure programme, a bug bounty or a responsible disclosure policy. At this scale, external researchers will find things your internal programme misses, and having a defined process for receiving and handling those reports is expected.
Managing Your Vulnerability Management Programme with ComplyJet
Setting up the policy is one part. Keeping it audit-ready over time is the part that actually takes effort.
ComplyJet gives you a pre-built vulnerability management policy template already mapped to SOC 2 CC7.1/CC7.2, ISO 27001 A.8.8, NIST CSF, and PCI DSS. You fill in your specifics rather than starting from scratch.
The approval workflow routes the policy to the right person, captures the sign-off with a timestamp, and versions the document automatically. No chasing people over email.
Employee acknowledgement tracking shows you who has confirmed they have read the policy, sends reminders for overdue acknowledgements, and gives you a log you can export for audit purposes.
Every control is linked directly to the relevant framework criteria, so your auditor can trace from the policy to the evidence in one place rather than across six different systems.
As the programme runs, scan reports, exception logs, remediation tickets, and review records all get stored in context. When audit time comes, the evidence is already there.
FAQs
What is a vulnerability management policy?
A vulnerability management policy is a formal document that defines how your organisation identifies, assesses, prioritises, and remediates security vulnerabilities in its systems, software, and infrastructure. It sets the rules: who scans what, how often, what severity levels mean, who owns remediation, what the required timelines are, and how exceptions get approved and tracked.
The sample vulnerability management policy template in Section 6 shows what a complete, audit-ready version looks like. Without a policy, scanning activity is not a demonstrable control.
What should a vulnerability management policy include?
At minimum: purpose and scope, roles and responsibilities, vulnerability identification requirements (tools and frequency), risk rating methodology, remediation SLAs by severity, exception handling process, verification and retesting requirements, reporting requirements, and a review cadence. If you need a vulnerability management policy example with all of these pre-filled, the template in Section 6 above covers every one. See the “What Your Vulnerability Management Policy Should Cover” section for the full breakdown.
How does vulnerability management relate to patch management?
Patch management is one specific activity within vulnerability management. Vulnerability management covers the full lifecycle: discover a weakness, assess severity, prioritise against everything else, remediate (or formally accept the risk), and verify the fix. Patching is the most common remediation method, but not the only one. Misconfigurations need to be corrected. Credentials need to be rotated. End-of-life systems need compensating controls. Your policy needs to cover all of these cases, not just the patching scenario.
Does SOC 2 require a vulnerability management policy?
SOC 2 does not require a document with that exact title, but trust service criteria CC7.1 and CC7.2 require controls for detecting and responding to vulnerabilities. A written, approved policy is the standard way to evidence those controls, and most auditors expect to see one during a Type II audit. Without one, you are relying on informal scanning activity to satisfy a formal criterion.
How often should vulnerability scans be performed?
The industry standard minimum is monthly for internal production environment scans and quarterly for external scans. PCI DSS requires quarterly internal and external scans as a minimum. High-change environments often run continuous or weekly scans using tools like Snyk or AWS Inspector integrated directly into CI/CD pipelines. The right frequency depends on how often your environment changes and how quickly you need to detect new exposures.
Who owns the vulnerability management policy?
Typically the CISO, Head of Security, or at smaller companies, the Engineering Lead or CTO. What matters most is that there is a named individual accountable for the programme, not just the team that runs the scanner. The owner is responsible for policy compliance, scan execution, SLA enforcement, exception approval, and escalation when critical findings stay open too long.
How often should the vulnerability management policy be reviewed?
Annually at minimum. Beyond the annual cycle, the policy should be reviewed after a significant security incident, a major infrastructure change such as a cloud migration or acquisition, a change in regulatory requirements, or a change in policy ownership. The review date and reviewer must be documented and traceable as audit evidence.
What qualifies as an acceptable exception to the vulnerability management policy?
An exception is appropriate when a vulnerability genuinely cannot be remediated within SLA because of a documented business or technical constraint: the vendor has not released a patch, the fix breaks a critical business function, or the system is end-of-life and migration is planned but not yet complete.
Every exception must document the vulnerability, the specific reason for the exception, compensating controls in place, the risk owner, and an expiry date. Exceptions with no expiry or no compensating controls are not acceptable exceptions: they are open vulnerabilities with no plan.
Related Policies
- Network Security Policy: Governs the network controls that reduce attack surface and limit exposure when vulnerabilities exist in connected systems.
