Security Assessment and Remediation Plan
An organisation running business systems it depends on — some built in-house, some purchased, some inherited — that has never had them tested, and is asking either because a client demanded it or because something happened.
The problem
The organisation cannot say what its exposure is. It is deciding how much to worry based on nothing.
In scope
- Scoped external and internal testing
- Findings ranked by exploitability and business impact
- A remediation plan with effort estimates
- A retest of agreed fixes
- A report written for two audiences — a technical fix list and a summary a board can read
Out of scope
- Fixing everything found — remediation is a separate engagement, deliberately, so the assessment stays honest and is not a sales funnel for the fix.
- Compliance certification — Afivox assesses, it does not certify.
- Physical security and social engineering unless separately scoped and separately authorised.
- Anything outside the written scope, without exception.
What this would cover
Grouped by module — open the ones you want to read.
Scope and authorisation document
- Signed before any testing begins, naming exactly what may be tested, when, and by whom; this protects both parties and is not a formality
Findings register
- Each finding with evidence, exploitability, business impact, affected systems and a fix
Ranked remediation plan
- Ordered by risk against effort, so an organisation with limited capacity knows the three things to do first
Technical report
- For whoever will implement the fixes
Executive summary
- For the board or the client who asked, in plain language, without theatre
Retest report
- Verification that agreed fixes actually landed, which is the part most vendors skip
Data model
- Not a build. Deliverables are documents: scope and authorisation document, findings register, ranked remediation plan, technical report, executive summary, retest report.
Invariants
- Not applicable — this is an assessment engagement, not a deployed system. Findings are reported confidentially to the engaging authority, and Afivox does not publish, reference, or use any client's findings as marketing material, ever — including anonymised.
Offline behavior
Not applicable.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Nobody has a clean first assessment, and the buyer's real fear is not the attacker, it is how they will look.
This has to be said plainly on the page and in the first meeting, because the fear is what stops organisations commissioning the work. An assessment that finds nothing means the scope was too narrow. The report should open by naming that expectation rather than burying it.
Testing production systems carries a real risk of disruption.
The honest positions are a maintenance window, a staging environment that genuinely mirrors production, or a reduced-intensity test with the limitation stated in the report. Pretending there is a risk-free option is how assessments take down a business's order system on a Friday.
End state
What would be true about their day once this is running.
- The organisation knows what its exposure is, ranked, with evidence.
- It has a plan ordered by risk against effort rather than a list of everything.
- The fixes it agreed to have been retested and confirmed.
- The board has something it can actually read.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review