The ninety days after a red team report

What should you not do in the first week?

Four things. Do not start fixing individual findings, because the categorisation has not happened yet and you will spend the available attention on the cheapest items. Do not discipline anyone, including whoever clicked and whoever missed the alert, because the next real incident depends on people reporting early. Do not buy a product in the week after a debrief, when the failure feels like a tooling gap and the vendor conversation is easy. And do not circulate the full report widely, because it is an attack plan for your estate.

The one thing worth doing immediately is dealing with anything the engagement left live. Rotate every credential the team captured, revoke the exercise footholds, remove any persistence they installed, and confirm removal rather than accepting an assurance. This is a checklist item with a name against it, closed within days.

Then hold the joint debrief while the detail is fresh, with the testers, the defenders and someone who can authorise spend in the same room for half a day. If the calendar cannot accommodate that within a fortnight, the engagement will produce a filed document, and you would have been better off spending the money on the log pipeline.

How do you tell a symptom from a root cause?

Ask what would have had to be true for the finding to be impossible rather than merely fixed. A finding that a service account could list secrets across namespaces is a symptom; the root cause is that workload permissions are granted broadly by default and nobody reviews them, which produced that finding and will produce three more. Fixing the role closes one path. Changing how roles are issued closes the class.

Three examples worth recognising. Phishing succeeded, so the fix is training: no, the root cause is that a stolen password and an approved prompt are sufficient to authenticate, and the structural answer is phishing-resistant authentication for the accounts that matter. A container escape worked through a host path mount: the root cause is that no admission policy constrains what workloads may request, and the mount was the first one anyone looked at. Activity was invisible for eleven days: the root cause is a log source that was never routed, and no rule will fix it.

Keep the list of causes to five at most. The constraint is deliberate: these programmes fail not because the right causes were unknown but because thirty items of equal weight left nobody accountable for any of them. Five sentences with five names, reviewed monthly, outperforms a tracked spreadsheet of two hundred findings every time.

Write the causal statement for each cluster of findings in one sentence, and make somebody own the sentence. Anything with no plausible structural sentence behind it is genuinely a one-off defect, and belongs in the ordinary backlog rather than in the programme.

What does a ninety day plan look like?

Three phases, with the immediate hygiene separated from the structural work so the second does not wait for the first. The evidence column is what makes each item closeable, and an item with no evidence definition will still be open in a year.

Which structural fixes actually change the next result?

Four categories, in the order they usually pay. Authentication strength for privileged and administrative access, because credential theft is the mechanism behind most of what follows and phishing-resistant factors remove a whole branch of the attack tree. Then the permission model: least privilege on workload identities and cloud roles, with a review mechanism, since blast radius decides how bad any single compromise turns out to be.

Third, log routing and retention for the layers that were blank in the timeline, which in most organisations means the cloud control plane, the container platform and the build system. This is the least visible work and the one that determines whether next year's engagement can be measured at all. Do it as plumbing with a storage budget rather than as a security project needing a business case.

Fourth, policy enforcement at the point of deployment, because it is the only control that scales in a container estate. An admission policy that refuses privileged containers, host path mounts, host networking and images from unapproved registries prevents a class of finding permanently, and it is far cheaper than detecting the same conditions afterwards. Roll it out in audit mode first, read what it would have blocked for a fortnight, then enforce, because enforcing first is how these projects get abandoned.

What do you retest, and when?

Retest the objective, not the findings. Verifying that a specific vulnerability was patched is a five minute check anyone can do. The question worth paying for is whether the same objective is still reachable and whether it is now visible, which requires the same starting position, the same goal and preferably the same testers, so agree the retest and its price when you commission the original engagement.

Ninety days is the right interval for the detection half and too soon for some of the structural work. A practical split is a short retest at ninety days covering the detection gaps and the specific path taken, then a full engagement at twelve months with a different starting position to widen the coverage. Reusing the same foothold twice in a row measures progress; using a new one measures a new area, and you need both over time.

Budget for the retest at commissioning rather than hoping for it later. Once the initial report has been absorbed, the internal case for spending more on the same subject is much harder to make, and the retest is where the value of the whole programme becomes visible. Buying it as part of the original engagement removes that conversation entirely.

Insist that the retest report presents the two timelines side by side with the original. That single comparison is the artefact that justifies the whole programme internally, and it is the only defensible way to show a board that the spend changed something.

What can you tell the board and your customers?

For the board: the objective, whether it was achieved, the timings, the three to five root causes, and what each fix costs. Not the technique detail, and not a maturity score. The question they are really asking is whether the security spend is buying capability, and the answer is a comparison of this year's timings against last year's, stated in plain terms with the uncomfortable part left in.

For customers, share an attestation rather than the report. A short statement that an independent objective-based exercise was conducted in a stated period, that the findings were categorised and remediated on a stated schedule, and that a retest was performed, signed by the supplier where they will do it. Sending the report itself distributes a map of your estate to a mailing list you do not control, and it is not what the questionnaire needs.

Where the exercise touched real data or a real incident occurred during it, notification obligations depend on your jurisdiction and sector, and that determination belongs with counsel rather than with the testing team. The questions to put to them are narrow: did any regulated data get accessed in a way that requires reporting, does the contract with any affected customer require notice, and does the retention of the testers' evidence create an obligation of its own.