Website security checklist

Website Security
Updated: 4 October 2026
About 7 min read

Security is not a set-up you do once and forget; it is a habit made up of short, regular checks. This list groups the tasks for the owner or administrator of a website by how often they are done: a few minutes a week, half an hour a month, a thorough review once a year. The detail of each item is explained in the guide it links to.

You can turn the list into paper or a PDF with your browser's print command; in the print view the menu and link boxes are hidden. Take out the items that do not fit your site and add the ones you find missing; what matters is that the list is actually followed.

In brief

First complete the initial set-up items once, in full.
5–10 minutes a week, about 30 minutes a month, and a thorough review once a year.
Assign a person responsible and a day for every check.
The list is printable; every item links to the relevant guide.

On this page

How should you use the list?

Complete the initial set-up checks first

Regular checks are meaningful only if the basic measures are in place. Complete the items in the "Initial set-up" section below once, in full. For the overall framework of the site, you can start with the Website security guide.

: Enlarge
Decide who is responsible and on which day

A check that is "everybody's job" does not get done. For each frequency, assign a person responsible and a fixed day in the calendar; note down each check you carry out, with its date. If an agency manages the site, put in writing which items are theirs and which are yours.

: Enlarge
When you find a problem, do not put it off

The purpose of the check is not to tick boxes but to find a problem early. When you see a pending security update, a failed backup or an account you do not recognise, deal with it the same day. If there are signs of a compromise, follow the steps in the guide What to do if your website is hacked.

: Enlarge

Initial set-up (once)

Access

☐ The hosting panel, FTP, database and administrator passwords are long and all different from one another. (Strong passwords)
☐ Two-factor authentication is on for the hosting panel, the domain account and administrator accounts. (Two-factor authentication)
☐ Everyone has their own account; no shared accounts are used.
☐ File transfer is done over SFTP or FTPS. (Server and hosting security)

Server and configuration

☐ The whole site redirects to HTTPS; the certificate renews automatically. (Security headers and HTTPS)
☐ The basic security headers are defined; CSP is at least in report-only mode.
☐ Directory listing and on-screen error display are off.
☐ There are no backups, dumps, .git, .env, phpinfo or installation scripts in the web root.
☐ Files 644, folders 755; nothing has 777 permissions.
☐ Script execution is disabled in upload folders. (File upload security)
☐ The database is closed to outside access; the application user has least privilege.

Code

☐ All queries are written as prepared statements. (SQL injection)
☐ Output is escaped according to its context. (XSS)
☐ State-changing actions use POST and are protected with a CSRF token. (CSRF)
☐ Passwords are stored with password_hash; login attempts are limited; the session cookie is Secure, HttpOnly, SameSite. (Login and session security)
☐ Every page and action performs a permission check on the server.

Backup and monitoring

☐ Files and database are backed up automatically; one copy is off the server. (Backup and monitoring)
☐ A restore has been tried at least once.
☐ Uptime monitoring and Google Search Console notifications are on.
☐ Access and error logs are on; the retention period is known.
☐ Who to call during an incident and the first steps are written down.

Weekly (5–10 minutes)

☐ Are there any pending updates? Install the security updates. (Software updates)
☐ Was the latest backup taken successfully? Look at the backup report.
☐ Open the site without logging in, and once from a phone as well: is there any unexpected content, redirect or warning?
☐ Are there any alerts from uptime monitoring or Search Console?
☐ Is there a change in the file change report that you did not make?
☐ Is an unusual number or kind of submission coming through the contact form? (DDoS and bot attacks)

Monthly (about 30 minutes)

☐ Update all components: CMS, plugins, themes, libraries.
☐ Review the user and administrator accounts: are there any you do not recognise or that are no longer needed?
☐ Review the FTP, SSH and panel accounts; close the access of people who have left.
☐ Delete unused plugins, themes and files.
☐ Are there any unexpected files in the web root or the upload folders?
☐ Glance through the access and error logs: heavy requests to the login address, POSTs to files you do not recognise, runs of errors.
☐ Check the security issues report and the indexed pages in Search Console.
☐ Look at the certificate and domain expiry dates.
☐ Check the disk space and how full the backup store is.

Every three months

☐ Run a restore drill: set the backup up in a test environment and open the site.
☐ Review the security headers and the CSP violation reports.
☐ Review the third-party scripts added to your pages (analytics, chat, advertising); remove the ones that are not needed.
☐ Test the forms and file upload fields: are the type and size limits working?
☐ Check the file permissions.

Yearly (thorough review)

☐ Renew critical passwords and API keys, especially shared or old ones.
☐ Does the PHP version still receive security support? Plan an upgrade.
☐ Update the component inventory; replace plugins and libraries that are no longer maintained.
☐ Review from scratch who has which privileges.
☐ Review the backup plan: are the frequency, retention period and location still suitable?
☐ Update the incident response note and the contact details.
☐ Review your privacy notices under data protection law (e.g. the GDPR), your cookie policy and the personal data you hold; delete data that is not needed.
☐ For important sites, consider commissioning an independent security test.
☐ Give the team a short reminder. (How to spot a phishing email)

After every change

☐ Before adding a new plugin or library: is it from the official source, is it maintained, is it really needed?
☐ A backup before a major update; a check of the critical flows afterwards.
☐ If a new form or upload field has been added: are there validation, CSRF and type checks?
☐ If a new person has joined: their own account, least privilege, two-factor authentication.
☐ If a person has left: close all their access the same day and change shared passwords.
☐ If you use WordPress: the additional items in the WordPress security guide.

Frequently asked questions

Can someone without technical knowledge follow this list?

Most of the weekly and monthly items can be done through the admin panel and the hosting panel. For the initial set-up items that concern code and server configuration, get help from your developer or your hosting company and ask them to share the results with you.

If I do everything on the list, will my site be completely secure?

No list provides complete security; the aim is to lower the risk and to notice a problem early. The list closes off the most common causes and builds the habit of regular checks.

Can I automate the checks?

Most of them, yes: automatic updates, automatic backups and backup reports, uptime monitoring, file integrity checks and certificate expiry alerts can all be automated. Reviewing accounts and logs, however, needs a human eye.

BYK Yazılım Support Team
This guide is written and regularly reviewed by the BYK Yazılım support team. Last updated: 4 October 2026.

Related guides

Let us review your website together

BYK Yazılım builds corporate websites. Write to us with any questions about your site.