Most agencies can name the client site that worries them. It runs a form plugin that has not been touched since launch, three former staff still have administrator accounts, and the hosting login sits in an old spreadsheet. Nothing has gone wrong yet, so nobody has been paid to look at it. That is exactly the kind of site that ends up on a cleanup bill.
Security monitoring is the unglamorous work that makes that bill less likely. We do it for agencies as a back-office service: we watch the client sites you name, harden them once, keep checking that the hardening holds, and send what we find to you rather than to your client. It is one part of the wider guide to outsourcing WordPress work as an agency, and it sits on the prevention side. If a site is already compromised, that is a different job, covered on our page about cleaning hacked client sites for agencies.
Prevention is the part clients never notice
The awkward truth about security work is that when it goes well, nothing happens. No warning page in Chrome, no spam in the client’s sent folder, no call from their host. That makes it hard to sell and easy to quietly drop from a care plan when the team gets busy.
Agencies usually struggle with it for ordinary reasons rather than a lack of skill:
- Alerts from a dozen client sites arrive in one inbox, and after the first month nobody reads them.
- Each site was set up by a different person, so hardening is uneven: one has two-factor login, the next still allows XML-RPC and has a user called “admin”.
- Vulnerability notices for plugins appear constantly, and working out which client sites actually run the affected version takes time nobody has.
- When an alert does look serious, there is no agreed next step, so it waits until someone has a free afternoon.
A white-label WordPress security arrangement fixes the process problem more than the technical one. Someone owns the alerts, someone decides what each one means, and you hear about the ones that matter in a form you can act on.
What we actually watch on a client site
Monitoring is a vague word, so here is what it means in practice for the sites you hand us.
Changes to files that should not change
WordPress core files are the same on every installation of a given version, which makes them easy to compare against the official copies. Unexpected PHP files in the uploads folder, edited core files or new files in a theme nobody has touched are early signs worth acting on. Our existing post on checking core files against the originals explains the idea in more depth.
Who is logging in, and how
New administrator accounts, logins from places that make no sense for the client, and bursts of failed attempts against the login page all get noted. Where the site has an activity log, we read it rather than just collecting it.
Plugins and themes with known problems
When a vulnerability is published for a plugin, the useful question is not “is this serious?” but “which of your client sites run it, on which version?” We keep that answer ready, and we tell you which sites need an update now and which are unaffected.
The things outside WordPress
SSL certificates that are about to lapse, a domain on a search engine or browser blocklist, the site going down, or the host flagging the account. None of these are WordPress problems, but your client will treat all of them as “the website is broken”.
Hardening once, then checking it stays hardened
On the first pass through each site we bring it to a sensible baseline. That usually means removing old and shared administrator accounts, setting proper user roles, turning on two-factor login for anyone with admin rights, tightening file permissions, protecting wp-config.php, disabling file editing from the dashboard, and switching off features the site does not use. We write down what we changed on each site, because hardening that nobody recorded is hardening the next developer will undo.
We do not install a new security product on every site by default. If a client site already runs Wordfence, Sucuri or a similar plugin, we usually configure what is there. If you have a standard tool across your client base, we work with that. Consistency across your sites matters more than which brand of plugin is installed, which is part of why agencies benefit from settling on a standard plugin stack across client sites.
After that, the job is keeping the baseline in place. Sites drift. A client adds their nephew as an administrator, a designer installs a plugin to test a slider, someone disables two-factor because it was annoying. Part of monitoring is noticing that drift and putting things back, or asking you whether the change was intended.
How the white label arrangement works for security
Security alerts are where white label work can quietly leak. A plugin set up by an outside team will happily send its warnings to that team’s address, or put its own name in an email footer the client receives. So we settle these points with you at the start:
- Where alerts go. To an address you choose: one of yours, a shared address we can read, or the client’s if that is what your contract with them says. Nothing goes to a WebMaintor address that the client could ever see.
- What the client receives directly. Often nothing. Some agencies want clients to get a login notification for their own account; others want silence. Either is fine as long as it is decided.
- Whose name appears in the dashboard. Any admin user we use is named the way you prefer, typically after your agency’s support role rather than a person.
- Who decides on an urgent update. Some agencies let us patch a known vulnerability straight away and tell them afterwards. Others want a message first. We agree the rule per client, because a store and a brochure site deserve different caution.
What your client sees, and what they do not
From the client’s side, their site simply keeps working, and their agency occasionally tells them something sensible: an outdated plugin was replaced, a former employee’s account was removed, a certificate was renewed before it lapsed. They see your name on that message. They do not see our team, our tools or our notes unless you choose to pass them on.
What they also do not see is noise. A burst of failed logins from bots is normal on any public WordPress site and is not worth an anxious email. We filter that out so that when you do contact the client about security, it is about something they should actually know.
What you stay in control of
Done properly, white-label security monitoring takes the watching off your plate without taking the judgement away from you. You keep the decisions that touch the client relationship or the budget. We will recommend, but you decide whether a site that cannot be safely updated gets rebuilt, whether a client with a risky plugin is told now or at the next review, and whether a problem is covered by their plan or quoted separately.
You also keep the access. We work with the logins you give us, at the level the job needs, and we tell you when we no longer need one. If you have not yet settled how your agency hands out credentials, our post on sharing client logins without losing track of them is a good place to start, and it matters doubly for security work.
When monitoring finds something real
Sometimes the check turns up more than drift: an unknown administrator, injected code in a theme file, spam pages appearing in search results. At that point the job stops being monitoring. We tell you straight away what we found and how confident we are, take a backup of the current state before touching anything, and agree with you whether to move into cleanup. If you go ahead, the incident is handled as an urgent client-site problem and follows the process on our hack cleanup page, still under your name.
We will not quietly fix something serious and mention it in passing next month. You need to know early, because you may have obligations to your client, and your client may have obligations to their customers.
The security notes you receive
On a regular cycle you agree with us, you get short written notes for each site: what was checked, what was changed, anything that needs a decision, and anything we recommend that falls outside the agreed work. They are unbranded, so you can paste them into your own client reports under your agency name or keep them internal. We avoid padding them with counts of blocked bots; a short report that says “nothing needed doing” is a perfectly good report.
Security usually travels with routine upkeep, so many agencies pair this with our update work tested before it reaches the live site. If you are weighing the wider relationship rather than one service, the white label development page explains how we work with agencies in general, and our own security maintenance service for site owners shows the same technical work as we offer it to businesses directly.