NYDFS Part 500
cybersecurity requirements for financial services companies

NYDFS Part 500 in context: the Cybersecurity Requirements for Financial Services Companies

The New York Department of Financial Services Cybersecurity Requirements for Financial Services Companies, codified at 23 NYCRR Part 500, is the cybersecurity regulation that applies to entities authorised to operate under the New York Banking Law, the New York Insurance Law, and the New York Financial Services Law. Adopted in March 2017 and updated substantively through the Second Amendment effective 1 November 2023 (with phased implementation dates running through November 2025), Part 500 is the most prescriptive US state cybersecurity regulation that financial services regulators apply, and the Department uses it as the working framework for its IT examinations of Covered Entities.

Part 500 sits inside a wider US picture for financial-sector cybersecurity supervision. For federal banking organisations, the FFIEC IT Examination Handbook sets the comparable examination expectations, and the FFIEC member agencies (the OCC, the Federal Reserve, the FDIC, the NCUA, and the CFPB) read NYDFS Part 500 evidence alongside their own examination programme where the institution operates under both regimes. For publicly traded Covered Entities, the SEC cybersecurity disclosure rules run alongside Part 500 with a different posture: investor disclosure rather than prudential supervision. For payment card environments, the PCI DSS standard operationalises controls that often satisfy Part 500 obligations on the same scoped environment. Many Covered Entities also operate SOC 2, NIST 800-53, and the NIST Cybersecurity Framework as the operational catalogues the Part 500 cybersecurity programme structures itself against, with the Department recognising that Part 500 compliance can be evidenced through controls already operating under those catalogues.

In-scope Covered Entities: who Part 500 applies to

Part 500 applies to any Person operating under or required to operate under a licence, registration, charter, certificate, permit, accreditation, or similar authorisation under the Banking Law, the Insurance Law, or the Financial Services Law of New York. The Department refers to these entities as Covered Entities. The cybersecurity programme runs against the New York-licensed activity and the Information Systems that support it; an out-of-state parent that holds a New York licence operates the programme against that licensed activity rather than only against the New York entity.

Section-by-section: the seventeen operative obligations

Part 500 organises the cybersecurity programme across seventeen operative sections, each with examination-friendly evidence that the Department reads at the IT examination. The sections are not a checklist in isolation; they read together as the structural description of the cybersecurity programme the Covered Entity operates. The summary below captures the working obligation per section as updated through the November 2023 Second Amendment.

Vulnerability scanning evidence and penetration testing records sit at the centre of Section 500.05. The penetration testing workflow keeps engagement, findings, and remediation tied to a single record so the annual Section 500.05 evidence pack reads without reconstruction. The scanner result triage workflow covers turning raw scanner output from the bi-annual vulnerability programme into assessor-ready findings without losing the audit trail. The vulnerability SLA management workflow carries the remediation timelines the institution risk assessment defines and that the Department reads against the Section 500.05 programme expectations.

The November 2023 Second Amendment: what changed

The Second Amendment to Part 500, effective 1 November 2023 with phased implementation dates running through November 2025, restructured the regulation around heightened governance, broader multi-factor authentication, the new Class A company tier, and explicit notification obligations for extortion payments. The changes below capture the substantive shifts a Covered Entity programme already running against the original Part 500 needs to address.

The 72-hour notification clock and the extortion payment notice

Section 500.17(a) requires the Covered Entity to notify the superintendent no later than 72 hours after determination that a Cybersecurity Event has occurred. The trigger applies to events required to be reported to any government body, self-regulatory body, or other supervisor, and to events that have a reasonable likelihood of materially harming any material part of the normal operations of the Covered Entity. The 72-hour clock starts at the determination timestamp rather than at the detection timestamp, and the Department reads the gap between detection and determination as part of the supervisory dialogue rather than as a private institution matter.

The November 2023 amendments added a second notification clock for extortion payments: Section 500.17(c) requires the Covered Entity to notify the superintendent of any extortion payment made in connection with a Cybersecurity Event no later than 24 hours after the payment, with a written description of the reasons for the payment within 30 days. The payment-specific clock runs alongside the 72-hour event clock; the Department reads them as separate obligations rather than as parts of a single notification.

For the operating record that runs detection, determination, and notification on a single engagement trail, the incident response workflow holds the timeline the 72-hour clock measures from. The breach notification and regulator readiness workflow keeps the notification artefacts together so the Department filing and any parallel federal banking, state insurance, or SEC notification reads from the same record rather than from independently maintained narratives that drift.

The annual certification: Section 500.17(b)

Section 500.17(b) requires the Covered Entity to file by 15 April each year either a Certification of Material Compliance with Part 500 for the prior calendar year or an Acknowledgement of Non-Compliance identifying the sections the Covered Entity has not materially complied with and the remediation plan. The November 2023 amendments require the filing to be signed by the Senior Officer responsible for the cybersecurity programme and either the Chief Executive Officer or the Senior Governing Body Chair. The signature attaches accountability to the filing in a way the original Part 500 did not.

The filing is read against the evidence pack the Covered Entity holds. A certification signed against an evidence pack that does not exist on the workspace, or that has gaps the signatories were not aware of, sits at the centre of the Department recent enforcement record. The certification is not a compliance artefact in isolation; it is a statement against the evidence the Department can request at any subsequent IT examination or in connection with a Cybersecurity Event.

Class A companies: Section 500.24 additional obligations

The November 2023 amendments introduced the Class A company tier. A Class A company is a Covered Entity with at least USD 20 million in gross annual revenue averaged over the last two fiscal years from operations of the Covered Entity and its Affiliates in New York, and either over USD 1 billion in gross annual revenue from all business operations of the Covered Entity and its Affiliates in the last two fiscal years, or over 2,000 employees averaged over the last two fiscal years. Class A companies carry additional obligations under Section 500.24 that do not apply to non-Class A Covered Entities.

Section 500.24 obligations include an independent audit of the cybersecurity programme based on the risk assessment at a frequency the risk assessment defines, monitoring and filtering of email-based attacks (including blocking attachments and links from known malicious sources), endpoint detection and response and the related Security Information and Event Management or equivalent centralised logging, a password vault for privileged accounts and the automated blocking of commonly used passwords, and stronger authentication for privileged account use. Class A obligations are mandatory for Covered Entities meeting the threshold; the institution evidence pack records both the Class A status determination and the operationalisation of each Section 500.24 control.

Senior Governing Body oversight and the CISO function

The November 2023 amendments raised the bar on governance. The Senior Governing Body (the board of directors or equivalent body) approves the written cybersecurity policy and exercises oversight of the cybersecurity programme, including requiring the cybersecurity programme to be reported on at least annually by the CISO and confirming that management has sufficient personnel, resources, and tools to manage the cybersecurity programme. The Senior Governing Body documents its oversight cadence and the basis on which it confirms the programme.

The CISO function (Section 500.04) reports in writing at least annually to the Senior Governing Body on the cybersecurity programme, material cybersecurity risks, and plans to remediate inadequacies. The CISO function may be performed by an Affiliate or a qualified third-party service provider, but the Covered Entity retains oversight responsibility and the Section 500.04 obligations follow the institution regardless of how the function is staffed.

Section 500.05: penetration testing and vulnerability assessment in detail

Section 500.05 sits at the centre of the testing programme the Department reads at examination. The Covered Entity performs annual penetration testing from both inside and outside the Information Systems boundary, based on relevant identified risks in accordance with the risk assessment. Continuous monitoring or periodic vulnerability assessments evidence ongoing coverage. The November 2023 amendments added bi-annual systematic scans or reviews of Information Systems for publicly disclosed vulnerabilities and required automated scans across in-scope systems based on the risk assessment.

The testing programme reads against the asset register and the risk assessment, not against a generic scope. Internet-facing systems, customer-facing applications, systems processing Nonpublic Information, payment processing infrastructure, and systems supporting business-critical workflows typically receive testing at the documented cadence the institution risk assessment defines. The closure of findings the testing surfaces is evidenced through retest records or compensating control approvals, with the Section 500.07 access privilege review and the Section 500.11 third-party assessment often feeding the testing scope of the next cycle.

For the analytical view of how a finding ages into a remediation backlog and how that ageing reads at examination, the aging pentest findings research covers why an open finding lingering across cycles reads to a Department examiner as a programme weakness rather than as a delivery delay. For the recurring testing cycle that tracks Section 500.05 expectations, the retesting workflow evidences the closure of findings the examiner expects to see verified rather than self-attested, and the security testing programme management workflow carries the cumulative engagement record across the calendar year so the Section 500.17(b) annual certification has the supporting evidence ready by 15 April.

Evidence the Department (and your Senior Governing Body) expect

Part 500 examinations that go badly usually go badly because the artefacts are scattered across drives, secure email threads, and screenshots. Build the evidence pack as the work happens, retain raw evidence alongside the structured record, and tie every artefact back to the Part 500 section it operationalises and the owner who produced it. The Department reads the way the underlying record reads.

Common Part 500 gaps the Department reads at examination

The pattern below shows where Part 500 programmes most often fall short of what the regulation expects. Each gap is recoverable when the workspace record carries the upstream evidence; each one is hard to recover when the gap is discovered at examination or at a Cybersecurity Event when the 72-hour clock is already running.

Part 500 and adjacent frameworks: where the evidence pack overlaps

Most Part 500 Covered Entities run more than one framework at the same time. The institution may operate the PCI DSS standard on the payment card environments, the SOC 2 framework on the technology service operations, the SWIFT Customer Security Programme on the wholesale messaging infrastructure, the NIST Cybersecurity Framework as a control catalogue reference, and the NIST 800-53 catalogue when the institution serves the federal government. Insurance Covered Entities often run the HIPAA Security Rule alongside Part 500 where health information is in scope, and the GDPR regime applies to international policyholder data alongside the Part 500 obligations on Nonpublic Information.

Part 500 evidence reads against the controls these frameworks already operationalise; the same evidence pack often satisfies more than one regime when the mapping is built into the workspace from the start rather than rebuilt at examination time. For institutions that also operate under FFIEC supervision, the technology and cybersecurity controls overlap substantially, and the same testing programme typically supports both supervisory regimes with the additional Part 500-specific notification and Section 500.17(b) certification artefacts maintained on the same workspace.

Where SecPortal fits in a Part 500-aligned programme

SecPortal is the operating layer for the Part 500 programme, not a replacement for the Department, the pentest provider, the threat intelligence partner, or the Senior Governing Body. The platform handles scope, role records, findings, attestation artefacts, and the closure pack so the work runs as a structured workflow rather than a long encrypted email thread. Compliance tracking maps the Part 500 evidence pack to NIST CSF, NIST 800-53, PCI DSS, and SOC 2 for Covered Entities that have to satisfy more than one regime from the same body of work.

For the analytical view of remediation throughput a Section 500.05 programme depends on, the vulnerability remediation throughput research covers why the closure rate of the backlog drives the Department supervisory read on the cybersecurity programme. For the operational record that supports the CISO Section 500.04 annual report to the Senior Governing Body, the security leadership reporting workflow carries the trend, the SLA progress, and the residual-risk picture in the form the board and the audit committee expect.

For programmes that want continuous detection and trend evidence between IT examination cycles, the continuous monitoring capability and attack surface management capability produce the cadence and coverage record that examiners read most easily during the scoping conversation. The compliance tracking capability maps the Part 500 sections to the operating controls so the Section 500.17(b) annual certification reads from the underlying record rather than from a separately maintained compliance spreadsheet.

For in-house bank, credit union, payments, broker-dealer, asset manager, insurer, and fintech security teams running the Part 500 certification cycle alongside the FFIEC examination response, the DORA artefact set, the SWIFT CSP independent assessment pack, and the PCI DSS assessment evidence on the same workspace the operators run on, the financial services security teams workspace anchors the cross-regulator evidence pack on one record so the supervisor reads one trail rather than six reconstructions.

For in-house insurance company, fraternal benefit society, health maintenance organisation, accredited reinsurer, insurance producer, public adjuster, and reinsurance intermediary security teams whose New York-licensed activity sits inside Part 500 scope alongside the NAIC Insurance Data Security Model Law (MDL-668) written information security programme, the EIOPA Digital Operational Resilience Act artefact set for European entities, and the state insurance department market-conduct evidence pack, the insurance security teams workspace anchors the carrier-side and broker-side evidence pack on one record so the Department and the NAIC examiner read the same trail rather than parallel reconstructions across the policy-administration system, the policyholder portal, the claims-handling vendor, and the agency-management system.

Scope and limitations

23 NYCRR Part 500 is administered by the New York Department of Financial Services. The Covered Entity evidences how its cybersecurity programme meets the regulation during IT examination and through the Section 500.17(b) annual filing. SecPortal is the workspace that holds the engagement, the testing programme, the findings, the remediation record, and the audit trail. Examination responses, Section 500.17 notifications, the Section 500.17(b) annual certification, and any Section 500.17(c) extortion payment notice remain actions the institution takes through the Department portals and channels; SecPortal holds the supporting record so the response is grounded in the evidence pack rather than reconstructed from email and shared drives at the deadline moment.

Nothing on this page is legal advice. Part 500 certifications, notifications, and examination responses require the involvement of the Covered Entity general counsel, the CISO, the Senior Officer responsible for the cybersecurity programme, and the Senior Governing Body. The platform supports the underlying work record those roles rely on; it does not substitute for the legal and regulatory judgement that determines how the institution engages with the Department. This page describes the structure of Part 500 expectations and how a workspace-driven programme plays against them; the authoritative reference for the obligations remains 23 NYCRR Part 500 as adopted and amended by the Department, including the November 2023 Second Amendment and any subsequent guidance and industry letters the Superintendent issues.