If your company holds a license, charter or registration from the New York State Department of Financial Services (NYDFS), its cybersecurity regulation, 23 NYCRR Part 500, already tells you to keep audit trails. Since the second amendment of November 2023, the largest companies must also run a solution that centralizes logging and security event alerting. The regulation is short on technical detail. Yet every April 15, your most senior executive and your chief information security officer (CISO) must sign a statement that you comply. This guide turns the logging sections of Part 500 into a plain list: what to collect, how long to keep it and what evidence to have ready.
The short answer: Part 500 has three logging rules. Section 500.6 requires covered entities to keep audit trails designed to detect and respond to serious cybersecurity events for at least three years, and records that can reconstruct material financial transactions for at least five years. Section 500.14(a) requires risk-based monitoring of authorized users to detect unauthorized access, use or tampering. Section 500.14(b), in force since May 1, 2025, requires Class A companies to run endpoint detection and response and “a solution that centralizes logging and security event alerting,” unless the CISO approves equivalent or stronger controls in writing. The regulation never uses the word SIEM (security information and event management), but that last requirement describes what a SIEM does.
Who must follow the NYDFS logging rules
Part 500 applies to every covered entity: anyone operating under, or required to operate under, a license, registration, charter, certificate, permit, accreditation or similar authorization under New York’s Banking Law, Insurance Law or Financial Services Law (section 500.1(e)). That includes banks, credit unions with state charters, insurers, insurance agencies, mortgage companies, money transmitters and virtual currency businesses licensed in New York.
Which logging rules apply depends on your size.
| Type of company | Who qualifies (summary) | Logging rules that apply |
|---|---|---|
| Class A company (500.1(d)) | At least $20 million in revenue in each of the last two years, plus more than 2,000 employees or more than $1 billion in revenue, counting affiliates (details in the FAQ) | 500.6, 500.14(a), 500.14(b) endpoint detection and centralized logging, 500.7(c) privileged access monitoring, 500.2(c) independent audits |
| Standard covered entity | Neither Class A nor exempt | 500.6 audit trails, 500.14(a) monitoring, 500.16 incident response, 500.17 notices |
| Limited exemption (500.19(a)) | Fewer than 20 employees and contractors, or under $7.5 million in New York revenue in each of the last three years, or under $15 million in year-end total assets | Exempt from 500.6 and all of 500.14(a)(1), (a)(2) and (b); still bound by 500.7, 500.17 and others |
An exempt company must file a notice of exemption within 30 days (500.19(f)). If it stops qualifying, it has 180 days to comply with everything that then applies (500.19(h)).
The Part 500 sections that drive logging
The table paraphrases each section and adds what it means for your logs. Part 500 is a public regulation, and the full text is linked in the sources.
| Section | What it requires (paraphrased) | What it means for logs |
|---|---|---|
| 500.3(g) | A written policy covering systems and network security and monitoring | Your logging and monitoring rules must be written down and approved |
| 500.6(a)(1) | Systems designed to reconstruct material financial transactions | Transaction records in core banking, payment, policy or claims systems; keep 5 years |
| 500.6(a)(2) | Audit trails designed to detect and respond to cybersecurity events likely to materially harm normal operations | Security logs from the systems that matter; keep 3 years |
| 500.7(a) and (b) | Limit and review access at least once a year; remove access promptly when people leave | Account and access change logs prove the reviews and removals happened |
| 500.7(c) | Class A: monitor privileged access activity, run a privileged access management solution, block commonly used passwords | Administrator sessions and privileged account use must be collected and watched |
| 500.14(a)(1) | Monitor authorized users’ activity and detect unauthorized access, use or tampering with nonpublic information | Sign-ins, access to sensitive data and unusual user behavior |
| 500.14(a)(2) | Controls against malicious code, including monitoring and filtering web traffic and email | Web proxy, secure email gateway and filtering logs |
| 500.14(b) | Class A: endpoint detection and response, plus a solution that centralizes logging and security event alerting | One place where logs land and alerts fire |
| 500.16 | An incident response plan covering documentation, reporting, recovery from backups and root cause analysis | Incident records, timelines and root cause reports built from logs |
| 500.17 | Notify DFS within 72 hours of determining that a cybersecurity incident occurred; certify compliance by April 15 each year | Logs show when you knew, and support the annual certification |
The Department explained why it added 500.14(b) in its response to public comments: centralized logging and alerting “provide a holistic view of a covered entity’s security posture as well as valuable insights into incidents and anomalies.” In the same document, it refused a request to change “monitor” to “log” in 500.7(c), because monitoring “requires active conduct.” Collecting logs is not enough. Someone has to watch them.
When the amended Part 500 rules took effect
Compliance dates from section 500.22 and the DFS implementation timeline
- November 1, 2023Second amendment adoptedNew 72-hour and extortion notice rules apply December 1, 2023
- April 29, 2024Most new rules applyIncluding independent audits for Class A companies and yearly training
- November 1, 2024Governance and responseBoard oversight, encryption, incident response and business continuity
- May 1, 2025Logging and access controlsCentralized logging and endpoint detection for Class A, privileged access, email and web filtering
- November 1, 2025Last trancheMulti-factor authentication for all and asset inventory
What to log for NYDFS
Part 500 does not list events. Your risk assessment decides which systems matter, and 500.6(a)(2) asks for audit trails on the ones whose compromise could materially harm normal operations. For most banks and insurers, that list looks like this.
| Source | Events to capture | Part 500 link |
|---|---|---|
| Directory and identity provider | Sign-ins (success and failure), multi-factor events, new and disabled accounts, group and role changes | 500.7, 500.12, 500.14(a)(1) |
| Privileged accounts | Administrator sign-ins, use of elevated rights, sessions through the privileged access management tool | 500.7(c) |
| Endpoints | Endpoint detection and antivirus alerts, disabled protection, suspicious processes | 500.14(b)(1) |
| Email and web | Blocked malicious messages and downloads, filtering policy changes | 500.14(a)(2) |
| Network edge | Firewall denies at the boundary, virtual private network (VPN) sign-ins, remote access sessions | 500.6(a)(2), 500.7(b) |
| Core business applications | Access to customer data, high-value transactions, administrator changes | 500.6(a)(1), 500.14(a)(1) |
| Cloud and software as a service | Control plane changes, new keys, sharing and permission changes | 500.6(a)(2) |
| The logging system itself | Sources that stop sending, cleared logs, changes to alert rules | 500.6(a)(2): an audit trail with gaps cannot support a response |
Each entry should say who did what, when, from where, on which system and with what result. Sync every clock to one time source. The timeline you rebuild from those logs also shows when you “determined” an incident occurred, which starts the 72-hour clock in 500.17(a).
Which NYDFS logging rules apply to you
A simplified path through sections 500.1, 500.6, 500.14 and 500.19
How long to keep logs for NYDFS
Section 500.6(b) sets two numbers. Records that reconstruct material financial transactions must be kept for at least five years. Audit trails designed to detect and respond to cybersecurity events must be kept for at least three years. Most of the five-year records live in your core business systems. The three-year rule is the one that lands on your security logs.
The Department enforces it. In a December 2022 consent order, TTEC Healthcare Solutions agreed to pay $1.9 million after DFS found it kept active audit trail records for 90 days and archived records for another 15 months, short of the three years required.
Minimum log retention, in years
NYDFS compared with two other rules that often apply to the same companies
Three years of logs adds up. Keep recent data on fast disks and the rest on cheaper storage that can still be searched when an examiner asks. Our SIEM sizing calculator estimates the volume. For the payment card side, see PCI DSS logging requirements, and for criminal justice systems, see CJIS logging requirements.
Centralized logging for Class A companies
Section 500.14(b)(2) asks for “a solution that centralizes logging and security event alerting.” That is three tests: logs from the systems in scope land in one place, the solution keeps them (so it is also where your three-year audit trail lives), and it raises alerts on suspicious events instead of only storing them.
A SIEM meets all three by design. So can a log platform with good alerting, or a SIEM a provider runs for you, as long as you can show it covers your systems and that alerts reach someone who acts. A provider also falls under the third-party service provider policy that 500.11 requires.
The CISO can approve “reasonably equivalent or more secure compensating controls” instead. Put that approval in writing, explain why the alternative is as strong, and keep it with your certification records.
The companion rule, 500.14(b)(1), asks for endpoint detection and response that monitors anomalous activity, including lateral movement. The two work together: endpoint tools see each machine, and the central platform connects their alerts with sign-ins, firewall traffic and cloud activity.
The evidence to keep for examinations and certification
Each year, by April 15, a covered entity files either a certification that it materially complied during the prior calendar year or a written acknowledgment of noncompliance, signed by the highest-ranking executive and the CISO (500.17(b)). The supporting records must be kept for five years. For logging, that file usually holds:
- An inventory of log sources tied to the systems your risk assessment rates as important.
- Retention settings that show three years for audit trails.
- The alert rules in use, and records of who reviewed alerts and what they did.
- Incident tickets with timelines, root cause analyses and any 72-hour notices sent.
- For Class A companies, written CISO approvals of any compensating controls and the independent audit results under 500.2(c).
Weak monitoring has cost companies real money. In November 2024, GEICO agreed to pay $9.75 million in penalties, $5 million of it to DFS. The consent order found it did not implement effective monitoring of authorized users, in violation of 500.14(a).
Do you need a SIEM for NYDFS?
For a Class A company, in practice yes, or a CISO-approved equivalent. For other covered entities, the regulation names no tool, but three years of audit trails, user monitoring across many systems and a 72-hour notice clock are hard to meet with logs scattered across servers. Our guide to SIEM compliance requirements compares Part 500 with the other frameworks, and the GLBA security requirements guide covers the federal rule many of the same companies follow.
How UTMStack fits
We build UTMStack, so weigh our view accordingly. Here is what it does for Part 500 logging, and where it stops.
- Centralized logging and alerting. UTMStack collects logs from Windows and Linux hosts, firewalls such as Fortinet FortiGate, Palo Alto Networks, Cisco and SonicWall, Microsoft 365, Amazon Web Services, Azure and Google Cloud, and checks every event against more than 600 detection rules mapped to MITRE ATT&CK as it arrives, before it is stored. That is the job 500.14(b)(2) describes. See log management.
- Endpoint detection comes from your EDR. UTMStack is not an endpoint detection and response tool. It brings in alerts from tools such as CrowdStrike Falcon, SentinelOne and Sophos Central, so endpoint alerts sit next to sign-ins and network events. Response flows can isolate a host, disable an account or block an address. See automated response.
- Three years and more. Retention can be set up to five years. Older logs move to cold storage that stays searchable without a restore, which covers the three-year audit trail rule in 500.6.
- Compliance reports. The Enterprise edition includes a Banking Audit framework with 80 checks, mostly on Windows events such as sign-ins, policy changes and new accounts, grouped into log collection, correlation and real-time alerting. It is not a Part 500 report and does not map to the sections above. See compliance.
- Where it runs. Install it on your own servers, or use UTMStack Cloud, a dedicated instance per customer on OVHcloud, with regions that include the United States.
- Someone watching. The Department says monitoring “requires active conduct.” If your team cannot cover nights and weekends, our SOC Extension backs up your existing team for after-hours coverage, overflow and incidents. Your team stays in charge.
- What it does not do. UTMStack has no file integrity monitoring and no Google Workspace parser, so those need other tools. It has no built-in rules for new accounts or privileged group changes; write them as custom rules if your risk assessment calls for them.
UTMStack is priced per device, never by log volume, so three years of logs from every system does not multiply the bill. Ask for a quote or see pricing.
Frequently asked questions
Does NYDFS require a SIEM? Not by name. Section 500.14(b) requires Class A companies to run “a solution that centralizes logging and security event alerting,” which is what a SIEM does, unless the CISO approves equivalent controls in writing. Other covered entities must keep audit trails and monitor users, and most use a SIEM to do it.
How long does NYDFS require logs to be kept? Audit trails designed to detect and respond to cybersecurity events: at least three years. Records that reconstruct material financial transactions: at least five years (500.6(b)). Records that support the annual certification: five years.
What is a Class A company under NYDFS? A covered entity with at least $20 million in gross annual revenue in each of the last two fiscal years from its own operations and the New York operations of its affiliates, plus either more than 2,000 employees averaged over those two years or more than $1 billion in gross annual revenue in each of them, counting affiliates everywhere (500.1(d)). Affiliates count only if they share information systems, cybersecurity resources or part of the cybersecurity program.
When did the NYDFS centralized logging requirement take effect? May 1, 2025, 18 months after the second amendment took effect on November 1, 2023 (500.22). The same date applied to the privileged access rules in 500.7 and the email and web filtering rule in 500.14(a)(2).
Do small companies with a limited exemption need audit trails? Companies exempt under 500.19(a) do not have to follow 500.6 or 500.14(a)(1), (a)(2) and (b). They must still report incidents within 72 hours, so basic logging is still wise.
Sources
- New York State Department of Financial Services, Second Amendment to 23 NYCRR Part 500, adopted text (November 1, 2023): sections 500.1, 500.2, 500.3, 500.7, 500.14, 500.16, 500.17, 500.19 and 500.22
- NYDFS, 23 NYCRR Part 500, full text with the second amendment (the Department’s reading copy, labeled not official): section 500.6
- NYDFS, Implementation timeline for Class A companies
- NYDFS, Assessment of public comments on the second amendment (November 1, 2023)
- NYDFS, Consent order with TTEC Healthcare Solutions (December 2, 2022)
- NYDFS, Press release on the GEICO and Travelers settlements (November 25, 2024) and GEICO consent order
- PCI DSS v4.0.1, Requirement 10.5.1, available from the PCI SSC document library
- FBI, CJIS Security Policy, version 6.1, control AU-11
