In most of the organisations we work with, there is a fragmentation between marketing and IT teams regarding website and platform security.
The speed of response in a security incident matters more than anything else, and that depends on knowing who is accountable for what.
With responsibility split between marketing and IT, it’s often unclear who sets the security standard for the website and who needs to be involved when an issue comes up either at the server or application level, and that uncertainty can extend the time the site is exposed or offline.
Why websites got harder to own
Most websites run multiple integrations, tracking scripts, plugins and AI tools, and each one is a potential point of failure.
Websites also typically have multiple content editors across marketing teams, each with their own login and access level, alongside agencies and contractors who need access too.
Most of these integrations and users are added without a formal security review.
What happens when nobody owns website security
When we take on a site without clear ownership, we usually find the same issues across the gap of ownership between application and server level:
Application layer
Accounts that outlived the people
Admin logins for staff who left two years ago, or for an agency whose contract ended, still active because no one was responsible for removing them.
Plugins and scripts nobody remembers adding
A campaign tool installed for a launch in 2023, still running and still loading third-party code on every page.
Updates waiting for a decision
A fix for a critical vulnerability is available, but the update needs sign-off and the person responsible for approving it is unavailable.
Server layer
Server software left behind
The CMS is up to date, but the server is still running an end-of-life PHP version that no longer receives security fixes, because nobody owned the hosting upgrade.
Server access nobody revoked
FTP or SSH credentials issued to a previous agency are still active on the server, long after the relationship ended.
Backups nobody has tested
Backups run every night, but nobody has tried restoring one, so no one knows whether they’d work in an incident.
Across both
Microsites on different terms
The main site is hosted properly and patched monthly, while an event microsite built by another supplier sits on shared hosting and hasn’t been updated since launch. AI site builders have made microsites much quicker to launch, so more of them are appearing, often without IT’s knowledge.
Where the agency fits
Most agencies work reactively, fixing issues when they’re reported and applying updates when asked. The problems above tend to stay in place under that model, because nobody is actively looking for them.
An agency that manages the site proactively, and understands the hosting infrastructure as well as the application, is able to close a lot of these gaps, by monitoring the site against vulnerability data, patching to an agreed timescale, and keeping the user list and plugin inventory up to date. Where the same agency looks after both layers, there’s no handover between them when something needs fixing.
It can also act as the link between marketing and IT, giving marketing a single point of contact for the website and giving IT the reporting it needs to sign off the site’s security position, such as what was patched, when, and what’s still outstanding.
Getting access under control
Access is usually the first place governance gaps show up, because permissions build up over time.
Every modern CMS gives you the tools to control this: WordPress has a granular roles and capabilities model that can be customised well beyond the defaults, Payload handles access as code, with rules that can be set per collection, per field and per operation, and Sanity has role-based access with custom roles on its enterprise plans and scoped API tokens for integrations.
The basics we’d put in place are:
- Give people the lowest role that lets them do their job, since most editors don’t need admin.
- Use single sign-on where you can, so leaving the company removes website access automatically.
- Make multi-factor authentication mandatory for every account with publishing or admin rights.
- Give every agency and contractor named individual accounts, because shared logins make it impossible to trace who changed what.
- Review the full user list on a schedule, which for most of our clients means quarterly, plus a check whenever a supplier relationship ends.
Knowing what’s running on your site
Every site should have a current inventory of the plugins, packages, integrations and third-party scripts it runs, along with the server software underneath them, such as the PHP, web server and database versions, with an owner and a business reason against each one.
An up-to-date inventory allows you to act quickly when a vulnerability is disclosed, because you’re able to tell within minutes whether a new CVE affects anything you run. Our vulnerability tracker works to give our clients a quick count of the vulnerabilities disclosed across their site, which is a useful place to start.
Before a new plugin or tool goes on the site, someone should check that it comes from a reputable source, is actively maintained with regular updates, has a solid record of reviews and support, and only reaches the data it needs. Our look at how plugin vulnerabilities are trending this year shows why this matters.
Agencies and contractors working on your site should follow written security requirements covering how they store credentials, who has server access, how they test updates and how they respond to critical issues.
One standard across every site
Larger organisations usually run several sites, with regional, careers and campaign sites alongside the main corporate site.
A shared standard should set the minimum for every web property you own: hosting requirements, patching timescales, access rules, backup and recovery, and who’s accountable, with individual teams making their own decisions above that line.
Hosting should be part of that minimum, so every site sits on hosting with managed server and OS patching, daily backups that get tested, a recovery plan with a known recovery time, and a clear answer on where the data lives.
Our dedicated hosting runs every client on a pair of physical servers in active failover, with daily backups kept for at least 14 days.
Retiring sites matters too, because a microsite for a campaign that ended three years ago still carries your brand and still needs patching, so sites that are no longer needed should be taken down properly.
Treating security as ongoing work
Security should be part of the day-to-day running of the site, which means:
- A fixed patching cycle, with a faster route for anything high or critical, such as the one-day patching for high and critical vulnerabilities under our Cyber Shield SLA.
- Server and operating system patching on its own schedule, with a named owner, so the infrastructure under the site is kept as current as the application.
- Changes assessed for security impact before they go live, including content changes that add new forms or embeds.
- Security checks built into development, so code review, dependency scanning and automated testing happen while the work is being done.
- Updates tested on a staging copy of the site before they reach production, with a record of what changed.
Having a clear, detailed incident plan
Most of the avoidable damage in an incident tends to happen in the first hour, so who’s in charge needs to be agreed in advance.
A short written plan should cover who gets contacted first and how, how you establish whether the issue sits in the application or on the server, who can approve taking the site offline, who decides whether personal data has been affected, and who speaks to customers and to the regulator.
It also helps to know your suppliers’ response times before you need them, and on our hosting, a critical outage gets a response within 15 minutes and a resolution target of under two hours, with 24/7 cover.
The regulatory part comes with a deadline, because under UK GDPR a personal data breach that poses a risk to people’s rights has to be reported to the ICO within 72 hours of you becoming aware of it. In regulated sectors there may be sector-specific obligations on top.
After any incident or near miss, update the plan with what you learned, so the response is quicker the next time something happens.
Hosting and website management agreements
Many organisations have two separate contracts covering their website: a hosting agreement for the servers and infrastructure, and a website management agreement for the application itself, meaning the CMS, themes and plugins. Incidents can fall between the two, so it’s worth checking what each one covers before you need it.
The questions we’d ask of both agreements are:
- How quickly are critical and zero-day vulnerabilities patched, and is that timescale written into the contract?
- Who handles a compromise outside business hours, and is that covered by the hosting agreement, the website management agreement or both?
- Is incident work included in your monthly support hours, or billed separately?
- Where are backups held, including the region and legal jurisdiction, and is there disaster recovery at a geographically separate site?
- Can your provider share the data centre’s ISO 27001 certificate and any other audit reports, such as SOC 2?
At SoBold, our Cyber Shield SLA is part of our website management retainers. High and critical vulnerabilities are patched within one day and mediums within three days, with every patch tested on a staging site before it goes live. Plugins and WordPress core are monitored four times a day, alongside core file integrity checks and alerts on any unexpected plugin activity, and clients receive a monthly report on everything applied.
On the hosting side, a confirmed compromise is treated as a P1 incident, with containment and restore covered 24/7. Investigation and remediation at application level, covering core, themes and plugins, runs under the website management agreement during UK business hours, and our team does respond outside those hours to confirmed compromises. That incident work comes out of the client’s monthly hours, with any additional time billed at our ad-hoc rate.
Backups are held in the same region and jurisdiction as the hosting, and we confirm the exact location with each client. For geographic redundancy, we can replicate the platform to a disaster recovery node at a second, separate data centre, ready to serve traffic in under 15 minutes if the primary site goes down.
Knowing who owns what
If you want a sense of where you stand, work through these questions, and any you can’t answer with confidence are worth following up.
- Is there one named person accountable for the security of each website you run?
- Could you list every user with admin access to your main site today?
- Do agencies and contractors have their own named accounts, with access removed when the work ends?
- Has server access, such as FTP, SSH and the hosting control panel, been reviewed alongside CMS logins?
- Does your agency monitor and patch the site on a schedule, or only act when something is reported?
- Do you have a current inventory of the plugins, integrations, scripts and server software on each site, and do you know who updates each one?
- Does anything new get reviewed before it goes on the site?
- Are your microsites and regional sites held to the same standard as the main site?
- Is there a written incident plan, and do the people in it know they’re in it?
- Do you know what your hosting and website management agreements each cover, including patching timescales, out-of-hours compromises and where your backups are held?
- Do your security requirements get revisited when the site, the team or the suppliers change?
How we handle it
For clients on our support and growth retainers, we look after both the application and the hosting, with named responsibility for patching, updates and reporting, and we help clients put the rest of this in place, from access reviews to the incident plan.
We’re Cyber Essentials certified, and ISO 27001 certification for our data centres is available on request.
If you’d like a second opinion on where the gaps are in your own setup, get in touch.
