When we assess a technology environment for the first time, we are usually brought in for a specific reason, a recurring fault or a piece of work that needs scoping. What we find is rarely limited to the thing we were asked about, and after enough of these assessments a pattern becomes difficult to ignore.

Three findings appear with such regularity that we now check for them before anything else. None of them are exotic and none require specialist tooling to identify. They persist because they are nobody’s specific responsibility, they produce no symptoms while everything is working, and they become visible only at the moment they are most expensive.

These are worth checking in your own environment, and you do not need us to do it.

One: nobody can produce an accurate picture of the environment

The first thing we ask for is documentation, meaning a current record of what is connected to what, which party supplied and supports each element, where each service is hosted, and when things were last changed. In the overwhelming majority of cases no such record exists, or one exists that was accurate at some point in the past and has quietly diverged from reality since.

This is entirely understandable. Environments are built incrementally, by different people, over years. A connection is added, a device is replaced, a service is migrated, a supplier changes, and each of those decisions is documented at best in an email thread that nobody can now locate. Nothing breaks, so nothing prompts anyone to reconcile the picture.

The cost arrives later and in three forms. Diagnosis becomes slow, because every incident begins with reconstructing the environment from memory before anyone can reason about it. Change becomes risky, because nobody can confidently predict what a modification will affect. And planning becomes guesswork, because you cannot make good decisions about what to invest in when you do not have a reliable account of what you already have.

The fix is unglamorous and permanent. Build the picture once, properly, then keep it current as part of how changes are made rather than as a separate exercise that never gets scheduled.

Two: access that should have been removed years ago

The second finding is access that outlived its purpose. Accounts belonging to people who left the business, sometimes years earlier. Contractor logins from a project that finished. Shared credentials that circulated to a group of staff and were never rotated afterwards. Administrator rights granted temporarily to solve something urgent and never revoked. Service accounts created by a supplier who is no longer engaged, which nobody can now confidently say is safe to disable.

The reason this accumulates is structural rather than careless. Granting access is triggered by a clear event, somebody needs something in order to do their job, and it happens immediately. Removing access is triggered by nothing at all. Offboarding processes reliably collect the laptop and the access card and reliably forget the seven systems that were provisioned individually over three years by different people.

Each of these represents a route into the business that is not associated with anyone currently accountable for it, which is precisely the sort of access an attacker looks for, because it is unlikely to be monitored and its use is unlikely to be questioned. It is also, notably, the sort of exposure that no security product will flag, because from the perspective of the system the login is entirely legitimate.

The fix is a periodic access review, conducted seriously rather than as a formality, in which every account is matched to a named person who currently requires it and anything unmatched is removed.

Three: recovery that has never actually been tested

The third finding is the one with the greatest potential consequence. Almost every business we assess has backups configured. A meaningful proportion of those have never been tested by performing an actual restoration, and a smaller but real proportion turn out, on inspection, not to have completed successfully for some time.

Backups fail quietly. A storage location fills. A credential expires. A change to a folder structure means something is no longer included. A job runs and reports success while capturing an incomplete set. None of these announce themselves, because the whole point of a backup is that nobody looks at it until the day they need it, which is the worst possible day to discover a problem.

The same applies to failover connections and to recovery procedures generally. An arrangement that has never been exercised is an assumption rather than a capability. In our experience the first genuine test of an untested recovery configuration reveals at least one issue more often than not, and the issues are usually mundane and would have taken an hour to fix in advance.

The fix is to perform a real restoration on a schedule, document that it worked, and treat the absence of a recent successful test as equivalent to having no backup at all, because functionally it is.

What these three have in common

None of these findings are the result of anyone doing their job badly. Each supplier in a fragmented environment is responsible for their own component and performs adequately against it. What none of them is responsible for is the condition of the environment as a whole over time, and all three of these findings are conditions of the whole rather than faults in any part.

That is the gap our practice exists to close, and it is why we begin every client relationship by establishing an accurate picture of what is actually there. Not because documentation is interesting, but because everything else, diagnosis, security, planning and recovery, depends entirely on it and quietly degrades without it.

We will be returning to each of these in more depth over the coming months, starting in September with the discipline of governing an environment properly rather than simply operating it.

If you cannot confidently answer all three of these questions about your own environment, that is worth an hour of conversation. Siyaxhuma runs structured environment assessments for South African businesses. Get in touch.