SEC disclosure, the EU Cyber Resilience Act, DORA, NIS2, PCI DSS 4.0 and the AI Act

For most of the last twenty years, secure software development was something regulators encouraged and auditors sampled. That has changed. Securities regulators now expect cyber risk to be governed and disclosed. The European Union is making software makers liable for the security of what they ship. Financial regulators want evidence of resilience, and the payment card standard has added specific requirements about inventories and patching. Application security has become a matter of legal obligation and board accountability.

The dates that matter

Dates as published; later AI Act milestones in particular may move.

United States: disclosure and governance

SEC cybersecurity disclosure rules

Adopted in July 2023, the rules require public companies to disclose a cybersecurity incident they determine to be material, generally within four business days of that determination, on Form 8-K Item 1.05. Annual reports must also describe the company’s processes for assessing and managing cyber risk and the board’s oversight of it (Regulation S-K Item 106).

For application security the consequence is indirect but real. A materiality decision has to be made quickly, which requires knowing which systems were affected, what data they held and how the weakness arose. The annual description of risk management has to be true, and plaintiffs and regulators will compare it with what actually happened.

Federal software supply chain policy

Executive Order 14028 (2021) put software bills of materials and secure development frameworks, particularly NIST’s Secure Software Development Framework (SP 800-218), at the centre of federal procurement, and CISA’s Secure by Design programme has promoted the same practices to industry. Federal policy details have shifted since, but SBOMs and attestations of secure development practice have become normal requests from large customers, not only government ones.

European Union: liability and resilience

Cyber Resilience Act (CRA)

The CRA entered into force in December 2024. It applies to products with digital elements placed on the EU market and places obligations on manufacturers: design with security in mind, ship without known exploitable vulnerabilities, handle vulnerabilities throughout a support period, provide security updates, and document components, including through an SBOM. Reporting of actively exploited vulnerabilities and severe incidents applies from September 2026; most other obligations from December 2027.

“Known exploitable vulnerabilities” is the phrase to note. It makes exploitation data, such as CISA’s KEV catalog, directly relevant to legal compliance.

DORA and NIS2

The Digital Operational Resilience Act has applied to EU financial entities since January 2025. It requires an ICT risk-management framework, including identification of ICT assets and vulnerabilities, testing, and oversight of third-party ICT providers. NIS2 extends cybersecurity obligations to many more sectors, with member-state laws due by October 2024 (several states were late). It requires risk-management measures that explicitly include secure development and vulnerability handling, and makes management bodies accountable for approving and overseeing them.

The AI Act

The EU AI Act entered into force in August 2024 with obligations phased in over several years. For security leaders the relevant parts are the cybersecurity and robustness requirements on high-risk AI systems and the documentation duties that require knowing what AI is in use. Timelines for some obligations have been the subject of proposals to delay, so treat the later dates as indicative.

Payment cards: PCI DSS 4.0

Version 3.2.1 was retired at the end of March 2024, and the requirements that version 4.0 had marked as future-dated became mandatory at the end of March 2025. Several are directly about application security.

Requirement	What it asks	Evidence that satisfies it
6.3.1	Identify security vulnerabilities using reputable sources and rank them by risk	Threat intelligence on every finding; a documented risk-ranking method
6.3.2	Maintain an inventory of bespoke and custom software and third-party components	An SBOM per application, kept current
6.3.3	Install critical and high security patches within one month of release	SLA reporting by priority, with exceptions recorded
6.2.4	Prevent common software attacks in development	SAST, secrets and dependency scanning with a gate
6.4.3 / 11.6.1	Manage and monitor scripts on payment pages; detect unauthorised changes	Script inventory and change detection on checkout pages

What every regime asks for

Read together, these texts converge on a short list. A programme that can produce these artefacts on demand is in a strong position under all of them.

Capability	SEC	CRA	DORA / NIS2	PCI DSS 4.0
Software and component inventory (SBOM)	Supports	Required	Asset identification	6.3.2
Risk-ranked vulnerabilities	Supports	Known exploitable	Required	6.3.1
Remediation within defined timelines	Supports	Security updates	Required	6.3.3
Records of decisions and exceptions	Disclosure accuracy	Documentation	Required	Throughout
Board or management oversight	Item 106	—	Management accountable	—

Four business days: why the inventory matters in an incident

The SEC rule’s clock starts when a company determines an incident is material, and that determination is expected without unreasonable delay. In practice the first questions after a suspected application breach are the ones an application security programme should already be able to answer.

Illustrative. Hours spent finding these facts are hours taken from the assessment itself.

“How long was it known and unfixed” is the uncomfortable question. A programme that can show the vulnerability was risk-ranked, assigned and within its SLA — or that an exception was accepted by a named person for a stated reason — is in a very different position from one that finds the issue sitting in a backlog of thousands with no decision recorded.

The SBOM moves from good practice to requirement

Of all the artefacts above, the software bill of materials has changed status fastest. The CRA expects manufacturers to identify and document components, PCI DSS 4.0 requires an inventory of third-party components in bespoke software, and large customers increasingly ask for SBOMs in procurement. Three practical points matter more than the format debate between CycloneDX and SPDX.

• Generate it from the build, not by hand. An SBOM produced from the repository or image on every build is current; one assembled for an audit is out of date when delivered.
• Make it searchable across the estate. The question regulators and customers ask after a major vulnerability is “where do you run it?”. One SBOM per application is not an answer; a query across all of them is.
• Join it to exploitation data. An SBOM tells you what you ship. KEV and EPSS on each component tell you which parts of it are a reportable, “known exploitable” problem.

Questions auditors and regulators now ask

Question	Evidence that answers it
How do you identify vulnerabilities in the software you build and buy?	Scanner coverage by repository and image; scan history
How do you decide which to fix first?	A written prioritisation policy, and findings that show it was applied
How quickly do you fix the serious ones?	Time to remediate by priority over the last four quarters
Which known-exploited vulnerabilities did you have, and for how long?	KEV-flagged findings with first-seen and fixed dates
Who accepted the risks you did not fix, and why?	Dismissals and snoozes with actor, reason and expiry
How does the board oversee this?	Recurring board reporting on a stable set of risk metrics

A twelve-month readiness plan

Turning obligations into evidence

The hardest part of compliance is rarely the control. It is proving the control operated, continuously, for every application. That is where a single findings system pays for itself: the inventory, the priority, the due date and every decision are already recorded.

Keep reading