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.
- 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.
- 022 weeks
Build the cycle
Assurance calendar, severity thresholds, remediation SLAs and the exception route, agreed with engineering so the SLAs are achievable.
- 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.
- 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.
| Deliverable | What it contains | When |
|---|---|---|
| Assurance calendar | What 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 test | Scoped to what matters, delivered with reproductions engineers can act on. Criticals reported on discovery rather than held for the report. | As scheduled |
| Cloud configuration review | Against CIS benchmarks and your own baseline, covering identity, network exposure, logging, encryption and public access. | Quarterly |
| Vulnerability management process | Severity 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 tracking | Findings as a live backlog in your tooling with owners and dates, so closure is verified rather than assumed. | Ongoing |
| Assurance reporting | A recurring report showing coverage, findings opened and closed, ageing, and SLA performance - the evidence an auditor or customer asks for. | Quarterly |
FAQ
Questions people actually ask
How often should we run a penetration test?
What is the difference between a vulnerability scan and a penetration test?
What remediation timescales should we set?
Do we need continuous assurance for ISO 27001 or SOC 2?
Start
Three ways in, depending on how close the deadline is.
- Book it
Book a discovery call
Thirty minutes, no deck. We work out whether there is a real engagement here, and say so if there is not.
- Go
Check the EU AI Act applies
Six questions, a dated list of the obligations that reach you, and a calendar file so the deadlines land somewhere you will see them again.
- Go
Request a roadmap
You know the obligation and the deadline. We scope the sprints, the deliverables and the dates.
Or just email a human: hello@cloudgap.ai
We reply within24 hours