How it is created — SDL-STD-021 SDL Tailoring Rules

1. Why this artifact exists

A full lifecycle applied to a two-line bugfix produces one of two outcomes, and both are bad. Either the team follows it once, discovers the cost, and quietly stops — leaving a policy that describes a process nobody runs. Or the paperwork is generated retroactively to match what was already shipped, which is worse, because now the records are fiction and the release gate has been taught that it can be satisfied after the fact.

Tailoring is therefore not a compromise; it is what makes the lifecycle survivable. The danger is not tailoring itself but tailoring decided late, under delivery pressure, by whoever wants the release out. This document moves that decision to the front, where it is made calmly and by someone whose job is not the ship date.

It also carries the one call in the whole lifecycle with consequences that outlive the release: whether a change is a substantial modification. Get it wrong and the product has been placed on the market again without a conformity assessment — a finding that surfaces years later, in someone else's audit.

2. Inputs

• Your lifecycle phases and what each produces, so the matrix has rows.
• Your actual release history. The types should describe releases you really ship, not a textbook taxonomy — if you have never shipped one of your five types, you have four.
• The CRA's substantial-modification concept, and your product classification, because the consequence of "yes" is re-classification.
• Your release gate, since tailoring changes what enters the gate but must never change whether it happens.

3. Steps

1. Define release types by security-relevant impact, not by version number. What matters is whether interfaces, protocols, trust boundaries, security functions or security-path components changed — not whether the middle digit moved.
2. Have the PSL confirm the type before development starts, on the Product Manager's proposal. A type assigned afterwards is a rationalisation.
3. Make the type ratchet upward only. If content grows during development, the type grows with it. Without this rule the cheapest type is always the one you started with.
4. Build the matrix as phases against types, so tailoring is a lookup rather than a negotiation. One table settles most arguments before they happen.
5. Write the never-tailorable list explicitly and keep it short. Static analysis, the CVE scan, the coding standard and peer review, signing with four-eyes, the SBOM, and the release gate itself. Five or six items that hold under every kind of pressure.
6. Define the emergency release as expedited, not reduced. This is the sentence that gets tested during a real incident. The approver is reached out of hours; the gate still happens. A gate with a documented bypass is a gate an attacker only has to wait for.
7. Specify the delta assessment as a one-page artifact that can say no. If it can only conclude "tailoring valid", it is a form, not an assessment. Give it a conclusion field with two possible answers.
8. Require a signature on it, and have the release gate check for the signature rather than the file's existence.
9. Write the substantial-modification test as a small number of yes/no questions asked at every release. Five is enough: intended purpose, interfaces, security functions, risk profile, new security-path component. Any yes escalates.
10. Say what "yes" costs — re-classification, conformity route, new risk assessment and threat model, updated documentation, new Declaration of Conformity — and say what it does not change: the support period runs from first placement and does not restart.
11. Record the negative conclusions too. "We assessed this and it is not substantial" is the finding an assessor will probe, precisely because it was decided in your favour.

4. Done when

• Release types are defined by security impact and confirmed before development.
• A phase-by-type matrix exists, and the never-tailorable list is short and absolute.
• Emergency releases are expedited, with no documented bypass of the gate.
• The delta assessment is one page, signed, and capable of escalating.
• The substantial-modification test is a fixed set of questions asked every release, with both outcomes recorded.
• There is an exception path requiring two signatures, and exceptions are reviewed as a pattern.

5. Common mistakes

Tailoring by version number rather than by impact. Deciding the type after the content is known. Letting the "no change to threat model" statement become a checkbox nobody could have ticked differently. Allowing an emergency bypass of the release gate, which is the single most consequential sentence in the document. Never recording a "not substantial" conclusion, so the decision leaves no trace. And treating a large diff as substantial when it only restores intended behaviour, while treating a three-line change that alters the intended purpose as routine.

6. In TRA Studio

Tailoring decides which lifecycle activities run for a given release, so it decides which requirement assignments are actually exercised. Keep the never-tailorable set visible as activities that every release passes through, and treat the delta assessment as a real record with an owner rather than an implied step. A requirement assigned to an activity that this release tailored away is not covered for this release, and that distinction is invisible unless the tailoring decision is recorded somewhere the coverage view can see it.