What Continuous Actually Means in Managed Cybersecurity
An annual penetration test tells you how secure you were on one day last year. Here is what a continuous posture looks like in practice.
A penetration test is a photograph. It shows you the state of your systems on the day it was taken. That is genuinely useful, and it is also why an annual test on its own leaves you exposed for the other 364 days.
Between two annual tests, your team ships code, adds dependencies, opens ports, grants access to new starters, and integrates a tool somebody needed urgently. The photograph gets less accurate every week.
Managed cybersecurity is the attempt to replace the photograph with a video feed. Here is what that involves.
The gap nobody plans for
Most breaches are not sophisticated. They are ordinary.
An unpatched server. An account with more access than it ever needed. A dependency with a known vulnerability that has been public for months. One person clicking a convincing link on a busy Tuesday.
None of those require an attacker with unusual skill. They require an attacker with time and a scanner, which describes almost all of them. The defence is not exotic technology, it is someone competent looking closely, on a regular basis.
What actually needs watching continuously
Your dependency tree. New vulnerabilities are published in libraries you already use, every week. This is the highest value automated check available and the one most often left unconfigured.
Access. Not the list of who has access, which is easy. The list of who has access and no longer needs it. Permissions accumulate. Nobody ever asks for less.
Your external surface. What is reachable from the internet today, compared to last month. Test environments and forgotten subdomains are a favourite starting point precisely because nobody is watching them.
Certificates and expiry. Unglamorous, and the cause of a genuinely embarrassing category of outage.
Configuration drift. The environment as it exists now, against the environment as it was designed. Emergency changes made at 2am rarely get reverted.
Where periodic testing still belongs
Continuous monitoring is good at known problems: this library has a published vulnerability, this port is newly open, this account has excessive permissions.
It is bad at the thing a skilled human does well, which is chaining several individually minor issues into a real attack path. That still requires a person thinking adversarially about your specific system.
So the two are not alternatives. Continuous monitoring handles volume and speed. Periodic testing handles creativity. Dropping either one leaves a gap that the other cannot cover.
The measure that matters
Not the number of findings. A report with two hundred findings usually means a scanner ran and nobody triaged the output.
The useful measure is time to close. How long between a critical vulnerability being published and it being patched in your environment. That single number tells you more about your actual security posture than any certificate on a wall.
If nobody can answer it, that is the answer.
A reasonable starting point
If you are building this up from nothing, the order that gives the most protection per unit of effort is roughly:
- Automated dependency scanning, wired into your build so it blocks on critical issues
- An access review, done once properly, then quarterly
- External surface monitoring
- Then, once the obvious holes are closed, a penetration test
Running the test first is a common instinct and usually a waste of money. It produces a long report of findings you already could have found automatically, and buries the interesting ones underneath.
That combination, automated coverage underneath and human testing on top, is how our managed cybersecurity work is built. Where the gaps turn out to be operational rather than technical, they belong with infrastructure, and where they sit in the application itself, with development.