Website Security Checklist: 20 Checks for Business Websites

A website security checklist is a short list of settings and habits that keep your site from being hacked, defaced or used to steal customer data. For most business websites, 20 checks cover it: keep software updated, force HTTPS, lock down logins with two-factor authentication, back up off-site, watch for problems, and have a plan for the day something goes wrong.

Below are the 20 checks we run on business websites, grouped by area, with how often to repeat each one. Most take minutes. A few need your developer or hosting provider. At the end there is an Indian compliance section (CERT-In and the DPDP Act), a printable summary table, and steps to follow if your site is already hacked.

Why website security matters for a small business

Attackers rarely pick a small business site by name. Automated bots scan the web for outdated plugins, weak admin passwords and exposed files, and break into whatever they find. A five-page brochure site is as likely to be hit as a large store if it runs the same vulnerable plugin.

The cost shows up in two places. Google may flag a hacked site, and its Search Console Security Issues report explains that affected pages can carry a warning label in search results or a browser warning before visitors reach them. And if customer data leaks, Indian law now attaches reporting duties and penalties to it (covered further down).

The OWASP Top 10:2025, the standard list of web application risks, puts Broken Access Control first and Security Misconfiguration second. Both are mostly about settings and permissions, which is why a checklist like this one catches so many real problems.

The 20-point website security checklist

Work through the groups in order. If you only have one hour today, do checks 5, 6, 10 and 18 first: updates, plugin clean-up, two-factor login and backups.

Hosting and server

• 1. Use hosting that includes a firewall and malware scanning. Ask your host whether your site is isolated from other accounts on the same server, whether a web application firewall (WAF) is included, and whether they scan for malware. A CDN with a WAF in front of the site adds another layer.
• 2. Run supported versions of server software. PHP, Node.js, the database and the operating system all have end-of-life dates, after which security fixes stop. Check your hosting panel for the PHP or runtime version and move to a supported one after testing on a staging copy.
• 3. Force HTTPS everywhere and automate certificate renewal. Every page, including the admin area and forms, should load over HTTPS, with HTTP redirecting to it. Certificate lifetimes are getting shorter: the CA/Browser Forum approved ballot SC-081v3, which cut the maximum from 398 days to 200 days from 15 March 2026, with further cuts to 100 days in 2027 and 47 days in 2029. Manual renewal will not keep up, so make sure your host or CDN renews automatically.
• 4. Add security headers. Ask your developer to set HSTS (tells browsers to always use HTTPS), a Content-Security-Policy (limits which scripts can run), X-Content-Type-Options and a frame-ancestors rule (stops other sites loading yours in a frame for clickjacking). Most can be added in the server or CDN config without touching the site code.

Software and updates

• 5. Update the CMS core promptly. WordPress's own hardening guide says to keep up with the latest version because older versions stop receiving security fixes. Turn on automatic minor updates and apply major ones after a quick test.
• 6. Remove unused plugins and themes, and keep the rest updated. Every plugin is code someone else wrote running on your server. Install only from trusted sources, delete what you do not use (deactivated is not enough), and check that each remaining plugin is still maintained.
• 7. Turn off file editing in the dashboard and tighten file permissions. On WordPress, adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php stops anyone who gets into the admin area from editing PHP files there. The web server should only be able to write where it must, such as the uploads folder.
• 8. Keep a list of third-party scripts and libraries. Chat widgets, analytics tags, payment scripts and npm packages all run with your site's permissions. Software Supply Chain Failures is number three on the OWASP 2025 list. Review the list every quarter and remove anything nobody uses.

Logins and access

• 9. Use long, unique passwords. The current NIST guidance (SP 800-63B) asks for at least 15 characters when a password is the only factor, and at least 8 when it is part of multi-factor login. It also says not to force periodic password changes, only to change them when there is evidence of compromise. A password manager makes this painless.
• 10. Turn on two-factor authentication everywhere that matters. That means the CMS admin, the hosting account, the domain registrar, the CDN or DNS provider, and the email accounts that can reset all of those. An attacker who takes your registrar or email account can take everything else.
• 11. Give each person their own account with the lowest role they need. No shared "admin" logins. Content writers get editor access, not administrator. When staff or an agency leave, remove their accounts the same day, and review the user list every quarter.
• 12. Limit login attempts. Lock out or slow down repeated failed logins on the admin page, using your security plugin, firewall or CDN. This stops password-guessing bots from trying thousands of combinations.

Forms, data and payments

• 13. Protect every form. Contact, quote and signup forms should validate input on the server, use a CAPTCHA or honeypot field against spam bots, and never email file uploads straight into your inbox without scanning. Injection attacks through forms are still on the OWASP list.
• 14. Collect less personal data, and protect what you keep. Ask only for fields you use. Store form entries in a secured database or CRM rather than in plain email, restrict who can see them, and publish a clear privacy notice. This matters more now that the DPDP Rules are notified (see the India section below).
• 15. Never handle card details on your own server. Use a payment gateway's hosted or embedded checkout, such as Razorpay, Cashfree or PayU, so card numbers go straight to the gateway. Your site then never stores card data, which removes the most valuable thing an attacker could steal.

Domain and email

• 16. Lock your domain. Turn on registrar (transfer) lock, use 2FA on the registrar account, keep the contact email current, and set the domain to auto-renew. A lapsed or hijacked domain takes your website and email down together.
• 17. Set up SPF, DKIM and DMARC on your email domain. These DNS records tell mail servers which systems may send email as your domain. Without them, scammers can send fake invoices that appear to come from you, and your real emails are more likely to land in spam.

Backups, monitoring and response

• 18. Take automatic, off-site backups and test a restore. Back up files and the database daily (or after every change for small sites), store copies away from the hosting server, and keep several dated snapshots. WordPress's hardening guide recommends multiple snapshots because a hack is often found weeks after it happened. A backup you have never restored is a guess.
• 19. Monitor uptime, malware and Search Console. Set up an uptime monitor, a malware scan from your host or security plugin, and verify the site in Google Search Console so you get Security Issues alerts by email. Keep server and login logs; the CERT-In rules below say how long.
• 20. Write a one-page incident plan. List who to call (developer, host, registrar), where the backups are, how to put the site into maintenance mode, and who decides whether to report to CERT-In or notify customers. Writing this in advance saves hours on a bad day.

Website security checklist: printable summary table

Print this or copy it into a spreadsheet. "Owner" is a suggestion; on a small team one person may hold several roles.

Website security in India: CERT-In and the DPDP Act

Two sets of Indian rules affect how you run and secure a business website. Neither is a reason to panic, but both change what you should log and who you must tell after an incident. This is a practical summary, not legal advice; check with your lawyer for your specific case.

CERT-In directions (in force since June 2022)

The CERT-In directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporates and government organisations, so most registered companies are covered. Three points matter for a website:

• Listed incidents must be reported to CERT-In within 6 hours of noticing them. The list includes defacement of or intrusion into a website, compromise of critical systems, and data breaches.
• Logs of all ICT systems must be kept for a rolling 180 days within India and provided to CERT-In when asked.
• System clocks must be synchronised with the NTP servers of NIC or NPL, or servers traceable to them, so log timestamps line up.

For check 19, that means asking your host where logs are stored, for how long, and whether you can export them.

DPDP Rules (notified November 2025)

The Digital Personal Data Protection Rules were notified on 14 November 2025 with an 18-month phased compliance period, according to the government's PIB note. That note says businesses must inform affected individuals of a personal data breach without delay, and that failing to keep reasonable security safeguards can attract a penalty of up to ₹250 crore.

As MediaNama's summary of the notified rules explains, the Data Protection Board must also be told without delay, with a fuller report within 72 hours. The safeguards listed include encryption or masking of personal data, access controls, access logs, keeping logs for one year unless another law says otherwise, and backups. If your website collects names, phone numbers or emails through forms, checks 11, 14, 18 and 19 are where you start.

What to do if your website is already hacked

Work through these in order. Do not delete files at random before you have a copy; you may need them to find how the attacker got in.

1. Take a full backup of the hacked site and database as evidence.
2. Put the site into maintenance mode or take it offline if it is serving malware or phishing pages.
3. Change every password: CMS users, hosting, database, FTP/SFTP, registrar and email. Turn on 2FA while you are there.
4. Restore from a clean backup taken before the hack, or have a developer clean the files. Then update everything and remove unused plugins (checks 5 and 6).
5. Find and close the entry point, usually an outdated plugin, a leaked password or a writable folder. Restoring without this step usually means being hacked again.
6. Decide on reporting: CERT-In within 6 hours if the directions cover you, and customers plus the Data Protection Board if personal data was exposed and the DPDP breach rules apply to you.
7. Open Search Console's Security Issues report, fix every listed issue, and click Request Review. Google says reviews can take days or weeks and you should not resubmit while one is pending.

A hack also hurts rankings while warnings are live. Our guide on getting your website on Google's first page covers the SEO basics to recheck once the site is clean.

Does your platform change the checklist?

The checks stay the same, but who does them changes with the platform.

If you are still choosing a platform, our Shopify vs WooCommerce comparison for Indian businesses covers the trade-offs, and our breakdown of website development cost in India shows where maintenance fits in the budget.

Frequently asked questions

How often should I check my website's security?

Check for CMS and plugin updates weekly, review user accounts, scripts and backups quarterly, and run through the full checklist once a year or after any redesign. Automated alerts (uptime, malware scan, Search Console) should run all the time.

Is an SSL certificate enough to make a website secure?

No. SSL (HTTPS) encrypts the connection between the visitor and your server, so data cannot be read in transit. It does nothing about an outdated plugin, a weak admin password or a missing backup, which are common ways small sites get hacked.

Do small business websites really get hacked?

Yes. Many attacks are automated and look for known weaknesses rather than specific companies, so a small site running an outdated plugin is as exposed as a large one. Keeping software updated and turning on 2FA closes the usual entry points.

Do I need to report a website hack to CERT-In?

If the 2022 CERT-In directions cover your organisation, which includes body corporates, then website defacement, intrusion and data breaches are on the reportable list and must be reported within 6 hours of noticing them. Check with your lawyer if you are unsure whether you are covered.

Does the DPDP Act apply to my business website?

If your website collects personal data such as names, phone numbers or email addresses from people in India, the DPDP Act and its 2025 Rules are relevant to you. The rules are being phased in over 18 months from November 2025, so now is the time to reduce what you collect and secure what you keep.

What is the best free tool to check website security?

Start with Google Search Console, which is free and alerts you if Google detects hacked content or malware on your site. Add your host's malware scanner or a reputable security plugin, and an uptime monitor, and you have covered the basics without spending anything.

Get help securing your website

If you would rather not run these checks yourself, our website development team builds sites with these protections set up from day one and can review an existing site against this checklist. Contact Webhorse Studio to talk about your website.