Regulatory Compliance

NYDFS 500 Meets SBOM Requirements

23 NYCRR Part 500 was amended in 2023 with stronger third-party and vulnerability management language. For covered financial entities, SBOM practice has quietly become a compliance expectation.

Shadab Khan
Security Analyst
7 min read

The Amendment That Changed Everything Quietly

The New York Department of Financial Services cybersecurity regulation — 23 NYCRR Part 500, first effective in 2017 — is the most prescriptive state-level cybersecurity rule covering financial services. Covered entities include banks, insurance companies, and a range of other financial licensees operating in New York.

On November 1, 2023, NYDFS adopted the Second Amendment to Part 500, with staggered effective dates through November 2025. The amendment introduced Section 500.5 (Vulnerability Management), strengthened Section 500.11 (Third-Party Service Provider Security Policy), added Section 500.17(c) (Notification of compromise/ransomware), and created a new "Class A Companies" tier with heightened requirements.

None of the amendments mention "SBOM" or "software bill of materials." But if you read the language of 500.5 and 500.11 carefully, an SBOM has become the only practical way for a covered entity to comply with several specific obligations. This post walks through where and why.

Section 500.5 (Vulnerability Management)

Before the 2023 amendment, Part 500 referenced vulnerability management only obliquely in 500.2 (Cybersecurity Program) and 500.3 (Cybersecurity Policy). The new Section 500.5 is explicit. The effective date for non-Class A companies is November 1, 2024; for Class A companies, the heightened requirements took effect November 1, 2024 too.

The section requires covered entities to develop and implement "written policies and procedures for vulnerability management" that, at minimum, are designed to:

  1. Ensure penetration testing of the information systems from both inside and outside the information systems' boundaries.
  2. Conduct automated scans of information systems, and a manual review of systems not covered by such scans, for the purpose of discovering, analyzing, and reporting vulnerabilities, with the frequency of such scans and reviews determined by the covered entity's risk assessment.
  3. Have a monitoring process in place to promptly inform the covered entity of new security vulnerabilities.
  4. Timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose to the covered entity.

Points 2 and 3 are where SBOMs come in. "Information systems" includes the software those systems run. "Promptly inform" of new vulnerabilities requires knowing what components are deployed — which is an SBOM. "Timely remediate" with risk-based prioritization requires the kind of asset-to-component mapping that only SBOMs provide at scale.

Section 500.11 (Third-Party Service Provider Security)

The 2023 amendment strengthened Section 500.11 significantly. It now requires covered entities to implement written policies and procedures to ensure the security of information systems and nonpublic information accessible to, or held by, third-party service providers (TPSPs). The policies must address, among other things:

  • Identification and risk assessment of TPSPs.
  • Minimum cybersecurity practices required of TPSPs.
  • Due diligence processes used to evaluate the adequacy of TPSP cybersecurity practices.
  • Periodic assessment of TPSPs based on the risk they present.

Covered entities increasingly read "due diligence" and "periodic assessment" as requiring technical evidence — not just questionnaire responses. SBOMs have become part of that evidence. When a TPSP processes nonpublic information (NPI) through software, knowing the components of that software feeds the risk assessment.

For software vendors selling into NYDFS-covered financial institutions, SBOMs are now a customer-facing deliverable. I've worked with fintechs whose largest bank customers now condition contract renewal on SBOM delivery and vulnerability reporting cadence.

Class A Companies

The 2023 amendment created a Class A tier: covered entities with over $20 million gross annual revenue in each of the last two fiscal years AND either over 2,000 employees or over $1 billion gross annual revenue on a consolidated basis over each of the last two fiscal years.

Class A companies face additional obligations, most notably:

  • 500.4(c) — Design and conduct independent audits of the cybersecurity program.
  • 500.5(a)(2) — Penetration testing conducted by qualified external parties at least annually.
  • 500.14(a)(2) — Implement a monitoring process to alert the Chief Information Security Officer of new security vulnerabilities.

The CISO-alert requirement in 500.14(a)(2) pairs with 500.5(a)(3) and points again at SBOM-driven monitoring. The volume of CVEs published weekly is too high for human tracking; alert engineering off an SBOM inventory is the realistic mode.

Section 500.17(c) and Incident Notification

Section 500.17 requires 72-hour notification of cybersecurity events. The 2023 amendment added Section 500.17(c), requiring notification within 24 hours of an extortion payment and 30-day notification with additional detail. For software-supply-chain-originated incidents — think SolarWinds or 3CX — the 72-hour clock starts when the covered entity determines a cybersecurity event has occurred. Knowing what components are deployed dramatically shortens the determination time.

The SBOM-NYDFS Mapping

The practical mapping for a covered entity:

  • SBOM generation for in-scope systems500.5(a)(2) (automated scans to discover, analyze, and report vulnerabilities). An SBOM plus SCA is an automated scan.
  • Continuous vulnerability monitoring against SBOMs500.5(a)(3) (monitoring process to promptly inform of new vulnerabilities). KEV feed, OSV, and vendor advisories ingested against the SBOM.
  • Risk-based remediation with SLAs500.5(a)(4) (timely remediate, priority by risk). SLA tiers tied to severity and exploitation evidence.
  • Third-party software SBOMs from vendors500.11(a) (due diligence processes to evaluate TPSP practices). Request SBOMs in contract; review at renewal.
  • Incident response artifacts including component inventory500.17(a)(1) (72-hour notification of cybersecurity events). Having an SBOM accelerates determination of whether an event occurred.
  • CISO reporting on vulnerabilities and remediation500.4(d) (annual compliance report to the board) and 500.14(a)(2) (Class A vulnerability monitoring).

Documentation and Evidence

NYDFS has been increasing enforcement activity. Consent orders in 2020-2023 (First American, EyeMed, Residential Mortgage Services, Carnival, and several others) showed the pattern of NYDFS scrutiny: detailed examination of policies, procedures, and contemporaneous evidence. The agency expects written records that match operational practice.

For SBOM-adjacent evidence, the artifacts NYDFS exam teams look for include:

  • Written vulnerability management policy referencing component-level inventory.
  • SBOM generation logs or artifacts for in-scope systems, dated within current review window.
  • Vulnerability intake feeds (commercial or public) with evidence of matching to the SBOM.
  • Remediation ticket records showing SLA adherence.
  • TPSP due diligence records including software inventory requests from vendors.
  • CISO quarterly reports including vulnerability metrics.

Common Pitfalls

Treating 500.5 as a pen-test requirement. Pen testing is one component; vulnerability management is broader. The monitoring obligation is continuous.

Vendor questionnaires without technical follow-through. A TPSP's questionnaire response is not a substitute for an SBOM. NYDFS examiners have started asking whether questionnaire claims were validated.

Missing the November 2024 effective date. Several 2023-amendment requirements took effect in 2024. Class A companies face earlier dates. Check calendar against the NYDFS effective-date table.

CISO reporting without underlying data. Annual CISO reports under 500.4(d) need real numbers — MTTR by severity, open critical count, patch SLA adherence. These come out of SBOM-driven programs.

How Safeguard Helps

Safeguard generates SBOMs for covered-entity applications and TPSP-supplied software, matches them continuously against CVE, KEV, and vendor advisory feeds, and produces the "promptly inform" alert channel that Section 500.5(a)(3) requires. Vulnerability remediation tickets carry severity, SLA deadline, and 500.5 tag for audit-ready reporting. For TPSP programs, Safeguard's supplier risk assessments pull SBOM-level data from vendors to inform 500.11 due diligence. CISO quarterly reports and annual compliance exports under 500.4(d) draw from a single source, so the evidence NYDFS examiners ask for is a query away.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.