Website Security Checklist for Small Business

A small-business website does not become secure when it launches. The software changes, staff accounts change, plugins and third-party services change, vulnerabilities are discovered, certificates expire, forms collect new information, and backups quietly fail. Security is the continuing work of knowing what the site depends on, limiting access, applying updates, watching for abnormal behavior, and preparing to recover.

The website may be modest, but its consequences are real. An attacker who gains administrative access can alter pages, redirect customers, inject malicious code, steal form submissions, send spam, damage search visibility, or use the hosting account to reach other systems. A prolonged outage can interrupt enquiries, bookings, payments, and customer trust.

This practical checklist explains how a small business can manage website security after launch. It follows the same security-by-design principles used in Waldok’s security approach: clear data boundaries, explicit ownership, least-privilege access, secure delivery, monitoring, maintenance, and a tested path to recovery.

Treat website security as business risk

Security decisions should follow the website’s role. A five-page brochure site, customer portal, online store, membership site, booking system, and application form expose different data and operations. Start by identifying what the business could lose if the site were altered, unavailable, or used to expose information.

Consider customer harm as well as internal inconvenience. A forged bank-detail notice, malicious download, stolen contact form, or fake checkout can affect people who trust the business’s domain. Search engines and browsers may warn users or remove compromised pages from results. Recovery can involve technical cleanup, notifications, password resets, investigation, legal advice, and rebuilding confidence.

The NIST Cybersecurity Framework 2.0 resources for small businesses organize risk management around six functions: Govern, Identify, Protect, Detect, Respond, and Recover. A website-security program needs all six. Preventive controls alone do not tell the team how to recognize or recover from a failure.

Prioritize the customer journeys that matter

List the website tasks that generate revenue, service customers, or carry sensitive information: enquiries, appointments, purchases, account access, document uploads, payments, password resets, and integrations. Identify what each task depends on and how the business would operate if it failed.

This approach complements our guide to making a business website ready for modern search. A site cannot serve as a trustworthy public source of truth if attackers, expired software, or broken integrations can quietly alter what customers see.

Assign ownership and responsibilities

Every production website needs a named business owner and a named technical owner. The business owner decides what the site collects, publishes, and connects to. The technical owner manages the platform, access, updates, monitoring, backups, recovery, and vendor coordination. A small company may use one employee and one external provider, but the responsibilities still need names.

Write down who approves new administrators, plugins, forms, tracking tools, integrations, DNS changes, and production releases. Define who reviews alerts and who can take the site offline during an incident. Record an emergency contact outside the website itself so it remains available when the site is down.

Clarify the handoff after launch

Many security gaps begin with an incomplete project handoff. The developer assumes the host manages updates. The host manages the operating system but not the content-management system. The owner thinks backups are included, but nobody has tested a restore. The marketing agency retains an administrator account after the engagement ends.

The handoff should identify every layer, account, provider, renewal, monitoring tool, backup location, update process, and recovery step. Waldok’s delivery process treats documentation, deployment, validation, and ongoing improvement as parts of delivery rather than optional work after launch.

Know what the website depends on

Create an inventory that a person can understand without searching old email. Include the domain registrar, DNS provider, web host, server or plan, content-management system, theme, plugins or packages, database, storage, email delivery, forms, analytics, tag manager, payment provider, booking service, customer relationship system, content-delivery network, firewall, monitoring, and backup service.

For each component, record its purpose, owner, administrative URL, account owner, renewal date, current version where relevant, update method, data handled, provider contact, and what would happen if it failed. Store credentials in an appropriate password manager rather than in the inventory document.

Map data flows and secrets

A contact form may pass through the website, database, email service, staff inbox, spam filter, CRM, and backup. A booking may reach a calendar. A payment form may redirect to or embed a payment provider. Map the actual route and identify API keys, tokens, passwords, signing secrets, and encryption keys.

Secrets should not appear in public code repositories, page source, analytics, client-side scripts, screenshots, shared notes, or support tickets. Give each integration only the permissions it needs and rotate or revoke credentials when staff, vendors, or systems change.

Secure accounts and administrative access

An administrator account can often change content, install software, create users, export data, or run code. Protect the domain registrar, DNS, hosting panel, server, CMS, email, analytics, tag manager, payment, backup, and source-control accounts with the same seriousness as the website administrator.

Give each person an individual account. Shared logins make it difficult to remove one person, attribute changes, or investigate an incident. Use roles that match the job: an editor who publishes pages may not need plugin installation, user management, server access, billing, or DNS control.

Use password managers and strong MFA

Require long, unique passwords generated and stored in a reputable password manager. Do not reuse the owner’s email password for the website, hosting, or registrar. Recovery email accounts also need strong protection because they can reset other credentials.

CISA’s small-business MFA guidance recommends enabling MFA wherever possible, beginning with administrative and sensitive access. It also explains that phishing-resistant options such as security keys provide stronger protection than text or email codes. Use the strongest practical option the service supports and protect recovery codes.

Review access on a schedule

At least quarterly, list administrators and privileged service accounts across every layer. Remove former employees, expired agencies, duplicate accounts, test users, and integrations that no longer serve a purpose. Disable an account before an offboarding meeting ends when the situation requires immediate separation.

Manage updates and software supply chains

Website software contains code from several sources. The core platform, theme, plugins, packages, server components, deployment tools, and third-party scripts can each introduce vulnerabilities or incompatible changes. Updates are security work and change management at the same time.

Maintain a regular update window and an emergency path for actively exploited or high-impact vulnerabilities. Before a routine change, confirm that a current backup exists, understand what is changing, and test high-value journeys afterward. Critical patches may need faster action with focused validation.

The OWASP Top 10:2025 includes software supply chain failures among its major web-application risks. A component may be compromised upstream, abandoned, obtained from an untrusted source, or replaced with a malicious package. Version numbers alone do not establish trust.

Use trusted sources and verify support

Download the platform and extensions from official repositories or established vendors. Check who maintains the component, how recently it was updated, which platform versions it supports, whether security issues receive fixes, and how the vendor communicates advisories.

Keep a record of custom code and local changes. An update process that overwrites undocumented modifications may break the site; avoiding every update to preserve those modifications creates a larger security problem. Move custom work into supported extension points and version control.

Reduce plugin, theme, and integration risk

Every extension increases the amount of code, privilege, and vendor dependency the site must manage. Install a plugin or third-party script only when it solves a defined requirement. Remove inactive or replaced components rather than leaving them disabled indefinitely.

Review requested permissions. A form tool may need to store submissions and send email. It may not need user-administration access. A marketing script may observe visitors across every page. A support widget may receive names, messages, page URLs, and device information. Understand the data and authority before adding it.

Avoid overlapping tools

Several security, cache, image, SEO, backup, form, or analytics plugins that perform similar jobs can conflict and make responsibility unclear. Choose one controlled approach per function where practical. Document why each component exists and who owns its configuration.

Test removal in a safe environment. Some plugins leave scheduled jobs, database tables, user roles, files, redirects, or public endpoints behind. Deactivation is not always complete cleanup.

Review hosting and server boundaries

A hosting provider may manage physical infrastructure, networks, operating systems, control panels, malware scanning, firewalls, certificates, backups, and platform updates, or only some of them. Ask for a written responsibility boundary. “Managed hosting” has no universal meaning.

The FTC’s Cybersecurity for Small Business guidance recommends asking hosts about TLS, software versions and updates, administrative access, prior breaches, data storage and encryption, and the contact for suspicious activity. These are useful questions before purchase and during renewal. Our small-business hosting guide provides a complete provider scorecard.

Separate sites and environments

A development, staging, or old campaign site can become the weakest route into shared infrastructure. Apply authentication, updates, backups, monitoring, and deletion rules to non-production environments too. Do not copy real customer data into a test site unless there is a defined need and equivalent protection.

Use separate credentials and permissions where possible. A compromise in one small microsite should not automatically expose every domain, mailbox, database, and production secret in the account.

Use HTTPS and protective browser controls

HTTPS protects information in transit between the visitor and the site and helps the browser confirm which domain it reached. Redirect all ordinary HTTP requests to HTTPS, renew certificates automatically where practical, and monitor expiry and configuration. Fix mixed content so secure pages do not load scripts, forms, images, or fonts over insecure connections.

HTTPS does not prove that the site is trustworthy or uncompromised. It protects the connection. A malicious page can also use a valid certificate, and an attacker with administrator access can change content served over HTTPS.

Set browser security headers deliberately

Headers can reduce specific browser-side risks when correctly configured. Examples include HTTP Strict Transport Security, Content Security Policy, frame controls, referrer policy, content-type options, and permissions policy. The correct values depend on the site’s scripts, embeds, subdomains, and integrations.

Test in report-only or staging modes where appropriate. A copied policy can break payments, maps, forms, analytics, or accessibility tools. The MDN reference for HSTS explains how browsers remember to use HTTPS and why deployment details such as subdomains and certificate health matter.

Minimize form and customer data

Collect only information the business needs for a stated purpose. A simple enquiry rarely needs a date of birth, identification document, payment card, medical detail, or extensive profile. Every stored field adds handling, access, retention, and incident responsibilities.

Explain what the form collects and what happens next. Protect submissions during transit and storage. Limit access to the staff who handle them, and define when records leave the website database, how duplicates are managed, and when they are deleted.

Our guide to website accessibility for small businesses covers labels, understandable errors, keyboard access, and recoverable submission. Security controls should preserve those qualities. A CAPTCHA or timeout that blocks legitimate customers, assistive technology, or password managers needs a better design.

Treat file uploads as high risk

If customers upload documents, restrict allowed types and size, rename files, scan where appropriate, store them outside executable web paths, control access, and prevent public indexing. Do not trust a filename, extension, or browser-provided content type by itself.

Define who reviews uploads and how suspicious files are handled. A public upload form should not become a free storage service or a path to execute code on the server.

Back up the complete site and test restores

A useful backup includes everything needed to restore service: database, uploaded files, application code or deployment source, configuration, environment information, DNS and certificate details where relevant, and documentation for connected services. A database alone may not contain images or custom code. A file archive alone may not contain orders, users, or settings.

Keep more than one recovery point because a compromise or corruption may go unnoticed. Protect backups with access control and encryption appropriate to their contents. Keep at least one copy separated from the production account so an attacker or failed automation cannot destroy both the site and its recovery path.

Test the restore, not only the backup job

A green “backup complete” message proves that a process wrote something. It does not prove that the archive is complete, readable, safe, or restorable within the time the business needs. Perform a controlled restore to a separate environment and verify pages, forms, media, users, transactions, integrations, and configuration.

Record recovery time and the steps that required human knowledge. Update the runbook after every test. If one contractor is the only person who knows how to recover the site, availability depends on that person.

Monitor availability, changes, and alerts

Monitoring should answer: is the site reachable, are certificates healthy, do critical journeys work, did important files or settings change, are administrative logins unusual, are error rates rising, and did security controls block or detect something meaningful?

Send alerts to a monitored destination outside the website. Classify severity and assign an owner. Too many low-value notifications train people to ignore the message that matters. Combine automated alerts with periodic human review of administrator accounts, integrations, form delivery, backups, logs, and public pages.

Preserve enough evidence

Logs can help determine what happened, but they may also contain IP addresses, account names, URLs, form errors, and other sensitive information. Record events needed for security and operations, restrict access, protect integrity, synchronize time, define retention, and avoid placing passwords, tokens, or full form contents in logs.

Test the alert path. A monitoring email sent through the compromised website or to an abandoned mailbox may never reach the team.

Control spam, bots, and abusive traffic

Public websites attract crawlers, credential guessing, form spam, scraping, vulnerability probes, inventory abuse, fake account creation, and attempts to consume server resources. Use layered controls appropriate to the actual problem: rate limits, login throttling, bot filtering, email verification, server or application firewall rules, and review queues.

Avoid treating every visitor behind a shared network, privacy tool, slow connection, or assistive technology as malicious. Measure false positives. Provide a contact route when a legitimate customer is blocked.

Protect expensive actions

Some endpoints create direct cost: sending SMS or email, generating documents, calling an AI model, checking stock, reserving appointments, processing images, or querying a paid API. Authenticate where suitable, apply quotas and rate limits, validate inputs, and monitor unexpected usage. A form can be harmless to the database but expensive to a connected service.

Protect website-related email

Website security extends to the domain’s email reputation. An attacker who can alter DNS or send convincing messages from the domain may impersonate the business even if the public pages remain online. Protect registrar and DNS accounts with MFA and change alerts.

Configure SPF, DKIM, and DMARC for legitimate senders and monitor reports. The FTC small-business guidance recommends these email-authentication tools when a business uses domain-based email. Inventory every approved sending service before tightening policy so legitimate invoices, forms, newsletters, and account messages continue to work.

Do not make email the only copy of form submissions

Email delivery can fail because of configuration, reputation, filtering, DNS, or provider outages. If an enquiry is important, use a controlled system of record or queue and alert on delivery failures. Protect that record and avoid indefinite storage of every submission in multiple inboxes and databases.

Handle ecommerce and payments carefully

Use a reputable payment provider and a documented integration that minimizes the website’s exposure to card data. Keep checkout software, webhooks, API keys, plugins, and fraud controls current. Verify payment status from the trusted provider rather than from a redirect page or customer-supplied screenshot.

Protect order administration with strong access controls and MFA. Limit refunds, exports, discount creation, tax changes, and payment settings to appropriate roles. Monitor unusual orders, account changes, refunds, and failed payment patterns.

Confirm compliance responsibilities

Outsourcing payment processing can reduce scope, but it does not remove every responsibility. Determine the applicable payment-card validation, privacy, consumer, tax, and recordkeeping requirements with the provider, acquiring bank, and qualified advisers for the actual setup.

Prepare an incident-response plan

Write a short plan before an incident. Include who can declare an incident, emergency contacts, account and vendor escalation routes, how to preserve evidence, how to isolate affected systems, where clean backups and documentation are stored, who communicates with customers, and which legal, insurance, regulatory, or law-enforcement contacts may be needed.

Do not begin by deleting logs or reinstalling everything. First limit harm and preserve the information needed to understand the event. A qualified responder may need to identify how access was gained, what changed, what data or systems were reached, and whether other accounts remain exposed.

Use a clean recovery path

Restoring a vulnerable backup recreates the same problem. Recovery may require rotating credentials, removing unauthorized users, fixing the entry point, rebuilding from trusted software, checking connected services, reviewing data exposure, restoring verified content, and monitoring closely after relaunch.

The FTC’s guidance advises businesses to plan for continuity, preserve useful evidence, investigate, contain affected systems, use backups, and notify affected parties when required. Applicable duties vary by jurisdiction, sector, contract, and information involved, so obtain advice suited to the incident.

Ask vendors useful security questions

A developer, agency, host, managed provider, plugin vendor, form service, analytics tool, or payment processor may affect the site’s security. Ask specific questions and record the answers.

Which layers do you manage, and which remain our responsibility?
How quickly are routine and urgent security updates applied?
Which staff can access our site, data, backups, and production credentials?
Is MFA required for privileged access?
Where is data stored, which subprocessors receive it, and how long is it retained?
How are backups separated, protected, and restore-tested?
What monitoring and alerting are included, and who responds outside business hours?
How will you notify us of a vulnerability, breach, outage, or provider change?
Can we export our site, data, logs, configuration, and documentation in a usable form?
What happens to access and retained data when the service ends?

Keep business control of critical accounts

The business should know who legally controls the domain, hosting, analytics, payment, and other critical accounts. Use organization-owned contact details and maintain at least one appropriately protected business administrator. A vendor can manage the service without owning the only recovery email, billing relationship, or registrar login.

A WordPress-specific checklist

WordPress security follows the same general principles: trusted software, timely updates, limited access, containment, backups, monitoring, and recovery. The official WordPress hardening guide describes security as risk reduction and recommends current software, trusted sources, strong authentication, appropriate permissions, database protection, backups, and careful server configuration.

Keep WordPress core, the active theme, and all plugins current.
Remove unused themes and plugins after preserving anything required for rollback or licensing records.
Use individual accounts and the lowest suitable role; minimize administrators.
Require strong passwords and MFA for privileged accounts.
Protect hosting, SFTP or SSH, database, DNS, registrar, backup, and email accounts too.
Use trusted plugin and theme sources, and check maintenance and compatibility before installation.
Disable dashboard file editing when the deployment model does not require it.
Use secure file permissions and avoid broad write access.
Keep secrets outside public files and repositories; rotate exposed keys immediately.
Back up the database and files, separate copies from production, and test restoration.
Monitor administrator changes, file changes, login abuse, errors, uptime, and certificate health.
Test forms, search, navigation, login, checkout, and integrations after updates.

A security plugin is one control

A reputable security plugin may add login protection, file checks, firewall rules, scanning, or alerts. It cannot compensate for abandoned extensions, exposed hosting credentials, weak registrar access, untested backups, vulnerable custom code, or nobody reading alerts. Configure it for the site, understand what it covers, and review its data and server impact.

A 30-day security plan

Week 1: govern and identify

Name the business and technical owners. Inventory the domain, DNS, host, site software, plugins, themes, integrations, forms, data, email, payments, analytics, backups, and monitoring. List privileged accounts and remove obvious access that no longer belongs.

Week 2: protect

Place unique credentials in a password manager, enable MFA, apply current updates, remove unused components, confirm HTTPS, protect secrets, review roles, and document the host’s responsibility boundary. Minimize forms and close unnecessary public endpoints.

Week 3: detect and recover

Configure uptime, certificate, login, change, and error monitoring appropriate to the site. Verify alert delivery. Review backup scope and retention, then restore a copy in a separate environment and test the important journeys.

Week 4: respond and improve

Write the incident plan, vendor contacts, clean-recovery steps, and customer-communication ownership. Run a tabletop exercise: an administrator account is compromised, the homepage changes, or the checkout fails. Record gaps and schedule the next monthly and quarterly reviews.

Common questions

Is a small website worth attacking?

Attackers often scan large numbers of sites for known weaknesses, weak passwords, exposed services, or outdated components. They may want the site’s visitors, hosting resources, email reputation, customer data, or access to connected systems. Business size does not prevent automated targeting.

Does HTTPS make the website secure?

HTTPS protects the connection and confirms the domain when certificates and DNS work correctly. It does not secure administrator accounts, code, plugins, forms, databases, backups, third-party scripts, or business processes.

How often should website software be updated?

Maintain a routine review schedule and a faster process for important security fixes. The correct timing depends on the vulnerability, exposure, component, vendor guidance, and business impact. Back up and test critical journeys, but do not leave known serious issues open merely because the normal maintenance day is later.

Are host backups enough?

They may be, but verify the scope, frequency, retention, separation, encryption, access, recovery process, and restore time. Keep enough independent documentation and access to recover if the hosting account itself becomes unavailable or compromised.

Can a website ever be completely secure?

No useful internet-connected system can promise zero risk. The practical goal is to reduce likely paths, limit damage, detect problems, respond effectively, and recover within the business’s needs. Review controls as the site, threats, vendors, and business change.

Should the business perform penetration testing?

A qualified test can be valuable for custom applications, authenticated portals, payment or sensitive-data workflows, major changes, contractual requirements, or higher-risk services. Obtain written authorization, define scope and safety, coordinate with the host and vendors, and plan how findings will be fixed and retested.

Research references

A secure business website is an owned and maintained service. Know its dependencies, protect its accounts, keep its software current, collect less data, verify backups, monitor meaningful events, and practice recovery before an incident. For the wider business program, continue with our cybersecurity fundamentals guide. For help defining secure website or application boundaries, contact Waldok Solutions.