Normative Requirement Style

The release review says that customer exports must be “properly protected.” The API owner has added authentication, the data team has encrypted the export bucket, and the security reviewer expected an object-level authorization check before each export job. All three can claim compliance because the requirement never made the decision visible.

A security requirement is an agreement about observable system behavior. It should tell an engineer what must be true, a reviewer where the rule applies, and an operator what evidence remains after the software runs. If those readers can reach different answers without contradicting the sentence, the requirement is not ready to govern a release.

Start with the disputed decision

Use normative requirements for security catalogs, architecture-review conditions, release gates, policy-as-code rules, exception remediation plans, vendor obligations, and incident follow-up controls. Broad principles and design notes serve a different purpose: they can orient judgment without pretending to be pass-or-fail rules.

Before drafting, identify the decision the sentence must settle. For the export endpoint, the unresolved question is not whether exports should be secure. It is whether possession of a valid session is enough to retrieve any export job, or whether the server must authorize the caller against that particular tenant and export. The second statement can govern code and tests; the first can only invite agreement.

Write one controlling obligation at a time. If a sentence governs authorization, retention, alerting, and exception approval, a team can satisfy part of it and still argue that the requirement passed. Split obligations when they can fail, be owned, or be excepted independently.

Build the sentence from its decisions

Use this pattern as the default:

[Control ID] [Applicability]. The system MUST/SHOULD/MUST NOT [specific action or property] when [condition], using [approved mechanism or design pattern]. Verification: [test, review, monitor, or evidence].

The control ID gives the decision a stable reference; do not renumber it whenever wording or document order changes. Applicability narrows the population by system class, exposure, data class, assurance level, or role. The normative verb states the force of the rule. The action and condition describe observable behavior, while the mechanism constrains implementations only as far as the threat demands. Verification names an independent way to challenge the claim.

Soft verbs conceal missing decisions. “Ensure,” “harden,” “protect,” and “monitor” may express intent, but they do not say what the system does. Replace them with behavior a reviewer can inspect: reject a cross-tenant request, obtain a short-lived credential, verify an artifact signature, emit an authorization-denial event, or restore a named data set within a declared boundary.

The export requirement can now be written:

AUTHZ-API-004 [tenant-scoped export endpoints, Level 2+]. The API MUST authorize every read, download, cancellation, and deletion of an export job on the server using the authenticated subject, action, export resource, and tenant context. Verification: negative cross-user and cross-tenant tests, review of the policy enforcement point, and retained authorization-denial events.

Each phrase closes a real escape route. Applicability prevents the rule from drifting into unrelated endpoints. “Every” covers secondary actions such as cancellation and deletion. “On the server” rules out a user-interface check presented as authorization. The named inputs make the policy reviewable. Negative tests attempt the bypass, and denial events let operators investigate it later.

Normative Verbs

Use uppercase normative words consistently. MUST and MUST NOT mark required and prohibited behavior for the stated applicability. SHOULD and SHOULD NOT define an expected default that may be departed from through the book’s exception process. MAY identifies a permitted choice, not work that a reviewer should expect.

Avoid phrases such as “must where possible” and “should always.” Each combines incompatible force levels. If migration state or platform capability changes the obligation, say which systems are in scope now and write the exception or transition requirement separately.

Complete Requirement Record

The normative sentence is only the decision surface. Its catalog record should preserve the reasoning and operating context needed to maintain it:

• a stable control ID and concise title;
• the requirement and its exact applicability;
• the threat, failure mode, or assurance need that supplies the rationale;
• approved implementation guidance and shortcuts that do not satisfy the rule;
• a verification procedure that can fail, not merely a document to collect;
• the resulting evidence artifacts and their retention expectation;
• common bypasses, especially plausible ways to satisfy the words while missing the threat;
• related threats, controls, and incident or operating playbooks;
• framework mappings when they help assurance work rather than replace engineering proof;
• the owner role, review trigger, and exception route.

Keep rationale out of the obligation when it would make the sentence harder to test. Keep implementation guidance outside it when several mechanisms control the same threat. The requirement should constrain the security property; guidance can evolve as platforms change.

For example, “Secrets must be protected” provides neither a boundary nor a failure test. A useful catalog separates secret delivery from prohibited storage:

SECRETS-RUN-002 [production workloads]. Production workloads MUST obtain runtime secrets from the approved secrets manager through workload identity and short-lived access. Verification: deployment-manifest review, workload-identity policy, and a rotation drill record.

SECRETS-STORE-003 [repositories and production delivery artifacts]. Production secrets MUST NOT be stored in source code, container images, chat messages, tickets, or unencrypted environment files. Verification: repository and artifact secret-scanning results, delivery-config review, and leak-response test records.

These are two obligations because they can fail independently. A workload might use the approved manager while an old credential remains in an image; a team might remove embedded credentials while retaining a long-lived manually distributed secret. Separate statements make both failures visible and allow remediation or exception handling to address the right one.

Exception Language

Write exception rules as requirements, not side conversations.

EXC-SEC-001 [all accepted security exceptions]. A security exception MUST name the risk owner, affected systems, compensating controls, detection plan, expiration date, review cadence, and evidence required for reapproval. Verification: approved exception record and alert or control evidence attached to the release review.

Never append “unless approved” to a control. That phrase creates an unnamed authority with no expiry. An exception must identify the risk owner and affected systems, describe compensating controls and detection, set an expiration and review cadence, and name the evidence required for reapproval. The exception changes neither the original requirement nor its meaning; it records a bounded decision not to meet it.

Review Checklist

Before adding a requirement to a catalog, give it to someone who did not draft it and ask them to decide what would pass. Then check:

• The requirement has one controlling obligation.
• The applicability is narrower than “all systems” unless that is genuinely true.
• The mechanism is specific enough for implementation review.
• Verification can be performed by someone who did not write the requirement.
• The proposed verification can disprove compliance, not merely confirm that a document exists.
• Evidence is named, attributable to the applicable system, and collectible during normal engineering work.
• Common bypasses are listed when the rule is easy to game.
• The rule does not hide legal, contractual, or policy advice inside engineering language.

Now try to defeat the requirement. Could a team satisfy the text with a client-side check, a screenshot, a test against one happy-path account, a control that never runs in production, or evidence that cannot be tied to this system and release? Could two careful reviewers disagree about whether SHOULD blocks release? Could an exception remain open after its compensating control disappears?

Every credible bypass should lead to one of three decisions: tighten the obligation, strengthen the verification, or record a residual risk that the control does not claim to solve. Do not keep adding clauses until the sentence becomes unreadable. Split independent obligations and preserve their relationships in the catalog.

Field Reference

Requirement sentence:

[CONTROL-ID] [applicability]. The system MUST/SHOULD/MUST NOT [specific action or property] when [condition], using [approved mechanism]. Verification: [test, review, monitor, drill, or evidence].

Release-gate rule:

If two independent reviewers cannot reach the same pass, fail, or exception decision from the requirement and its evidence, rewrite it before using it as a release gate.