SECTION OVERVIEW
An independent read of where you actually stand
An assessment ends in a document somebody has to act on, so we write it for the two people who will: the engineer who has to fix it, and whoever signs the budget that lets them.
Every engagement opens with scope. Systems, environments and dates are agreed in writing before work starts, and the report carries them on its face — along with a classification, because a report about your weaknesses is itself sensitive and is marked and handled that way.
Findings are counted plainly and early: how many issues were found, how many we resolved during the engagement, and how many remain open. A reader should know where they stand before the second page, not after the appendix.
We then trace causes rather than list symptoms. Where several faults share a root, they are presented as a chain — the sequence that produced the failure, each link marked resolved or pending. Three alerts caused by one race condition is one finding, not three.
Recommendations are graded by urgency as well as severity: immediate, urgent, planned. Severity tells you how bad something is; urgency tells you what to do on Monday. Each one names the system it applies to and what finishing it looks like.
The report closes on a path forward — what we would do next, what your team can carry themselves, and what should be retested once the fixes land.
An assessment can stand alone or open a managed engagement. Taking the report and acting on it yourselves is a legitimate outcome, and a common one.
CASE STUDY
Down for two months. Up in two days.
Outage recovery and system stabilisation
The system had been down for two months. ARPACORP was engaged, and it was back up in two days.
It holds tens of millions of biometric records. Nothing was running when we were engaged — the estate was down in full, and we brought all of it back up.
Eight issues were identified across the assessed estate. Six were resolved inside the engagement window. The remaining two were handed over as short, low-risk steps the client’s own team could apply themselves, without further downtime and without us on site.
Those eight findings traced back to three underlying causes, not eight separate faults — which is the difference between fixing a system and clearing a queue of alerts. The most consequential recommendation was procedural rather than technical: the outage originated in an informal, undocumented startup procedure, and replacing it with a controlled one is what stops it happening again.
Two months of downtime, resolved in two days once someone was looking at the whole system rather than the alert in front of them. That gap is the argument for assessment: the same work costs far less before it becomes an incident.
Summarised with operational detail removed. Engagement reports are classified and are not published.