The Cloud Assessment Was Accurate in March. It Is October.

A report describes one day and says nothing about how long that day lasts

The assessment on the desk is a good piece of work. Every finding was read from a live estate, graded, and traced to the setting it came from. Seven months later it is still the document people quote in meetings, and every sentence reads with the confidence it carried in March.

What happened in between was ordinary. An account was opened for a project that had a deadline. A team adopted a managed service that holds customer data and had no entry in the scope list. Suppose a platform group closed a set of findings in April, and one came back when a pipeline reasserted the definition it builds from. Each of those is visible to the people doing it. The document was finished in March, and a finished document takes no updates.

The report carries no statement about its own durability. A reader in October cannot tell from the page which sentences still describe something real, and the lines that quietly stopped being true look identical to the ones that held.

Four things the document cannot say about itself:

• Which findings were read from a resource that still exists in the configuration described.
• Which parts of the estate were created after the reading and appear nowhere in it.
• Which closures since have survived the deployments that followed.
• Whether the scope in the appendix still enumerates the estate.

A report ages without showing it. In October every sentence reads exactly as confident as it did in March.

Some findings hold for a year and some are stale in a month

A considered view, reasoned from tool agnostic multi-cloud posture assessment: findings decay unevenly, and the difference is large enough to plan around. Findings printed in the same table, carrying the same severity, stay true for very different lengths of time.

The statements that hold longest describe relationships. Which account groups trust each other, how the identity model is shaped, which network path exists because a migration needed it. Changing any of those needs a design, a funded project and a maintenance window, so a sentence written about them in March has to survive all three before it stops describing the estate.

The statements that go stale first come out of counting. A number of accounts meeting a baseline, a proportion of storage encrypted under a managed key, a count of reachable endpoints. Each describes the morning of the export, and every deployment since has moved it.

In between sit the readings of individual resources, and how long each holds depends on something outside it. A setting asserted by an organization policy stays asserted until the policy is amended, or until an account joins the estate somewhere the policy does not reach. Ownership follows the people named in it, and reorganizations do not wait for the assessment cycle.

Sorting a report's own contents by how long each part lasts takes an afternoon:

• Structural statements about trust, network paths and the identity model, which hold until a project changes them.
• Readings of a single resource, which hold as long as whatever asserts that setting goes on asserting it.
• Counts and proportions, which describe the morning of the export.
• Ownership and accountability, which hold until people move.
• Documented exceptions, the one part of the report already carrying the date it expires on.

The events that end a report's usefulness

Assessments repeat annually because a year is easy to budget and easy to remember. An annual cycle is a budgeting rhythm, not a property of the estate. An estate that spent the year in maintenance is served about as well by a twelve month old report as by a three month old one. An estate that closed an acquisition in June stopped being described by anything written in March, and nobody found out until the next scheduled cycle.

What follows is a CWS position. A report should name, on the day it is written, the events that would end its usefulness, specifically enough that somebody recognizes one when it happens. Every event on that list has a witness, and the witness knew within the week.

The list is short, and each entry names a change somebody made on a day they could state:

• An account, subscription or project created outside the process that applies the baseline.
• A region enabled, or a managed service adopted that holds data and was out of scope at the reading.
• An acquisition or a divestiture closing, which changes the estate and the people accountable for it in the same week.
• A change to a trust relationship between two providers, or to the federation humans sign in through.
• An amendment to the policy that asserts the baseline, which changes the standing of every finding it was holding closed.
• A reorganization that moves the owners named against the findings.

An event has a witness. Somebody knew the day the acquisition closed, and a calendar reminder knows nothing at all.

What a report has to say about its own expiry

A shelf life statement is one page, and whoever wrote the report already knows most of what goes on it. The hard part is agreeing to print it, because it tells a reader when to stop trusting the rest of the document.

Start with the reading dates. The date on the cover is the date the report was issued, not the date the estate was read, and across three providers those readings span several weeks. Print each one against the evidence it produced.

Then the assumptions. Every section rests on something the assessment took to be true: that the scope list enumerated the estate, that the policy asserting a baseline was in force. Written down, each is something a reader can test in a minute. Left implicit, each is a way for the report to become wrong quietly.

The last of the five below is the one that gets dropped, and it is what makes the other four work. A trigger needs somewhere to arrive. Name a person, agree what reaches them, and the page starts doing something. It carries:

• The date each evidence source was read, set against the findings it produced.
• The scope as an enumeration of identifiers, so a reader can set it beside today's estate.
• How long each class of finding can be expected to hold.
• The assumptions each section rests on, written as sentences somebody can test.
• The events that trigger a re-look, and the person who is told when one happens.

The delta report and what it has to separate

A second assessment arrives as a second full report in the structure of the first, and reading it feels like starting again. The finding table is rebuilt, the summary rewritten from the top, and somebody on the customer side works out by hand the one thing they wanted, which is what moved.

The comparison is the deliverable. A re-assessment should lead with the movement and keep the full report behind it as the reference: the full document is what an auditor asks for, and the shorter one is what gets opened twice. That ordering is CWS design, argued here rather than borrowed from a published method.

The unchanged entries are the ones to protect from editing. Two readings apart, the identical sentence is the finding, and how long it has stood is what the reader needs.

A delta earns its place when it keeps five states apart that a count of open findings runs together:

• Closed at the first reading and still closed at the second, verified on the resource after the deployments that followed.
• Closed and returned, reported against the original finding, so the record shows how long the estate carried it.
• Unchanged, quoted word for word from the previous report.
• New because the estate itself is new, covering an account, service or region that came into being after the first reading.
• New because the second reading reached further, which is coverage improving and reads as posture declining if nobody labels it.

A finding quoted word for word from the last report says something no percentage says. Somebody has been living with it since March.