The starting point
The business was — and is — genuinely digital: public web portals handling serious traffic, integration APIs with third parties (valuers, listing portals, financial entities) and a relentless deployment cycle pushed by the business and marketing. Every new campaign meant a new landing page; every new partnership, a new integration. Security trailed behind: occasional scans, no complete inventory of web assets, and no process connecting findings to the development team.
The most telling symptom surfaced in the first month: old campaign websites still live that IT did not even know existed. No point-in-time scan would ever have covered them, because they were on no list. And all that exposed estate processed customer data — enquiries, valuations, contact details — in a sector where trust is the product. A critical vulnerability on a public portal was not a technicality: it was a potential headline.
How we approached it
- Continuous web asset discovery — recurring sweeps of domains, subdomains, certificates and DNS records to keep a living inventory. The first pass uncovered campaign sites and agency microsites IT had no control over; three years on, every newly published asset shows up in the inventory within days, not whenever somebody happens to remember it.
- Recurring scanning of applications and exposed infrastructure — periodic assessment of the high-traffic portals, the integration APIs and the infrastructure serving them. The everyday findings: outdated JavaScript libraries, weak security headers and TLS configurations, the occasional XSS and access controls on APIs that needed tightening.
- Prioritisation driven by business context, not just CVSS — the question that orders the queue is not "what score does it carry?" but "is this on the internet and does it process customer data?". A medium-severity flaw on a public portal with real traffic can jump ahead of a high on an internal system.
- Remediation woven into the development release cycle — findings land as tickets in the team's backlog, with severity, context and remediation steps; criticals on public assets carry an agreed SLA and go into the next release or a hotfix. After each deployment we rescan to verify closure.
- Third parties and agencies inside the perimeter — supplier-managed websites are scanned just the same, and findings are handed over with deadlines and evidence. Over time, minimum security requirements and remediation deadlines ended up written into the agency contracts.
- Constant follow-up with trend metrics — regular sessions with IT and development reviewing a trend rather than a list: newly discovered assets, time-to-fix by severity, accumulated debt and recurrences. That is what turns a scanner into a programme.
Results
days
exposure window for criticals on public assets — it used to be measured in weeks
100%
of the web estate under inventory and continuous scanning — at the start a complete list did not even exist
3 years
of continuous programme integrated with the deployment cycle, and counting
The deeper change is not a figure but a habit: when a critical vulnerability appears on a public portal, the circuit to resolve it already exists — who receives it, on what deadline, in which release it ships and who verifies closure. Outdated JavaScript libraries, weak headers and improvable API access controls keep turning up, because the business keeps deploying; the difference is that they are now detected, prioritised with context and closed within a known window.
Three years also buy what no one-off scan ever sees: debt falling release after release, campaign websites retired when they stop being used instead of staying published forever, and agencies that now deliver knowing their work will be scanned. The programme has not slowed the pace of business and marketing — it has embedded itself in it.
What made it work
- In a digital business every public website is attack surface — including the campaign sites nobody remembers. If it is not in the inventory, it is not in the scan.
- A critical vulnerability on a public portal that processes customer data is direct reputational risk, not a technicality in a report.
- Detection is automated; remediation is governed. Without SLAs, tickets in the development backlog and post-deployment verification, a scanner only produces PDFs.
Frequently asked questions
How do you discover the web assets IT has never catalogued?
Through continuous discovery, not a one-off snapshot: the organisation's domains and subdomains, issued TLS certificates, DNS records and IP ranges are swept on a recurring basis, and every new asset that appears is checked against the inventory. Businesses with an active marketing function are where shadow IT surfaces most: campaign landing pages, agency-built microsites and test environments published without anyone telling IT. Each finding is classified — owned, third-party, obsolete — and either enters the scanning cycle or gets decommissioned. The asset list stops being a document and becomes a process.
How does remediation fit a development team that ships every week?
By adapting to their cycle rather than imposing another one. Findings arrive as tickets in the team's backlog, with severity, exposure context and concrete remediation steps; critical issues on public assets carry an agreed SLA that puts them into the next release — or a hotfix when they cannot wait. After every deployment we rescan to verify closure. The result is that fixing vulnerabilities stops being a separate project and becomes one more sprint task, with the least possible friction.
What about websites run by third parties or agencies?
They are scanned all the same, because to an attacker — and to the end customer — they carry the organisation's brand, whoever administers them. The difference lies in remediation: responsibility is shared, so findings on third-party assets are passed to the agency or supplier with deadlines, and the programme provides the evidence to enforce them. Over time those demands end up in the contracts: minimum security requirements, remediation deadlines and the right to verify. It is one of the programme's least visible and most profitable improvements.
What does a programme like this cost compared with a one-off scan?
As an order of magnitude, a year of continuous programme costs what a handful of point-in-time audits would — but it does not compete with them on price; it competes on temporal coverage. A one-off scan describes a single day; the next release ships and the report starts going stale. On a platform that deploys weekly, the relevant question is not what the programme costs, but what it costs to leave a critical vulnerability exposed for weeks on a public portal that processes customer data. The programme exists so that window is measured in days.
Related services
Do you know how many of your websites are on the internet right now?
If you have to ask, the honest answer is "more than you think". Our continuous vulnerability management inventories your exposed surface, scans it on a recurring basis and governs remediation with your development team — at the pace your business actually ships.