How to write security findings for systems that are still being implemented

Security professionals are often asked to write formal findings against systems that are still being built.

The target may be a partially implemented application, platform, or network. Some elements may have been reviewed hands-on, others only at a design or configuration level, and some areas may still be unsettled. The project team wants something they can act on inside real constraints. Management wants the bottom line, but with enough nuance to judge where the work stands now and where it is likely to land if the team delivers what it says it will deliver.

This is usually the point where the report becomes either mush or fiction. The finding turns into caveat-laden mush, or it hardens into a level of certainty the evidence does not support.

State what was actually assessed, and in what state. Point in time assessment is not filler. It tells the reader that the conclusion attaches to the implementation as it existed when you looked at it, not to the cleaner or more complete version shown on an architecture diagram or promised for later. If the system is an in-flight pre-production environment, say so. If parts of the final implementation are still being confirmed, say that too.

Security reports on work in progress usually mix at least five variables:

• what exists now
• what was assessed hands-on
• what is still TBD
• what the implementation team says it intends to do
• when the report and any meaningful follow-up testing can land

Those variables should not be blurred together.

Team intent is the easiest place to lose discipline. Stated intent can affect how you frame the current position and what you expect the residual risk to be if the team follows through. It should not be written up as if it were already implemented fact. If a risk looks lower because the team has agreed to do Y, say that explicitly. Do not quietly rewrite the finding as though Y already exists.

A report may combine document review, design review, configuration review, control validation, and hands-on penetration testing. Those are not interchangeable. One of the practical questions is when hands-on penetration testing will be most meaningful.

It is not enough to say that testing will happen later. The useful part is why. Sometimes hands-on penetration testing before go-live is worthwhile. Sometimes the platform is still moving, key controls are not settled, or earlier evidence already covers part of the ground and the better use of time is to test the final implementation. The report should explain that reasoning, because the timing is part of the assessment story, not an administrative note.

Report timing matters as well. A draft may need to land before a change control board, a go-live meeting, or another governance checkpoint. That does not excuse sloppy wording. It means the wording has to separate current evidence, implementation intent, and deferred validation cleanly enough that the document is still useful under time pressure.

The same applies to executive summary writing. If the implementation is still moving, I would usually defer a substantive executive summary until the final report. A holding statement is often enough in the draft: a short note on the current phase, the material risks already visible, and the recommendations that follow from them. That avoids spending time polishing management language around positions that are still likely to move, and avoids inviting premature arguments about statements made too early.

Implementors need to know what you found and what can realistically be done next, given the constraints of the programme. Management needs a bottom line that does not hide uncertainty, plus enough detail to judge whether the current position is acceptable and whether the stated plan is likely to close the gap.

Security report authors often fall back on templated wording, and that is usually too generic to be useful. The better direction is succinctness with nuance. The catch is that once you start tightening, it becomes easy to chop too much. That is especially true if you ask an LLM for help. They are famous for verbosity, but mature users know they can also be excellent at conciseness, sometimes too good. A cleaner sentence is not better if it drops the identifiers that tell the reader which component, interface, control, or data path the finding is actually about. A shorter sentence is not better if the reader is left wondering which bit is risky. A finding about an export control should stay clearly about export. A finding about an administrative interface should stay clearly about the administrative interface.

Most of these decisions are better made up front. If the engagement is likely to mix partial implementation, staged assurance, draft reporting ahead of governance checkpoints, and later hands-on penetration testing, agree that approach with the client or project team early. The project timeline will dictate much of the timing. Your job is to recognise the right points to punch in: where the work still has leverage, where formal reporting adds value, and where later testing can answer questions that the current phase cannot.

After reading your findings, an implementor should be able to tell what exists now, what was tested, what still has to be validated, and what the team has only said it will do. Management should be able to tell the same story at a higher level and judge the current risk accordingly. That means not under-hedging and implying certainty you have not earned, but not over-hedging to the point that the finding dissolves into caveats. If the wording does not make those distinctions plain, the finding has failed even if the prose sounds polished.