SDL-STD-021 — SDL Tailoring Rules

1. Why tailoring needs rules

A 45-person company cannot run a full threat-modelling workshop for a two-line bugfix, and pretending otherwise produces one of two outcomes: the process is followed once and then quietly abandoned, or the paperwork is produced retroactively and means nothing.

So tailoring is legitimate. What is not legitimate is deciding how much process a release deserves after the release is under time pressure, by the person who wants it shipped. This document fixes the decision in advance: what kind of release this is, what that kind requires, and who signs.

The other half of the job is the boundary the CRA draws. Below it, a release is a release. Above it — a substantial modification — the product is treated as newly placed on the market, and classification and conformity assessment re-open. Getting that call wrong is not a process shortcut; it is a compliance failure that surfaces years later.

2. Release types

The type is proposed by the Product Manager and confirmed by the PSL before development starts. A release cannot be re-typed downward once development has begun; if the content grows, the type grows with it.

3. What each type requires

Never tailorable, at any release type:

1. Static analysis and the dependency/CVE scan (Phase 4).
2. The secure coding standard and mandatory peer review (Phase 3).
3. Signing under SDL-STD-025, including four-eyes authorisation.
4. The release gate itself. An emergency security release is expedited — the approver is reached out of hours — but never skipped. A gate that can be bypassed under pressure protects nothing, because pressure is exactly when bad releases ship.
5. The SBOM. Every build produces one.

4. The delta assessment

The artifact that substitutes for a full Phase 1–2 in a tailored release. One page, and it must be capable of concluding "no, this needs the full treatment".

Content:

1. What changed, in terms of interfaces, protocols, trust boundaries, security functions and third-party components — the five questions from §5.
2. Which threat-model elements the change touches; if none, the statement "no change to threat model" with the reasoning that supports it.
3. Which security requirements are affected, and whether any new one is derived.
4. Whether any risk in the current risk assessment changes score.
5. The conclusion: tailoring valid, or escalate to the next release type up.

Signed by the PSL. Filed in the release dossier. An unsigned delta assessment does not satisfy Phase 2, and the release gate checks for the signature, not for the file.

5. Substantial modification — the five questions

Asked at every release, answered in the delta assessment. Any "yes" means the release is at least Major and requires the substantial-modification assessment in §6.

1. Does the change alter the intended purpose or introduce a new use case?
2. Does it add, remove or change an interface, protocol or trust boundary?
3. Does it modify a security function — authentication, cryptography, secure boot, the update mechanism, access control?
4. Does it change the product's risk profile as assessed in the risk assessment?
5. Does it integrate a new third-party component in a security path?

A defect correction that restores intended behaviour is not a substantial modification, however large the diff. A small diff that changes what the product is for, is.

6. Substantial modification — consequences

Where the assessment concludes the modification is substantial, the product is treated as newly placed on the market:

• Product classification re-opened (REG-REC-020).
• Conformity assessment route re-confirmed (REG-REC-021).
• Risk assessment to a new full version (SDL-TMP-010), threat model re-run (SDL-TMP-011).
• Technical documentation updated and a new Declaration of Conformity issued.
• The support period is not restarted — it runs from first placement of the product, and the register (PSM-LST-001) is the authority on that date.

The assessment and its conclusion — including a conclusion of "not substantial" — are recorded. The negative case is the one an assessor will ask to see, because it is the one that was decided in ACME's own favour.

7. Records

Release-type confirmations, delta assessments with PSL signature, substantial-modification assessments, and any tailoring exception approved under §8. Filed in the release dossier.

8. Exceptions

A tailoring decision outside these rules requires written approval by the PSL and the Managing Director, states what is being omitted and why, names the compensating measure, and is reviewed at the next management review. Exceptions are recorded even when the release turns out fine — the pattern of exceptions is what tells you the rules need changing.

Revision history