April 30, 2026 18 min read Uncategorized

Financial Services Compliance: NYDFS 23 NYCRR 500 vs FTC Safeguards Rule (GLBA)

If you work in U.S. financial services compliance, there is a conversation that happens in almost every serious planning meeting. Someone says the words NYDFS and GLBA in the same sentence, and the room gets quiet. Because everyone in that room knows what follows: two regulators, two rulebooks, overlapping but different definitions, different reporting timelines, […]

The good news is that you do not need two separate programs. What you need is one solid, well-documented baseline built around the stricter expectations of the two frameworks, with specific add-ons for the areas where the requirements genuinely diverge. Done correctly, that approach reduces duplicated work, simplifies audits, and produces a security program that actually reduces risk rather than just generating paperwork.

This guide compares the NYDFS Cybersecurity Regulation (23 NYCRR Part 500), enforced by the New York Department of Financial Services, and the FTC Safeguards Rule under GLBA, enforced by the Federal Trade Commission for covered financial institutions outside the jurisdiction of federal banking regulators. The focus is on what matters operationally: who is covered, what controls are expected, how incident reporting works including the NYDFS 72-hour rule and extortion payment notices, and how to build one harmonized program that genuinely meets both sets of requirements.

Why These Two Rules Feel Different Even When They Overlap

At a high level, both NYDFS and the FTC are aiming at the same destination. Protect customer financial information. Reduce cybersecurity risk. Hold organizations accountable for the security of the systems and data they operate.

But they come from different regulatory traditions, and that difference shows up clearly in how organizations experience compliance.

NYDFS is a state financial regulator. Its cybersecurity rule reads like it was written by people who had watched financial institutions actually respond to incidents and found the results wanting. It is prescriptive in places, aggressive on timelines, heavy on documentation discipline, and explicit about executive accountability. The underlying message is: we expect this program to function under real operational stress, not just look good on paper.

The FTC Safeguards Rule is a federal consumer protection rule grounded in GLBA. It was designed to cover a wide range of non-bank businesses that handle consumer financial information, many of which are smaller and less sophisticated than the institutions NYDFS regulates. The rule is risk-based in structure, but the updated 2023 version is significantly more prescriptive than its predecessor. It now includes specific requirements for qualified individual oversight, written risk assessments, access controls, encryption, incident response planning, service provider oversight, and a formal breach notification requirement to the FTC for certain qualifying events.

Compliance teams who work across both frameworks often describe NYDFS as the harder standard in practice. Not because the FTC is permissive, but because NYDFS pushes faster incident timelines, more executive accountability, and a prove-it documentation discipline that the FTC does not replicate at the same level of intensity. If you build your program to NYDFS standards first, meeting the FTC requirements becomes considerably more manageable.

Who Is Covered Under Each Rule

NYDFS Cybersecurity Regulation: Covered Entities

23 NYCRR Part 500 applies to covered entities regulated by the New York Department of Financial Services. If your organization is licensed, registered, or otherwise authorized by DFS under applicable New York financial services laws, you almost certainly fall within the rule’s scope. This commonly includes banks, insurers, mortgage servicers, licensed lenders, money transmitters, and a range of other DFS-regulated financial businesses.

NYDFS also distinguishes Class A companies based on size thresholds, specifically organizations with at least $20 million in gross annual revenue from New York business, over 2,000 employees, or over $1 billion in total assets. Class A companies face enhanced requirements in certain program areas, including independent audits and more specific penetration testing expectations. If your organization qualifies as Class A under the 2023 amendments, you should plan for a higher bar in those areas.

FTC Safeguards Rule: Covered Financial Institutions

The FTC Safeguards Rule applies to financial institutions under the FTC’s jurisdiction that are not supervised by another federal regulator for GLBA safeguards compliance. This is the part many organizations miss when they first assess their regulatory footprint.

The definition of financial institution under GLBA is broader than the word suggests. It can include non-bank lenders, auto dealers who arrange financing, finance companies, mortgage brokers, debt collectors, credit counselors, tax preparation firms, and a range of other businesses that engage in financial activities involving consumer information. If your business collects, stores, or processes consumer financial data and does not fall under a federal banking regulator’s oversight for GLBA purposes, the FTC Safeguards Rule likely applies to you.

For corporate groups that operate across multiple business lines, both frameworks can apply simultaneously to different entities within the same organization. One subsidiary may be NYDFS-regulated while another falls under the FTC rule. That is exactly the scenario where building a single harmonized program with clear regulatory mapping becomes the most efficient path forward.

What Each Rule Expects at the Program Level

NYDFS: A Program Built to Operate Under Stress

NYDFS requires covered entities to maintain a cybersecurity program designed to protect the confidentiality, integrity, and availability of information systems and nonpublic information. The program must be based on a formal risk assessment and must support core security functions: identifying risk, protecting systems, detecting events, responding effectively, recovering from incidents, and meeting regulatory reporting obligations.

The underlying expectation is operational maturity. NYDFS does not want to see a binder of policies that no one has tested. It wants evidence that the program can actually function when things go wrong. That distinction drives a lot of the documentation and testing requirements in the regulation.

FTC Safeguards Rule: A Written Program With Specific Minimum Requirements

The FTC Safeguards Rule requires covered entities to develop, implement, and maintain a comprehensive written information security program. The program must be appropriate to the organization’s size and complexity, the nature and scope of its activities, and the sensitivity of the customer information it handles.

The 2023 version of the rule is meaningfully more specific than earlier iterations. It requires designating a qualified individual to oversee the program, maintaining written risk assessments, implementing access controls and multi-factor authentication, managing encryption for customer information in transit and at rest, maintaining and testing an incident response plan, and overseeing service providers with appropriate contractual controls.

Both frameworks are formally risk-based. But both now provide enough specificity that organizations can build a concrete, defensible baseline without significant interpretive guesswork.

The Significant Overlap: Where One Program Covers Both

The most efficient compliance strategy starts with identifying the shared requirements and building one baseline that satisfies both. The overlap between NYDFS and the FTC Safeguards Rule is substantial, and it covers the areas where the most operational investment is required.

Risk Assessment and Risk Management

Both rules require formal, ongoing risk assessment. Neither accepts a point-in-time snapshot treated as a permanent answer. You need a living process that identifies risks across systems, data types, vendor relationships, and business operations, tracks changes over time, and connects assessment findings to remediation priorities.

A practical approach is to maintain a single enterprise risk assessment methodology that applies to both nonpublic information and regulated systems under NYDFS, and to customer information flows under the FTC rule. Feed that assessment into a risk treatment plan with named owners, documented timelines, and audit evidence. When the assessment process is genuinely integrated, it becomes the foundation that justifies every control decision in the program.

Governance and Leadership Accountability

Both regimes require clear ownership and leadership visibility. NYDFS places particular emphasis on senior accountability, requiring a designated Chief Information Security Officer (CISO) function, annual compliance certification involving senior leadership, and board reporting on cybersecurity matters. The FTC requires a qualified individual to oversee the program and expects regular reporting to leadership and the board or equivalent governing body.

A governance structure that satisfies both typically includes:

A clearly designated security program owner with defined authority and organizational access
A consistent leadership reporting cadence with documented minutes or summaries
Defined escalation thresholds for major risk decisions and incident events
Documented decision records for risk acceptance, exceptions, and program changes

Access Controls and Authentication

Credential abuse is one of the most reliable attack paths against financial services organizations, and both frameworks address it directly. NYDFS requires multi-factor authentication for remote access and for any access to nonpublic information. The FTC Safeguards Rule requires MFA or functionally equivalent controls for accessing customer information.

A baseline access control program that satisfies both includes:

Least privilege and role-based access for systems handling regulated data
Multi-factor authentication for remote access, privileged accounts, and customer data systems
Privileged access management controls, even at a basic level for smaller organizations
Regular access reviews for critical platforms, conducted at least annually
Prompt offboarding procedures that remove access within defined timeframes after termination

Encryption and Data Protection

Encryption appears prominently in both frameworks, and for good reason. When customer financial information is exposed, whether through a lost device, a cloud misconfiguration, or a stolen backup, encryption can mean the difference between a reportable breach and a contained incident.

A practical encryption baseline for compliance with both frameworks includes:

Encryption in transit for all external connections and, where feasible, internal service-to-service communication
Encryption at rest for endpoints, servers, databases, cloud storage, and backup media containing customer information
Documented exception handling with compensating controls for systems where full encryption is not immediately feasible
Key management practices that prevent encryption from becoming a checkbox exercise

Encryption status is specifically relevant to how FTC breach reporting is analyzed. The FTC notification event definition focuses in part on whether information was acquired in unencrypted form. Maintaining strong encryption coverage directly reduces breach notification exposure under the FTC rule.

Incident Response Planning and Testing

Both regimes expect real incident response capability. Not a printed plan in a binder, but a practiced, tested function that can actually operate under pressure.

A single incident response program that satisfies both frameworks includes:

Clear role assignments, including an incident commander and a designated compliance reporting owner
Playbooks for high-probability scenarios: ransomware, data exposure, third-party incidents, and credential compromise
Evidence preservation procedures that support investigations and regulatory reporting without being disrupted by remediation activities
Annual tabletop exercises with documented lessons learned and follow-up actions
Backup and recovery testing, with documented recovery time validation

The critical design requirement is that incident response must be directly connected to regulatory reporting workflows. The reporting requirements under NYDFS and the FTC are different, and both require specific triggers and timelines to be embedded in the response process, not bolted on afterward.

Service Provider and Vendor Oversight

Third-party risk is a shared compliance priority under both NYDFS and the FTC Safeguards Rule. Vendors who handle customer information or provide critical services are part of your regulatory risk perimeter, regardless of where they sit in your organizational chart.

A shared baseline approach to vendor oversight includes:

Security due diligence as a standard step before onboarding any vendor handling regulated data
Contract provisions requiring minimum security controls, breach notification obligations, and audit rights
Ongoing monitoring for high-risk and high-impact vendors, calibrated to the sensitivity of what they access
A vendor incident escalation workflow that feeds directly into your internal incident response process

Vendor notification timing is a place where the NYDFS 72-hour clock can become acutely painful if vendor contracts do not include fast notification requirements. If you discover that a vendor was breached through a public news report rather than a direct notification, that gap will cause real problems in meeting regulatory timelines.

The Differences That Require Separate Workflows

Building one program means recognizing where the two frameworks genuinely diverge and building specific workflow branches for those areas. There are three differences that matter most in practice.

Difference 1: Reporting Timelines Are Fundamentally Different

NYDFS operates on an aggressive notification timeline. Covered entities must notify NYDFS within 72 hours of determining that a cybersecurity incident has occurred, using the definition and criteria established in Section 500.17 of the regulation. That 72-hour clock begins at determination of the incident, not at full forensic confirmation.

NYDFS also has a separate extortion payment reporting requirement that has no direct equivalent in the FTC rule. If a covered entity makes an extortion payment in connection with a cybersecurity event, it must notify NYDFS within 24 hours of making that payment. Within 30 days of the payment, a written explanation is required covering why payment was necessary, what alternatives were considered, and what due diligence was performed on the recipient. This requirement means that ransomware payment decisions cannot be treated as purely operational choices. They carry immediate regulatory consequences.

The FTC breach notification requirement works on a different logic entirely. It requires notifying the FTC within 30 days of discovering a notification event, which is defined as unauthorized acquisition of unencrypted customer information affecting 500 or more consumers. The FTC reporting trigger is consumer data focused and threshold-based. It requires an assessment of what information was accessed, whether it was encrypted, and how many consumers were affected.

The practical consequence is this: if your incident response program is designed to meet FTC timing, it may be too slow to meet NYDFS reporting expectations. If it is designed to meet NYDFS timing, meeting the FTC timeline is straightforward. Build to the faster standard.

Difference 2: Ransomware Is Framed Very Differently

NYDFS treats ransomware deployment as an event that can trigger the incident definition and reporting requirements quickly, even when the primary impact is operational disruption rather than confirmed data exfiltration. The operational focus of the regulation means that significant system encryption or disruption can move an organization toward a notification determination faster than many teams expect.

The FTC Safeguards Rule does not treat ransomware as a distinct category. Its notification event framework is focused on whether customer information was acquired, whether it was unencrypted, and whether the 500-consumer threshold is met. A ransomware event can absolutely become FTC-reportable, but the analysis path runs through data access and encryption status rather than operational disruption.

During an active ransomware incident, these two frameworks pull in different analytical directions. NYDFS pushes toward fast operational impact assessment and regulatory notification. The FTC framework pushes toward detailed data exposure analysis. Both analyses need to happen, and they need to run in parallel rather than sequentially.

Difference 3: Documentation Discipline and Annual Certification

NYDFS treats documentation as a first-class compliance requirement. Covered entities must maintain evidence of their program on an ongoing basis and must submit an annual certification or acknowledgment of compliance to NYDFS. That certification is signed by a senior officer, which means executive credibility is directly on the line. Organizations that treat evidence collection as an annual scramble find this process very uncomfortable.

The FTC rule also requires a written program, documented risk assessments, and evidence of implemented safeguards. But it does not replicate the annual certification mechanism or the same level of ongoing evidence collection discipline that NYDFS imposes.

If NYDFS applies to any part of your organization, the most practical approach is to build continuous evidence collection into routine operations across the entire program. Log reviews, access certifications, vendor assessments, penetration test results, training completion records, and governance meeting notes should all be collected and retained as a matter of standard workflow. When evidence collection is a regular habit rather than a compliance event, annual certification becomes a review exercise rather than a reconstruction project.

How to Build One Program That Covers Both Without Duplicating Work

The following approach works well for organizations that need to operate under both frameworks without building and maintaining two separate compliance programs.

Step 1: Map Regulatory Scope Once and Document It

Before anything else, create a clear written scope map that identifies which systems, data flows, and business processes fall under NYDFS because they support a DFS-regulated entity, which fall under the FTC Safeguards Rule because they involve customer information handled by an FTC-covered business line, and which are shared infrastructure used by both.

Most organizations discover quickly that core infrastructure, including identity systems, endpoint management, email, cloud platforms, network controls, and vendor management functions, is genuinely shared. That is where standardized controls deliver the most leverage.

Step 2: Adopt NYDFS Timelines as the Internal Standard

Set your internal incident escalation discipline to operate as if NYDFS timelines apply across the entire program, even for business lines that are only subject to the FTC rule. This eliminates confusion during incidents where multiple regulatory obligations may be in play, and ensures that the slower FTC timelines are automatically satisfied as a byproduct of meeting the faster NYDFS standard.

In practical terms, this means your program must be able to determine incident reportability within hours, produce a regulator-ready incident summary rapidly, handle ransomware payment decisions with an immediate 24-hour notification trigger for NYDFS-covered entities, and receive vendor breach notifications fast enough to meet the 72-hour reporting clock. Vendor notification timing should be baked into contracts before you need it, not negotiated during an active incident.

Step 3: Build and Maintain a Shared Baseline Control Set

Standardize one control baseline that satisfies the core requirements of both frameworks. The shared baseline should cover:

Written risk assessment and documented risk treatment tracking
Identity and access management with multi-factor authentication
Encryption in transit and at rest for customer and nonpublic information
Centralized logging and security monitoring
Vulnerability management and patch discipline with defined timelines
Incident response playbooks covering ransomware, data exposure, and third-party events
Backup and recovery testing with documented results
Vendor due diligence, contract requirements, and incident notification obligations
Annual security awareness training with completion tracking
Governance reporting and documented decision records

This baseline satisfies both regimes. The regulatory-specific workflows are additive layers on top of it.

Step 4: Build an FTC Breach Assessment Routine

Because FTC reporting is tied to a specific notification event definition, your program needs a repeatable assessment routine that can answer the following questions quickly when a potential incident is identified:

Was customer information involved in the event?
Was any of that information unencrypted at the time of the unauthorized access?
How many consumers were potentially affected?
Does the event meet the 500-consumer threshold that triggers FTC notification?
If notification is required, can the team assemble the required report content accurately within 30 days of discovery?

This routine should be documented, tested in tabletop exercises, and reviewed against updated FTC guidance at least annually.

Step 5: Add NYDFS-Specific Reporting and Extortion Payment Workflows

NYDFS adds two operational workflows that need to be built into incident response as standing procedures, not improvised during events.

The first is the 72-hour incident notification workflow. This requires a designated notification owner with authority to submit the report, a clear determination process for when an event meets the NYDFS incident definition, and a pre-built reporting template that can be populated quickly under time pressure.

The second is the extortion payment compliance workflow. The moment a ransomware payment is authorized or executed, the notification clock begins. The compliance reporting owner must be in any conversation where payment is being considered, not informed afterward. The 24-hour notification to NYDFS and the subsequent 30-day written explanation should both be templated in advance so that the reporting function can execute without building the process from scratch during a crisis.

The Scenario That Tests Everything: Ransomware With a Payment Decision

Ransomware incidents under both frameworks represent the highest-complexity compliance scenario, and they deserve specific attention.

When ransomware hits, the organization faces simultaneous pressure on multiple fronts. Systems may be offline. Customers may be affected. Recovery costs are mounting. Leadership is asking about payment options. Legal counsel, cyber insurers, and professional negotiators may all be involved in decisions that are moving quickly.

Under NYDFS, the operational disruption itself can trigger the incident definition and reporting timeline. If a payment is made, a separate 24-hour notification is required regardless of what else is happening in the incident. That clock does not pause for recovery operations or payment negotiations.

Under the FTC Safeguards Rule, the focus shifts to data exposure analysis. Was customer information on the encrypted systems? Was it in an unencrypted form that an attacker could have accessed? How many consumers were potentially affected? These questions often cannot be answered quickly during the acute phase of a ransomware response, but they must be pursued in parallel with recovery efforts.

The organizations that handle ransomware compliance well are the ones whose incident response programs include explicit procedures for both the NYDFS operational reporting workflow and the FTC data exposure assessment workflow, and whose compliance reporting owner is in every conversation where a payment decision might be made.

What Audit-Ready Looks Like Under Both Frameworks

Neither NYDFS nor the FTC expects perfect security. Both expect reasonable, documented, and consistently operating security controls. Organizations that are genuinely audit-ready typically can demonstrate the following:

A current written information security program with clear scope and governance structure
A documented risk assessment conducted within the past 12 months, with evidence of how findings were addressed
Access control records showing least privilege enforcement, MFA coverage, and regular access reviews
Encryption coverage documentation with exception tracking
Logging and monitoring configuration evidence
Incident response plans with proof of annual testing, such as tabletop exercise reports or after-action reviews
Vendor oversight records, including due diligence files, contract provisions, and ongoing monitoring documentation
Training completion records for all relevant personnel
Leadership and board reporting evidence, such as meeting materials or documented briefing records
A clear regulatory notification workflow for both NYDFS and FTC reporting triggers

Organizations that collect this evidence as a routine part of operations, rather than assembling it in a rush before an audit, experience significantly less pain during regulatory examinations and respond to examiner inquiries much more quickly and confidently.

One Program, Two Regulators, and a More Defensible Security Posture

The practical path forward for organizations navigating both NYDFS 23 NYCRR 500 compliance and FTC Safeguards Rule compliance is not to build two programs. It is to build one program that is calibrated to the more demanding framework and extended with specific workflows for the areas where the requirements genuinely differ.

Build your baseline to NYDFS standards. Its faster timelines, stronger documentation discipline, and explicit executive accountability requirements will naturally carry you into compliance with the FTC’s expectations in the areas where they overlap. Then layer on the FTC-specific breach assessment logic and reporting threshold analysis as documented routines within your existing incident response framework.

What you end up with is not just a compliance program. It is a security program that can operate with real discipline when things go wrong, produce evidence quickly when regulators ask for it, and respond to incidents without improvising the process at the worst possible moment. That is the real value of getting this right.

References

New York Department of Financial Services, Cybersecurity Resource Center (Part 500 guidance and current timelines): https://www.dfs.ny.gov/industry_guidance/cybersecurity

NYDFS 23 NYCRR Part 500 Second Amendment text (Section 500.17 incident notification and extortion payment notice): https://www.dfs.ny.gov/industry_guidance/regulations/final_adoptions_fs/rf_fs_2amend23NYCRR500_text_20231101_alt

Federal Trade Commission, FTC Safeguards Rule: What Your Business Needs to Know: https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know

FTC Press Release on Safeguards Rule deadline extension and updated requirements: https://www.ftc.gov/news-events/news/press-releases/2022/11/ftc-extends-deadline-six-months-compliance-some-changes-financial-data-security-rule

Federal Register, Standards for Safeguarding Customer Information (Safeguards Rule breach reporting amendment): https://www.federalregister.gov/documents/2023/11/13/2023-24412/standards-for-safeguarding-customer-information

FTC Business Blog, Safeguards Rule notification requirement now in effect: https://www.ftc.gov/business-guidance/blog/2024/05/safeguards-rule-notification-requirement-now-effect

eCFR, 16 CFR Part 314 Standards for Safeguarding Customer Information (full regulatory text): https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314

Add to Preferred Sources

Need help reducing your business security risk?