N100FN100F
Published on

The life of a standard

A standard that never changes ends up ignored; one that changes with no warning ends up broken. Treating it as a product with versions, proposals, review, a transition period and retirement is what keeps it alive and respected.

Service line Multicloud Governance

The frozen document

Many standards are written once, approved in a meeting and never touched again. Two years later they describe technologies nobody uses any more and forbid things everybody does. Teams learn that the standard does not reflect reality, and stop looking at it.

The opposite extreme fails too: standards somebody modifies whenever they feel like it, with no notice, that turn up different on any given Monday.

A cycle with states

The life of a ruleThe states of a rule: proposed, under review, in force, periodic review and retirement, with an example version.GOVERNANCE · LIFECYCLEThe life of a ruleProposedanyone, with a reasonUnder reviewdomain ownerIn forcewith a date and transitionPeriodic reviewevery yearRetired or replacedcites the previous onecontinuesv3.2 · 2026-09 · Tagging: from recommended to mandatoryannounced 30 days ahead · 60-day transition for what existsThe best proposals come out of operations:incidents, recurring exceptions, rules nobody complies with.Example versionN100F · n100f.com

Every rule in the standard passes through known states:

  1. Proposed. Anyone can propose a new rule or a change, with a reason: an incident, a technology change, a legal requirement.
  2. Under review. The domain owner assesses it and adjusts it with the teams affected.
  3. In force, with transition. It is approved with an effective date and a period to adapt. Anything new is required from day one; what already exists has a deadline.
  4. Periodic review. Every so often (once a year, for instance) it is confirmed that it still makes sense.
  5. Retired or replaced. A rule that no longer adds anything is retired; one that changes is replaced by a new version citing the previous one.

Versioning like software

  • Every version of the standard has a number and a date, and a readable list of changes.
  • Changes are announced before they take effect, not afterwards.
  • You can tell which version applied at any point in the past, which matters in an audit.
  • Automated rules follow the standard: when a rule changes, its automatic check changes in the same version.

Where proposals come from

The best proposals do not come from a committee, but from operations: an incident that revealed a gap (as in every failure leaves a rule), an exception that recurs so often it should be the rule, a rule nobody complies with because it makes no sense.

That last source deserves its own article, because well-managed exceptions are the best thermometer of a standard.

How we apply it: Multicloud Governance.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk