AppSec Compliance Deadlines You Can’t Afford to Miss

In 2017, Equifax lost the personal data of 147 million people because of a single unpatched Apache Struts vulnerability that their team had known about for months but never tracked to the specific application where it ran in production. The breach cost Equifax over $1.4 billion in settlements, legal fees, and infrastructure overhaul. What made the breach so instructive is the gap between knowing that a CVE exists and knowing where in the software it actually lives.

The EU’s Cyber Resilience Act, the NIS2 Directive, the Digital Operational Resilience Act, and PCI DSS 4.0.1 are collectively turning software composition visibility, continuous vulnerability tracking, and machine-readable component inventories into enforceable requirements — with fines that can reach tens of millions of euros. And the regulatory momentum extends well beyond Europe: Japan, Hong Kong, Brazil, Saudi Arabia, and Singapore have all introduced or tightened cybersecurity legislation within the past twelve months.

The question worth asking, then, is not whether these regulations affect the organization — the scope criteria are specific enough to answer that quickly — but whether the development lifecycle is structured to produce the evidence that regulators will soon be requesting.

 

Who Falls Under Which Framework

Before mapping the deadlines, it helps to understand the jurisdictional geometry, because these frameworks overlap in ways that catch organizations by surprise.

The Cyber Resilience Act is the broadest of the four: it applies to any manufacturer, importer, or distributor that places a product with digital elements on the EU market, which means standalone software, IoT devices, embedded firmware, and connected hardware all fall within scope. Roughly 90% of digital products land in the default self-assessment category; the remaining 10%, deemed critical or important, require third-party conformity assessment. Medical devices and vehicles covered by the existing sector legislation are excluded — everything else is in.

The NIS2 Directive takes a different cut: it targets organizations operating in 18 critical sectors — including energy, transport, health, digital infrastructure, manufacturing of certain products, and public administration — that meet size thresholds of 50+ employees and €10 million+ in annual revenue. Because NIS2 is a directive rather than a regulation, each member state transposes it differently, and the enforcement timelines vary.

DORA focuses squarely on financial services and covers approximately 22,000 financial entities across the EU, extending crucially to their ICT third-party providers: if your SaaS platform, cloud infrastructure, or custom software supports a bank’s operations, DORA’s requirements on incident reporting, resilience testing, and risk management reach you through contractual obligation even if your company is headquartered outside the EU.

PCI DSS 4.0.1 is the most globally distributed of the four, because it follows payment card data rather than geography: any organization that processes, stores, or transmits cardholder data — merchants, processors, acquirers, and their service providers — must comply, regardless of where they operate.

 

Where We Stand Today

Several of these deadlines have already passed, and the enforcement machinery is running.

DORA became fully enforceable on January 17, 2025 — financial institutions must now maintain ICT risk frameworks, report incidents within 4 hours, and verify that their technology vendors can demonstrate component-level vulnerability exposure on request; penalties reach €20 million or 10% of turnover. 

PCI DSS 4.0.1 became mandatory on March 31, 2025, shifting the standard from annual assessments toward continuous security validation — with script inventory, tamper detection, and automated web app protection.

NIS2 transposition is well underway: Germany’s implementation entered into force in December 2025, 20 of 27 member states have completed transposition, and the directive’s personal accountability provisions — executives can face temporary bans from leadership roles for non-compliance — are now live.

 

Globally:

• Japan’s Active Cyber Defense Act passed in May 2025; 

• Hong Kong’s Critical Infrastructure Ordinance took effect January 1, 2026; 

• Singapore’s Cybersecurity Amendment Act commenced October 31, 2025; 

• Saudi Arabia’s NCA released updated Essential Cybersecurity Controls (ECC-2) with enforcement fines up to SAR 25 million.

 

That’s the ground already covered.

 

The Deadlines That Haven’t Hit Yet

CRA: The SBOM Deadline Hiding Inside a Reporting Deadline

Of the four frameworks, the CRA deserves the closest reading, because its enforcement schedule contains a dependency that most compliance teams have not yet internalized.

The full enforcement date — December 11, 2027, when CE marking, conformity assessments, and all technical documentation become mandatory — receives most of the attention. But the regulation’s reporting obligations begin much earlier, on September 11, 2026, when manufacturers must start notifying ENISA and national CSIRTs of actively exploited vulnerabilities within 24 hours. What makes this deadline especially acute is Article 69(3), which extends this reporting obligation to products already on the market — not just those placed on the market after full enforcement.

The SBOM requirement itself, defined in Annex I Part II as a machine-readable inventory of at least top-level dependencies, officially takes effect in December 2027. You cannot inventory components without SBOM. Which means, in practice, that SBOM readiness becomes a prerequisite for compliance with the September 2026 reporting deadline — a full fifteen months before the SBOM requirement formally kicks in.

This telescoping of timelines is the part that organizations building medical devices, industrial controllers, automotive firmware, or any embedded system with a long deployment lifecycle need to internalize: the products shipped in 2020 will be subject to the same reporting obligations as the ones building today.

 

NIS2: National Enforcement Ramp-Up

Germany requires full compliance for essential entities by March 31, 2026. Italy’s full compliance obligations apply from October 2026. For development teams, every third-party dependency is now part of your supply chain security obligation: documented risk assessments, continuous vulnerability tracking, and incident reporting within 24 hours (early warning) and 72 hours (full report) are the baseline.

 

Hong Kong: Operator Designation Begins

The ordinance is in force, but the Commissioner’s Office is designating Critical Infrastructure Operators in phases from mid-2026, across eight sectors with annual risk assessments, biennial independent audits, and 12-hour serious incident reporting. Fines reach HK$5 million with daily penalties for continuing violations.

 

Japan: Incident Reporting by November 2026

Reporting obligations for essential infrastructure providers are expected to take effect in or before November 2026. Japan does not yet mandate specific secure development practices, but the trajectory signals formalized software security requirements ahead.

 

Brazil: First LatAm Cybersecurity Law on the Horizon

Bill 4752/2025 proposes a National Cybersecurity Authority and mandates supply chain risk assessments for public procurement. If passed, Brazil will become one of the first Latin American countries with a federal-level cybersecurity law.

 

Africa: Enforcement Gets Real

44 countries now have data protection laws with 38 operational authorities. Nigeria’s NDPC fined Multichoice ₦766 million in 2025 and launched compulsory inspections. Kenya imposed 48-hour breach notification requirements. South Africa’s POPIA enforcement now includes mandatory online breach reporting.

 

The Full Timeline

 

What Actually Needs to Change in SDLC

Across all four frameworks and their regional counterparts, the operational demands converge on three capabilities that most engineering organizations have not yet built into their standard workflow.

The first is SBOM generation as a repeatable, automated artifact of the build process rather than a one-off compliance exercise. The CRA expects machine-readable SBOMs covering at least top-level dependencies; DORA expects ICT asset inventories; NIS2 expects documented supply chain risk assessments. 

When a tier-2 automotive supplier needs to satisfy all three — for a firmware stack written in C/C++ with legacy Delphi diagnostics and Python build tooling — what do they do? Especially when they find that most SCA vendors could handle the Python and the C, but nothing on the market covers the Delphi components?

DerScanner has recently announced their Delphi SCA that processes the entire stack in one scan, outputting CycloneDX SBOMs that OEM customers can accept for CRA, UN R155, and DORA third-party documentation simultaneously.

 

 

The second is continuous vulnerability tracking that operates in hours, not quarters. The CRA’s 24-hour reporting window and DORA’s 4-hour initial notification leave zero room for periodic scans. When a new CVE drops, you need to know within minutes whether it affects the deployed products — and that requires a live, maintained component inventory linked to vulnerability databases.

The third is coverage for legacy and niche technology stacks, because regulated industries — finance, healthcare, manufacturing, public infrastructure — are precisely the sectors where COBOL, Delphi, ABAP, and embedded C dominate the most critical codebases. An AST platform that excels at JavaScript and Python but leaves gaps in the languages where your most sensitive code runs creates, paradoxically, the highest compliance risk exactly where the regulatory exposure is the greatest. 

DerScanner’s SAST engine covers 43 languages including these niche ecosystems, paired with SCA that includes supply chain attack detection for threats like MavenGate, typosquatting, and starjacking — and a hybrid SAST+SCA mode that traces whether a vulnerable function is actually reachable in your code, which separates genuine exposure from noise in an auditor’s report.

 

 

The Shape of the Next Two Years

The regulatory landscape between now and December 2027 is a staggered sequence of obligations that, taken together, transform software supply chain visibility from a quality aspiration into an audit-ready deliverable. 

The organizations that will navigate this most effectively are the ones that treat SBOM generation, continuous SCA, and automated static analysis not as compliance add-ons bolted on before an audit, but as native outputs of their development pipeline — present in every build, accessible to every auditor, consistent across every jurisdiction.

The timelines are set and the fines are specified. What remains — is the engineering work.