An auditor will accept a short written policy that you demonstrably follow: scan on a schedule, rank findings with a stated method, fix within times you chose, record exceptions, and keep tickets that show each step. The policy matters less than the trail. A modest promise that you keep beats a strict one that you break.
What does the auditor actually look at?
Reports such as SOC 2 are built on published criteria. The AICPA describes its Trust Services Criteria as control criteria for evaluating and reporting on the security, availability, processing integrity, confidentiality or privacy of information and systems. The criteria say what a control environment should achieve, but your policy describes how you achieve it, and testing compares your practice to your own description.
That is why startups get into trouble by copying a policy that promises more than they can do. If the document says critical issues are fixed in 24 hours, the auditor will sample critical issues and read the dates. Set a time you can meet, then meet it.
How should you rank findings?
NIST's patch management guide frames patching as preventive maintenance and describes the process as identifying, prioritizing, acquiring, installing and verifying updates. The prioritisation step is where you need a stated method. Public signals you can name in the policy:
- CVSS, from FIRST, gives a numerical severity based on a vulnerability's characteristics. It measures severity, not likelihood.
- EPSS, also from FIRST, publishes a daily probability that a CVE will be exploited in the wild in the next 30 days.
- The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation, and CISA's directive for federal agencies gives them two weeks for newer entries and six months for older ones, though your obligations differ.
- CISA's SSVC decision tree considers exploitation status, safety impact and how common the affected product is.
For a startup, a short rule is enough: anything on the exploited list or reachable from the internet with a high score goes first. State the rule in the policy and apply it.
A constructed policy table
- Urgent: known exploited and internet facing, fixed in 7 days.
- High: high severity with a reachable code path, fixed in 30 days.
- Normal: medium or low, or not reachable, fixed in 90 days.
- Exception: cannot be fixed in time, so a written risk acceptance with an expiry date.
These numbers are an illustration, not a standard. Choose your own.
What evidence do you keep?
Keep four things for the audit period.
- Scan records. Dated outputs for code dependencies, container images and the cloud environment, on the schedule you stated.
- A ticket per finding above your threshold. With severity, owner, due date, link to the fix and closing date.
- A fix record. The pull request or deployment that closed it, and a rescan that shows it gone.
- Exceptions. A named approver, a reason, a compensating control and an end date. Review them when the date arrives.
Also keep proof that the process runs without you: a recurring calendar item, a pipeline job, and the meeting note where someone reviewed open items.
A constructed example
A twelve person SaaS company scans dependencies on every pull request and weekly across production images. A critical advisory lands on a library. The ticket opens automatically, the owner confirms the vulnerable function is reachable, ships a fix in three days and attaches the rescan. A second finding in a development-only package is marked not reachable, with a note, and scheduled in the normal queue. In the audit window, the sample of ten findings shows ten closed tickets inside target. That is the whole story the auditor needs.
What to do
- Write a one page policy with scope, schedule, ranking rule, targets and exception process.
- Choose targets you can hit, and revisit them each quarter.
- Automate scans in CI and on production assets, and keep the outputs.
- Open a ticket for every finding above the threshold, with owner and date.
- Subscribe to advisories for your main stack and check the exploited list on a schedule.
- Record exceptions with expiry and review them.
- Run a quarterly review and keep the notes.
- Do a mock sample yourself before the audit.
Safeguard provides dependency scanning, reachability analysis and compliance automation that can organise this evidence, but your auditor, not a tool, decides what is accepted. See the exploitability check demo.
Quick check
Is a strict remediation policy better for an audit?
No. Auditors test practice against your own policy, so a strict policy you miss creates exceptions. A realistic one you meet produces clean evidence.
Is CVSS enough to rank findings?
It measures severity, not likelihood of exploitation. Add signals such as EPSS or the exploited vulnerabilities catalog, and whether the code is reachable.
Sources
- AICPA: 2017 Trust Services Criteria
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- FIRST: Common Vulnerability Scoring System
- FIRST: Exploit Prediction Scoring System
- CISA: Known Exploited Vulnerabilities Catalog
- CISA: BOD 22-01
- CISA: Stakeholder-Specific Vulnerability Categorization
Last reviewed: 18 October 2026.
