Website Security Checklist for South African Small Businesses

A secure business website is not a site with a padlock and one security plugin. It is a website with current software, tightly controlled access, tested recovery, protected forms, useful monitoring and named people who know what to do when something looks wrong.

Use this checklist to find the gaps and assign them. You do not need to become a security engineer, but you do need to know who owns the domain, hosting account, application, backups and third-party services. If every answer is “the web person handles it”, the business has an ownership problem before it has a tooling problem.

What good website security looks like

No checklist can prevent every breach. The practical goal is to reduce avoidable exposure, spot trouble earlier and recover without guessing. That means protecting four things at the same time:

• Access: only the right people can reach the domain, hosting panel, website admin and connected services.
• Software: the CMS, themes, plugins, extensions and custom code are supported and patched.
• Data and recovery: backups contain what the business needs and have been restored successfully.
• Response: alerts reach a real person, suppliers know their roles and the business has a first-hour plan.

The domain name, DNS, web hosting and website application are separate layers. If that distinction is unclear, start with the explanation of domain names versus web hosting, then add the registrar, DNS provider, maintainer and application owner to your map.

Who is responsible for each security task?

Website security is shared, but shared does not mean vague. Write down the accountable party for each row and confirm the scope with the supplier. A provider can only be held to the service it actually supplies.

If two suppliers both say a task belongs to the other, the task is unowned. Resolve that before adding another plugin or dashboard.

Website security checklist: start with the highest-impact gaps

1. Map every account and recovery path

Create a simple register for the domain registrar, DNS, hosting panel, CMS administrator, database, CDN or WAF, analytics, form service, payment gateway and backup location. Record the business owner, technical contact, billing contact, renewal method and recovery email for each.

Then test the uncomfortable questions:

• Does the business control the primary account, or does a former employee or agency own it?
• Can one inaccessible mailbox lock you out of the registrar, host and website at the same time?
• Are recovery codes stored somewhere other than the device used for login?
• Can the business contact the supplier without relying on the compromised website?
• Is there a current handover document for the domain, DNS and website stack?

Do not ask suppliers to share passwords in email or WhatsApp. Give each person their own account where the platform supports it, then remove access when the job ends.

2. Patch the website without turning updates into a gamble

Outdated CMS software, plugins, themes, libraries and server runtimes can leave known weaknesses open. WordPress sites need core, plugin and theme updates; other platforms have their own release and support cycles. Remove unused extensions rather than leaving them disabled and forgotten.

An update process should include:

1. Check whether the component is still maintained and compatible with the current platform and PHP/runtime version.
2. Confirm a usable pre-change backup and a rollback path.
3. Test material updates on staging where the business risk justifies it.
4. Apply the update during a known change window.
5. Test login, forms, search, checkout, payments and other revenue-critical functions.
6. Record what changed and who verified it.

Automatic security updates can reduce delay, but they do not remove the need to watch for failed updates and broken functionality. If nobody inside the business owns this cycle, define it inside a website maintenance scope instead of waiting for a visible failure.

3. Lock down privileged access

Start with the accounts that can change DNS, install code, add administrators, view customer data or alter payment settings. Give them unique passwords stored in a password manager and enable multi-factor authentication wherever the platform supports it. Prioritise the registrar, hosting panel, CMS administrators, business email and payment services.

Apply least privilege:

• Editors should not be administrators simply because it is convenient.
• External developers should have named, time-bounded access rather than a shared permanent login.
• Unused staff, agency, FTP/SFTP, database and API accounts should be removed.
• API keys should have the narrowest permissions the integration needs.
• Account recovery details should belong to the business and be reviewed after staff or supplier changes.

MFA reduces account-takeover risk, but it is not a reason to reuse passwords or approve unexpected prompts. Keep backup codes protected and require a second person for high-impact account or payment changes where practical.

4. Use HTTPS everywhere, but do not stop at SSL

TLS—the technology still commonly called SSL—protects data travelling between the visitor's browser and the website. Every public page, login, form and checkout should use HTTPS with a valid certificate, and HTTP requests should be handled safely. Watch certificate renewal, redirects and mixed-content errors.

If the site does not have a working certificate, follow the South African SSL setup guide. Once the padlock appears, keep going. HTTPS does not patch an outdated plugin, remove a stolen admin account, validate a file upload, scan the application for malware or recover deleted data. It protects the connection, not every part of the website.

5. Back up for recovery, not for reassurance

“Backups are enabled” is not enough. Confirm exactly what is copied: website files, database, media, configuration and any data held by separate services. Record frequency, retention, storage location, exclusions and who can start a restore.

The right frequency follows the rate of change. A brochure site that changes monthly and an online store receiving orders all day do not have the same acceptable data-loss window. The business must decide how much work or transaction history it could afford to lose, then check whether the backup schedule matches.

Run a controlled restore test. Prove that the selected copy can rebuild the site in a safe location, that the database matches the files, that logins work and that critical journeys still pass. Also confirm how you would select a clean restore point if malware sat unnoticed for days. Restoring the newest infected copy only returns the problem.

Keep at least one usable recovery path outside the live website's immediate failure or account boundary where the service design allows it. Do not assume a copy stored inside the same compromised account is independent.

6. Protect forms, uploads and the admin area

Contact, quote, application and checkout forms connect the public internet to business systems. Review every live form, including old campaign pages and staging sites.

• Collect only the information the process genuinely needs.
• Send submissions to an actively monitored destination and test delivery from outside the company.
• Use server-side validation; browser-side required fields are not a security boundary.
• Rate-limit or challenge abusive automated submissions where appropriate.
• If uploads are allowed, restrict file types and size, rename and store files safely, scan where possible and prevent uploaded code from executing.
• Remove abandoned forms, test accounts, debug pages and public staging copies.
• Do not expose secrets, access tokens, database errors or personal information in logs and confirmation pages.

A hidden admin URL is not a substitute for strong access control. Use MFA, limited roles, logging and provider/application protections that match the platform.

7. Ask the hosting and maintenance questions that reveal the boundary

A host can protect the server and network while the website remains vulnerable through an old plugin or stolen administrator account. A developer can patch the application while the hosting account recovery path remains weak. Ask both sides concrete questions:

• Who patches the operating system, control panel, PHP/runtime, CMS core, themes and plugins?
• Which firewall, DDoS, malware scanning or account-isolation controls are included, and which need separate setup?
• What logs and alerts are available to the customer?
• What does the backup cover, how long is it kept, and can the customer restore or export it?
• Who investigates a suspected compromise at server level and application level?
• What proof will the business receive after updates, scans, restores or incident work?

Use the answers—not a generic “secure hosting” label—when comparing web hosting options in South Africa. Verify the live plan and service scope before ordering; this checklist does not assume or promise a specific feature on every plan.

8. Monitor signals somebody will actually act on

Monitoring is useful only when an alert reaches a person with a response path. At minimum, decide who receives and reviews:

• website downtime and repeated availability failures;
• certificate expiry or HTTPS errors;
• unexpected administrator creation, role changes or unfamiliar logins where the platform exposes them;
• failed backups and failed updates;
• malware, file-change or blacklist warnings from the tools in use;
• form delivery failures, checkout errors and unexpected redirects;
• domain, DNS, nameserver, billing-contact and renewal changes.

Do not send every alert to a former agency address or an inbox nobody checks. Test one alert end to end, record the expected first response and review noisy rules that teach people to ignore them.

9. Prepare the first hour of an incident

Write a one-page incident card before you need it. It should list the business decision-maker, developer or maintainer, host, registrar/DNS provider, payment or form providers, insurer or legal adviser where applicable, and an out-of-band way to reach them.

If the website shows a malicious redirect, unexpected administrator, changed bank details, injected pages or a malware warning:

1. Record what was observed, when, by whom and from which device.
2. Contact the named technical responders and contain access without destroying logs or evidence.
3. Do not blindly wipe the site or restore the newest backup before the affected scope and likely clean point are understood.
4. Reset compromised credentials from a trusted device and review registrar, DNS, hosting, CMS, email and connected-service access.
5. Test the cleaned or restored site in a controlled environment before returning it to service.
6. Document the cause, affected data or functions, corrective actions and monitoring changes.

If personal information may be involved, escalate immediately to the business's Information Officer or Deputy Information Officer and get appropriate legal/compliance advice. The Information Regulator's current fact sheet directs responsible parties to notify the Regulator through its eServices portal and notify affected data subjects when a POPIA security compromise occurs. Do not let a web developer or hosting ticket become the only incident record.

South Africa's National Cybersecurity Hub accepts incident reports and routes them to the appropriate authority. It is a coordination route, not a promise that the Hub will repair the website for you.

A workable website security schedule

Turn the checklist into recurring ownership. The exact frequency should follow the site's change rate, data sensitivity and business impact; this table is a starting rhythm, not a guarantee.

Do not keep completed checks as private knowledge in one supplier's head. A short business-owned register is more valuable than a long security report nobody can use during an incident.