Skip to content

Managed vCISO

Continuous assurance and penetration testing

What this is

Continuous assurance is the ongoing verification that security controls are working, combining vulnerability management, cloud configuration review, penetration testing and remediation tracking. It differs from point-in-time testing by treating findings as a managed backlog with owners and deadlines rather than a report delivered and filed.

The problem

The annual penetration test finds the same things it found last year.

The pattern is familiar. A test is commissioned because a customer or a framework requires one. It produces findings. The critical ones get fixed, the high ones get tickets, the medium ones get acknowledged. Twelve months later the next test finds the mediums still open, plus new ones, plus two of the highs that were closed without being verified.

The test was not the problem. The problem is that testing was treated as an event rather than as one input to a cycle - and that nobody owned the findings after the report was delivered. A finding without an owner and a date is a record of knowledge, not a plan to fix anything.

Meanwhile the estate changes weekly. Cloud configuration drifts, dependencies age into known vulnerabilities, and someone opens a security group for a debugging session in March that is still open in November. An annual snapshot cannot see any of that.

Who this is for

  • Organisations whose last penetration test findings are still partially open.
  • Teams shipping frequently, where an annual test is stale within weeks.
  • Companies needing evidence of ongoing assurance for ISO 27001, SOC 2 or PCI DSS.
  • Firms with a growing cloud estate and no continuous configuration review.
  • Anyone who cannot currently answer how long it takes them to patch a critical vulnerability.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 012-3 weeks

    Establish the baseline

    What is currently tested, what is not, and what the open finding population actually is including everything inherited from previous reports.

  2. 022 weeks

    Build the cycle

    Assurance calendar, severity thresholds, remediation SLAs and the exception route, agreed with engineering so the SLAs are achievable.

  3. 034-8 weeks

    Run the first cycle

    Testing executed, findings triaged into the backlog with owners, and the first ageing report produced - which is usually uncomfortable and useful.

  4. 04Ongoing

    Steady state

    Testing on schedule, continuous configuration monitoring, quarterly reporting, and verified closure rather than assumed closure.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Continuous assurance and penetration testing, with what each one contains and when it lands
DeliverableWhat it containsWhen
Assurance calendarWhat gets tested, how often and by whom across the year - penetration testing, cloud review, dependency scanning, access review - sequenced against release cycles.Week 2
Penetration testScoped to what matters, delivered with reproductions engineers can act on. Criticals reported on discovery rather than held for the report.As scheduled
Cloud configuration reviewAgainst CIS benchmarks and your own baseline, covering identity, network exposure, logging, encryption and public access.Quarterly
Vulnerability management processSeverity thresholds, remediation SLAs, an exception route with an owner and an expiry, and reporting that shows whether the SLAs are being met.Week 4
Remediation trackingFindings as a live backlog in your tooling with owners and dates, so closure is verified rather than assumed.Ongoing
Assurance reportingA recurring report showing coverage, findings opened and closed, ageing, and SLA performance - the evidence an auditor or customer asks for.Quarterly

Frameworks this touches

FAQ

Questions people actually ask

How often should we run a penetration test?

Annually as a floor, and additionally on significant change - a new customer-facing application, a material architecture change, or a move to a new cloud platform. Frameworks generally require annual testing, and PCI DSS requires it after significant change too. For organisations shipping continuously, annual testing alone leaves most of the year unexamined, which is why it works better as one component of a cycle that includes continuous scanning and configuration review.

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is automated and identifies known vulnerabilities by signature and version. A penetration test is performed by people who chain findings together, exploit business logic, and find the things scanners systematically miss - authorisation flaws, logic errors, and issues that only appear when two components interact. Scanning gives breadth and frequency; testing gives depth. Neither substitutes for the other.

What remediation timescales should we set?

A common and defensible starting point is critical within seven days, high within thirty, medium within ninety, and low at the next planned cycle. The specific numbers matter less than that they are agreed with the people who have to meet them, applied consistently, measured, and that exceptions require a named owner and an expiry date rather than being granted indefinitely.

Do we need continuous assurance for ISO 27001 or SOC 2?

Both require evidence that controls operate over time, which is exactly what continuous assurance produces. ISO 27001 requires monitoring, measurement and internal audit. SOC 2 Type II tests operating effectiveness across the observation window by sampling evidence from throughout it. Organisations running a genuine assurance cycle find both audits considerably easier, because the evidence already exists rather than being assembled for the auditor.