meilynx

Reference · Cybersecurity

23 NYCRR 500.13: Asset Management and Data Retention

Asset management and data retention requirements

Last reviewed August 14, 2026

Section 500.13 of the NYDFS Cybersecurity Regulation requires covered entities to maintain a documented inventory of their information systems and to securely dispose of nonpublic information that is no longer needed. Unlike much of Part 500, it is prescriptive: it names the fields the inventory must carry.

Who it applies to

Covered entities — any person or organisation operating under a license, registration, charter, or similar authorisation under New York Banking Law, Insurance Law, or Financial Services Law. NYDFS supervises more than 3,000 such institutions. Non-U.S. banks licensed to operate in New York are included.

What it requires: 500.13(a) — asset inventory

  • Written policies and procedures for producing and maintaining a complete, accurate, documented inventory of information systems.
  • Tracking, for each asset, of key information including owner, location, classification or sensitivity, support expiration date, and recovery time objectives.
  • A defined frequency for updating and validating the inventory.

What it requires: 500.13(b) — secure disposal

  • Policies and procedures for the secure disposal, on a periodic basis, of nonpublic information as defined in section 500.1 that is no longer necessary for business operations or other legitimate business purposes.
  • Two exceptions: where the information is otherwise required to be retained by law or regulation, and where targeted disposal is not reasonably feasible due to the manner in which the information is maintained.
The second exception is narrow and load-bearing. It excuses disposal that is genuinely infeasible given how data is stored — it does not excuse an institution that never built the capability. Where AI systems copy nonpublic information into prompts, embeddings, caches, or logs, the practical question is whether the institution can locate and dispose of it at all.

Control mapping

What a reviewer expects to be able to see.

ObligationWhat the system must doEvidence a reviewer expects
Asset inventoryMaintain a documented inventory of information systems, explicitly identifying those handling nonpublic informationInventory export with all required fields populated
Required fieldsRecord owner, location, classification, support expiration date, and recovery time objective per assetField-level completeness report and exception list
Validation cadenceUpdate and validate on a defined, documented schedulePolicy stating the cadence, plus evidence of validation runs
Disposal policyDefine what nonpublic information is disposed of, when, and by what methodWritten retention and disposal policy with defined periods
Disposal executionLocate and delete nonpublic information across all stores where it came to rest, including derived copiesDisposal logs tied to specific records, systems, and dates
Documented exceptionsRecord every retention exception and the legal basis or infeasibility rationaleException register with basis, owner, and review date

Key dates

  • 1 March 2017Part 500 adopted.
  • 1 November 2023Second Amendment adopted, adding the asset inventory obligation to what had been a disposal-only section.
  • 1 November 2025Asset inventory requirements under 500.13(a) in force.

Primary sources

Common gaps

Where the requirement and operational reality most often diverge.

  • A retention policy with no disposal capability. Most firms can produce a policy stating what is kept and for how long. Far fewer can show information was located and deleted on schedule. The regulation asks for the second.
  • Derived copies outside the inventory. Nonpublic information copied into prompts, embeddings, caches, and logs rarely appears on the inventory or within reach of disposal tooling. It is still nonpublic information.
  • Partially populated inventory fields. Support expiration date and recovery time objective are most often blank. The regulation names them, so gaps are findings rather than judgement calls.
  • Over-reliance on the infeasibility exception. It covers disposal that is genuinely infeasible given how data is maintained, not a capability never built. Asserting it without a technical rationale invites the follow-up.
  • Undocumented exceptions. Where law requires retention, record the basis, owner, and review date per exception. An unwritten understanding is not an exception register.

Last reviewed August 14, 2026. This reference summarises publicly available regulatory guidance and is provided for general information. It is not legal advice. Obligations depend on an institution's charter, registration status, size, and activities. Verify against the primary sources cited above and consult counsel before relying on any summary here.