---
title: "Website security starts before the first line of code: a practical checklist for business owners"
description: Seven security questions every business owner should ask their web developer, covering accounts, updates, backups, logins, forms and third-party code.
---

<https://www.filtedev.com/>

- [Services](https://www.filtedev.com/services)
- [Work](https://www.filtedev.com/work)
- [About](https://www.filtedev.com/about)
- [Blog](https://www.filtedev.com/blog)

[Request a quote](https://www.filtedev.com/contact)

[← All articles](https://www.filtedev.com/blog)

# Website security starts before the first line of code: a practical checklist for business owners

Edmond DemaSeptember 26, 20266 min read

Most small business websites are not hacked by someone who chose them as a target. They are found by automated tools that scan the internet around the clock, looking for known weaknesses: an outdated plugin, a reused password, an admin account nobody remembered to remove. Once found, the site is used to send spam, host malware or redirect visitors elsewhere, often without the owner noticing for weeks.

The good news is that most of these problems are preventable, and preventing them is much cheaper than cleaning up afterwards. The catch is that security is hard to add at the end. It depends on decisions made at the start of a project: who owns what, how updates happen, and what gets installed. This checklist covers the questions worth asking before a new website is built, or about the one you already have.

## 1. Who owns the accounts?

Your domain name, your hosting, your DNS settings and your website platform should all be registered in your business's name, with your email address as the owner. Your developer should have their own login with the access they need, not the master account.

This matters for security as much as for business continuity. If a developer or agency disappears, gets hacked or simply stops replying, you need to be able to change passwords, revoke access and move on without asking anyone's permission.

**Ask:** "If we stopped working together tomorrow, could I lock you out of everything on my own?" The answer should be yes.

## 2. How will updates be handled?

Every website runs on software that needs updating: the content management system itself, its plugins or extensions, and the code libraries a custom site depends on. Security fixes are released regularly, and attackers pay close attention to what they fix, because every published fix also tells them which older versions are vulnerable.

A site that was secure on launch day will not stay secure on its own. Someone has to apply updates, check that nothing broke, and do it on a schedule rather than when there is spare time.

**Ask:** "Who applies updates, how often, and how do you test them before they reach the live site?"

## 3. What happens if something goes wrong?

Backups are the difference between a bad afternoon and a lost business asset. A useful backup setup has three qualities: it runs automatically, copies are stored somewhere separate from the website itself, and someone has actually tested restoring from them.

That last point is the one most often skipped. A backup that has never been restored is a hope, not a plan.

**Ask:** "How often is the site backed up, where are the backups kept, and when did you last test a restore?"

## 4. Who can log in, and how?

Every person who works on your site should have their own account, with only the permissions their role needs. A content editor does not need the ability to install plugins. A freelancer who finished a project last year does not need access at all.

Shared logins make it impossible to know who did what, and impossible to remove one person without disrupting everyone else. Two-factor authentication should be switched on for every account that can change the site, especially administrators.

**Ask:** "Does everyone have their own login, is two-factor authentication required, and how do we remove people who leave?"

## 5. How are your forms protected?

Contact and quote forms are often the only part of a business website that accepts information from strangers, which makes them a common target. At a minimum, forms should be protected against spam bots, check the information they receive, and send it over an encrypted connection.

It is also worth knowing where form submissions go. Sending them to a CRM or a secure inbox is fine. Sending sensitive details such as health, financial or identity information through plain email notifications is not, and in some industries it creates legal obligations you may not be meeting.

**Ask:** "Where does form data end up, who can see it, and is anything sensitive being emailed around?"

## 6. What third-party code runs on your site?

Analytics tools, advertising pixels, chat widgets, booking tools and embedded videos all load code from other companies onto your pages. Each one is useful, and each one is a dependency you do not control. If one of those providers is compromised or changes what its code does, your website changes with it.

This does not mean avoiding third-party tools. It means keeping a list of what is installed, removing anything no longer used, and being deliberate about adding new ones.

**Ask:** "Can you give me a list of every external script on the site and what each one is for?"

## 7. Are the basics in place?

A few technical foundations should be standard on any professional website today:

- HTTPS on every page, so information between visitors and your site is encrypted.
- Security headers that tell browsers how to handle your content safely.
- Administrator areas that are not left open to anyone who guesses the address and a password.
- Error pages that do not reveal technical details about how the site is built.

You do not need to understand how each of these works. You do need a developer who can explain, in plain language, what they have done about them.

## Red flags when hiring a developer

Be cautious if a developer or agency:

- Wants to register your domain or hosting in their own name.
- Shares one login across their whole team.
- Has no answer for how updates will happen after launch.
- Cannot explain where backups are stored or how a restore would work.
- Installs a new plugin for every small feature without discussing it.

None of these automatically means someone is careless, but each is worth a direct conversation before you sign anything.

## How we approach it at FilteDev

FilteDev is led by an engineer who spent two years working full time in information security before returning to development, including work on websites delivered under HIPAA obligations for healthcare organizations. That background shapes how every project here is built: accounts stay in the client's name, access is limited to what each person needs, updates and backups are planned before launch, and every third-party tool is there for a reason.

Security is not a separate package or an upsell. It is part of building a website properly.

If you would like a second opinion on your current website, or you are planning a new one, [send us a short brief](https://www.filtedev.com/contact) and we will tell you honestly where you stand.

[← Back to all articles](https://www.filtedev.com/blog)

## Want this done properly?

Send a short brief about your website or project and we will reply with next steps and a written quote.

[Request a quote](https://www.filtedev.com/contact)[contact@filtedev.com](mailto:contact@filtedev.com)

**FilteDev**

Web development studio led by Edmond Dema. Based in Kosovo, working with clients in the United States and Europe.

[Services](https://www.filtedev.com/services)[Work](https://www.filtedev.com/work)[About](https://www.filtedev.com/about)[Blog](https://www.filtedev.com/blog)[Contact](https://www.filtedev.com/contact)

[contact@filtedev.com](mailto:contact@filtedev.com)[+1 724 345 2739](tel:+17243452739)[Privacy policy](https://www.filtedev.com/privacy)

© 2026 FilteDev. All rights reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@id" : "https://www.filtedev.com/about#edmond-dema",
    "@type" : "Person",
    "name" : "Edmond Dema",
    "url" : "https://www.filtedev.com/about"
  },
  "dateModified" : "2026-09-26T13:01:01Z",
  "datePublished" : "2026-09-26T12:49:22Z",
  "description" : "Seven security questions every business owner should ask their web developer, covering accounts, updates, backups, logins, forms and third-party code.",
  "headline" : "<span id=\"hs_cos_wrapper_name\" class=\"hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text\" style=\"\" data-hs-cos-general-type=\"meta_field\" data-hs-cos-type=\"text\" >Website security starts before the first line of code: a practical checklist for business owners</span>",
  "inLanguage" : "en",
  "mainEntityOfPage" : "https://www.filtedev.com/blog/website-security-starts-before-the-first-line-of-code-a-practical-checklist-for-business-owners",
  "publisher" : {
    "@id" : "https://www.filtedev.com/#organization",
    "@type" : "Organization",
    "name" : "FilteDev",
    "url" : "https://www.filtedev.com/"
  },
  "url" : "https://www.filtedev.com/blog/website-security-starts-before-the-first-line-of-code-a-practical-checklist-for-business-owners"
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Edmond Dema",
    "url" : "https://www.filtedev.com/blog/author/edmond-dema"
  },
  "dateModified" : "2026-09-26T13:01:01.621Z",
  "datePublished" : "2026-09-26T12:49:22.000Z",
  "headline" : "Website security starts before the first line of code: a practical checklist for business owners",
  "mainEntityOfPage" : {
    "@id" : "https://www.filtedev.com/blog/website-security-starts-before-the-first-line-of-code-a-practical-checklist-for-business-owners",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject"
    }
  }
}
```