How to prove you fixed it
Finding a security problem is one job. Proving you fixed it is a different one, and most tools only help with the first. If you are still working out what you expose in the first place, start with the attack surface management guide.
The difference matters because the person who needs convincing usually was not there. A manager approving next year's budget, an auditor asking for evidence, a customer sending a security questionnaire, an insurer pricing a policy - none of them watched you fix anything. They need something they can read.
This page is about building that something.
Why you are being asked for this now
In an open letter published in August 2026, 116 organisations - including Microsoft, Google, AWS, Cisco, Cloudflare, CrowdStrike, IBM, Oracle and Palo Alto Networks - called on every organisation to remove their riskiest weaknesses and verify the results without disrupting essential services. (A call for collective action on cyber defense, OpenAI)
That second half is the part that changes work. "We patched it" has been an acceptable answer for a long time. It is becoming a less acceptable one.
What counts as evidence, and what does not
A screenshot of a clean scan is not evidence. It has no before, it has no date you cannot edit, and you produced it yourself.
Evidence of remediation needs four things:
1.
A before. The problem, as it was, with a date.
2.
An after. The same check, run the same way, with a later date.
3.
A method. What was checked and how, so the two are comparable.
4.
A source that is not your own assertion. Something generated by a tool, not typed by the person being asked.
Miss any one and you are back to being believed rather than being shown.
The cheapest way to have all four is to be measuring before anyone asks. Evidence cannot be produced retroactively - if there is no record of the problem, there is no way to show it is gone.
What each audience actually wants
They are not asking the same question, and sending all of them the same PDF is why this usually goes badly.
| Who is asking | What they actually want | What to send |
|---|---|---|
| Your management | Did the money we spent change anything? | One number over time. A grade that moved from D to B says more than forty resolved findings |
| An auditor | Can you demonstrate a control operates? | The dated before, the dated after, and the method. Detail is welcome here |
| A customer's security review | Are you a risk to us? | A current summary, shareable, that does not require them to create an account |
| An insurer or a procurement team | Is your posture improving or decaying? | The trend, not the snapshot |
The common failure is sending an auditor's level of detail to a manager, or a manager's summary to an auditor. The first is ignored; the second comes back with questions.
How to build the trail
This works with any tool that keeps history. The sequence matters more than the product.
1. Establish the baseline before you fix anything. This feels backwards and it is the step people skip. A scan run today, while problems still exist, is the "before" you will need in three months. Once it is fixed, that record cannot be created.
2. Use one measure that survives translation. Finding counts go up when you look harder, which makes improvement look like decline. A single graded measure moves in the direction a non-technical reader expects.
3. Re-run the same checks on a schedule, not by hand. Two scans run differently are not comparable, and an evidence trail with a gap in it invites the question you least want.
4. Keep the history long enough to matter. A month of history proves a fix. A year proves a programme. Whatever your tool retains is the longest period you can ever demonstrate - check it now rather than in December.
5. Record the fix, not just the result. What was changed, by whom, when. The scan shows the problem stopped; this shows it stopped for a reason and not by accident.
How AYAsec does this
Every scan produces a 0-100 score and a grade from A+ to F, so the before and the after are one comparable number rather than two lists.
Scans can run on a schedule, which means the record accumulates without anyone remembering to produce it. If a grade drops between scans, you are told - you do not have to notice.
Reports export as PDF in two forms: brief for the audience that wants the conclusion, full for the audience that wants the working. Any report can also be turned into a shared link that opens without an AYAsec account, which is usually what a customer's security review actually wants.
How much history you keep depends on your plan: seven days on Free, thirty on Starter, with audit export available from Pro. Free is enough to see whether this works for you. It is not enough to prove anything in December, and that is worth knowing in September rather than in December.
What this is not
AYAsec produces findings, grades and a dated record. It does not produce a compliance attestation or a certificate. Nobody can hand you one of those from a scan - certification involves an assessor, and evidence like this is an input to that process rather than a substitute for it.
If someone tells you their scanner makes you compliant, that is a claim worth reading twice.
Frequently asked questions
We fixed things before we started measuring. Can we still show it?
Not for those fixes, and no tool can change that. Start the record now so the next round is provable.
Is a grade enough on its own?
For management, usually. For an auditor, no - they will want the underlying findings and the dates, which is what the full report is for.
How far back should we keep evidence?
Long enough to cover whatever cycle you are asked about. Annual budget conversations and annual audits both mean a year is the practical answer.
Can we show this to a customer without giving them access to our account?
Yes. A report can be shared as a link that opens without an account, and the link can be revoked.
Does a clean report mean we are secure?
It means those checks passed on that date. That is a useful thing to be able to show, and it is not the same claim.