Anyone can write that a door is unsecured. The harder part is writing a finding that helps the client understand why the condition matters and what needs to happen next.
That difference matters because a physical-security assessment is not finished when the assessor identifies a problem. The client still has to understand it, prioritize it, assign responsibility and decide what to do about it.
A poorly written finding creates work for the reader. A good one carries enough of the assessment reasoning with it that the client can act.
Start with the condition, not the recommendation
Assessors sometimes begin writing a finding with the solution already in mind: install another camera, replace the lock, add lighting.
Those may eventually be appropriate recommendations, but starting there skips an important question: What is actually wrong?
Suppose a delivery entrance cannot be observed from the staffed reception point and has no electronic monitoring. That condition should be documented clearly before the assessor decides whether the appropriate response is CCTV, access control, procedural changes or something else.
The finding should describe the problem. The recommendation should address it.
Be specific enough that the client can find the problem again
“Perimeter security is inadequate” sounds serious but tells the client very little.
Which part of the perimeter? What was observed? Under what circumstances?
A useful finding identifies the location or process clearly enough that somebody who was not on the site walk-through can locate and understand it. That might mean a particular gate, employee entrance, camera field of view, visitor procedure, key-control process or storage area.
Specificity matters during follow-up too. It is difficult to verify corrective action if nobody can determine exactly what the original finding referred to.
Explain the security consequence
A condition becomes a meaningful finding when the assessor explains why it matters.
The second version gives the reader more information without resorting to dramatic language. The assessor can then explain the concern created by that condition.
The objective is not to frighten the client. It is to connect the observed condition to a plausible security consequence.
Avoid overstating what you know
Security reports lose credibility when every problem is described in extreme terms.
Not every deficiency is “critical.” Not every unlocked door creates an “immediate catastrophic vulnerability.” If the condition is serious, explain why. If there are mitigating controls, acknowledge them.
For example, a poorly positioned camera may be partially offset by staffed access control during business hours. That does not eliminate the camera problem, but leaving out the compensating measure may make the finding less accurate.
Strong reporting is usually measured rather than dramatic.
Photographs should support the finding, not substitute for it
A photograph is useful evidence of a physical condition. It should not force the reader to figure out what the assessor saw.
If a photograph shows vegetation blocking part of a camera's field of view, the finding should say so. The photograph supports that statement. The client should not need to examine an image and reverse-engineer the assessor's reasoning.
Make the risk rationale visible
Whatever risk method is being used, the client should have some understanding of why one issue receives more attention than another.
That does not require exposing every internal calculation in the main body of the report. It does require avoiding unexplained rankings.
If one finding affects an entrance leading directly into a critical operational area while another concerns a low-use storage space protected by several compensating controls, those facts matter. The reader should not simply see two red boxes marked “High.”
Write recommendations that answer the finding
A recommendation should have a visible relationship to the problem that came before it.
If the finding concerns shared mechanical keys that cannot be accounted for, the recommendation should address key control. If the finding concerns an uncontrolled pedestrian approach to a restricted area, the recommendation should address that condition.
Recommendations become weak when they sound interchangeable between reports: “Improve security awareness.” “Enhance access control.” “Upgrade surveillance.” Those may be headings. They are rarely complete recommendations.
The assessor does not always need to prescribe a particular manufacturer, product or technical design. Sometimes the appropriate recommendation is to establish the security outcome the client needs to achieve and leave detailed design to the people responsible for implementation.
Think about corrective action while writing the finding
A good test is to imagine reading the report six months later. Could the client tell whether the problem had been corrected?
If the finding is vague, verification will be vague too. If the original record identifies the condition, location and expected security outcome, later follow-up becomes much easier.
For the next step in that chain, see Verifying Corrective Action After a Physical Security Assessment.
Before finalizing a finding, read it without the rest of the report. Would it still make sense to someone who had not joined the site visit? Would they know what was wrong? Would they understand why the assessor cared? Could they identify the evidence supporting it? Would the recommendation make sense as a response to that problem?
Physical-security findings do not need to sound complicated. They need to be clear, supportable and actionable.
Keep the path from fieldwork to report visible
Read From Observation to Finding for a broader look at maintaining traceability through the assessment record.
Sources and further reading
Keep findings connected to the field record
FieldFindings Professional keeps observations, supporting photographs and files, risk context, recommendations, corrective actions and reporting together in a structured Windows workspace.
Explore FieldFindings Professional