What vulnerability management will auditors accept at an insurer?

Auditors accept vulnerability management that is written down, risk-based and evidenced: annual penetration testing, automated scans at a set frequency and after material changes, a way to learn of new vulnerabilities promptly, and remediation ordered by risk. New York's 23 NYCRR 500.5 states exactly these items for insurers licensed in the state.

Who is covered?

Part 500 defines a covered entity as any person operating under a license, registration or similar authorization under New York's Banking Law, Insurance Law or Financial Services Law. Many insurers fall inside. Other states and regulators have their own rules, so confirm which apply to you.

What does section 500.5 require?

Each covered entity must develop and implement written policies and procedures for vulnerability management, in line with its risk assessment, designed to ensure it:

• conducts penetration testing from inside and outside the systems' boundaries by a qualified internal or external party at least annually
• runs automated scans, plus manual review of systems the scans do not cover, to discover, analyze and report vulnerabilities, at a frequency set by the risk assessment and promptly after material system changes
• is promptly informed of new vulnerabilities through a monitoring process
• remediates vulnerabilities in a timely way, prioritizing by the risk they pose

Notice what is absent: no fixed deadline in days. The test is whether your own policy sets sensible, risk-based timelines and whether you meet them.

What evidence do auditors ask for?

The rule's structure tells you.

• The written policy, approved and dated.
• The risk assessment that sets scan frequency. Section 500.9 requires a periodic risk assessment, reviewed at least annually and when business or technology changes materially.
• Penetration test reports from the last year, with the tester's qualifications.
• Scan schedules and results, including proof that scans ran after material changes.
• Coverage notes for assets scans do not reach, and the manual review done instead.
• The feed or process that tells you about new vulnerabilities.
• A remediation log: finding, risk rating, owner, due date, closed date, and approved exceptions.

Which third parties are in scope?

Section 500.11 requires written policies for the security of systems and nonpublic information accessible to third-party service providers, based on risk assessment, including due diligence and periodic assessment, with guidance on access controls, encryption, incident notice and warranties. Software vendors and open source components used in your claims or policy systems sit inside that picture.

What about incidents and certification?

Section 500.17 requires notice to the superintendent as promptly as possible and no later than 72 hours after determining a cybersecurity incident occurred at the covered entity, its affiliates or a third-party service provider. It also requires an annual submission by April 15, either a certification of material compliance based on data and documentation sufficient to demonstrate it, or a written acknowledgment that identifies the sections not met, with a remediation timeline. The highest-ranking executive and the CISO sign it.

Because the certification must rest on documentation, your vulnerability records are not paperwork. They are the evidence.

What to do

1. Write or refresh the vulnerability management policy so it mirrors the four items above.
2. Set remediation timelines by severity and by exposure, and approve them.
3. Schedule scans across code, dependencies, containers and infrastructure, and trigger scans after material changes.
4. Book the annual penetration test and keep the report.
5. Track exceptions with owner, reason and expiry.
6. Include third-party and open source components in the inventory and scan scope.
7. Export a quarterly summary for the person who signs the annual certification.

Constructed example: a claims platform team finds a critical vulnerability in a library. Reachability analysis shows the vulnerable function is never called, so it is ranked below a reachable medium issue in a public portal. The log records that reasoning, which an auditor can follow.

Safeguard's dependency scanning, reachability analysis and policy gates produce that kind of record in the pipeline, and its compliance automation can organise it as evidence. The compliance judgment stays with your compliance team.

Quick check

Sources

• 23 NYCRR 500.5 Vulnerability management, Legal Information Institute
• 23 NYCRR 500.1 Definitions
• 23 NYCRR 500.9 Risk assessment
• 23 NYCRR 500.11 Third-party service provider security policy
• 23 NYCRR 500.17 Notices to superintendent

Last reviewed: 18 October 2026.