Security questions to ask a website supplier

A short, direct set of questions, asked before a deposit is paid rather than discovered after an incident, tells a business considerably more about a supplier’s actual security practice. That beats any general reassurance on their marketing page. A supplier confident in their own process answers all of these plainly and specifically. A vague answer to any one of them is itself the answer.

The six security questions to ask before paying a deposit

Who applies updates, and how often

Ask directly whether core software, themes and plugins will be kept updated after launch, by whom, and on what schedule. “We’ll take care of it” is not an answer — a specific cadence and a specific named responsible party is. If the answer is that updates are the client’s own responsibility with no ongoing arrangement offered, that is a legitimate answer too, provided it is stated plainly rather than left ambiguous until it matters.

Where backups are stored, and whether a restore has ever been tested

Ask specifically where backups are kept — on the same server, with the hosting provider, or somewhere genuinely separate. Ask whether the supplier has ever actually restored from one, for any client, as opposed to simply configuring the process and assuming it works. Backups you have actually tested sets out why this distinction matters as much as the backup existing at all.

How admin access is handled, and by whom

Ask who will hold administrator access once the site launches, and whether two-factor authentication is enabled on it. Also ask how many people currently have any level of access to the site during the build. A supplier who cannot immediately answer who currently has access to a client’s own site in progress is not tracking it closely enough.

What happens if the site is compromised

Ask what the supplier’s actual process is if a client’s site is compromised. Not a general reassurance, but a specific description of what they would do in the first hour. Also ask whether that is covered under any existing arrangement, or billed as separate emergency work. A supplier with no answer to this has not thought about it, which is itself informative.

Whether payment data is handled directly or through a gateway

For any site taking payments, ask explicitly whether card details ever pass through the business’s own server, or go directly to a payment gateway from the customer’s browser. Payments, and what you should never store yourself explains why the second answer is the only acceptable one for a small business.

What is left running after the project finishes

Ask whether any staging, test or old version of the site will be removed once the live site is confirmed working, and if not, why not. Staging, test and abandoned installations sets out why a forgotten copy is a genuine, common risk, rather than harmless leftover clutter.

Reading the answers you get from a supplier

What a vague answer to any of these actually tells you

Not necessarily that the supplier is dishonest. More often it means security has not been a deliberate, named part of their process. That is common, and still worth knowing before signing rather than after. A supplier who answers all six specifically and confidently is telling you something concrete about how the rest of the engagement will be run.

Why written answers matter more than a verbal reassurance

A supplier’s spoken confidence in a sales conversation is not the same as a written commitment. Asking for these six answers in writing — in a quote, a proposal, or an email — creates a record that can actually be referred back to later. That beats a general impression of reassurance that is hard to hold anyone to afterwards.

Timing this conversation correctly

These questions are best asked before signing, not after a project has already started. A supplier’s answers can genuinely change the choice of who to engage. Discovering a weak answer partway through a build is a far more awkward and costly moment to renegotiate expectations than before any commitment has been made.

A short version of the whole list, for a quick conversation

Updates, backups, access control, incident response, payment handling, and cleanup after launch — six words, six questions. A supplier confident across all six is telling a business something genuinely useful about how the rest of the relationship will likely run.

If a supplier’s answers are not good enough

What to do with an unsatisfactory set of answers

Raising the specific gap directly, rather than walking away silently, gives a supplier the chance to close it before work begins. Many gaps in this list are gaps of practice rather than of intent. They are often fixed simply by being named plainly and agreed to in writing.

Why this list is worth revisiting with an existing supplier too

These questions are not only for a new engagement. Putting them to a long-standing supplier occasionally is a reasonable, ordinary check-in, rather than an accusation. A supplier confident in their own practice will not be offended by being asked to restate it.

A note on tone

None of these questions need to be adversarial. Framed as ordinary due diligence — “just confirming how we handle X” — they read as the responsible, competent question they are. A good supplier answers them as a matter of course, rather than as a challenge to their professionalism.

The same questions in vendor and supply-chain security terms

What to ask suppliers about a threat, incident, data stored, vulnerability or attacks

In the language larger organisations use, a web design supplier is a vendor, or a third party handling company data on the business’s behalf. The same cybersecurity due-diligence questions enterprise vendor-risk and supply-chain processes put to vendors and companies generally apply here too, at a smaller, more practical scale. That means how access is controlled, whether sensitive information or other company data is encrypted, what an incident response actually looks like, and whether known vulnerabilities and security threats in the software get patched promptly — the same questions a larger organisation would put to any vendor in its supply chain, to guard against supply-chain attacks reaching its own systems through a third party. A small business does not need a formal set of security requirements, a security-measures audit or a penetration-test report from every supplier. The plain-English version already covered above — data stored somewhere the business can name, and a breach response the supplier can actually describe — covers the practical risks a small business genuinely faces, without importing enterprise vendor-risk process wholesale.

Where to go from here

The broader set of questions worth asking any supplier before signing, beyond security specifically, is set out on choosing between suppliers. And the causes these questions are actually testing for are set out fully in why small-business websites get compromised.