Examiners want proof for each clause of your written vulnerability policy: testing performed, scans and manual review of systems the scans miss, a feed of new vulnerabilities, and fixes ordered by risk. New York's Part 500.5 spells these out clearly, so it makes a useful worked example for any retail bank, whether or not it is covered.
Which rule is this based on?
The New York Department of Financial Services regulation, 23 NYCRR Part 500, applies to organizations operating under a license, registration, charter or similar authorization under New York's Banking, Insurance or Financial Services laws. Section 500.5 covers vulnerability management. We use it here because the text is short and testable. Other regulators, and your own jurisdiction, will have different wording, so treat this as a template for evidence thinking, not as legal advice about your obligations.
The section requires written policies and procedures for vulnerability management, in line with the entity's risk assessment, designed to assess and maintain the effectiveness of its cybersecurity program.
Clause by clause, what evidence answers it?
500.5(a)(1): penetration testing. At least annual testing of information systems from both inside and outside their boundaries, by a qualified internal or external party. Evidence: the scope document, tester qualifications, the report, and the remediation tracker for its findings. Inside and outside are separate, so have two clearly labelled scopes.
500.5(a)(2): automated scans and manual review. Scans, plus manual review of systems the scans do not cover, to discover, analyse and report vulnerabilities, at a frequency set by the risk assessment and promptly after material system changes. Evidence: a scan calendar derived from the risk assessment, dated scan outputs, a list of systems excluded from scanning with the manual review record for each, and change tickets linked to rescans. Retail banks usually have systems that scanners handle badly, such as mainframe-adjacent applications, appliances and vendor-managed platforms, so this list is not optional.
500.5(b): being promptly informed. A monitoring process for new security vulnerabilities. Evidence: the list of sources you follow, such as vendor advisories and the CISA Known Exploited Vulnerabilities catalog, who reads them, and tickets or messages generated from them. Show a real example from the last quarter.
500.5(c): timely remediation, prioritised by risk. Evidence: a documented ranking method, targets by class, closed tickets with dates, and approved exceptions. The method can use public signals. FIRST's CVSS reflects severity, EPSS estimates exploitation probability over 30 days, and the CISA catalog marks vulnerabilities with observed exploitation. The point is that the method is written and applied, and that internet facing and customer data systems come first.
What gaps should you look for first?
Three gaps are worth checking before anyone else does. First, scope drift: the scan asset list does not match the asset inventory. Second, aging exceptions: risk acceptances with no end date. Third, vendor systems: the bank asks the vendor for a clean letter and has no view of fixes. NIST's patch management guide frames patching as a cost of doing business and a core part of preventive maintenance, which helps when you need to argue for downtime windows to the business.
A constructed example
A regional bank runs quarterly external scans and monthly internal scans, set by its risk assessment. A card platform from a vendor cannot be scanned, so a manual review each quarter checks the vendor's patch notes and configuration. A new advisory for a web server appears on the exploited list on a Tuesday. The monitoring owner opens a ticket, the infrastructure team patches the internet facing servers in four days and the rest in thirty, and the ticket links the rescan. At the annual review the examiner samples six items and each has a complete chain.
What to do
- Write the policy so each of the four clauses has a named procedure and owner.
- Reconcile the scan scope against the asset inventory every month.
- Keep a list of systems that scans do not cover, with the manual review procedure.
- Schedule annual penetration tests with separate inside and outside scopes, and track findings to closure.
- Subscribe to advisories and the exploited vulnerabilities catalog, and log what you did with each relevant item.
- Define remediation targets by risk class and report on them.
- Require end dates and approvers on all exceptions.
- Ask critical vendors for patch evidence, not only assurances.
Safeguard dependency scanning, reachability analysis and compliance automation can feed parts of this trail for software you build. They do not replace network or infrastructure scanners, and they do not certify compliance. See the exploitability check demo.
Quick check
Does 500.5 require annual penetration testing?
Yes, at least annually, from both inside and outside the system boundaries, by a qualified internal or external party.
What if a system cannot be scanned?
The text requires manual review of systems not covered by scans, so keep a list of them and a record of each review.
Sources
- Cornell LII: 23 NYCRR 500.5 Vulnerability management
- NYDFS: Cybersecurity Resource Center
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- FIRST: Exploit Prediction Scoring System
- FIRST: Common Vulnerability Scoring System
- CISA: Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
