How do you fit web application security scanning into an existing compliance programme?

You fit web-app scanning into a compliance programme the same way you fit any control in: give it a trigger (when it runs), an owner (who acts on it), and a record (what proves it happened). The scan itself is the easy part — the discipline is wiring the output into whatever register, risk log, or evidence file your compliance process already uses, so a finding doesn’t just sit in a PDF nobody reopens.

Most South African small and medium businesses we work with aren’t running a mature GRC platform. They’ve got a POPIA compliance file, maybe a risk register a director reviews annually, and an insurer or bank that occasionally asks “what have you done about security?” That’s a real compliance framework, even if it’s a folder rather than software. Scanning has to slot into that folder, not replace it.

Three points where scanning belongs

At release. Before a new feature, a redesigned client portal, or a new payment integration goes live, that’s the highest-value moment to run a Deep Scan. New code is where new vulnerabilities are introduced, and testing it before customers touch it means any finding gets fixed before it’s an incident rather than after.

After significant change. Not every commit — most changes are cosmetic or backend-only and don’t touch the attack surface. But a new login flow, a new file upload feature, a new integration with a third-party API, or a platform migration all change what an attacker can reach. That’s a re-scan trigger, and it’s worth writing down as a rule in your change-management process rather than relying on someone remembering to ask.

On a recurring cadence. This is where our Monitoring Retainer fits — quarterly re-scans with alerts, run on a schedule rather than only when someone thinks of it. Applications drift: a plugin updates, a configuration changes, a new subdomain gets stood up. Point-in-time testing tells you the state of your app on the day we tested it, not the day after. A quarterly cadence catches drift before it becomes a finding an auditor catches first.

Between those three triggers you’ve covered the honest version of “continuous” — not an always-on scanner (we don’t run one; Deep Scan is operator-run, not an unattended bot), but a predictable rhythm that a bank, insurer, or auditor can actually see.

Where the findings go in your register

Every Deep Scan finding we report is mapped to four reference frameworks: MITRE ATT&CK (the technique an attacker would use), NIST CSF (which of the Identify/Protect/Detect/Respond/Recover functions it falls under), OWASP (the vulnerability class), and CWE (the specific weakness type). That mapping isn’t decoration — it’s what lets a finding drop straight into whatever register format your compliance process already uses.

If you’re maintaining a risk register for POPIA §19 purposes, the NIST CSF tag tells you which control family it lives under and the CWE reference gives you a stable identifier to track the same weakness across scans over time — useful when you want to show a finding was closed, not just found. If your bank or insurer’s questionnaire asks about your alignment to a named framework, you can point to the specific category rather than a vague “yes, we do security testing.”

Section 19 of POPIA requires “appropriate, reasonable technical and organisational measures” to secure personal information, verified regularly and updated as risks change. It doesn’t specify a scanning tool or a testing cadence — that’s deliberately left to what’s reasonable for your business. A Deep Scan plus a quarterly retainer is a legitimate answer to “what technical measures have you taken and how do you know they’re still working?” without buying a level of testing sized for a bank’s PCI programme.

What re-runnable proof buys your remediation cycle

We report only vulnerabilities we can prove, with a reproducible proof-of-concept attached, so 0 false positives on confirmed findings. That matters for compliance for a mundane reason: remediation has to be verifiable. When your developer fixes a finding, the same proof-of-concept re-run either reproduces the vulnerability or it doesn’t. There’s no ambiguity to argue about at the next review, and no chasing down whether a scanner flagged something real or noise. If a director or an insurer asks “how do you know this was actually fixed?” the answer is a re-run, not a developer’s word.