How it is created — SDL-PROC-004 V-Model Secure Development Process

1. Why this artifact exists

A phase-and-gate process tells you that a risk assessment must exist before architecture freeze. It does not tell you how the threat "an attacker replaces the firmware over the maintenance port" becomes a requirement, a design decision, a module, and finally a test that someone ran and signed. That chain is where compliance is actually won or lost, and it is where teams quietly fail: the requirement is written, the code is written, and the test that would have proven the connection was never specified — so at release the team tests what is easy to test rather than what was promised.

The V exists to make that failure structurally impossible. Each specification level is only finished once it has named the verification level that will close it, with an acceptance criterion. The V shape is not decoration; it is a statement that specification and verification come in pairs, and that a pair with one half missing is an open item.

The second reason is that IEC 62443-4-1 is written as eight practices, not as a lifecycle. Practices are a good checklist and a poor schedule — nothing in the list tells an engineer what to do on Monday. Mapping SR/SD/SI/SVV onto a V turns the checklist into a sequence with entry and exit criteria, while SM, DM, SUM and SG stay what they are: continuous, and outside the V.

2. Inputs

• The company development process (SDL-PROC-001) — the phases and gates this document refines. The V must fit inside them; where it contradicts them, one of the two is wrong.
• The SDL policy (SDL-POL-001) and the tailoring rules (SDL-STD-021).
• The practice list you are structuring on. For an industrial line that is IEC 62443-4-1; for software-only products the NIST SSDF or ISO/IEC 27034 serve the same purpose. Structure does not require certification, and you should say so in the document so nobody reads it as a claim.
• Your real verification capability: what your CI actually runs, whether you can fuzz, whether you have anyone independent enough to sign off a test they did not write, whether penetration testing is bought in. The right leg is worth exactly as much as this is honest.
• The Annex I Part I property list, which is what the security requirements at V2 have to cover in the end.

3. Steps

1. Count your levels before you draw anything. Four on each side is a good default for an embedded product: context/threat model, requirements, architecture, module design. Fewer than three and the levels are too coarse to test against; more than five and delta changes become unaffordable to re-close.
2. Pair every level with its verification level, and write the pair down together. This is the whole method. Do the pairing before you fill in any activity detail, because the pairing is what you will be arguing about later.
3. Give each pair a question in plain language — "are the threats defeated?", "are the requirements met?", "do the layers integrate?". Engineers remember the question; nobody remembers "SVV-2".
4. Map the practice requirements onto the levels you already have. Not the other way round. A process derived from a requirement list reads like a requirement list and gets ignored. Cite the identifiers (SR-2, SD-3, SVV-1 …) in a column so the mapping is auditable, and do not copy the standard's text into your document — cite it.
5. Decide what is explicitly not a level. Security management is a precondition; defect management, update management and the user guidelines start after the release gate. Draw them as bands, above and below, so nobody looks for them on a leg.
6. Name the evidence per level, not per phase. "Test report" is not evidence. "SR-sheet test report, every line pass/fail/waived, tester named" is.
7. Write the entry and exit criteria for each gate as records that exist or do not exist. A design gate that a project can talk its way through is a meeting, not a gate.
8. Write the delta rules before you need them. For each kind of change, which level do you re-enter and what must you re-close? Without this table the V is used once, at the first release, and then abandoned — because nobody wants to re-run everything and nobody has written down what "not everything" means.
9. Add the traceability table — left level, what it states, the right level that closes it, the evidence. This is the page an assessor reads first, and it is the page that shows you your own open levels.
10. Say what may never be tailored away. Every process gets tailored; the question is whether the floor is written down or improvised under release pressure.
11. Approve at management level. Independence of testers and external penetration testing cost money — a process that assumes them without a signature is a wish.

4. Done when

• Every left level names exactly one right level, and every right level names what it closes.
• Every security requirement in the sheet has an acceptance criterion and a verification level assigned at review time, not at test time.
• Each gate lists records as its exit criteria.
• The delta table covers, at minimum: new interface, changed requirement, architecture change, module-internal change, new CVE in a component, substantial modification.
• SM, DM, SUM and SG each have a home, and none of them is hidden inside a level.
• The document states which standard it is structured on and that this is not a certification claim.
• Management has signed a dated revision.

5. Keeping it alive

Review annually with SDL-PROC-001, and after every release retrospective. The two questions worth asking each time: which level was closed with weaker evidence than it promised, and which finding was discovered at V1′ that should have been caught at V3′ or V4′? A finding caught late is not a testing success; it is a signal that a level below it is under-specified. Feed both answers back into the tables — that is what SM-13 (continuous improvement) is asking for.

6. In TRA Studio

The V is a shape the tool already stores. Model the eight levels as activities in your Secure Lifecycle under Workflow & Processes — the seeded Secure SDLC baseline, whose phases are already the V, is a starting skeleton — then map the requirements of your in-scope standards onto them. The left-leg activities carry the specification requirements, the right-leg activities carry the verification requirements, and each activity records its responsible role and the artifact it produces.

The traceability table in the artifact then stops being something you maintain by hand: requirements with no activity are your open gaps, the coverage view is the live version of the level-to-level table, and the release gate refuses to sign off while a required requirement is still unassigned or unevidenced. If your product line delegates part of the V to another team, model that team's work as a child workflow and delegate the requirements to it, so the parent gate still sees the coverage without owning the activities.