Two things get sold under the same name. One is a scan: automated tooling pointed at your systems, producing a list of known issues. The other is a penetration test: a person trying to get in, using the scan as a starting point and their judgement for everything after.
Both are useful. They cost differently and they tell you different things, and being sold the first while paying for the second is common.
Two different purchases
Automated scan
- Tooling checks against a database of known issues.
- Fast, repeatable, inexpensive.
- Finds missing patches and obvious misconfiguration.
- Produces a long list, ranked by generic severity.
- Cannot chain small issues into a real attack.
Penetration test
- A person actively tries to reach something that matters.
- Slower, more expensive, scheduled.
- Finds logic flaws no scanner can describe.
- Produces findings tied to your actual business risk.
- Shows how three minor issues combine into one serious one.
The chaining is the part worth paying for. Scanners rate issues in isolation. An attacker does not care about your severity ratings, they care that a low-rated information leak plus a weak password policy plus an over-permissive role gets them to your customer data. Only a person joins those up.
What findings are actually worth
A report with two hundred findings is usually worth less than one with twelve. Volume is easy to produce and expensive to act on.
What makes a finding useful
Tied to something the business would actually lose
Reproducible, with clear steps
Comes with a specific fix, not a category
Ranked by your risk, not generic CVSS alone
Written so the person who must fix it understands it
We write findings for three readers, because three different people have to act on them. The owner needs to know what it would cost the business. The IT lead needs to know what to prioritise this month. The engineer needs to know exactly what to change. One document, three registers.
Where POPIA fits
POPIA requires that you secure personal information you hold, using measures appropriate to the risk. It does not name tools or mandate an annual test. What it does mean in practice is that if something goes wrong, you need to be able to show you took reasonable steps, and "we never looked" is not one.
There is also a notification duty. If personal information is compromised, the Information Regulator and the affected people have to be told. Knowing what you hold and where it lives is what makes that possible on a bad day.
The order that works
From nothing to defensible
- 1
Inventory
What systems exist, what personal information they hold, and who can reach them. Most organisations cannot answer this on day one.
- 2
Scan
Automated coverage across the estate to clear the known and the obvious cheaply.
- 3
Test
A person going after what actually matters, chaining what the scan found.
- 4
Fix and re-test
Findings closed, then verified. An unverified fix is a belief, not a fact.
That last step gets skipped more than any other. A report is not a security improvement. The improvement happens when things are changed and someone checks that the change worked.
What to have ready
Before commissioning a test
- A list of the systems, domains and applications in scope.
- Written authorisation from whoever owns each of them.
- What you most fear losing: customer data, money, uptime, reputation.
- Whether the test should be announced to your team or not.
- Who will own the fixes, and what capacity they have.
- Any compliance deadline that shapes the timing.
Authorisation matters more than people expect. Testing systems you do not own, or cannot prove you were permitted to test, is a legal problem rather than a technical one. Anyone credible will ask for it in writing before they start.
If you are not sure which of the two you need, tell our concierge what you are protecting. It scopes the work with you and passes a proper brief to the team.