Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
SDL-PROC-004 — V-Model Secure Development Process
| Document ID | SDL-PROC-004, rev. 1.0 |
| Owner | Product Security Lead (PSL) |
| Approved by | Managing Director, 2026-08-05 |
| Scope | Engineering execution for the industrial product line (SensorNode S300 and successors), from architecture start to the release gate |
| Relationship | Refines phases 1–3 of SDL-PROC-001 into engineering levels; governed by SDL-POL-001; tailoring per SDL-STD-021. It does not replace either — the phase plan stays the record of when, this document is the record of how the work is decomposed and proven |
| Structured on | IEC 62443-4-1 Ed. 1.0, practices SM, SR, SD, SI, SVV, DM, SUM, SG (used for structure only — ACME is not certified to 62443-4-1) |
| Legal anchors | CRA (EU) 2024/2847: Annex I Parts I & II, Art. 13, Art. 14 |
SDL-PROC-001 answers when does it happen, who owns it, which record proves it. That is the answer an auditor wants. It is not the answer an engineer wants, because it says nothing about how a security requirement becomes a tested line of firmware.
This document answers the engineering question, and it uses the oldest shape in safety-critical development to do it: a V. Going down the left leg, each level takes the level above it and decomposes it into something smaller and more concrete. Going up the right leg, each level integrates what was built and proves the left level opposite it. The rule that makes the shape worth anything is this: a specification level is not finished until it has named the test that will close it. Not "we will test it later" — the acceptance criterion, the evidence and the tester's independence are decided while the requirement is being written, not after the product exists.
Note on the standard: the IEC 62443-4-1 requirement identifiers below (SM-1, SR-2, SVV-4, …) are cited so this process can be traced to a recognised structure. The normative text of the standard is not reproduced here; obtain it from IEC. Using the structure does not require, and does not imply, certification.
The V at a glance
How to read it
- Left leg, four levels. Each one produces a specification and hands the next a smaller problem. Nothing on the left leg is code.
- Vertex. Secure implementation — the only place where the product is actually built.
- Right leg, four levels. Each one integrates and verifies. Each sits opposite the left level it exists to prove; the dashed tie is a real dependency, not decoration.
- The band above. Practice 1 (SM) is not a level. It is the condition under which any level may run at all: a defined process, named responsibilities, people with security expertise, a protected development environment, controlled signing keys, and security requirements imposed on suppliers.
- The band below. Practices 6, 7 and 8 (DM, SUM, SG) begin where the V ends. The V finishes at the release gate; roughly half of the CRA's obligations start there.
The V is drawn once per release, not once per company, and it is not a waterfall. The S300 firmware runs three-week iterations; what iterates is the depth of the V, not its order. A change that touches a trust boundary re-enters at V3 or higher and comes back up through the levels it invalidated — see Delta-V below. What the shape forbids is the thing that actually goes wrong in practice: writing a security requirement that nobody ever decided how to test.
Left leg — specify and decompose
| Level | Activity | 62443-4-1 | CRA anchor | Responsible | Output | Closed by |
|---|---|---|---|---|---|---|
| V1 | Establish the product security context: intended use, foreseeable misuse, network exposure, physical-access assumptions, who operates the device and with what skill. State the assumptions the product is allowed to make about its environment — those become user obligations later (SG-2) | SR-1 | Annex I I(1) | PSL + Product Manager | Security context section of SEC-RA-S300 v0.x | V1′ |
| V1 | Threat model the product in that context: assets, entry points, trust boundaries, threat actors, attack paths. STRIDE-per-element per SDL-TMP-011. Feeds, and is fed by, the risk assessment | SR-2 | Annex I I(1) | PSL + FW Lead | SEC-TM-S300 | V1′ |
| V2 | Derive product security requirements from the threat model and from Annex I Part I: authentication and access control, confidentiality in transit and at rest, integrity, availability, data minimisation, logging, secure update. One requirement per line, each traceable to a threat or to an Annex I property | SR-3, SR-4 | Annex I Pt I | PSL | Security Requirements Sheet (SR sheet) | V2′ |
| V2 | Review the security requirements with development, test and the product owner. Every requirement leaves the review with a stated acceptance criterion and a named verification level — a requirement whose test nobody can describe is not yet a requirement | SR-5 | Annex I Pt I | PSL (chairs) | Signed SR review record | V2′ |
| V3 | Secure architecture: apply secure-design principles (least privilege, minimal attack surface, fail secure, no security by obscurity) and lay out defence in depth — which layer stops which attack path, and what still holds when one layer fails | SD-1, SD-2 | Annex I I(1)(2) | FW Lead + PSL | Security architecture document, attack-surface plan ENG-DES-033 | V3′ |
| V3 | Security design review against the threat model: each attack path is either mitigated by a named design element or accepted with a rationale in the risk assessment. Unmitigated and unaccepted is a defect at this level, not at test | SD-3 | Annex I I(1) | PSL (chairs) | Design review record | V3′ |
| V4 | Detailed module design for the security-relevant modules — update parser, crypto/key handling, provisioning, management interface: interfaces, input validation rules, error handling, state machines, key lifecycle. Apply the secure design best practices of the coding standard at design time, not review time | SD-3, SD-4 | Annex I I(2)(4) | Module owners | Module design notes, interface contracts | V4′ |
| V4 | For each module, write what proves it: the module's security test cases and the static-analysis rule set that applies to it. Handed to V4′ before implementation starts | SD-4 | Annex I Pt I | Module owners + QA | Module test specification | V4′ |
Gate DG (design gate, end of the left leg): threat model approved; every SR-sheet line has an acceptance criterion and a verification level; defence-in-depth documented; every attack path mitigated or accepted; module test specifications exist. Implementation of a security-relevant module may not start before its own V4 row is closed.
Vertex — secure implementation
| Activity | 62443-4-1 | CRA anchor | Responsible | Evidence |
|---|---|---|---|---|
| Implement to the module design under the secure coding standard (SDL-STD-020, MISRA-C subset): no hard-coded secrets, validated input at every trust boundary, no debug paths compiled into production images | SI-2 | Annex I Pt I | Dev team | Merge requests, CI configuration |
| Security implementation review of every change to a security-relevant module: peer review plus PSL review, against the module design and the coding standard. Automated checks (SAST, secrets scan, dependency/CVE scan) run per commit and are an input to the review, not a substitute for it | SI-1 | Annex I Pt I | Dev team, PSL | Review approvals, CI reports |
| Generate the SBOM (CycloneDX) on every build; new third-party components only via SDL-POL-005 approval | SM-9 | Annex I II(1) | DevOps | SBOM per build, component registry |
| Keep the development environment and signing keys protected: hardened build agents, reproducible builds, release keys in the HSM per SDL-STD-025 | SM-7, SM-8 | Annex I Pt I | DevOps | Access records, key ceremony records |
Right leg — integrate and verify
Read this table bottom-up: V4′ runs first.
| Level | Activity | 62443-4-1 | CRA anchor | Responsible | Evidence | Closes |
|---|---|---|---|---|---|---|
| V4′ | Module and code verification: the module test specification written at V4 is executed; static analysis clean against the agreed rule set; fuzzing of every externally reachable parser; dependency and CVE scan of the module's components. Findings ≥ CVSS 7.0 block the merge | SVV-3 | Annex I Pt I | Module owners + QA | CI reports, fuzzing corpus & crashes triaged | V4 |
| V3′ | Security integration testing: the layers are assembled and each defence-in-depth claim from V3 is attacked on the integrated system — does layer 2 still hold when layer 1 is bypassed? This is threat-mitigation testing: one test per mitigated attack path from the threat model | SVV-2 | Annex I I(1)(2) | QA + FW Lead | Threat-mitigation test report, traced to SEC-TM-S300 | V3 |
| V2′ | Security requirements testing: every line of the SR sheet executed against its acceptance criterion on integration hardware. Result per line is pass, fail, or waived-with-rationale — never blank. Coverage of the SR sheet is reported as a percentage and must be 100 % | SVV-1 | Annex I Pt I | Verification Lead (QA) | SR-sheet test report | V2 |
| V2′ | Independence of testers: security requirements testing is not signed off by the person who implemented the module. For the S300, module tests are run by the module owner but reviewed by QA; requirements testing and penetration testing are run by someone outside the development team | SVV-5 | Annex I Pt I | QA | Test sign-off records naming the tester | V2 |
| V1′ | Security validation on a production-fused unit: the secure-by-default configuration verified as shipped (SDL-CHK-030), the product exercised in the security context defined at V1 — the assumptions from V1 are checked against how the device actually behaves | SVV-2 | Annex I I(2)(3) | QA + PSL | Signed SDL-CHK-030, validation report | V1 |
| V1′ | Penetration testing against the threat model, scoped to the entry points identified at V1 and performed by testers independent of the project. Every finding is entered into defect management (DM) and either fixed or risk-accepted before release — a pen-test report with open findings and no decisions is not a closed level | SVV-4 | Annex I I(1) | External/independent testers | Pen-test report + disposition of each finding | V1 |
Gate RG (release gate): all four right-leg levels closed; SR-sheet coverage 100 %; no open blocking findings; risk assessment finalised at v1.0 with residual risks accepted; SBOM final; user documentation (SG) complete; firmware image signed. Chaired by the PSL, recorded in the Release Gate Record. The CRA conformity steps that follow (technical documentation per Annex VII, conformity assessment, DoC, CE marking) are phase 3 of SDL-PROC-001 and are not repeated here.
Across the whole V — Practice 1 (SM)
These are not levels and have no counterpart on the other leg; they are the conditions under which the V may be run at all. They are verified once per year, not once per release, in the internal conformity review (SDL-REC-002).
| Activity | 62443-4-1 | Responsible |
|---|---|---|
| A defined, documented development process — this document and SDL-PROC-001 | SM-1 | PSL |
| Named responsibilities and deputies for every role in the tables above (QM-ORG-003); no level self-approved by whoever performed the work | SM-2 | MD |
| Applicability: which products run the full V and which are tailored (SDL-STD-021), and the scoping rationale | SM-3, SM-5 | PSL |
| Security expertise: named security-trained engineers, annual refresh, threat-modelling competence in the team rather than bought in per project | SM-4 | MD |
| Integrity of the artifacts the V produces: version control, signed tags, protected branches, retention of every risk-assessment version | SM-6 | DevOps |
| Secure development environment; control of private keys (SDL-STD-025) | SM-7, SM-8 | DevOps |
| Security requirements imposed on suppliers and on externally provided components (SDL-POL-005, CON-CLS-007) | SM-9, SM-10 | PSL |
| Security-related issues assessed and addressed wherever they arise, including during development | SM-11 | PSL |
| Process verification and continuous improvement: annual review, lessons from incidents fed back into this document | SM-12, SM-13 | QA / PSL |
After the release gate — DM, SUM, SG
The V ends at the release gate; the obligations do not.
| Activity | 62443-4-1 | CRA anchor | Where it is described |
|---|---|---|---|
| Receive, review, assess, address and disclose security-related issues for the whole support period | DM-1 … DM-6 | Annex I Pt II | PSM-PROC-002, PSM-PROC-003 |
| Qualify, document and deliver security updates — including updates to dependent components and the OS — in time and free of charge | SUM-1 … SUM-5 | Art. 13(8), Annex I I(2), Pt II | SDL-STD-022, PSM-PROC-002 |
| Ship the security guidelines with the product: hardening guide, secure operation, account management, secure disposal, and the defence-in-depth measures expected from the operating environment (the V1 assumptions, written down for the user) | SG-1 … SG-7 | Annex I Pt I, Art. 13(18) | User documentation set, derived from V1 and V3 |
| Periodic review of the defect-management practice itself | DM-6 | Annex I Pt II | SDL-REC-002 |
Note the loop: SG-2 exists only because V1 recorded assumptions about the environment. If V1 is done sloppily, the user documentation cannot be written honestly, and the residual risk the manufacturer accepted is never communicated to the person who has to carry it.
Delta-V — what forces a return down the left leg
A V that only runs forwards goes stale. Each trigger below re-enters the V at a named level and must climb back up through every level above the entry point.
| Trigger | Re-enter at | Must re-close |
|---|---|---|
| New or changed external interface, port, protocol or trust boundary | V1 (threat model delta) | V1′ … V4′ for the affected paths |
| New or changed security requirement, or a waived requirement being revisited | V2 | V2′, V1′ |
| Architecture change affecting a defence-in-depth layer | V3 | V3′, V2′, V1′ |
| Change inside one security-relevant module, interfaces unchanged | V4 | V4′, plus V3′ for the paths that module carries |
| New CVE in a shipped third-party component | V4 (component decision) | V4′; V1′ only if the attack path was previously mitigated by that component |
| Substantial modification in the CRA sense | V1 and SDL-PROC-001 phase 1 | The full V, plus re-classification and a new conformity assessment |
A delta-V is recorded like a full V, only shorter: the delta threat-model record, the affected SR-sheet lines, and the re-run tests. "No change to the threat model" is a valid outcome — signed by the PSL, per SDL-STD-021.
Level-to-level traceability
The sheet handed over first at an audit. Every left level has exactly one closing right level; a row without evidence is an open level, not a finished one.
| Left level | States | Closed by | Evidence that closes it |
|---|---|---|---|
| V1 — Security context & threat model | What we are defending, against whom, in what environment | V1′ — Security validation & penetration testing | Signed SDL-CHK-030, validation report, pen-test report with every finding dispositioned |
| V2 — Product security requirements | What the product must do | V2′ — Security requirements testing | SR-sheet test report, 100 % of lines pass/fail/waived, tester named and independent |
| V3 — Secure architecture & defence in depth | How the requirements are met structurally | V3′ — Security integration testing | Threat-mitigation test report, one test per mitigated attack path |
| V4 — Detailed module design | How each security-relevant module behaves | V4′ — Module & code verification | Module test results, static analysis, fuzzing, CVE scan |
| Vertex — Secure implementation | The product itself | Reviewed, not tested, at its own level | Merge-request approvals, PSL review of security-relevant changes, CI reports |
Tailoring
Per SDL-STD-021. A maintenance release with no interface change may collapse V1–V3 into a signed delta assessment and run only V4/V4′ plus a regression subset of V2′. What may never be tailored away: the SR-sheet coverage report, the independence of the tester for whatever requirements testing does run, and the release gate itself. Tailoring decisions are recorded per release, with a reason.
Revision history
| Rev | Date | Change | Approved |
|---|---|---|---|
| 1.0 | 2026-08-05 | Initial issue. Engineering-level refinement of SDL-PROC-001 phases 1–3, structured on IEC 62443-4-1 practices | MD |