Main idea

Almost every requirement placed around a piece of development is negotiated against what the product at hand has at stake. The level of testing expected of a small throwaway internal tool is not the level expected of a billing module; review, documentation and deployment strategy are dosed the same way, and that is healthy.

Security does not behave like that, because its risk is measured not by how important the tool is but by what it gives access to. A hacked-together internal screen that queries the production database is a door, however seriously anyone takes it; the leak does not depend on the object's intended lifespan, and the attacker does not look up which category the organization had filed it under.

The security requirement therefore has to sit outside the scaling grid, as the one line that depends neither on the mood of the moment nor on the stakes as declared.

Why it matters

It stops a policy of relaxation — justified and useful on tests, review and documentation — from carrying security along with it out of sheer consistency of reasoning. That is the natural slide: the moment you write "low stakes, low formality", security falls into the same basket.

It also makes the rule enforceable, because security is precisely the line where the tooling already exists: continuous integration, scanners, rules and practices held by the development teams do not have to be reinvented for output that comes from elsewhere.

Nuances and limits

The claim holds for the requirement, not for the means. An isolated tool, with no real data and no network exposure, does not call for the same setup as an exposed service — but the difference is about the surface to protect, not about the right not to protect it.

And a non-negotiable requirement is not the same as a requirement that holds: it only counts when it is backed by automatic checks, failing which it reverts to a declaration.

Open questions

• Do other requirements behave the way security does — regulatory compliance, access traceability, reversibility of writes — or is the exception genuinely unique?