Product security compliance readiness checklist

Product security regulation has converged on a common substance, whatever the framework’s name: know your components, handle vulnerabilities across the support period, ship without known-exploitable issues, and be able to prove it. This checklist maps those expectations to the capabilities you need in place - the capabilities take longest to build, which is why the honest time to start is before a deadline forces it.

Use it to find the gaps between a signed attestation and the demonstrable practice behind it.

Know your components

• Do you produce a machine-readable bill of materials for every product release, generated from real builds?
• Does it cover the components regulators care about - commercial, open-source, and off-the-shelf?
• For cryptographic obligations, can you also inventory your cryptographic assets, not just software components?
• Are the inventories stored so you can answer, later, what a given shipped version contained?

Handle vulnerabilities

• Do you identify vulnerabilities across the product surface - code, dependencies, containers, configuration - on an ongoing basis, not once?
• Is there a documented process to assess, prioritize, and remediate them, with records that show timeliness?
• Do you monitor already-shipped versions against newly disclosed vulnerabilities, so a disclosure years after release still reaches you?
• Is there a coordinated vulnerability disclosure path for issues reported from outside?

Ship clean

• Can you determine, at release, whether a build contains known-exploited vulnerabilities?
• Is there a release gate that can block a build carrying them, with exceptions recorded rather than silent?
• Do products ship with secure default configurations?

Prove it

• Is your evidence - inventories, findings, remediation records, decisions - reproducible and reviewable, rather than reconstructed from tickets after the fact?
• Are results deterministic, so a report from months ago can be re-derived and verified?
• Is the documentation maintained per release and ready for a market-surveillance or audit request?
• Are access to, and changes in, this evidence audit-logged?

Report on time

• Can you determine quickly which products are affected by a newly disclosed or actively exploited vulnerability, to meet tight reporting windows?
• Is the affected-versions question a query against stored inventories, or an archaeology project?

Reading the gaps

The pattern in the failures is always the same: policies exist, but the demonstrable capability behind them does not - the vulnerability-handling process has no tracked queue, the SBOM is a one-time document, the evidence is a screenshot from last quarter. Regulators and their technical staff sample the capability, not the policy.

Our compliance guides map specific frameworks to the technical evidence, the EU CRA countdown covers the timing pressure, and a demo shows the whole loop - scan, gate, document, monitor - running on a real product inside a network you control.

This checklist is guidance, not legal advice; how a specific framework applies to your product is a determination for your compliance function.