Website Security Remediation Plan
Turn audit findings into a plan someone can work: owner, effort, priority, due date, verification step, quick wins first - exported as Markdown or CSV.
Runs locallyEverything happens in your browser. What you paste or drop here is never uploaded, logged or stored.
Use the tool
A list of findings is not a plan
An audit tells you what is wrong. It does not tell you what to do on Monday. The gap between those two things is where most security reports go to die: a list of twenty findings with no owner, no estimate and no order gets read once and filed.
This turns the findings into work items. Each one carries a severity, the actual fix, an owner, an effort estimate, a due date and - the part that usually gets left out - how you will know it is done. A remediation item with no verification step closes on a configuration change that may never have reached production.
How items are ordered
Severity first, then effort. Two critical findings where one takes an hour and the other takes a week are not equally urgent to start, and ordering by severity alone hides that. Everything small enough to finish inside an hour, at medium severity or worse, is also pulled out into a Do these first list - because a plan that opens with a fortnight of work rarely gets started at all.
Effort estimates come from what the fix physically is: a response header is a line of configuration, a TLS protocol change is a configuration change plus a compatibility decision, and a Content Security Policy is a project. They are a starting point and every one of them is editable.
Unknowns become investigations, not fixes
When an audit could not establish something - a responder timed out, a check did not complete - the honest work item is find out, not fix the missing thing. Writing a remediation step for a finding that was never confirmed would be inventing the finding.
These items are marked Investigate and their verification step is different: you close a fix by re-testing the control, and you close an investigation by getting an actual answer. If the plan is built on an audit with gaps, the tool says so at the top rather than presenting a partial picture as a complete one.
Everything stays in your browser
An audit result names a site and every weakness found on it. It is read, planned and exported locally - nothing is uploaded, and the Markdown, CSV and JSON exports are generated on your machine.
Frequently asked questions
Where does the audit JSON come from?
Run the Website Security Audit and use its export button. Any export of schema version 1.x is accepted, including older exports that predate schema versioning - those are upgraded automatically on read.
Can I change the owners and estimates?
Yes. Owner, effort, due date and status are all editable in the table and are carried into every export. Changing an effort re-orders the plan, since effort is the tie-breaker within a severity.
Why does an item say "Investigate" instead of giving me a fix?
Because the audit could not establish the state of that control. The task is to get a definite answer. A control you cannot observe is not a control you can rely on, but it is also not a confirmed problem - and the plan should not pretend otherwise.
Are passing findings included?
No. Passes, informational notes and not-applicable findings are not work. Unknowns are included, as investigations.
Is my audit result uploaded?
No. It is read and processed entirely in your browser, and so are the exports.
References
Related tools
Other Tools
Popular tools from across A2Z
Rate this tool
Was this tool useful? Your feedback helps us improve it.