Which parts of security are yours and which are your developer's

Website security responsibility splits along one line: you own the accounts, the domain and the data; your developer owns the code, the server hardening and the patches they are paid to maintain. The gap appears where neither list is written down. That gap — not the hacker — is what takes most sites down.

Key Takeaways

• Ownership is about accounts and renewal paths, not good intentions. If you cannot log in to the registrar today, you do not own the domain.
• Your developer's security duty ends when the engagement ends, unless a written maintenance scope extends it.
• Backups, monitoring and incident response live in a negotiable grey zone. Name an owner or they quietly stop happening.
• Each orphaned item has a predictable failure mode: expired SSL, exploited plugin, lapsed domain, lost admin access.
• A one-hour ownership audit predicts your next incident better than any vulnerability scanner.
• A retainer makes sense once the site takes payments or holds personal data; a static brochure site can often run on managed hosting plus ad-hoc fixes.

Why does website security fall through the cracks?

Most breaches follow a handoff that was never written down. The owner assumes the developer handles security because they built the site; the developer assumes the owner renews services because the bills go to their inbox. When an assumption fails — an expired certificate, an unpatched plugin — it looks like bad luck, but it is a missing owner for a named item.

Cloud vendors write shared responsibility into their terms: the provider secures the infrastructure, you secure what runs inside it. A website build rarely gets the same treatment. The developer delivers the site, the owner pays the invoice, and both sides believe the other is watching the updates. WordPress widens the gap because the attack surface is not the code you commissioned — it is the plugins, themes and core files that update on a schedule nobody tracks.

A common mistake we see is treating "security" as a single deliverable. It is not. It is a list of small, boring, recurring tasks, each with an owner. The moment one task loses its owner, it becomes the route in.

Which parts of security are genuinely yours?

As the site owner, you own the accounts and legal duties nobody can transfer: the domain registrar login, the DNS records, the hosting and billing accounts, the business email that receives renewal notices, and the data your visitors hand over. If you cannot log in to these today, you do not own them — you are renting access from whoever does.

• Domain registration — the registrar account, the WHOIS contact, and the card that pays for renewal.
• DNS — the zone file at the registrar or a provider like Cloudflare, including MX records for email.
• Hosting and billing — the control panel, the payment method, and the account recovery path.
• SSL certificate — if you buy it separately from hosting, its renewal and private key sit with you.
• Admin user accounts — who can log in to the CMS, with what role, and how you revoke a leaver.
• Data protection — the legal side of handling customer details, orders and enquiries.

These are not technical chores you delegate and forget. They are the keys to the building. Losing the registrar login is worse than any single vulnerability, because it cuts off your ability to fix everything else. If you are unsure who actually holds the code and the domain, this breakdown of website code ownership spells out the risk.

Which parts does your developer own?

Your developer owns the security of the code they ship: dependency patches, framework upgrades, sanitising input, hardening the server, configuring TLS, setting file permissions, and keeping the build free of leaked secrets. That ownership lasts only as long as the engagement — a fixed-price build that ends at launch transfers none of it forward.

On the code side, this means the usual web application risks: injection, broken authentication, cross-site scripting and misconfigured access control. A developer who builds custom software should write against those from the start, not bolt them on afterwards. On the platform side, WordPress work means keeping core, plugins and themes current and tested — the official WordPress plugin security guidance is the baseline we work from.

Server hardening is the same duty one layer down: SSH keys instead of passwords, a firewall that only opens the ports the site needs, TLS configured to current standards, and file permissions that stop a compromised plugin from writing everywhere. These are the developer's natural territory because they touch the code and the operating system together.

What is negotiable — monitoring, backups and incident response?

Monitoring, off-site backups and incident response sit in a grey zone. Either side can run them, but they must be named and paid for. A developer who checks logs weekly under a maintenance plan owns them; a developer who handed over a finished site does not. Unspoken, these are the first items to vanish.

Backups are the clearest example. A backup that exists but has never been test-restored is not a backup — it is a hope. Someone has to own the schedule, the off-site copy and the quarterly restore drill. Monitoring is similar: uptime checks, certificate expiry alerts and file-change detection all need a human who reads the alerts. Incident response, the ugliest item, is who you call when the site is already down or defaced, and whether they answer at 2 a.m.

None of this is free, and none of it happens by default. The question to settle is not "whose job is security" but "which of these recurring jobs is inside the paid scope, and which is not".

How do you verify who currently holds what?

Run a one-hour ownership audit, not a technical penetration test. Log in to the registrar, the DNS provider, the hosting panel and the site's admin as a full administrator. For each, record who else has access, whose email receives renewal notices, and which card on file pays. The gaps you find here predict your next incident better than any scanner.

1. List every service in the stack: domain, DNS, hosting, email, CDN, backups, monitoring, code repository, CI.
2. Log in to each one as the owner. If you cannot, that item is already orphaned — start the recovery now.
3. Check every account for other admin or root users. Ask whether each still needs access.
4. Confirm the billing and renewal contact email is yours, not a former employee's or a contractor's personal address.
5. Export a password-manager entry for each service, with a note on who else can reach it.
6. Compare your list against what the developer says they maintain — in writing, not in a call.

If the audit feels like archaeology, that is a finding in itself. A clean handover should make every row answerable in minutes. This handover checklist walks through the same ground from the other direction, and these questions for a web developer help you pin the scope down before work starts.

What breaks when nobody owns an item — and what it costs

Each orphaned item has a predictable failure mode. An unowned SSL certificate expires and browsers show a full-page warning. An unowned WordPress plugin gets exploited and the site serves spam or a defacement page. An unowned domain lapses and the whole brand, email included, stops resolving. Recovery costs dwarf the prevention every single time.

The order of damage matters. A defaced page is embarrassing; a lapsed domain is existential, because your email dies with it and a squatter may take the name. A leaked .env file exposes database credentials and forces a full rotation of every secret the application touches. An open uploads directory turns your server into a file host for someone else's malware.

When you find a problem, check in this order: is the account still under your control, is there a recent backup, and does the current developer still have access. That sequence tells you whether you are fixing a vulnerability or rebuilding a relationship with a former contractor.

What should a handover or maintenance agreement actually cover?

A useful agreement lists named services, not promises. "Security" is not a deliverable; "monthly WordPress core, plugin and theme updates, tested on staging, with a rollback plan and a written changelog" is. Attach the ownership audit from above as an appendix. If the scope says a developer maintains the site but nobody has said who pays for the staging copy, you have found a gap.

The agreement should also answer the ugly questions before they happen: who is called first when the site is down, what the response time is, and whether incident work is inside the retainer or billed separately. If the developer leaves, the document must say how credentials and repositories transfer back to you. A maintenance scope that cannot survive the developer resigning is not a scope; it is a dependency.

Cost and operational overhead — what actually drives it

Security maintenance costs are driven by cadence and blast radius, not by the number of pages on the site. A single WordPress site with ten plugins needs weekly update checks and a tested rollback plan; a custom application with a build pipeline needs dependency scanning and staging deploys. The more third-party code you run, the more engineer time you buy.

Think of the cost qualitatively: every plugin is a subscription to future updates. Every form that collects data raises the care standard. A self-managed VPS costs less in hosting fees but more in engineer hours than managed hosting, because someone has to patch the operating system and read the logs. Compliance needs — if you take card payments or hold personal data — add their own audit trail.

For current vendor figures, use the provider's own pricing calculator; the numbers change too often to quote here. For our work, website maintenance is scoped and priced per site after we see the stack, never from a rate card.

Common mistakes we see

The developer registers the domain in their own account to save time, then leaves. The renewal email goes to a personal address of someone who resigned three years ago. Backups run nightly but nobody has ever restored one. The maintenance plan was agreed in a call and never written down. Everyone assumes the hosting company handles security — managed hosting patches the operating system, not your plugins.

The pattern underneath all of these is the same: ownership was assumed, not assigned. That is why changing web developers mid-project is where the gaps surface fastest. The outgoing developer has the logins, the incoming one has the code, and the owner is in the middle with neither.

A concrete scenario

A restaurant in Kathmandu runs a WordPress site with online reservations. The developer built it two years ago, registered the domain in their own name to move quickly, set up hosting, and turned on auto-renew with a personal card. The owner assumed the developer handled everything. The developer moved on.

A reservation plugin falls out of date. The site is defaced, Google flags it, and bookings drop. The owner tries to fix it but cannot reach the registrar, because the account belongs to a former contractor. The backups are on that contractor's laptop. What should have been an afternoon of patching becomes weeks of chasing access, rebuilding trust with customers, and paying a premium to recover a domain that was never truly theirs.

The breach was not the plugin. The breach was the unowned accounts.

Alternatives compared — retainer, ad-hoc, in-house

Three models cover most sites. A maintenance retainer gives you a named owner for the recurring list, with predictable cost and a response path when something breaks. Ad-hoc fixes are cheaper month to month, but you are at the back of the queue during an incident and nobody is watching between tickets. In-house gives full control but means hiring, training and covering for holidays and leavers.

The simpler option often wins. A static brochure site with no forms can run fine on managed hosting plus occasional ad-hoc help. The moment you take payments, hold personal data or depend on the site for bookings, a written retainer or a real in-house owner stops being optional. The deciding question is not "can we afford it" but "who answers the phone at 2 a.m. when it is down".

In short

• You own the accounts, the domain, the data and the renewal paths.
• Your developer owns the code, the hardening and the patches inside the paid scope.
• Backups, monitoring and incident response need a named owner or they lapse.
• Verify ownership once, in writing, before you need it in a crisis.

People also search for

• Who actually owns my website code and domain?
• What should a website handover checklist include?
• How do I change web developers without losing access?
• Does shared hosting include security for me?
• Should I rebuild my website to fix security debt?
• What questions should I ask a web developer about maintenance?

If you are not certain which list is yours, our team can run the ownership audit with you, turn the gaps into a written plan, and help you keep every account in your own name — without locking you into anything. Start with a conversation at our contact page, or see what ongoing care covers under website maintenance.