Section 500.13 of NYDFS Part 500 requires a covered entity to keep a complete, accurate and documented inventory of its information systems. The written procedure must track owner, location, classification or sensitivity, support expiration date and recovery time objectives where they apply, and state how often the inventory is updated and validated.
This is general information, not legal advice.
What the text says
The rule is short. Subsection (a) asks for written policies and procedures that produce and maintain the inventory, and it lists the minimum content. Subsection (b) is about disposal of nonpublic information that is no longer needed, which is a separate duty that often lands on the same team.
| Field in 500.13(a)(1) | What an engineering team usually records |
|---|---|
| Owner | A named team or person who can answer for the system |
| Location | Cloud account and region, data center, or vendor tenant |
| Classification or sensitivity | Whether it holds nonpublic information, and at what level |
| Support expiration date | End of vendor or community support for the OS, runtime or product |
| Recovery time objectives | How long the business can tolerate the system being down |
The phrase "as applicable" matters. A stateless internal tool may have no meaningful recovery objective, and the inventory can say so.
Why software belongs in the inventory
The definition of an information system in section 500.1 covers a set of electronic information resources organized for processing and sharing information. Applications and the components they run on fit that description in practice. Many teams track servers and SaaS accounts well and miss the libraries, container base images and build tools that sit under them. Those are where support expiration dates quietly pass.
A practical split:
- Systems and services: hosts, clusters, databases, SaaS tenants, repositories.
- Software inside them: dependencies, base images, runtimes, with versions.
- Owners and sensitivity attached to the first list, inherited by the second.
Keeping it accurate
The rule asks for a stated frequency to update and validate the inventory. It does not set a number, so you choose one that matches how fast your estate changes and then keep to it. Three habits make the choice defensible:
- Generate the list from sources of truth, such as cloud APIs, repositories and build output, instead of editing a spreadsheet by hand.
- Run a validation step that flags assets with no owner or no classification.
- Record the date of each validation run so you can show the schedule was followed.
If your inventory is a spreadsheet, treat the last edited date and the person who edited it as evidence, and replace it with an automated export when you can.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components and versions are listed per project. That is the software layer your asset inventory should be able to reach.
Where Safeguard fits
Safeguard offers asset discovery and SBOM and dependency scanning, which can produce the component level list that feeds an inventory. It does not replace your own owner and classification decisions. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does 500.13 set how often the inventory must be updated?
No. It requires the written procedure to state the frequency for updating and validating the inventory. You decide the interval and then follow it.
Is a spreadsheet acceptable?
The text requires a complete, accurate and documented inventory maintained under written procedures. It does not name a format. Accuracy is the hard part with a hand edited sheet.
Sources
Last reviewed: 19 October 2026.
