DORA, PCI DSS and NYDFS all now require a software inventory. Most banks cannot produce one.

Roughly a third of the first DORA Register of Information submissions came back with invalid or missing legal entity identifier (LEI) codes. Blank sub-outsourcing templates for major cloud providers were among the most common errors in the collection.

Filing errors, on paper. What they describe is a lot of institutions sitting down to write out their own dependency chain and finding they could not finish it.

I have some sympathy. Anyone who has been through an examination knows the pattern: a request arrives, and the next two weeks go on assembling something that mostly already exists but has never been in one place. Usually you get there. The DORA collection is the first time I have seen the assembly fail at scale, publicly, with the error rates published afterwards.

Three regulators have now asked a version of the same question within twelve months, without coordinating with each other.

1. PCI DSS 4.0 requirement 6.3.2, mandatory since 31 March 2025. An inventory of bespoke and custom software, and of the third-party components incorporated into it.
2. NYDFS Part 500.13(a), effective 1 November 2025. Written policies for an asset inventory tracking owner, location, classification, support expiration date and recovery time objective. First certification due 15 April 2026.
3. DORA Article 28, first register filed Q1 2026. Nine linked templates, the ICT assets behind each service, and the sub-outsourcing chains behind material sub-contractors.

Requirements of each

Requirement 6.3.2 specifies third-party components incorporated into your custom software, which is a narrower ask than an application inventory. Nobody on your team chose most of those. They arrived as dependencies of dependencies, and if you have ever tried to produce that list by hand you know it is not a list, it is a graph.

DORA goes past your suppliers to theirs. Sub-outsourcing chains for material sub-contractors means your vendor's vendors. That is why those templates came back blank, and I would not read it as laziness. Most institutions genuinely do not have that data and have no route to it.

NYDFS wants a recovery time objective (RTO) per asset. A recovery time objective is a promise about restoration speed, and it is only as good as your understanding of what the asset is built from.

Why the scanner-built inventory you have fails the requirement

Nearly every institution can produce a software inventory, and most of them come out of a scanner.

A scanner inspects the finished artifact and reads its manifest. The manifest is a declaration of what the software is supposed to contain, written by whoever assembled it. Most scanners resolve the first couple of layers of the dependency tree and take the manifest's word for the rest. Whatever sits below that line does not come back flagged as unknown. It does not come back at all, and the report looks identical either way, which is the part that should bother people more than it does.

J.P. Morgan's Eye on the Market put 95% of open source vulnerabilities in transitive dependencies, with the average JavaScript project carrying 683 of them against 10 direct. That is the region all three regulations cover.

There is a second gap the standard toolchain leaves alone entirely, and it is the one I think gets underrated. Beyond a known vulnerability sitting on a reachable path, there is the case where the artifact you are running has diverged from the source it came from. SolarWinds was signed, audited and trusted, and the artifact itself was the attack. The XZ backdoor shipped in the release tarball and never appeared in the git repository. Diffing the distributed artifact against its source would have surfaced it in seconds. That diff is not part of most pipelines.

What an incomplete inventory costs

Security is a cost center. It does not ship product and it does not generate revenue. Its job is risk reduction per dollar, and compliance work is where that ratio quietly goes bad.

You can satisfy an examiner with a document assembled by hand once a quarter. It answers the examination and nothing else. You finish the year having spent the money and remaining exactly as unable to answer the question when it matters.

DORA has partly closed that route, which I think is the most underappreciated thing in the regulation. Article 28 requires the register on request at any time. A quarterly manual exercise does not satisfy that, and I suspect a number of institutions have not fully absorbed the difference.

Then there is the SEC disclosure clock, where somebody has four days to characterise material impact. At that point you are doing forensics on your own estate under a deadline set by somebody else. The damage is already done.

The 2026 Verizon DBIR put median time to remediate at 43 days, with only 26% of CISA known-exploited vulnerabilities fully closed last year. Most of that clock goes on working out what is affected.

What a source-built inventory looks like

Kusari builds the dependency graph from source and build systems rather than reading it back from finished artifacts, so the transitive layers and the provenance land in the same place, in SPDX, CycloneDX, and in-toto attestations a third party can check. It also ingests vendor SBOMs and reconciles them against your own source, which for institutions that buy their core systems is the only way the bought half of the estate ends up in the same picture as the built half.

The Q1 register was the first real test and the error patterns suggest a lot of teams learned something uncomfortable while filling it in.

For anyone who filed one: was the hard part collecting the data, or discovering it did not exist in a form anybody could assemble? And has that changed what you are building this year, or only how early you start the spreadsheet.

Quick answers

What does PCI DSS requirement 6.3.2 require?

PCI DSS 4.0 requirement 6.3.2 requires an inventory of bespoke and custom software, and of the third-party software components incorporated into that software. It became mandatory on 31 March 2025. The requirement covers transitive dependencies, meaning components that arrived as dependencies of other dependencies rather than ones a developer selected directly.

What is the DORA Register of Information?

The DORA Register of Information is a set of nine linked data templates that EU financial entities must maintain and submit annually to their national competent authority under Article 28. It covers every contractual arrangement with an ICT third-party provider, including the ICT assets associated with each service and the sub-outsourcing chains behind material sub-contractors. The first submission was due in Q1 2026, and the register must also be delivered on request at any time.

What does NYDFS Part 500.13 require?

NYDFS Part 500.13(a), effective 1 November 2025, requires covered entities to maintain written policies for creating and updating an asset inventory. Each asset must record its owner, location, classification, support expiration date and recovery time objective. The first certification covering this requirement was due 15 April 2026.

Why do most software inventories fail regulatory review?

Most inventories are produced by scanners, which inspect the finished artifact and read its manifest. Scanners typically resolve about two layers of a dependency tree and take the manifest's word for the rest, so deeper components are absent from the report rather than flagged as unknown. J.P. Morgan research found 96% of vulnerabilities sit at least two layers below the dependency a developer actually changed, which is the region these regulations ask about.

Do these regulations require an SBOM?

None of the three names SBOM as a required format. All three require the information an SBOM contains: a component inventory covering third-party and transitive dependencies, with provenance. SPDX and CycloneDX are the standard formats for producing that information in a machine-readable and independently verifiable way.