NYDFS Now Requires an Asset Inventory. Most Firms Can't Produce One.

For years, keeping an asset inventory was something security teams knew they should do. In New York, it is now something they must do. As of November 1, 2025, Section 500.13 of the NYDFS Cybersecurity Regulation — 23 NYCRR Part 500 — requires covered entities to maintain a complete, accurate, documented asset inventory. This is not guidance. It is an examinable rule, and examiners will ask to see it.

Who this applies to

Part 500 governs “covered entities” — the financial institutions and financial services companies licensed or authorized to do business in New York. That is a large population on its own. But NYDFS has become a template: other states and regulators have modeled their own rules on it, so the reach of 500.13 extends well past New York. If you operate in financial services, this is either your requirement now or your preview of one.

What Section 500.13 actually demands

The regulation is specific. Covered entities must have written policies and procedures that produce and maintain a complete and accurate inventory of their information systems. For each asset, where applicable, the inventory must track:

Required field	What it captures
Owner	Who is accountable for the asset
Location	Where it physically or logically sits
Classification / sensitivity	How critical or sensitive the asset is
Support expiration date	When it reaches end-of-support
Recovery time objectives	How quickly it must be restored after an outage

Plus the frequency at which the inventory is updated and validated.

Two details matter more than they first appear. First, scope: NYDFS declined to limit the inventory to assets that hold nonpublic information. It covers all assets included in your risk assessment — and it defines “information systems” broadly, reaching industrial and OT systems, IoT, and the unmanaged devices most inventories quietly omit. Second, completeness: responding to public comment, NYDFS emphasized that the inventory should be complete and in one place, carrying each of those fields even when the same information already lives somewhere else. A drawer full of partial lists is not an inventory.

Why this is the hard part

On paper, an asset inventory sounds like table stakes. In practice it is where most programs quietly fail, because the information 500.13 asks for is scattered across tools that were never built to agree:

• Your EDR knows the endpoints it manages — and nothing about the ones it doesn’t.
• Your CMDB holds owner, location, and recovery objectives, if it’s current. It rarely is.
• Your vulnerability scanner knows software versions and support dates for the hosts it reached.
• Your identity provider knows accounts and access, not hardware.

Ask three of these tools how many assets you have and you get three different answers. The gaps between them — orphaned devices, rogue hardware, shadow IT — are exactly the assets an inventory exists to catch, and exactly the ones a manual spreadsheet misses. And a spreadsheet is stale the day it’s exported. The regulation’s demand for update frequency is really a demand that the inventory be alive, not a snapshot.

The inventory is the foundation, not a checkbox

500.13 is not an isolated requirement. It is the ground the rest of Part 500 stands on. You cannot run a credible risk assessment (500.9) over assets you haven’t enumerated. You cannot manage vulnerabilities (500.5) on hosts you can’t see. You cannot confirm endpoint detection coverage (500.14) without knowing which assets are missing an agent. You cannot scope an incident (500.16) against an inventory you don’t trust. Fail at the inventory and every downstream control inherits the gap.

Where KeyCaliber fits

KeyCaliber builds the inventory 500.13 asks for from the tools you already run. Instead of another scanner to deploy, it connects by API to your EDR, vuln scanners, CMDB, identity, and cloud, and correlates what each one sees into a single validated picture of every asset — one place, complete, and continuously current.

That maps directly onto the requirement:

• Owner, location, and classification are pulled from the systems that already hold them and reconciled into one record per asset.
• Support-expiration and end-of-life signals come from your vulnerability and endpoint data.
• Classification by business impact — KeyCaliber computes what each asset is worth to the organization, so sensitivity and criticality aren’t guesses.
• Always current — because it’s API-connected and continuous, the inventory updates as the environment changes, satisfying the validation-frequency expectation.
• Audit-ready — every observation keeps the full vendor payload alongside the normalized fields, so what you show an examiner is defensible down to the source.

And because KeyCaliber detects coverage gaps automatically, it doesn’t just list your assets — it shows you the critical ones missing EDR or other controls, the evidence 500.14 asks for in the same view that satisfies 500.13.

NYDFS wrote into law what was always true: you cannot secure, scan, or account for what you cannot see. The asset inventory is where compliance starts. The only question is whether yours is complete, current, and defensible — or a spreadsheet you hope no one asks about.