The first time I tried to build a project plan against prEN 40000-1-3 I made the obvious mistake. I divided the work into six phases, allocated proportional time to each, and walked into the first sprint expecting Preparation to be slightly heavier than the others — six requirements out of twenty-five would have meant 24%, ten out of twenty-five means 40%. The plan held for about two weeks. By the time the SBOM tooling decision was being argued in design review, the original allocation had quietly fallen apart. The Preparation phase wasn’t 40% of the work. It was closer to two-thirds.
This essay is about why. Three structural reasons sit underneath the asymmetry, and they all point in the same direction: PRE is the phase you cannot postpone, and that property compounds.
§ 01The numbers, before the argument
Twenty-five requirements across six phases. The distribution is uneven by design — the standard’s authors did not pretend the phases were equal. Here is what the count actually looks like:
| Phase | Requirement IDs | Count | Share |
|---|---|---|---|
| [PRE] Preparation | PRE-1 → PRE-10 | 10 | 40% |
| [RCP] Receipt | RCP-1 → RCP-7 | 7 | 28% |
| [VRF] Verification | VRF-1, VRF-2 | 2 | 8% |
| [RMD] Remediation | RMD-1 → RMD-3 | 3 | 12% |
| [RLS] Release | RLS-1, RLS-2 | 2 | 8% |
| [PRA] Post-release | PRA-1 | 1 | 4% |
| Total | 25 | 100% |
40% is the floor. It is what an honest count of paragraph-level requirements will give you. Anyone who wants to dispute the asymmetry has to dispute it from at least there. The argument that follows is why the implementation footprint runs heavier than the floor — three reasons, each independent of the others.
§ 02Reason one — Preparation cannot be retrofitted
Look at what PRE-7 and PRE-8 ask for: a software bill of materials and a hardware bill of materials. Look at what they presume about your engineering organisation. They presume that for every product you ship, you can produce a current, accurate inventory of every software component (with version, licence, and cryptographic hash) and every hardware component (with manufacturer, part number, and provenance). And they presume you can do that continuously, because RCP-3 and RCP-4 then ask you to map any newly disclosed CVE back to the products that contain the affected component.
That is not a document. That is a CI/CD integration. An SBOM produced by hand once a year is worthless under prEN 40000-1-3 because it desynchronises from the build the moment it is produced. To satisfy PRE-7 you have to wire CycloneDX or SPDX generation into your build pipeline, version-control the output, and treat it as an artefact alongside the binary. For most APAC ODMs that means changing how the build is wired — adding a dependency-tracking step, retraining the build engineers, and finding budget for a tool like Dependency Track or Anchore.
Compare that to RMD-2, “Remediation development”. RMD-2 is also non-trivial. But RMD-2 work happens per vulnerability, on demand, when something specific has surfaced through RCP and VRF. You can hire a contractor, accept a longer cycle time, escalate to senior engineers — there are flexibility levers. PRE-7 has no flexibility lever. Either your build produces an SBOM or it doesn’t. Either every release is covered or none are.
The same shape applies to PRE-1 (vulnerability handling policy), PRE-2 (CVD policy), PRE-3 (operational security), PRE-5 (secure communication), PRE-6 (product identification), PRE-9 (test and review planning), and PRE-10 (distribution mechanisms). Each of these is structural — once it’s in place the marginal cost per vulnerability drops to near zero, but if it isn’t in place the entire downstream pipeline jams. PRE is the load-bearing infrastructure. Everything else operates on top of it.
§ 03Reason two — Preparation produces persistent artefacts
Run through what each phase actually leaves behind in your evidence binder. PRE produces durable objects: a vulnerability handling policy, a CVD policy, an SBOM (regenerated every build), an HBOM, a product identification scheme, a security test and review plan, a list of distribution channels, a documented operational security regime. These are standing documents. A notified body or market surveillance authority assessing your Article 13(8) compliance will spend most of an audit reading these.
RCP produces traces: receipt logs, monitoring logs, periodic test reports, periodic review reports. These accumulate but each individual artefact is small. VRF produces one tracked, verified vulnerability report per vulnerability triaged. RMD produces a remediation decision, a developed fix, and a test report — also one set per vulnerability. RLS produces a security update binary plus a CSAF advisory — again, per vulnerability. PRA produces a brief retrospective per release.
The asymmetry is not just in count, it is in persistence. PRE artefacts are read every quarter and updated every release. RCP through PRA artefacts are written once per incident and then archived. The senior engineering hours that go into PRE artefacts are paid every cycle. The senior engineering hours that go into RMD artefacts are paid only when an actual vulnerability arrives. Auditors know this. They open audits with PRE.
§ 04Reason three — Preparation is the only proactive phase
Look at the phases through a different lens: which ones run on their own schedule, and which ones run on the schedule of an external event?
RCP, VRF, RMD, RLS, PRA all run on the schedule of vulnerabilities. They are reactive phases. They do not consume engineering capacity until a vulnerability surfaces, at which point they consume it intensely for a bounded period, and then they go quiet again. A team that ships a product without significant vulnerabilities for six months pays almost nothing in RCP/VRF/RMD/RLS/PRA cost during that window. The cost is real but it is event-driven.
PRE is the opposite. PRE runs on your release schedule. Every build regenerates an SBOM. Every product line update revisits product identification. Every quarter you review the test plan against PRE-9. The CVD policy gets renewed when staff turn over. The cost is continuous and unavoidable, regardless of whether any vulnerability is found.
That makes PRE the only phase whose cost is fixed and predictable. It also makes PRE the only phase you can actually finish ahead of an external event. RCP through PRA are forever — they continue for the entire support period. PRE has a moment of completion: the day your CI/CD produces a clean SBOM, the day your CVD policy is published, the day your secure communication channel works. After that, PRE shifts from a build cost to a maintenance cost.
This third reason is why the engineering organisations that handle CRA well sequence PRE first. They get past the initial spike of structural investment, and then they have capacity left for everything else. The organisations that try to do all six phases in parallel run out of capacity in their first real incident, because PRE infrastructure was supposed to be in place to absorb it and wasn’t.
§ 05What this means for sequencing
If 40% is the floor and the implementation footprint is closer to two-thirds, the calendar should reflect that.
2026 H1. Almost all of it goes to PRE. SBOM toolchain selected, integrated into CI/CD, validated on at least one product line. CVD policy drafted, reviewed by legal, published with a working contact channel (the security.txt + email alias both alive). Product identification scheme decided. Operational security regime documented. By the end of June, you should be able to point at every PRE-1 through PRE-10 deliverable and say “that one is real, here is the artefact, here is the process that maintains it.”
2026 Q3. Now you can afford RCP. Wire the CVE feeds. Subscribe to upstream advisories for every component the SBOM lists. Run the first regular test under RCP-6 and the first regular review under RCP-7. The receipt mechanism gets exercised against deliberately-crafted test reports. By 11 September, the reporting capability is alive and tested — which is what Article 14 asks for.
2026 Q4 onwards. VRF, RMD, RLS, PRA exist as documented procedures rather than functioning departments. They get exercised the first time a real vulnerability arrives. Until then, the engineering hours that would have gone to building these from scratch are instead going to the harder Annex I Part I work — secure-by-design, the construction obligations of Article 13 itself, the conformity assessment evidence binder for December 2027.
The organisations that get this sequencing wrong typically do one of two things. They allocate proportionally — six phases, six equal slices of the year — and end up with all six half-built when Article 14 activates. Or they sprint at all six in parallel because everything looks urgent, and they exhaust senior engineering capacity by mid-2026 with nothing complete. The shape that works is the one that respects the asymmetry: PRE first, RCP second, and the reactive phases last because they will be tested by reality before they are tested by audit.
40% on paper. Closer to two-thirds in practice. Plan accordingly.