What is the letter actually for?
It is the artefact a client forwards. A customer’s procurement team, an investor, an acquirer or a board asked whether the software is fit to depend on, and the letter is what answers them without those readers running their own review.
Which means the letter is read by people who were not in the engagement, will not read the full report, and need to know what they are relying on. That shapes what it has to contain.
What has to be in it
Scope, in specifics. Which applications, which environments, which roles, which integrations, and the date range of the work. A letter without a scope is an impression.
Exclusions, stated as exclusions. What was deliberately not examined, and why. A regulator or an acquirer reads this first, and an omission discovered later damages the whole document.
Method, named. What was tested by hand, what was automated, and which published standard the work was scored against. Naming a standard lets the reader compare this letter against the next one.
Findings, rated. Ratings such as strong, satisfactory, moderate and weak across the areas examined, rather than a mark out of ten. A numeric score implies a precision the evidence does not support, and the maturity-rating convention comes from audit practice for exactly that reason.
A date, and what it means. The assessment describes the system as it was. Software changes weekly, and the letter should say plainly that its statements attach to a point in time.
“A letter that could not be wrong is not saying anything.”
— on assessment languageWhat it does not promise
That the software is secure. No assessment can support that sentence, and one that uses it has told you something about the assessor rather than the system.
That nothing will go wrong. The letter describes what was examined and what was found; it does not underwrite the outcome.
That the system will stay in this condition. A release next week can undo a finding, which is why the date and the re-check matter more than the adjectives.
| Says | Reader can rely on | Honest? |
|---|---|---|
| “The system is secure.” | Nothing — unfalsifiable and unbounded | No |
| “No critical issues were found.” | Something, if scope and method are stated | Only with both |
| “These areas were examined against ASVS 5.0 between these dates; ratings and exclusions as listed.” | A specific, checkable claim | Yes |
| “Two critical findings were identified and re-tested as closed on this date.” | The strongest available statement | Yes |
The re-check is part of the product
A finding is closed when it has been fixed and re-tested, not when a remediation plan has been written. An assessment that ends at the report leaves the client to assert their own closure to the customer who asked, which is the weakest possible position for them.
Including a re-check after remediation changes what the letter can say, from findings identified to findings identified and verified as addressed on a stated date. That is a materially stronger document, and it is the version procurement teams accept without a second conversation.
Where we draw the line
We give a professional opinion about what we examined, with liability capped in the engagement. We do not certify, we do not attest to a regulator, and we do not run a public badge programme that turns an assessor into a marketing surface for the client.
The boundary is worth stating in the letter itself. A reader who knows exactly what they are relying on can act on it. A reader who has to guess will discount it.
Article
Published 1 September 2026
By Agile Labs
Agile Labs is a Singapore enterprise software engineering company. We design, build and secure enterprise software and AI systems.
Sources
- Professional assurance reporting practice, including maturity rating precedent.
- OWASP Application Security Verification Standard 5.0.
- Agile Labs Enterprise Readiness Assessment delivery protocol, September 2026.
