NYDFS 500 & PCI DSS Compliance for New York Payment Companies
In January 2025, the New York State Department of Financial Services (NYDFS) settled a cybersecurity enforcement action against PayPal, Inc. for $2 million. The claim centered on a single incident from December 2022, one that exposed the personal information of nearly 35,000 PayPal customers and traced back to a change PayPal was legally required to make.
On December 6, 2022, a PayPal security analyst found a message posted online: “PP EXPLOIT TO GET SSN,” with a link to PayPal’s own site. Within a day, PayPal’s cybersecurity team confirmed threat actors were using credential stuffing to access the exposed forms at scale.
NYDFS’s investigation found the root cause sitting further upstream than the exposed data itself. The team responsible for the 1099-K change had classified it as a routine platform migration rather than a new product capability, a classification that meant no risk assessment, penetration test, or vulnerability scan ever touched the change before it went live. It is exactly the kind of governance gap NYDFS’s cybersecurity regulation, 23 NYCRR Part 500, was built to catch, and exactly the kind of gap that resurfaces across nearly every NYDFS settlement on record, including two more recent cases, at Healthplex and Delta Dental, that we’ll get to shortly.
What makes PayPal’s case worth a closer look isn’t the breach itself. It’s what PayPal was already required to comply with when it happened and how that same requirement quietly overlaps with a second compliance regime most payment companies treat as entirely separate.
Inside the consent order
The exposure traces back to a change PayPal was legally required to make. In 2021, the American Rescue Plan Act lowered the reporting threshold for Form 1099-K, meaning far more PayPal customers now qualified to receive one. PayPal’s engineering team built the update to its data flows to meet that requirement, and the change went live on October 18, 2022.
The consent order’s finding is specific about what went wrong in the build process. Under PayPal’s own change management policy, any new capability or feature for an existing product triggers a Risk and Control Identification Process (RCIP), a mandatory review, test, and approval step before launch. The team responsible for the 1099-K change classified it instead as a routine platform migration, a category that does not require RCIP, and the classification error meant no risk assessment, penetration test, or vulnerability scan touched this change before it reached production.
That single misclassification cascaded. Multi-factor authentication (MFA) was optional rather than required on the accounts later compromised. No one on the reviewing side flagged that the updated forms displayed Social Security numbers in plain text. The change management process that was supposed to ask “does this touch sensitive data, and has someone signed off on it” never fired, because the system depended on a human correctly tagging the change by hand.
What NYDFS 500 was built to prevent
New York’s cybersecurity regulation predates this incident by five years. It took effect in March 2017, written explicitly to avoid being overly prescriptive about how a regulated entity protects data, so that cybersecurity programs could keep pace with changing risk and technology. The regulation asks for outcomes, a qualified security team, effective access controls, a documented asset inventory, and leaves the implementation method to the entity.
The 2023 amendment to Part 500, which took effect that November, sharpened several of those outcome requirements. Governance obligations expanded, access-prevention controls tightened, and risk assessment and incident response planning both became more frequent and more formal. One of the least publicized additions was Section 500.13, which requires every covered entity to build and maintain a documented, current inventory of its information systems, tracking each asset’s owner, location, classification, support expiration date, and recovery time objective.
PayPal’s failure was not a missing firewall or an unpatched server. It was a governance gap: a change to a production system went live without anyone confirming what that system touched, who owned the sign-off, or what data classification applied. Section 500.13 exists precisely to close that gap, by requiring the kind of standing, current asset record that would have made “is this a new capability touching NPI, or a routine migration” answerable by lookup rather than by a team’s memory.
One map, two zoom levels
PayPal’s obligations did not end with NYDFS. As a company processing card payments, it also falls under PCI DSS, the card networks’ own security standard, enforced through processor and acquirer contracts rather than government statute. PCI DSS Requirement 12.5 requires an entity to maintain a current inventory of every system component within its cardholder data environment (CDE), reviewed at least once every 12 months and confirmed after any significant change.
The two inventory mandates are not competitors; they are nested. NYDFS Section 500.13 requires an inventory covering the entity’s entire information systems environment. PCI DSS Requirement 12.5 requires an inventory covering only the subset of that environment that touches cardholder data, the CDE. For a company like PayPal, licensed in New York and processing cards, the cardholder data environment sits inside the broader NYDFS-covered environment, the same way a room sits inside a building.
One current, well-tagged asset and service map, a configuration management database, or CMDB built to satisfy the broader NYDFS standard already contains the narrower PCI-scoped subset within it. It does not eliminate the PCI assessment process. A Qualified Security Assessor will still want the CDE pulled out on its own confirmation cycle, with data flow diagrams specific to card data. But the underlying system of record does not need to be built and maintained twice.
The same map, now for disclosure
Asset inventory is the standing, day-to-day compliance axis. A separate axis activates only when an actual incident occurs: who has to be told, and how fast.
NYDFS Section 500.17(a) requires a covered entity to notify the superintendent within 3 days of determining that a cybersecurity incident has occurred, once either of two thresholds is met: notice was required to some other government or supervisory body, or the incident has a reasonable likelihood of materially harming normal operations. There is no discretion in the clock itself; once the threshold is crossed, the 72 hours starts.
The SEC’s parallel rule works differently. Item 1.05 of Form 8-K, which became mandatory for large registrants on December 18, 2023, requires public companies to disclose a cybersecurity incident within four business days, but only if the company itself determines the incident is material to investors. That determination is a judgment call, made without a fixed timeline, and a company can conclude an incident does not clear the bar at all. When that happens, no 8-K is filed, and none is required.
NYDFS asks a factual question: did this happen, does it meet the threshold, and the clock is automatic once the answer is yes. The SEC asks a business-impact question, and the clock only starts if the company’s own judgment says yes. The same incident, at the same company, on the same day, can trigger one regulator’s notification requirement while legitimately clearing none of the other’s disclosure bar. Neither outcome is a failure of process; they are two different tests, run against two different questions, both pulling from the same underlying facts about what happened and what was exposed.
NYDFS 500, the deep dive
Part 500 applies to any entity operating under a license, registration, charter, certificate, permit, or similar authorization issued under New York’s Banking Law, Insurance Law, or Financial Services Law. In practice, that covers banks, insurers, mortgage lenders, money transmitters, and virtual currency businesses, anyone NYDFS licenses, regardless of whether they are also regulated federally.
The regulation’s core requirements run across sixteen operative sections: a written cybersecurity program and policy based on a documented risk assessment; a designated Chief Information Security Officer (CISO) who reports at least annually to the entity’s governing body; access privilege limits and periodic access reviews; MFA across nearly all systems as of the November 2025 phase-in; a complete asset inventory under Section 500.13; encryption of nonpublic information (NPI) in transit and at rest; and incident response, business continuity, and disaster recovery plans, tested at least annually.
Annual certification is due every April 15, either confirming full compliance or disclosing specific gaps with a remediation timeline. NYDFS has been explicit that a partial, honest certification carries less regulatory risk than a false claim of full compliance, a distinction that matters for any covered entity weighing whether to disclose a known weakness or paper over it.
What non-compliance costs
Section 500.20 gives NYDFS wide latitude in setting penalties, with no fixed cap. The regulation instead lists the factors the superintendent weighs: the entity’s cooperation during investigation, whether the violation was inadvertent or willful, the entity’s history of prior violations, the extent of consumer harm, and whether required disclosures were made accurately and on time.
The dollar figures already on the record give a sense of scale. PayPal paid $2 million for the 2022 incident. Healthplex paid the same amount in August 2025 for a phishing-driven breach compounded by a four-month delay in notifying NYDFS, well past the 72-hour requirement. Delta Dental paid $2.25 million in April 2026 for a MOVEit-related breach where the underlying failure was a data retention gap combined with a similarly delayed notification. None of these penalties came from a single catastrophic technical failure; each traces back to a documented governance or process gap that existed before the breach occurred.
The infrastructure answer
None of these settlements describe a company that lacked cybersecurity tools. They describe companies where the map of what existed, who owned it, and what it touched was incomplete, outdated, or dependent on someone remembering to check it. A CMDB is the system of record that keeps that map current by design rather than by memory: every asset tagged with an owner, a classification, a support status, and a change history that survives staff turnover and reorganizations.
For a New York-licensed entity processing cards, that same map does double duty. The NYDFS-scoped inventory required under Section 500.13 already contains the narrower PCI-scoped cardholder data environment inside it, and the incident response and business continuity plans required under Section 500.16 draw on the same asset data that any SEC materiality determination would need first. Virima’s platform maintains that map through high-frequency scheduled discovery across on-premises, AWS, and Azure environments, tracking Kubernetes pods, services, and config maps as configuration items alongside traditional infrastructure, giving a compliance team one current source of truth to pull from, whichever regulator is asking.
See how a CMDB built for NYDFS 500.13 and PCI DSS 12.5 can serve both regulators from a single, authoritative source. Explore Trusted Runtime Truth.
