The situation agencies are actually in
You did not build most of these servers. They were set up years ago by a developer who has left, or by the client, or by another agency, and you inherited them along with the retainer. Each has a slightly different stack and nobody has a complete picture of any of them.
You are nonetheless the number the client calls when their site is defaced, sending spam, or down. Being responsible for security on infrastructure you did not choose is the normal condition of agency work.
The honest constraint is time. Logging into each server to look around does not survive a busy month, and it is the first thing to lapse precisely when it matters, which is why the discovery is usually the client phoning rather than you noticing.
What changes with monitoring in place
- Attacking addresses are blocked automatically within seconds, so the highest-volume category never needs a person.
- Every client server appears in one dashboard with its own risk score, open findings and agent health.
- File integrity flags changed WordPress core, plugin and theme files, plus system files outside the web root that a plugin cannot see. Pro plan and above.
- Webshells in web-served directories are detected and AI-screened, which is the usual foothold on an agency-maintained site. Pro plan and above.
- Installed packages are matched against published CVE data, so you know which of the servers you inherited are running something exposed.
- Website and TLS monitoring tells you a client site is down or a certificate is expiring before the client does. Pro plan and above.
Keeping clients separate
If you want each client isolated rather than all servers in one account, the reseller and MSSP arrangement gives every client their own organisation with its own data, and a fleet view across all of them for you.
That also makes the conversation easier when a client asks whether their data is mixed with another client of yours. It is not.
The security conversation you can now have
Agencies are increasingly asked what security is in place, sometimes by a client and sometimes by that client’s insurer. "We keep things updated" is a weak answer and everyone in the room knows it.
Continuous monitoring produces a specific one: what is monitored, what was detected, what was blocked and when, with a history rather than an assertion. One-click PDF reports aligned with NESA and PDPL expectations are available for clients who need something formal.
It is also a straightforward retainer line item. Monitoring you can evidence is easier to charge for than vigilance you cannot.
A realistic starting point
Start with the servers where a compromise would be most expensive, usually the ones carrying e-commerce or personal data, then add the rest as their retainers renew. Every server is one install command, so this does not need to be a project.
A reasonable first pass is to enable monitoring in Awaiting Approval mode so nothing is changed automatically beyond blocking attackers, review what the first week of findings actually surfaces on servers you inherited, and move the well-understood ones to Automatic once you trust what you are seeing.