Pentest Today.
Start free
security policy

Vulnerability Management Policy

vuln-management.md·SOC 2 · CC7.1

Generate a Vulnerability Management Policy with scanning cadence, a severity-to-SLA matrix, and a pentest requirement — backed by the scans Pentest Today already runs.

Generate this policyBrowse all policies

What's in the policy

Defines how vulnerabilities are scanned, triaged, and remediated within SLAs.

✓Scanning cadence and coverage
✓Severity classification and remediation SLAs
✓Patch management process
✓Penetration testing requirement
✓Exceptions and risk acceptance
✓Reporting and metrics
Mapped toSOC 2 (CC7.1)ISO 27001 (A.8.8)PCI DSS (Req. 6/11)

What the document actually says

These are the standing requirements every generated copy of the document is written from — the clause text itself, not a description of it. The document you receive is drafted on top of them: it expands on them and fills the current-state detail from your intake, and the generator is instructed to keep them, to state them fully, and never to claim a certification or invent a fact you did not supply.

How vulnerabilities get found

- Production infrastructure and applications are scanned for vulnerabilities on a regular cadence (at least monthly, and continuously for dependencies). - Third-party dependencies are continuously monitored (e.g., via automated dependency scanning). - Penetration testing is performed at least annually and after significant architectural change. - A channel exists for external parties to responsibly report suspected vulnerabilities.
SOC 2 CC7.1 · ISO 27001 A.8.8 — four named channels vulnerabilities get found through: infrastructure and application scanning, dependency monitoring, annual penetration testing, and an external reporting channel, instead of leaving 'we look for problems' unstated.

Remediation SLAs, stated as a number

Findings are triaged by severity (typically CVSS-based) considering exploitability and exposure, and remediated within the following target timelines: | Severity | Remediation SLA | | --- | --- | | Critical | 7 days | | High | 30 days | | Medium | 90 days | | Low | Best effort / next cycle | Where a fix cannot meet the SLA, a documented, risk-assessed exception with compensating controls is required.
SOC 2 CC7.1 · ISO 27001 A.8.8 — a stated day-count per severity instead of 'promptly', and a documented, risk-assessed exception required wherever a fix cannot meet its own SLA.

Confirming a fix actually closes it

- Remediations are verified (re-scan or retest) to confirm the issue is resolved. - Vulnerabilities and their status are tracked to closure in a system of record. - Recurring or systemic issues are escalated for root-cause remediation.
SOC 2 CC7.1 · ISO 27001 A.8.8 — a fix isn't done until it is re-scanned or retested, every finding is tracked to closure in one system of record, and a pattern of recurring issues triggers root-cause work instead of repeat patching.
Dependabot + Snyk + Datadog

Filled in for a real stack

Placeholder

Vulnerability management process: To be confirmed. Monitoring tooling: To be confirmed.

Resolved

Vulnerability management process: Dependabot flags dependency advisories on every pull request, Snyk scans container images before each deploy, and criticals are fixed well inside the seven-day SLA. Monitoring tooling: Datadog covering infrastructure and application logs, with anomaly alerts routed to the on-call channel.

What the auditor asks for alongside it

A specific finding remediated inside its stated SLA, not just the SLA table.
The remediation ticket for that finding, timestamped against the severity table: seven days for critical, thirty for high, ninety for medium. The policy sets the clock; the ticket is what a reviewer checks it against, including the documented exception on file for the rare one that missed it.
Findings with a severity a reviewer can actually check the SLA table against.
The penetration test report. Severity is on every finding, with evidence and reproduction steps attached where the finding carries them — the input this policy's SLA table is triaged against — and the retest letter records which findings were re-checked and closed, which is what the Verification & tracking section requires before a fix counts as done.
The answer a customer receives when they ask how patching and remediation actually work.
The drafted questionnaire response to a question about patching or scanning cadence. Phrased that way rather than around the word 'policy', it resolves to the vulnerability-management topic specifically, and the draft is built from the vulnerability management process entered at intake, quoted back over the severity-to-SLA table this document sets.
The systems and dependencies 'production infrastructure and applications' in this document actually refers to.
The architecture and data-flow diagram, built from your hosting and cloud-provider answers. It places the specific stores, services, and integrations inside the hosting trust boundary, so the identification clause's scope is a labeled diagram rather than a phrase a reviewer has to take on faith.

Where these documents go stale

The clock in this document is the part most likely to be broken quietly. A critical finding's seven-day SLA only means something if the scanning behind it still covers what is running: a scanner swapped for a cheaper one, or a new production account stood up without being added to coverage, both leave 'production infrastructure is scanned' true and false at once, depending on what sits in the gap. Dependency monitoring carries the same risk in miniature — a new service with its own manifest and no scanner wired to it inherits none of the promised coverage. The exception process drifts similarly: a risk-assessed exception is supposed to be time-bound, and the SLA table means little if exceptions pile up and never expire. Re-validate by walking scan coverage against the real list of production accounts and dependency manifests, not the SLA numbers.

From intake to enterprise-ready in three moves
01

Tell us about your stack

Answer a short intake — cloud, data types, tools. No agents to install.

02

We generate a tailored draft

Not a blank template: a document written for your environment and pre-mapped to controls.

03

Review, edit, and share

Export it or attach it straight to an enterprise security review or questionnaire.

Vulnerability Management Policy, answered

What is a vulnerability management policy?

A vulnerability management policy states how an organization finds, prioritizes, fixes, and confirms the fix for security vulnerabilities across its infrastructure, applications, and dependencies. It names the channels vulnerabilities get found through, sets a remediation deadline for each severity, and requires the fix to be re-checked before anyone calls it closed.

What are typical remediation SLAs for vulnerabilities?

Seven days for critical findings, thirty for high, ninety for medium, and best effort for low is the timeline most reviews expect, and the one this policy sets. A finding that can't be fixed inside its window still needs a documented, risk-assessed exception with compensating controls — an undocumented miss counts as a violation, not a pass.

Does SOC 2 require a vulnerability management policy?

Yes, in substance. CC7.1 covers identifying and evaluating vulnerabilities, and reviewers ask for the written policy plus evidence the SLA table is actually followed — a sample of real findings checked against their deadlines, not just the document. This policy is written against SOC 2 CC7.1 and ISO 27001 A.8.8.

How does this policy say vulnerabilities get found?

Through four named channels: scanning production infrastructure and applications, monitoring dependencies for known vulnerabilities, an annual penetration test after significant architectural change, and a channel for outside parties to report issues responsibly. Naming the channels is what lets a reviewer check coverage instead of taking 'we look for problems' on faith.

What happens when a finding can't be fixed by its deadline?

A finding that misses its deadline doesn't just slip by. The policy requires a documented, risk-assessed exception with compensating controls before a missed SLA is acceptable, and that exception is usually a reviewer's next question after the SLA table itself — an undocumented late fix is treated the same as no fix at all.

How is this different from a penetration test?

This document is the standing commitment: how vulnerabilities get found, how fast each severity has to be fixed, and how a fix gets confirmed. A penetration test is one of the channels the policy names and evidence a reviewer checks findings against — the policy sets the rule, the test result is what gets measured by it.

How does Pentest Today generate the policy?

Answer a short intake about your stack and we generate a tailored draft — not a blank template — pre-mapped to the controls your framework requires. You review, edit, and export it.

Can I edit the generated policy?

Yes. Every document is a starting draft you can edit, brand, and export. It's written to be review-ready but stays fully under your control.

Free · no account

Start your Pentest

Our agent swarm and human experts test your endpoints and deliver an audit, fast.

Start your PentestHow it works

More from the policy library

security-training.md→

Security Awareness Training Policy

information-security.md→

Information Security Policy

secure-sdlc.md→

Secure SDLC Policy

ai-governance.md→

AI Governance Policy

ai-acceptable-use.md→

AI Acceptable Use Policy

ai-vendor-review.md→

AI Vendor Review Policy

Generate your full security policy pack.

Get the vulnerability management policy plus everything else an enterprise security review asks for — generated from your real environment.

Get startedBrowse all policies