Website Security Checklist for Small-Business Sites

Website security checklist: start with assets, data, and consequences

A website security checklist should begin with what the business could lose: availability, trustworthy content, customer information, money, or control of its accounts. Those consequences determine the systems, evidence, and response work that deserve priority. Record the assumptions and the person authorized to accept unresolved risk.

This checklist establishes an ownership and configuration baseline for a small organization. It is not a penetration test, security assessment, compliance statement, or legal opinion. Custom applications, sensitive data, authentication, payments, and incident evidence can require qualified security, privacy, and legal professionals.

Inventory domains, hosting, software, integrations, data, and owners

List the domains and subdomains, registrar, DNS provider, hosting accounts, servers, control panels, CMS, themes, plugins, packages, and server runtimes that keep the site operating. Add form services, CRM, payments, chat, analytics, email marketing, transactional email, monitoring, deployment systems, code repositories, and recovery mailboxes.

Map the information those services collect and exchange, including uploads, exports, backups, and spreadsheets created outside the site. Assign each asset and integration a named owner, recovery path, support contact, and review date. Retire or isolate forgotten staging hosts and campaign sites instead of leaving unmaintained software attached to the brand.

• Asset, account, version, purpose, and environment
• Data received, stored, transmitted, and retained
• Business owner and technical operator
• Recovery method, vendor contact, and next review

Minimize data collection, retention, and access

Review every form field and data flow. The FTC's guidance for businesses recommends taking stock of personal information, keeping only what is needed, protecting it, disposing of it securely, and planning for incidents. Remove fields and copies without a documented purpose, define retention and disposal, and involve qualified counsel when legal requirements are unclear.

Apply least privilege to people and services. Give editors, support staff, agencies, plugins, and API clients only the access required for their work. Prefer individual accounts so access can be revoked and activity can be attributed. Review access after role changes and departures, not only during an annual audit.

Protect registrar, hosting, CMS, email, and vendor accounts

Prioritize the accounts that can redirect, reset, or replace the site: registrar, DNS, hosting, primary email, CMS, repository, deployment, payments, and backup systems. Use unique credentials stored in an approved password manager and multi-factor authentication where available. Verify that recovery addresses and phone numbers are current and controlled by the business.

Use named accounts instead of a shared administrator credential. Keep registrar contact information monitored, enable available transfer protections, restrict administrator roles, and review vendor access. Document a break-glass recovery route and protect it as carefully as the everyday login.

Maintain software, configuration, transport security, and secrets

Keep supported versions of the CMS, themes, plugins, dependencies, and server runtimes, and remove components the site no longer uses. Review release notes and test business-critical changes in a controlled window. WordPress's hardening guidance provides platform-specific recommendations for updates, file permissions, database access, and administration.

Serve the public site over HTTPS, monitor certificate renewal, and remove mixed-content requests. Store API keys, tokens, and database credentials in the platform's secret or environment configuration rather than published files or tracked source. Rotate an exposed secret; removing it from the latest version does not invalidate a credential that may already have been copied.

Verify backups, restoration, logging, monitoring, and alerts

Set backup frequency from the amount of data the business can tolerate losing. Capture the parts required for recovery, keep a protected copy outside the failure boundary it is meant to cover, and test a restore in an isolated environment. Record the recovery point, elapsed time, missing elements, and any change made to the procedure.

Retain the logs needed to investigate the systems in scope, protect them from casual alteration, and synchronize system time. Monitor availability and meaningful failures, including forms, scheduled jobs, certificate renewal, and update errors. Route alerts to a named person with a response instruction rather than to an unattended mailbox.

Review forms, uploads, authentication, sessions, and business logic

OWASP's Top Ten and Web Security Testing Guide describe important categories and test areas for web applications, including access control, injection, authentication, configuration, and business logic. An owner can verify intended behavior and collect evidence, but a few manual checks do not establish that an application is secure.

Confirm that private pages require the expected authorization, account recovery does not reveal unnecessary information, logout and session expiry work, and errors do not expose internal details. Review upload types, sizes, storage, and delivery. Test discounts, permissions, booking limits, and other business rules in an authorized non-production environment. Escalate unexpected behavior rather than experimenting against live customer data.

Prepare an incident response and vendor-notification path

Write down who can contain the site, preserve evidence, restore service, communicate internally, contact vendors, and authorize public or customer communications. Keep provider support channels, account identifiers, backup locations, counsel, insurance, and specialist contacts in a protected location available during an outage.

Preserve relevant logs and a copy of the affected state before cleaning up when it is safe and authorized to do so. A restore without identifying and correcting the entry path may reproduce the incident. Notification obligations depend on the data, location, sector, and contracts involved; obtain qualified legal advice rather than deciding from a generic checklist.

Know when to commission professional security testing

Obtain qualified testing when custom code controls authentication, authorization, transactions, uploads, or sensitive records; when contracts or regulation require evidence; or after a material incident. OWASP's Web Security Testing Guide can help define areas of review, but the engagement still needs a written scope, authorized environment, rules of engagement, reporting method, and retest plan.

Budget for remediation and verification, not only the initial report. Track findings with owners and due dates and distinguish a confirmed fix from accepted residual risk. Your next action is to complete the asset-and-owner inventory, then protect the registrar, DNS, hosting, CMS, and recovery email accounts with the strongest available account controls.