NYDFS Part 500 requirements impose risk-based cybersecurity controls, governance, incident notices and annual filings on covered entities operating under New York financial-services authorizations, subject to defined exemptions and transition periods.
It is not a general cybersecurity law for every company in New York. Start with covered-entity status, then test any exemption section by section.
Who is a covered entity
Part 500 defines a covered entity as a person operating under, or required to operate under, a licence, registration, charter, certificate, permit, accreditation or similar authorization under the relevant New York financial-services laws.
That can include banks, insurers, money transmitters, virtual currency businesses and other DFS-supervised firms. The authorization, not a marketing label such as “fintech”, determines coverage.
A company with a New York customer is not automatically covered. A company conducting activity that requires a DFS authorization may be.
The core program
A covered entity must maintain a cybersecurity program designed to protect its information systems and nonpublic information.
The regulation connects that program to a periodic risk assessment. The firm should not copy a generic checklist and call it complete. Its controls need to follow the systems, data, users, vendors and threats identified in the assessment.
Part 500 addresses areas including:
- cybersecurity governance;
- written policy and procedures;
- vulnerability management;
- access privileges;
- application security;
- risk assessment;
- cybersecurity personnel and intelligence;
- third-party service-provider security;
- multi-factor authentication;
- asset inventory and data retention;
- monitoring and training;
- encryption;
- incident response and business continuity.
The list is a map. The regulation’s operative sections and the firm’s facts decide the actual requirement.
Governance and written policy
The covered entity must maintain written cybersecurity policies based on its risk assessment. The policy must be approved at least annually by a senior officer or the senior governing body.
The CISO oversees and implements the program. Governance is not satisfied by handing the file to an IT vendor: management remains responsible for the regulated entity’s compliance and risk decisions.
Part 500 also requires a periodic CISO report to the senior governing body on material cybersecurity issues.
Access control and MFA
The regulation requires access privileges to be limited and reviewed. Its MFA section requires multi-factor authentication for individuals accessing covered-entity information systems, subject to the limited-exemption rules and a written path for qualifying compensating controls.
For an entity with the limited exemption in Section 500.19(a), MFA still applies to remote access to information systems, remote access to third-party applications containing nonpublic information and privileged accounts other than non-interactive service accounts.
MFA is one control. It does not replace account inventory, least privilege, logging or prompt removal of access.
Incident and extortion-payment notices
A covered entity must notify the superintendent as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the entity, an affiliate or a third-party service provider.
The regulation’s definition of a reportable cybersecurity incident includes events that trigger notice to another government or supervisory body, have a reasonable likelihood of materially harming a material part of normal operations, or deploy ransomware in a material part of information systems.
If the entity makes an extortion payment connected to a cybersecurity event, Part 500 requires:
- notice within 24 hours of the payment;
- a written explanation within 30 days covering the reasons, alternatives considered and diligence, including sanctions compliance.
The clocks run from the events stated in the regulation. An internal policy should identify who decides, who files and how third-party incidents reach that team.
The annual April 15 filing
Each covered entity must submit by April 15 either:
- a certification that it materially complied during the prior calendar year; or
- an acknowledgment that it did not materially comply, identifying the sections, describing the non-compliance and providing a remediation timeline or completion confirmation.
The filing is signed by the highest-ranking executive and the CISO. Supporting documentation must be retained for five years.
This is not a simple “yes” checkbox. The regulation expects records sufficient to support the statement.
Limited exemptions are not a full exit
Section 500.19(a) provides a limited exemption when a covered entity meets any of three thresholds:
- fewer than 20 employees and independent contractors, counted as specified;
- less than $7.5 million in gross annual revenue in each of the last three fiscal years under the section’s calculation;
- less than $15 million in year-end total assets under the section’s calculation.
The exemption removes specified sections, not the entire regulation. Other duties remain, including some MFA, notice and filing obligations. The firm must also file its exemption status as required.
Thresholds and affiliate calculations need careful reading. Do not rely on an old summary after a merger, funding round or staff change.
A working compliance file
Keep one control map linking each applicable section to:
- policy owner;
- system evidence;
- review frequency;
- vendor evidence;
- last test;
- open remediation;
- filing or notice owner.
For example, the incident-response row should link the plan, tabletop record, backup-restore test, contact tree and DFS notification procedure. The third-party row should link due diligence, contract controls and incident-notice obligations.
This turns an annual filing into a record of year-round work.
Where to be careful
Part 500 has been amended, and implementation dates differ by section. Use the current DFS text and official guidance, not a static checklist copied from an earlier version.
A firm should get legal advice on whether it is covered and how an exemption applies. The regulation is detailed enough that a product launch, new entity or vendor architecture can change the answer.
See NYDFS BitLicense and trust charter routes for the separate question of New York crypto authorization.
