Prepare a package with your written policy, scan schedule and coverage list, a ranked findings export, remediation records with dates, exception approvals, change tickets for fixes, and reporting to senior leaders. A reviewer wants to see that the program is written, followed and checked.
Build it before anyone asks
Pulling this together under a deadline invites gaps. Keep a folder, or better a repeatable export, refreshed each quarter. The structure below follows the ideas common to the rules and control catalogs, rather than the demands of any single examiner.
The checklist
| Area | What to include | Why it matters |
|---|---|---|
| Policy and procedure | Approved vulnerability policy, with approval date | Shows it is written |
| Scope and inventory | List of systems and software covered, and what scans cannot see | Shows coverage is known |
| Discovery | Scan schedule, tool configuration, manual review notes | Shows a defined method |
| Results | Dated scan exports, ranked findings | Shows the program ran |
| Prioritization | Ranking criteria and examples | Shows risk-based decisions |
| Remediation | Tickets with created, fixed and verified dates | Shows timeliness |
| Exceptions | Register with approver, control, expiry | Shows knowing acceptance |
| Change records | Change tickets for sampled fixes | Shows authorized changes |
| Testing | Latest penetration test summary and retest | Shows independent testing |
| Oversight | Reports to senior officers or the governing body | Shows accountability |
NIST SP 800-53 families map to the same areas: vulnerability monitoring and scanning (RA-5), flaw remediation (SI-2), configuration change control (CM-3), a plan of action and milestones (CA-5) and continuous monitoring (CA-7).
What reviewers like to sample
Expect a request for a population, then a sample. For example: all critical findings in the last twelve months, from which they pick ten and ask for the full trail. Make sure your tracker can export that population quickly, with consistent dates.
- Population export, with finding ID, system, severity, detection date, fix date, status.
- Sample trails: finding, ticket, change record, deployment evidence, verification scan.
- Overdue list at period end, with explanations.
- Exception register as of period end.
Oversight evidence
New York's rule asks the CISO to report in writing at least annually to the senior governing body, covering items such as cybersecurity policies and procedures, material risks, program effectiveness and plans to remediate material inadequacies. Keeping the report and any minutes that show discussion is part of the package.
Honest gaps
If something is missing, say so and show the plan. A documented gap with an owner and a date reads better than a surprise discovered during sampling.
Our guide on how long to keep audit evidence covers how long to hold this.
Where tooling helps
Safeguard supports compliance and evidence automation: mapping findings and controls to frameworks and collecting dated exports, which shortens the work of assembling a package. It does not make you compliant on its own, and it does not hold any certification claims for your program.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one finding maps to several control areas, the same linkage a reviewer will follow.
Quick check
How far back should the package go?
Cover at least the review period the examiner or auditor states, and keep earlier material per your retention policy.
Do screenshots count as evidence?
They can, but system exports with dates and identifiers are stronger and easier to sample.
Sources
- NIST SP 800-53 Rev. 5 catalog, RA-5, SI-2, CM-3, CA-5, CA-7
- 23 NYCRR 500.4, Cybersecurity governance
Last reviewed: 19 October 2026.
