What an estate review actually inspects, in order

There is a specific, awkward moment in replacing an IT provider. You need to know what you have in order to decide what running it should cost, and the only current record of what you have is held by the firm you are considering leaving. Asking them for it is both reasonable and a signal, and what you get back, if you get anything, is a spreadsheet that was accurate at some point.

So the first paid piece of work in this division is not a service agreement. It is a fixed-fee review that builds the record from the estate itself, and it is deliberately scoped as something with an end: an inventory, a dependency map and a risk register that are yours to keep, and are worth having whether or not you go any further. This piece is the method, in enough detail that you can run it yourself if you would rather. That would be a good outcome; it is worth more to you than to us, and it is worth most while whoever holds the knowledge today is still reachable.

The one rule: read the estate, not the memory of it¶

Every finding worth having comes from the difference between what the systems say and what people believe. Ask an operations manager how many laptops the company has and the answer will be confident, round and low; it omits the ones in drawers, the four the sales team took, and the eleven that were replaced but never removed from the license count. None of that is carelessness. It is what an inventory maintained in a head looks like after three years.

That has a practical consequence for how a review is run: everything gathered by asking is a lead, not a fact, and has to be confirmed against the system that would know. The interview is still worth doing; it is how you find out what breaks and what everyone works around, but it produces questions rather than answers. Any review that ends with a document assembled from conversations has measured the organization’s beliefs about itself, which is a genuinely interesting thing and not what was bought.

Five passes, and why the order is fixed¶

An estate review runs in five passes in a fixed order, because each pass produces the list of objects the next one has to enumerate. Run them out of order and the result is an inventory with holes in it that nobody can explain, which is worse than an obviously incomplete one because it looks finished.

Identity is first because it is the pass that defines the population. Every later question (which endpoints matter, which mailboxes have data in them, which accounts a firewall rule was written for) is a question about principals, and enumerating assets before you know who exists produces a list you cannot attribute. Contracts are last for the opposite reason: the answer is only meaningful once you know what the contracts are for, and you learn that from the four passes that precede it.

The identity pass, in more detail¶

The identity pass has the highest ratio of findings to hours in an estate review, and almost all of it comes from three enumerations that any directory can produce and almost nobody runs.

• Every account holding a privileged role, cross-referenced against last sign-in. A dormant account with standing administrative rights is the highest-value object in most estates and the one least likely to be noticed, because nothing about it generates a ticket.
• Every account that is not a person: service accounts, shared mailboxes, integration identities, the account the backup software runs as. For each one, who owns it, what it is for, and whether its credential is subject to any rotation at all. Expect at least one whose purpose nobody can state.
• Every guest, federated or external identity with access to anything. This is where former contractors and wound-down vendor relationships persist, because offboarding processes are written for employees.

None of that is exotic and none of it needs specialist tooling; the reason it goes unrun is that it produces work. Which is also the argument for having somebody outside the arrangement run it: an incumbent enumerating the standing access it granted itself is being asked to file a finding against its own housekeeping.

Data survival, which is four claims wearing one word¶

“We have backups” is the sentence that most reliably means less than it sounds like. It bundles four separate claims, and they fail in a strict order; each one can be true while the next is false, and almost every estate satisfies the first two.

A review tests the second and third claims for real, on at least one system that would actually hurt to lose. Not the dashboard, not the report: a restore performed and the result opened. It is the check most likely to return an answer nobody wants, which is precisely why it is worth spending the hours on while somebody who knows the system is still employed.

None of this is a house opinion, and it is worth being able to say so to a board. CISA and MS-ISAC's #StopRansomware Guide asks for the same four things in the same order and in about as many words: maintain offline, encrypted backups, and regularly test the availability and integrity of those backups in a disaster-recovery scenario; keep golden images that a system can actually be rebuilt from; and keep the copies offline, because, in the guide's own reasoning, many ransomware variants go looking for reachable backups in order to delete or encrypt them first. The fourth claim in that table is the same sentence read as a requirement instead of as a warning.

The output, and which part of it is actually the valuable one¶

Three documents come out, and the middle one is the one people underrate. The inventory is the list of what exists. The risk register is the list of what is wrong, ordered worst first, with what each item would take to close. Between them sits the dependency map, and it is the artifact that makes the other two usable.

An inventory tells you that a particular virtual machine exists. The dependency map tells you that the file share the production scheduling spreadsheet lives on is hosted there, that the nightly export another department relies on runs from it, and that it authenticates against a domain controller which is the only one at that site. That is the difference between a list of eighty objects and knowing which four of them are load-bearing. It is also the part that cannot be produced by a scanner, because it is a set of relationships that mostly exist in configuration, in scheduled tasks and in habits.

The risk register is ordered by what it would cost you if it happened, not by severity score. Those two orderings disagree more often than they agree: an unpatched internet-facing service scores high everywhere and may be genuinely less urgent for you than a backup that has never been restored, because one is a scored abstraction and the other is a specific thing that will fail on a specific Tuesday.

What a review cannot see¶

Stating this is the difference between a review and a sales artifact, and there are three real limits.

1. 1.Anything seasonal. A two-week window in August does not observe the month-end close, the annual audit export, or the week in November when the warehouse runs double shifts and the network behaves differently. Those get captured as questions in the register rather than as findings, and they are flagged as such.
2. 2.Anything that requires a third party’s cooperation. Whether a circuit is contracted in your name is answerable from the carrier’s records, and the carrier will not discuss it with someone who is not the account holder, which is itself the finding, and the reason that question is asked before it is needed.
3. 3.Anything under load the estate is not currently under. A review can tell you a link is saturated at four in the afternoon. It cannot tell you what happens the first day everyone is in the building after a change to how they work.

And the whole thing has a shelf life. An estate review is a photograph, and estates drift, a new site, a departing administrator, a vendor’s platform change. What keeps it from aging into fiction is that the inventory and the risk register become living documents maintained as the work happens, which is the same discipline that makes a handover pack worth anything and, not coincidentally, the same documents.

Why this is a fixed fee with an end¶

The review is priced and scoped as a piece of work that finishes, and the reason is that anything else changes what gets written. A free review is a sales visit, and a sales visit finds problems the visitor sells the solution to. A review folded into the first month of a service agreement is written by a party that has already won, at the point when the least flattering possible account of the estate is also the most convenient starting position.

Paid, bounded and yours regardless of what you do next is the only structure where the document has no reason to be anything other than accurate. It also produces the number the whole exercise was for: what running this estate properly actually costs, quoted against what is in it rather than against a seat count, and given to you before you commit to anything.