N100FN100F
Published on

A standard you can actually comply with

IT standards tend to fail through excess: too long, too vague, impossible to verify. A useful standard is short, neutral, says what is mandatory and what is not, and every rule can be checked.

Service line Multicloud Governance

The hundred-page standard

Almost every organisation has one: a long document, written with good intentions, mixing principles, recommendations, obligations and examples. Nobody reads it all the way through, nobody knows which part is mandatory and nobody can check whether a design complies with it. In practice, it governs nothing.

Five traits of a standard that works

Short. Each rule in one or two sentences. Long explanations go separately, linked.

Neutral. It describes what is required, not with which tool or from which provider. 'All data at rest is encrypted' survives a change of cloud; 'switch on option X of service Y' does not.

With an explicit level. Each rule says whether it is mandatory, recommended or advisory. Without that distinction, everything looks mandatory and nothing gets complied with.

Checkable. Every mandatory rule answers the question 'how do I know it is being met?'. If there is no answer, it is not a rule, it is a wish.

Separate but assemblable. One standard per topic (identity, network, data, cost, documentation), each independent, that can be combined into a single document when needed.

From vague to checkable

From vague to checkableThree rules rewritten from their vague version to a checkable one, with their level and how they are checked.GOVERNANCE · THE STANDARDFrom vague to checkable'Adequate security'cannot be checkedAll data at rest and in transit is encryptedMandatoryChecked with: automatic policy'Clear names'cannot be checkedPattern: environment-application-componentRecommendedChecked with: plan review'Control the costs'cannot be checkedOwner and cost centre tagsMandatoryChecked with: compliance reportShort, neutral, with an explicit level, checkable and by topic.Making it your own is not inventing: it is writing down decisions taken.N100F · n100f.com

Most of the work of writing a standard is this: taking a reasonable intention and turning it into something that can be verified. 'Adequate security' cannot be reviewed; 'all data at rest and in transit is encrypted' can, and it can also be checked automatically (as in rules as code).

Based on what already exists

Your own standard does not have to invent everything. The sensible approach is to start from recognised frameworks (each provider's well-architected frameworks, security standards, FOCUS itself for cost) and adapt them to the organisation. What makes the standard your own is not originality, but that it reflects decisions that were taken and written down.

A standard like that starts going out of date the day it is published. That is why it needs a lifecycle.

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