How to talk to your developer about website security

You have a security report in front of you, an email from your hosting company, or a message from a customer saying something looks odd. You are not sure how serious it is. You do not want to sound as if you have no idea, and you do not want to pay for work that was never needed.

You do not need technical knowledge to have a good conversation with your developer. You need structure: a clear request, a firm date, and a way to check the job was done. Here is how to put that together.

What to send in the first message

A developer works fastest when they get three things up front.

The finding in the source's own words. Copy the name of the problem exactly as the report or the host wrote it. Do not paraphrase. "Backup file publicly accessible" tells a developer far more than "something is wrong with the backups".

The exact address. Not "on the website", but the full address of the page or file, for example https://yourdomain.com/backup.zip.

The evidence. A screenshot with the date visible, the full report attached, the forwarded email from your host. That way nobody has to guess what you saw.

The whole message can be as short as this:

Subject: yourdomain.com, backup file publicly accessible

Hi Mark, a security check on 2 September showed that a backup of the site can be downloaded from https://yourdomain.com/backup.zip. The screenshot and the full report are attached. Could you confirm whether that is right, and send me a quote and a date for the fix? If you think it is a false alarm, please tell me why in a couple of sentences.

One thing not to send: passwords in the body of an email. If your developer needs access to the admin panel, create a separate account for them that is easy to remove later.

Ask for a quote and a date, not for "a quick look"

"Have a quick look when you get a minute" is a request that can wait for months. Ask for four concrete things instead: what exactly will be done, what it costs or how many hours it takes, by when, and whether anything could stop working in the process.

That last question matters more than it seems. Updating an old plugin can be simple, or it can drag changes to the theme along with it. Better to know beforehand than to find out on a Friday evening that the order form is broken.

If you pay your developer a monthly fee, ask whether the fix is covered or counts as separate work. For anything serious, ask them to separate two things: removing the symptom and closing the cause. Deleting a malicious file without finding out how it got onto the server is a fix that lasts about a week.

Agree what happens this week, this month and later

Not everything is urgent, and trying to fix everything at once usually means nothing gets done properly. Three time frames work well.

This week covers anything someone could use right now or that exposes data: a backup or configuration file anyone can download, a plugin with a known hole that is being actively exploited, a Google warning, an expired certificate, an admin account nobody recognises, a form that sends data unencrypted.

This month covers overdue updates with no known active attack, a missing DMARC record or one set to p=none, missing security headers, and old accounts belonging to former staff or contractors.

Later covers things that raise the bar but will not hurt anyone if they wait a few weeks: hiding version numbers, fine-tuning a content security policy, moving to better hosting.

Your developer may see the order differently, and it is worth hearing why. The final call is yours, though, because you carry the risk and pay for the consequences.

How to check the fix was done

"Done" in an email is not enough. Ask for a short note: what was changed, where and when. Two sentences will do, as long as they are in writing.

Some things you can check yourself. If the problem was a backup file, its address should now show an error rather than start a download. If it was the certificate, the padlock in your browser will show a new expiry date. If it was updates, nothing should be waiting in the queue on the Plugins page in WordPress.

The simplest check is to run the same test that found the problem and compare the results. If the finding has gone from the report, you have your confirmation. If it has not, you have a specific reason to pick up the conversation again.

Keep all the correspondence in one folder. It helps with the next fix, and if data ever leaks, it shows you took care of security, which GDPR expects you to be able to prove.

What a sensible maintenance plan includes

One-off fixes put out fires. To stop them starting, a website needs regular care. A sensible monthly scope for a small business site looks like this:

• updates to the CMS, theme and plugins at least once a month, with urgent security patches sooner, and a check of the site after every update,
• backups stored away from the server, with a test restore every so often,
• monitoring that the site is up and that the certificate is not about to expire,
• a review of the accounts that can log in to the admin panel,
• a periodic security check from the outside,
• a short monthly summary: what was done and what needs your decision,
• an agreed response time and contact channel in case of a break-in.

Prices vary a lot, so compare what is included rather than the monthly figure alone. And make sure of one thing whatever the contract says: the domain and the hosting should be registered to your business, and you should have your own administrator account. If the relationship ends, you must not be locked out of your own website.

Red flags in the answers

You do not need to judge the site technically to spot answers that should worry you:

• "WordPress is secure, there is nothing to do."
• "We don't update because something might break." Sometimes that is true, but then the answer is a staging copy of the site where updates get tested first, not skipping updates.
• "The backups are on the server." If that means the same server the site runs on, a break-in or a failure takes them out together with the site.
• "Just send me your password." Everyone should have their own account.
• "It's a false positive", with no explanation.
• "I'll get to it", with no date.
• Reluctance to give you access to your own hosting, domain or admin panel.

A good developer does not take questions personally, because clear questions make it easier to agree the scope and get paid for it. If the answers come back vague or defensive, that tells you something too, and it is good to have it in mind before the next contract.