polara labs

Templates · 6 min read

A vulnerability tracker template with fix-by dates

Every finding with severity, owner and a fix-by date, and the response times behind them.

A vulnerability tracker is one row per finding: where it was found, its severity, the owner and the date it must be fixed by. A second sheet sets the response time for each severity.

The workbook is below. Feed it from your scanners and penetration tests, and close each row with the date and the ticket that fixed it.

The template in full

Below is the whole workbook as it downloads. Every bracketed field, such as [Company name], is a detail to fill in before you adopt it. There is no form and no email address to hand over, and the file is yours to edit.

Vulnerability Tracker

Findings

One row per vulnerability found in [Company name] systems. Add a row the day a finding is confirmed and close it only with a fix date and evidence.

IDFound onSourceSystemFindingSeverityDue byOwnerStatusFixed onEvidence link

The sheet starts empty: one row per entry, under these columns.

Response times

The maximum time [Company name] allows between finding a vulnerability and fixing it. Due by equals Found on plus these days.

SeverityFix within (days)Example
Critical7Remotely exploitable flaw in a production system, or one already being exploited.
High30Serious flaw that needs some access or user action to exploit, such as an outdated library with a known exploit.
Medium90Flaw with limited impact or hard to exploit, such as a missing security header.
Low180Minor hardening item or informational finding.

How to use

  1. Every finding gets a row, whatever its source: scanner, penetration test, dependency alert, customer or researcher report.
  2. Set Severity using the scanner rating or the Response times sheet, then set "Due by" to the "Found on" date plus the days for that severity.
  3. Every row has one named owner. Status moves Open > In progress > Fixed. "Fixed on" and an evidence link (the pull request, ticket or rescan result) are required to close a row.
  4. "Accepted risk" is only for a finding that will not be fixed. [Policy approver role] approves it in writing, and the reason goes in the Finding column or the linked ticket. Review accepted risks every quarter.
  5. Free scanners that cover most small companies
  6. GitHub Dependabot: turn on Dependabot alerts and security updates in each repository (Settings > Code security). Free for all repositories. It flags vulnerable open source dependencies and opens fix pull requests.
  7. Trivy: free, open source scanner for container images, file systems and infrastructure as code. Run it in the build pipeline, for example "trivy image <image>".
  8. OWASP ZAP (ZAP): free, open source web application scanner. Run a baseline scan against a staging copy of the product.
  9. Package manager audits: "npm audit", "pip-audit" or "bundle audit" list known vulnerable dependencies at no cost.
  10. Monthly routine (first working week of each month)
  11. Review open Dependabot alerts and scanner results, and add any new finding here.
  12. Run the web application scan and the container scan, and save the reports.
  13. Check every open row against its due date. Escalate anything overdue to [Policy approver role].
  14. [Security owner role] records the review date in the Notes of the most recent row or in the monthly review record.
  15. Evidence for the auditor: this tracker, the saved scan reports and the pull requests or tickets that fixed each finding.

What an auditor checks

An auditor samples findings from the period and compares the fix date with the deadline for that severity. A critical finding fixed after its deadline is an exception, even if it is closed now.

They also check the tracker is complete: scan reports from the period should map to rows here. The response times must match your vulnerability management policy, because that is the standard you are tested against.

Which criteria it maps to

It supports CC7.1 and CC7.2.1 A template is evidence of intent. The examination tests whether the control operated over the period, so keep the dated records the workbook produces. Every criterion, explained one by one, is on the Trust Services Criteria page.

Questions

What should a vulnerability tracker record?
The finding, where it came from, severity, owner, the date found, the fix-by date, and the date and ticket that closed it.
What remediation times does SOC 2 require?
None are set by the criteria. You set them in your policy, and the auditor tests whether you met them.
Can a ticketing system replace the tracker?
Yes, if it records the same fields and you can export the population. The spreadsheet is for teams without that setup.

Sources

  1. TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.

Related

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.