NYDFS Encryption of Nonpublic Information

NYDFS 23 NYCRR § 500.15 requires covered entities to protect Nonpublic Information by implementing controls, including encryption, for data both in transit over external networks and at rest (23 NYCRR Part 500). To operationalize it, you need a complete data inventory, clear encryption standards, enforced technical controls, and documented CISO-approved compensating controls where encryption at rest is infeasible.

Key takeaways:

• Encrypt Nonpublic Information in transit over external networks and at rest, as a default control (23 NYCRR Part 500).
• If you cannot encrypt data at rest, document effective compensating controls and obtain written CISO approval with rationale (23 NYCRR Part 500).
• Evidence matters: examiners look for technical enforcement, scope clarity, and repeatable governance, not just policy language (23 NYCRR Part 500).

“NYDFS encryption of nonpublic information requirement” is straightforward on paper and easy to get wrong in execution. Under 23 NYCRR § 500.15, the operative challenge is scope: identifying where Nonpublic Information is held or transmitted, then proving that encryption controls are actually enforced across systems, networks, endpoints, and third parties (23 NYCRR Part 500).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a control system with three deliverables: (1) an authoritative inventory of Nonpublic Information data stores and flows, (2) a standard that specifies approved encryption methods and where they must be used, and (3) technical configuration evidence showing the standard is implemented (or that approved compensating controls exist when encryption at rest is infeasible) (23 NYCRR Part 500).

This page translates § 500.15 into requirement-level steps you can assign to Security, Infrastructure, Application Engineering, and Procurement/Third-Party Risk. It also tells you what artifacts to retain so you can answer exam questions without scrambling.

Regulatory text

Regulatory requirement (excerpt): “Each covered entity shall implement controls, including encryption, to protect nonpublic information held or transmitted by the covered entity both in transit over external networks and at rest.” (23 NYCRR Part 500)

Operator interpretation:
You must (a) identify Nonpublic Information (NPI), (b) know where it is stored and how it moves, and (c) enforce encryption for NPI at rest and for NPI transmitted over external networks (23 NYCRR Part 500). Where encryption at rest is infeasible, you can use effective alternative compensating controls, but you need written CISO approval and documented rationale (23 NYCRR Part 500).

Plain-English meaning (what the rule is really asking)

• Encryption is the default. If NPI exists in a system, encryption should be on unless there is a documented exception (23 NYCRR Part 500).
• “In transit over external networks” is a specific trigger. Any time NPI crosses an external boundary (internet, third-party connections, cloud egress, remote access paths), the expectation is encrypted transport (23 NYCRR Part 500).
• “At rest” includes more than databases. Backups, object storage, file shares, SaaS data exports, endpoint caches, and log stores that contain NPI are in scope (23 NYCRR Part 500).
• Exceptions are allowed only for encryption at rest, not as a general preference. If you claim infeasibility, you need compensating controls and written CISO approval with rationale (23 NYCRR Part 500).

Who it applies to (entity and operational context)

This requirement applies to NYDFS “covered entities” under the Cybersecurity Regulation, including financial institutions and state-registered advisers in scope of 23 NYCRR Part 500 (23 NYCRR Part 500).

Operationally, it applies anywhere your organization:

• Stores NPI: core systems, data warehouses, file shares, email archives, backups, endpoint devices, and cloud storage (23 NYCRR Part 500).
• Transmits NPI over external networks: customer portals, APIs, SFTP transfers, third-party integrations, remote access, and cloud-to-on-prem connectivity (23 NYCRR Part 500).
• Uses third parties that touch NPI: SaaS platforms, managed service providers, claims processors, payment processors, call centers, and consultants handling NPI on your behalf (23 NYCRR Part 500).

What you actually need to do (step-by-step)

Step 1: Define and scope Nonpublic Information for encryption

1. Adopt an internal NPI definition aligned to Part 500 and map it to your data classification scheme (e.g., “NPI = Confidential/Restricted”).
2. List NPI data elements and record types you actually process (account data, ID documents, policy records, client communications, etc.).
3. Decide what “held or transmitted” means operationally for your environment: production, non-production, backups, logs, analytics copies, and exports should be explicitly addressed (23 NYCRR Part 500).

Deliverable: a one-page NPI encryption scope statement that Security and Engineering can implement against.

Step 2: Build a defensible inventory of where NPI is stored and how it moves

1. Data stores: Identify systems of record and downstream replicas (databases, warehouses, object stores, file systems, email platforms).
2. Data flows: Map transfers across external networks (customer access, third-party integrations, batch file transfers, APIs).
3. Endpoints and removable media: Confirm whether NPI can land on laptops, mobile devices, or portable storage; if yes, include endpoint encryption controls.
4. Third parties: Identify all third parties that store/process/transmit your NPI and confirm contract/security requirements align to encryption expectations (23 NYCRR Part 500).

Practical tip: Most teams move faster by starting with the top NPI-heavy systems and working outward, but keep a living inventory so “unknown stores” shrink over time.

Deliverable: NPI data inventory + data flow map (even a spreadsheet plus architecture diagrams is acceptable if maintained and owned).

Step 3: Set encryption standards you can enforce

Write a standard that answers:

• Where encryption is mandatory (NPI at rest; NPI in transit over external networks) (23 NYCRR Part 500).
• Approved encryption approaches by platform type (database, object storage, file storage, backups, endpoints, SaaS).
• Key management expectations (ownership, rotation approach, access controls, separation of duties, and logging). Part 500 requires encryption, but examiners commonly test whether key control undermines encryption’s value; treat key management as part of the control.
• Certificate/TLS management for transport encryption (certificate issuance, renewal, deprecated protocols handling).

Deliverables: Encryption standard, key management standard, and exception procedure (with CISO sign-off workflow).

Step 4: Implement and validate encryption in transit (external networks)

Execution checklist:

• Customer-facing web apps and portals: enforce HTTPS/TLS; disable insecure ciphers/protocols as your baseline.
• APIs: require TLS for all external API traffic; ensure mTLS where your risk assessment requires it.
• File transfers: replace plaintext FTP with SFTP/FTPS or encrypted tunnels; validate configuration and authentication.
• Remote access: enforce encrypted channels for VPN/zero trust access paths.

Validation evidence:

• Configuration exports or screenshots for TLS enforcement at ingress points (load balancers, API gateways).
• Network diagrams showing external boundaries and encryption points.
• Test results from internal scans or configuration checks.

Step 5: Implement and validate encryption at rest

Execution checklist by common storage types:

• Databases: enable native encryption-at-rest capabilities and restrict access to keys/secrets.
• Object storage and file shares: enforce server-side encryption and block unencrypted writes where the platform supports it.
• Backups: ensure backup media and backup destinations are encrypted; confirm encryption persists through export/offsite processes.
• Endpoints: require full-disk encryption where endpoints can store NPI.
• Logs/telemetry: if logs contain NPI, treat the log store as in-scope for encryption at rest.

Validation evidence:

• System settings and policy enforcement proof (for example, cloud policies that deny unencrypted storage objects).
• Reports showing coverage across accounts/subscriptions/environments.
• Backup configuration evidence.

Step 6: Handle “infeasible” encryption at rest via compensating controls (formal exception)

If a team claims encryption at rest is infeasible:

1. Require a written justification explaining what is infeasible and why (technical limitation, legacy constraints, operational impact).
2. Define compensating controls that materially reduce risk (tight access control, segmentation, monitoring, DLP, tokenization, strong key protection around any partial encryption features, etc.).
3. Get CISO approval in writing and retain the rationale (23 NYCRR Part 500).
4. Add an end-state plan to remove the exception (system upgrade, platform migration), with governance tracking.

Deliverable: CISO-approved exception record with compensating controls and rationale (23 NYCRR Part 500).

Step 7: Prove it stays enforced

• Add encryption checks to change management (new system onboarding, new storage provisioning).
• Add encryption signals to continuous monitoring (alerts for unencrypted resources, certificate expiry, misconfigurations).
• Add third-party due diligence checks for encryption where third parties process your NPI (23 NYCRR Part 500).

If you use Daydream to manage third-party risk and control evidence, treat encryption as a standard control requirement for any third party handling NPI: collect encryption attestations, architecture notes, and contract clauses, and track exceptions with CISO approval artifacts.

Required evidence and artifacts to retain

Keep artifacts that prove scope, enforcement, and governance:

Governance

• Encryption policy/standard covering at rest and in transit over external networks (23 NYCRR Part 500)
• Data classification/NPI definition and scope statement
• Exception procedure and CISO written approvals with rationale (23 NYCRR Part 500)

Technical evidence

• Inventory of NPI repositories and data flows
• System configuration evidence for encryption at rest ¹
• Transport encryption configuration evidence (TLS configs, gateway settings)
• Key management documentation (roles, access controls, logging)
• Monitoring/alerting evidence for encryption drift (reports, tickets)

Operational evidence

• Change management records showing encryption requirements are gating controls
• Third-party contracts/security addenda requiring encryption for NPI handled by third parties (23 NYCRR Part 500)
• Periodic control testing results (internal checks, audit reports)

Common exam/audit questions and hangups

Expect questions like:

• “Show me where NPI is stored and confirm each location is encrypted at rest.” (23 NYCRR Part 500)
• “How do you ensure NPI is encrypted when transmitted over external networks?” (23 NYCRR Part 500)
• “Do any systems store NPI without encryption at rest? If yes, show CISO approvals and compensating controls.” (23 NYCRR Part 500)
• “How do you manage encryption keys, and who can access them?”
• “How do you prevent engineers from provisioning unencrypted storage?”
• “How do you ensure third parties encrypt NPI you share with them?” (23 NYCRR Part 500)

Hangups that slow teams down:

• No single owner for the NPI inventory.
• Confusion between “encryption available” and “encryption enforced.”
• Exceptions that exist informally in tickets but lack CISO written approval (23 NYCRR Part 500).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Policy-only compliance.
   Fix: Pair policy with technical controls that block noncompliant deployments and produce logs/screenshots/reports as evidence.

2. Mistake: Missing backups and exports.
   Fix: Treat backup targets and data export pipelines as first-class data stores in your NPI inventory.

3. Mistake: Encrypting storage but exposing keys broadly.
   Fix: Lock down key access to a small set of roles, log key operations, and require change control for key policy changes.

4. Mistake: Treating “in transit” as only web traffic.
   Fix: Include batch transfers, partner connections, remote admin paths, and API integrations that cross external networks (23 NYCRR Part 500).

5. Mistake: Uncontrolled exceptions.
   Fix: Create a formal exception register with CISO written approvals and compensating controls; review exceptions routinely (23 NYCRR Part 500).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog, so this page does not cite specific NYDFS actions. Practically, encryption findings tend to escalate when examiners see weak scope control (unknown NPI locations), inconsistent implementation across environments, or undocumented exceptions. Treat encryption as a measurable control: you should be able to show coverage, drift detection, and approvals for any gaps (23 NYCRR Part 500).

Practical execution plan (30/60/90)

You asked for a plan you can run quickly; use phases rather than calendar promises.

Immediate (stabilize scope and stop the bleeding)

• Assign a single accountable owner for the NPI encryption program (GRC + Security).
• Publish the NPI encryption scope statement and encryption standard (23 NYCRR Part 500).
• Implement hard requirements for transport encryption on all external entry points (23 NYCRR Part 500).
• Start an exception register and require CISO written approval for any encryption-at-rest infeasibility claims (23 NYCRR Part 500).

Near-term (cover the major data stores and prove enforcement)

• Complete a first-pass inventory of NPI repositories and external data flows.
• Encrypt at rest for top NPI systems (systems of record, major object stores, primary backups).
• Implement preventive controls where possible (deny unencrypted storage creation; enforce baseline templates).
• Begin collecting durable evidence packets per platform (configs, reports, screenshots, tickets).

Ongoing (close gaps, harden key management, operationalize monitoring)

• Expand inventory to long-tail apps, analytics copies, legacy file shares, and log stores.
• Mature key management controls and access governance.
• Add continuous monitoring for encryption drift and certificate hygiene.
• Integrate third-party encryption requirements into onboarding and periodic reviews (Daydream can centralize evidence and exception tracking across third parties) (23 NYCRR Part 500).

Frequently Asked Questions

Does NYDFS require encryption for all data, or only Nonpublic Information?

23 NYCRR § 500.15 is scoped to Nonpublic Information held or transmitted by the covered entity (23 NYCRR Part 500). You can still encrypt broader datasets as a policy choice, but your compliance proof must cover NPI at rest and in transit over external networks.

What counts as “in transit over external networks”?

Treat it as any transmission of NPI that crosses outside your internal network boundary, including internet-facing apps, partner connections, and third-party integrations (23 NYCRR Part 500). Document your boundary assumptions in your data flow map so your interpretation is consistent.

Can we use compensating controls instead of encrypting data at rest?

Yes, but only where encryption at rest is infeasible, and you need effective compensating controls approved in writing by the CISO with documented rationale (23 NYCRR Part 500). Keep the approval and the rationale with your exception record.

If our cloud provider encrypts storage by default, is that enough?

It can be, if you can prove encryption is enabled and enforced for the specific services storing NPI, and that your configurations prevent unencrypted deployment paths. Audits typically ask for account-level or tenant-level enforcement evidence, not a marketing statement.

Do backups and replicas fall under “at rest” encryption expectations?

Yes if they contain Nonpublic Information, because they are “held” by the covered entity (23 NYCRR Part 500). Backups are a common gap; ensure encryption persists through export, offsite storage, and restore workflows.

How should we handle third parties that store or process our NPI?

Treat them as in-scope for your NPI protection program and require encryption commitments and evidence through third-party due diligence and contracting (23 NYCRR Part 500). Track their responses, exceptions, and remediation plans in a system that supports ongoing monitoring, such as Daydream.

Footnotes

1. 23 NYCRR Part 500