Security · Backend

What a two-week assessment actually checks

A zipper manufacturer had an ERP that had been running for ten years. Management had been told more than once that it was time for a rewrite, and the question they actually wanted answered was narrower and harder: is this safe to keep?

That is a good question and it does not have a graded answer. "Seven out of ten" tells a board nothing it can act on. So the output of an assessment is not a score, it is a prioritised list of fixes with each one sized in hours — which is the only format that lets someone decide between doing the work and replacing the system.

The code was better than feared. That is the most common finding, and almost nobody is paid to report it.

What gets worked through

Two weeks is not long enough to read everything, and reading everything is not the job. The job is to find the things that would hurt, in the order they would hurt. On this system that meant:

  1. How credentials are stored and handled. Password storage first, because it is the finding with the widest blast radius and the one least likely to have been revisited since the system was written.
  2. Where database credentials live and who or what can read them.
  3. The server stack — what is running, what version it is on, and what has stopped receiving security updates.
  4. Whether anything is tested automatically, which determines the cost of every fix that follows.
  5. The shape of the data — whether the figures the business runs on can be reconciled from the schema, or only by hand.

Four of those came back at the top severity band and one a step below. The specific findings are listed, with severities, on the case study.

Why "sized in hours" is the whole deliverable

Every finding carries an estimate, and the estimates are in hours rather than days or story points. Hours are uncomfortable to commit to and that is the point: an estimate that cannot be wrong is not an estimate, it is a hedge.

The total for the critical findings on this system came to eight hours. Ten years of accumulated fear, and the work that stood between the client and a system they could trust was one working day.

That number is the argument for assessing before deciding. A rewrite had been floated three times. Nobody had priced the alternative, because pricing the alternative requires someone to look.

The part that makes it repeatable

An assessment is only useful if its commercial shape is fixed before it starts. Two weeks, a price quoted upfront, a report and a plan as the deliverable, and no commitment afterwards.

The last clause does most of the work. A cautious buyer who has been burned by open-ended consulting reads "no commitment after" and understands that the assessment is not a sales mechanism with a predetermined conclusion. It also keeps us honest: if the right recommendation is to keep the system and fix four things, there is no incentive structure pushing against saying so.

Start with a straight answer.

A fixed-price technical assessment, with no commitment afterwards. Or simply book a call.