N100FN100F
Published on

Exceptions with an expiry date

Every standard has legitimate exceptions. The problem is not that they exist, but that they get forgotten. A healthy exception has an owner, a reason, an accepted risk and an expiry date, and lives in a register somebody reviews.

Service line Multicloud Governance

The permanent exception

'Just this once, until we finish the migration.' Three years later, the migration did not finish and the exception is still there: an open port, an unencrypted database, an untagged account. Nobody remembers who authorised it or why. Multiplied by fifty, that is the real distance between what the standard says and what exists.

What turns an exception into something governed

A well-recorded exception has six pieces of information:

  • Which rule it breaches, cited with its version.
  • Which resource or system it affects.
  • Why it is necessary.
  • What risk is accepted and what measures offset it while it lasts.
  • Who approves it and who is responsible for closing it.
  • When it expires.

Every exception expiresFive exceptions on a timeline: in force, one expiring this month and one overdue.GOVERNANCE · EXCEPTIONSEvery exception expiresJulAugSepOctNovDecJantodayPort 443 in acceptanceJ. SotoUnencrypted database (migration)R. DíazoverdueUntagged accountL. Gilexpires this monthRegion off the listM. RuizLocal user in developmentA. PérezON EXPIRY, THERE ARE ONLY THREE WAYS OUTIt is closedIt is renewed, with a reasonIt is escalatedIllustrative data; they do not correspond to any real caseN100F · n100f.com

The date is what matters

With no expiry date, an exception is a new rule written somewhere nobody looks. With a date, one of three things happens when it comes due:

  1. It is closed: the resource now complies with the standard.
  2. It is renewed, with a new reason and a new date, approved again.
  3. It is escalated, if nobody closes it or renews it.

What cannot happen is for it to carry on existing with nobody deciding so.

The register as a thermometer

Reviewing the exception register says a lot about the standard:

  • Many exceptions against the same rule: the rule is probably wrong, and it is worth proposing a change (as we saw in the life of a standard).
  • Overdue exceptions piling up: the review process is not working.
  • Few exceptions, all with dates: the standard and reality are reasonably aligned.

With the rules and their exceptions under control, what remains is taking all of this to several clouds at once. The first governance decision in any cloud is also the most structural: how the accounts are organised.

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