What Does a Website Security Audit Cover? A Business Owner’s Checklist

A vulnerability scan and a security audit are not the same thing

These terms are often used interchangeably.

They should not be.

A vulnerability scan generally uses automated software to identify known weaknesses.

It might detect:

• outdated software;
• known vulnerabilities;
• exposed services;
• weak TLS configuration;
• certain security-header issues;
• common server misconfigurations.

This is useful.

But it is only one part of security assessment.

A website security audit is broader.

It should also consider questions such as:

• Who can access the website?
• Does every administrator still need that access?
• Is multi-factor authentication enabled?
• Are backups independent from the live server?
• What happens if the website is compromised?
• Are security logs available?
• Can sensitive data be reached through an API?
• Are old development systems still accessible?
• Who controls the domain and DNS?
• What third-party scripts can execute on checkout pages?

The NCSC specifically recommends scoping manual security audits around the actual risks that matter to the organisation rather than treating testing as a generic exercise.

For a business, that distinction matters.

A scanner may report fifty low-priority technical warnings while completely missing that three former contractors still have administrator privileges.

Start by identifying what the website actually does

Security requirements should reflect business risk.

A five-page brochure website is different from an ecommerce platform storing customer information.

A booking system is different from a blog.

A customer portal containing sensitive records is different from a marketing website.

Before auditing, document the functions that matter.

Examples include:

• lead-generation forms;
• customer accounts;
• ecommerce checkout;
• payments;
• booking systems;
• membership areas;
• document uploads;
• APIs;
• CRM integrations;
• administrative dashboards;
• email integrations;
• AI chatbots;
• internal portals.

Then identify what information each function handles.

The website might process:

• names;
• email addresses;
• telephone numbers;
• addresses;
• payment information;
• account credentials;
• uploaded documents;
• order histories;
• commercially sensitive information.

The more sensitive the data and the more business-critical the process, the more carefully it should be tested.

1. Inventory the technology stack

You cannot secure systems you do not know exist.

A security audit should therefore start by identifying the website's technology.

That might include:

• CMS;
• CMS version;
• theme;
• plugins;
• server software;
• PHP or other runtime version;
• JavaScript frameworks;
• databases;
• CDN;
• web application firewall;
• hosting platform;
• APIs;
• third-party widgets;
• analytics;
• payment providers;
• CRM integrations.

For WordPress, for example, this should include every installed plugin and theme—not only the active ones.

Old software left installed can still create unnecessary risk depending on how it is exposed and maintained.

A useful inventory records:

Component
Version
Purpose
Owner
Current status
Last reviewed

If nobody knows why a plugin or service exists, investigate whether it is still required.

2. Check software versions and security updates

Keeping software current is one of the most basic security controls.

It is also one of the easiest to neglect.

Security vulnerabilities are regularly found in:

• CMS platforms;
• plugins;
• themes;
• frameworks;
• libraries;
• server software;
• operating systems.

WordPress's own security guidance recommends remaining on supported versions and keeping the software current as part of hardening a site.

This is not theoretical.

WordPress continued publishing security releases throughout 2026. WordPress 7.1.2 was released on 22 September 2026, while security updates were also published for older supported branches during the year.

A website audit should therefore identify:

• outdated CMS versions;
• outdated plugins;
• abandoned plugins;
• unsupported themes;
• old server runtimes;
• outdated libraries.

But avoid the simplistic rule:

Update everything immediately without testing.

Business-critical websites may need staging and controlled deployment.

Security patches should be applied promptly, but updates also need to be tested where compatibility risk exists.

3. Look for known exploited vulnerabilities

A vulnerability being theoretically possible is not the same as evidence that attackers are actively exploiting it.

Prioritisation should take real-world exploitation into account.

The US Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalogue specifically to identify vulnerabilities known to have been exploited in real attacks.

For businesses, this can help distinguish:

“A weakness exists”

from:

“Attackers are actively using this weakness.”

Known exploited vulnerabilities generally deserve high priority where the affected technology exists in the environment.

The audit should therefore consider:

• CVE severity;
• exploitation evidence;
• whether the vulnerable feature is exposed;
• available patches;
• compensating controls;
• importance of the affected system.

Risk should drive remediation order rather than the number of scanner findings.

4. Review administrator accounts

One of the most important questions in a security audit is remarkably simple:

Who can change the website?

Review all accounts with access to:

• CMS;
• hosting;
• domain registrar;
• DNS;
• CDN;
• source-code repositories;
• databases;
• deployment systems;
• analytics;
• CRM integrations.

Look for:

• former employees;
• old agencies;
• freelancers whose projects ended;
• generic shared accounts;
• dormant administrators;
• duplicate accounts.

Remove access that is no longer required.

5. Review administrator permissions

Not everybody needs administrator access.

A content writer probably does not need permission to install plugins.

A marketing employee may not need access to server configuration.

A freelancer editing one landing page probably does not need control over DNS.

Permissions should follow the principle of least privilege.

Give users enough access to perform their job, but not more.

The NCSC's identity and access guidance similarly recommends restricting privileged access and separating administrative activities from ordinary day-to-day accounts.

This limits the damage possible if one account is compromised.

6. Enable multi-factor authentication

Administrator accounts should use multi-factor authentication where supported.

A strong password is important.

It is not enough on its own.

The NCSC recommends MFA for administrative accounts and notes that adding a second authentication factor substantially improves protection if somebody obtains a password.

Review MFA for:

• CMS administrators;
• hosting;
• domain registrar;
• DNS;
• cloud services;
• source-code repositories;
• CRM;
• email accounts controlling password resets.

The domain registrar is particularly important.

If somebody gains control of your domain, they can potentially redirect traffic away from the legitimate website.

7. Eliminate shared administrator accounts

Accounts such as:

admin

or:

website-team

used by several people create accountability problems.

If something changes, who did it?

Individual accounts allow access to be:

• granted;
• monitored;
• restricted;
• revoked.

This becomes especially important when employees or suppliers leave.

8. Check password-reset routes

A website's security can be undermined by the account used to reset its passwords.

For example:

Website administrator account ↓ Password reset email ↓ Shared email inbox ↓ Weak email password

The effective security of the CMS is now determined partly by the email account.

Review recovery routes for privileged accounts.

9. Audit hosting access

Website security is not limited to WordPress or whichever CMS appears in the browser.

Hosting access may allow somebody to:

• modify every website file;
• download databases;
• create email accounts;
• change server settings;
• restore backups;
• create new users.

Review:

• hosting users;
• SSH accounts;
• FTP/SFTP users;
• API tokens;
• deployment credentials;
• database access.

Remove credentials that no longer have a purpose.

10. Check FTP versus SFTP or SSH

Traditional unencrypted FTP should generally be avoided for administration.

Secure alternatives such as SFTP or SSH protect credentials and data in transit.

If old FTP users remain configured because an agency used them five years ago, remove them.

11. Audit TLS and HTTPS

Websites should use HTTPS.

But seeing a padlock icon does not mean every aspect of transport security is configured well.

The NCSC recommends modern TLS configuration and advises against supporting deprecated protocol versions. Its TLS guidance also recommends measures that help prevent insecure resources from being loaded into otherwise secure pages.

An audit should review:

• valid certificate;
• certificate expiry;
• HTTP → HTTPS redirects;
• old TLS versions;
• mixed content;
• insecure assets;
• redirect consistency.

Also check whether important cookies use suitable security attributes.

12. Review security headers

HTTP security headers can instruct browsers to apply additional protections.

Examples include:

• Content-Security-Policy;
• Strict-Transport-Security;
• X-Content-Type-Options;
• Referrer-Policy;
• Permissions-Policy.

Not every website needs identical settings.

For example, a restrictive Content Security Policy can break functionality if implemented carelessly.

The audit should evaluate settings in context rather than blindly copying a perfect-score configuration from an online generator.

13. Review Content Security Policy

Content Security Policy, or CSP, can help restrict which scripts and resources the browser is allowed to load.

This is increasingly relevant because websites commonly execute code from multiple third parties.

For example:

• analytics;
• chat widgets;
• advertising pixels;
• payment systems;
• review tools;
• A/B testing services.

A CSP may help reduce the impact of certain injection attacks.

But implementing one properly requires understanding what the website actually loads.

Start by inventorying external scripts.

14. Audit third-party scripts

Every third-party script creates an additional dependency.

Examples include:

• Google Tag Manager;
• live chat;
• Meta Pixel;
• analytics tools;
• booking widgets;
• heatmaps;
• review platforms;
• payment components.

Ask:

• Who provides it?
• Why is it installed?
• What data can it access?
• Does it still need to exist?
• Where does the script load?
• Who can change the script remotely?

This becomes particularly important on ecommerce checkout pages.

The PCI Security Standards Council's current ecommerce requirements include controls intended to protect payment pages from unauthorised script activity and e-skimming attacks.

15. Ecommerce websites need additional scrutiny

If your website takes card payments, payment architecture changes the security requirements.

There is a major difference between:

Customer enters card data directly into your own website environment

and:

Customer is securely redirected to a specialist payment provider.

PCI DSS exists to protect environments where payment account data is stored, processed or transmitted.

Even merchants outsourcing payment processing may still have responsibilities around their ecommerce webpages depending on the implementation.

PCI SSC clarified in 2026 that applicable SAQ A ecommerce environments can require external vulnerability scanning by an Approved Scanning Vendor.

Do not assume:

“We use Stripe/PayPal/another processor, therefore our website security does not matter.”

The page leading customers into the payment process can still be important.

16. Check for malicious script injection

E-skimming attacks attempt to capture payment information through malicious code.

That code may be introduced through:

• compromised administrator accounts;
• vulnerable plugins;
• compromised third-party scripts;
• insecure deployment processes.

This is another reason ecommerce security should include script monitoring, change management and access controls—not only payment-provider selection.

17. Audit forms and user input

Forms accept information from users.

From a security perspective, user input should never automatically be trusted.

WordPress's development security guidance explicitly recommends validating and sanitising untrusted input, including information from users, APIs and stored data.

Forms may be vulnerable to problems such as:

• injection;
• cross-site scripting;
• spam abuse;
• file-upload attacks;
• excessive input lengths;
• malformed requests.

Test:

• contact forms;
• search;
• login;
• registration;
• comments;
• file upload;
• account settings.

The implementation should validate information on the server, not solely in browser-side JavaScript.

18. File uploads deserve special attention

Allowing users to upload files introduces additional risk.

Check:

• permitted file types;
• file-size restrictions;
• filename handling;
• storage location;
• malware scanning where appropriate;
• direct execution prevention;
• access permissions.

A profile-picture upload and a confidential-document portal require very different controls.

19. Audit APIs

Modern websites often depend heavily on APIs.

An API may connect the site to:

• CRM;
• payment provider;
• booking system;
• mobile app;
• AI assistant;
• internal systems.

The NCSC explicitly points organisations implementing APIs towards common API security risks and the OWASP API Security Top 10.

Audit questions include:

• Does the endpoint require authentication?
• Can one user access another user's data?
• Are permissions checked on the server?
• Is rate limiting used?
• Are error messages revealing sensitive information?
• Are API keys exposed in frontend JavaScript?
• Is input validated?

An API can be secure from a networking perspective while still exposing data because of faulty authorisation logic.

20. Search for exposed secrets

Sensitive credentials should not be publicly accessible.

Look for:

• API keys;
• database passwords;
• private tokens;
• development credentials;
• .env files;
• source maps containing secrets;
• Git history;
• accidentally public configuration files.

Frontend JavaScript is visible to users.

Any secret included there should generally be assumed visible.

21. Audit source-code repositories

If the website is managed through GitHub, GitLab or another repository, review:

• who has repository access;
• branch protections;
• deployment keys;
• secrets;
• automated workflows;
• inactive collaborators.

Repository access may indirectly provide production access.

Security boundaries should reflect that.

22. Review database exposure

Most business websites do not need their database directly accessible from the public internet.

Review:

• database listening interfaces;
• permitted hosts;
• database users;
• passwords;
• permissions;
• old databases.

Database accounts should have the minimum permissions required for their purpose.

23. Review default settings

Security problems frequently come from defaults that were never changed.

Examples include:

• default administrator usernames;
• sample accounts;
• unused demo applications;
• default passwords;
• development endpoints;
• exposed server status pages.

A production system should not contain unnecessary defaults simply because they were convenient during setup.

24. Check for development and staging websites

Businesses frequently forget about staging environments.

Examples:

staging.example.com

dev.example.com

old.example.com

These sites may contain:

• copied customer information;
• weaker passwords;
• outdated plugins;
• debug settings;
• no monitoring.

Attackers do not care whether the system is officially “production”.

If it is publicly reachable and connected to your organisation, it matters.

Review all subdomains and old environments.

25. Never assume staging is harmless

A staging copy may contain exactly the same database as production.

If it has weaker security, it can become an easier route to customer information.

Use:

• authentication;
• network restrictions;
• sanitised data;
• separate credentials.

Delete old staging instances that are no longer required.

26. Review WordPress-specific security

For WordPress websites, an audit should normally include:

• WordPress version;
• plugin versions;
• theme versions;
• administrator accounts;
• inactive plugins;
• inactive themes;
• file permissions;
• configuration;
• XML-RPC use where relevant;
• login security;
• database configuration;
• backups;
• logging.

WordPress's official hardening guidance emphasises that website security is about risk reduction and damage containment, not a claim that any system can become perfectly secure.

That is an important principle.

No credible audit can guarantee that a website will never be compromised.

27. Do not rely solely on a WordPress security plugin

Security plugins can provide useful functionality such as:

• malware scanning;
• login protection;
• file-change detection;
• firewall rules;
• alerts.

But a plugin cannot protect:

• a compromised domain registrar;
• a stolen hosting account;
• exposed repository credentials;
• poor backup strategy;
• vulnerable custom code;
• insecure external APIs.

Use security tools as layers within a broader security approach.

28. Review file permissions

Website files and directories should not be more writable than necessary.

Excessive permissions can make it easier for a compromised component to modify other files.

Exact permission requirements depend on the hosting architecture, but a security audit should identify unnecessarily permissive settings.

29. Audit custom code

A website may use fully updated WordPress software while containing vulnerable custom development.

Custom code should be reviewed for issues including:

• input validation;
• authentication;
• authorisation;
• output escaping;
• SQL injection;
• cross-site scripting;
• CSRF;
• insecure API usage;
• error handling.

This applies to:

• custom plugins;
• custom themes;
• bespoke applications;
• integrations.

Keeping the CMS updated does not automatically secure custom code.

30. Review authentication flows

Test:

• login;
• registration;
• password reset;
• account recovery;
• MFA;
• logout;
• session expiry.

Look for problems such as:

• account enumeration;
• unlimited login attempts;
• weak recovery mechanisms;
• long-lived sessions;
• session tokens remaining active after password changes.

31. Rate limiting

Public-facing endpoints can be abused through automated requests.

Examples include:

• login;
• password reset;
• contact form;
• API;
• search;
• AI chatbot.

Rate limiting can help prevent certain types of abuse.

The exact thresholds should reflect normal user behaviour.

32. Review bot and spam protection

Security and anti-spam overlap in some areas.

Forms may be abused for:

• spam;
• account creation;
• credential testing;
• email flooding.

Controls might include:

• rate limiting;
• honeypots;
• challenge systems;
• reputation-based filtering.

Avoid making security controls unnecessarily hostile to real users or inaccessible to disabled people.

33. Audit DNS

Your domain's DNS controls where users are sent.

If DNS is compromised, an attacker may redirect website visitors even though your web server itself remains secure.

Review:

• DNS provider;
• administrator users;
• MFA;
• obsolete records;
• unused subdomains;
• DNSSEC where appropriate.

Domain and DNS security deserves the same level of attention as the website CMS.

34. Review domain registrar security

The registrar account controls ownership and important domain settings.

Check:

• account owner;
• MFA;
• recovery email;
• authorised users;
• domain lock;
• renewal settings.

Losing control of a domain can disrupt both website and email services.

35. Backups are part of security

Security is not just about preventing attacks.

It is also about recovery.

A ransomware attack, malicious administrator or broken update can make recovery necessary.

A backup strategy should define:

• what is backed up;
• how often;
• retention;
• where backups are stored;
• who can restore them.

Do not keep your only backup on the same server as the website.

If that server is compromised, both copies may be affected.

36. Test restoration

A backup file existing does not prove recovery will work.

Try restoring it in a controlled environment.

Check:

• database;
• uploaded files;
• configuration;
• application functionality;
• integrations.

A broken backup usually reveals itself at the worst possible time unless restoration is tested beforehand.

37. Protect the backups themselves

Backups often contain everything an attacker wants.

They can include:

• customer information;
• passwords;
• API configuration;
• source code.

Secure them accordingly.

38. Review logging

If somebody compromises the website, can you determine what happened?

Useful logs may include:

• web-server access;
• server errors;
• administrator logins;
• configuration changes;
• deployment logs;
• security alerts.

The NCSC recommends logging and auditing administrative activity because privileged-account misuse can have serious consequences and needs to be detected quickly.

Logging should therefore answer practical questions:

Who changed this?

When did it change?

From where?

What happened next?

39. Do not log unnecessary sensitive data

More logging is not automatically better.

Logs can accidentally contain:

• passwords;
• access tokens;
• personal information;
• payment details.

Logging should support security investigation without becoming another uncontrolled database of sensitive information.

40. Configure alerts

Logs are only useful during an active incident if somebody notices them.

Useful alerts might include:

• repeated failed administrator logins;
• unexpected administrator creation;
• malware detection;
• significant file changes;
• website downtime;
• unusual server activity.

Avoid excessive alerting.

If staff receive hundreds of meaningless notifications, important warnings become easier to ignore.

41. Audit error messages

Production websites should not expose unnecessary technical information.

A database error such as:

SQLSTATE... database user... /var/www/...

may reveal information useful to an attacker.

Users should receive a useful error message.

Detailed debugging information should go to secure logs.

42. Disable production debug modes

Framework and CMS debugging is valuable during development.

Production environments should not expose sensitive debug information to visitors.

Review:

• debug mode;
• stack traces;
• verbose API errors;
• development consoles.

43. Review personal-data handling

A website security audit is related to privacy because insecure personal information creates risk.

Identify where website data goes.

For example:

Website form

→ email

→ CRM

→ spreadsheet

→ marketing automation

Each copy creates another location that needs protection.

Do not retain data merely because storage is inexpensive.

44. Audit contact-form storage

Ask:

Where do form submissions actually live?

Possibilities include:

• website database;
• email;
• CRM;
• form provider;
• automation platform.

Businesses are sometimes surprised to discover that years of old customer enquiries remain inside WordPress even after they were copied into the CRM.

If that data is no longer needed, consider whether it should still be retained.

45. Review CRM and automation integrations

An integration may require API credentials allowing access to sensitive records.

For tools such as:

• HubSpot;
• Salesforce;
• Zapier;
• n8n;
• email platforms;

review:

• credentials;
• permissions;
• inactive workflows;
• old connections;
• former users.

A compromised automation platform may provide access to several connected systems.

46. Review AI chatbot security

AI chatbots create additional considerations.

If your chatbot can access:

• internal documents;
• CRM records;
• customer accounts;
• booking systems;

the audit should examine its permissions.

Questions include:

• Can anonymous visitors reach private information?
• What happens if a user asks the system to ignore its instructions?
• Can the model call tools?
• Which actions can those tools perform?
• Are high-risk actions confirmed?

An AI assistant answering public FAQs has a much smaller security surface than an agent capable of modifying customer accounts.

47. Audit supplier risk

Many website functions depend on suppliers.

Examples:

• hosting;
• CDN;
• payment provider;
• CRM;
• analytics;
• plugins;
• chat systems.

The NCSC's secure-online-service guidance explicitly treats supply chains as part of security.

You cannot eliminate third-party risk.

But you should know which suppliers are critical.

Ask:

• What happens if they are compromised?
• What data do they process?
• What permissions do they have?
• Can the integration be revoked quickly?

48. Consider a web application firewall

A web application firewall, or WAF, can filter certain malicious web traffic before it reaches the application.

Providers such as Cloudflare and specialist hosting platforms may provide this capability.

A WAF can be useful.

It is not a substitute for fixing vulnerable software.

Think of it as another defensive layer.

49. Review CDN configuration

A CDN can improve performance and security.

Misconfiguration can also expose:

• origin IP addresses;
• old content;
• insecure cache behaviour.

Audit CDN rules and confirm the origin server is configured appropriately.

50. Test website availability and denial-of-service resilience

For businesses heavily dependent on their website, availability is a security concern.

Review:

• uptime monitoring;
• CDN;
• traffic protection;
• hosting limits;
• response plan.

A marketing website being offline for ten minutes and a SaaS application being unavailable for ten minutes can have very different business consequences.

Security controls should reflect that impact.

51. Create an incident-response plan

Suppose you discover tomorrow that the website has been compromised.

Who does what?

A simple incident plan should answer:

• Who owns the response?
• Who contacts hosting?
• Who has DNS access?
• Who can take the website offline?
• Where are clean backups?
• Who investigates?
• Who communicates internally?
• Who determines whether customer notification is necessary?

Trying to answer these questions during the incident wastes valuable time.

52. Prepare a clean recovery route

If attackers have modified the live environment, restoring a backup to the same compromised environment without understanding what happened may recreate the problem.

Recovery planning should consider:

• clean infrastructure;
• credential rotation;
• patching the original weakness;
• restoring known-good data;
• verifying integrity.

Recovery is not always:

Click “Restore Backup”.

53. Know who to call

Small businesses often have:

• website developer;
• hosting company;
• marketing agency;
• IT support;

but nobody explicitly responsible for a cyber incident.

Define responsibility before the emergency.

The NCSC provides dedicated cyber-security and recovery guidance for small and medium-sized organisations, including preparation and incident response.

54. Security audits should be prioritised by risk

A scanner can produce hundreds of findings.

They are not equally important.

A useful report might classify issues as:

Critical

Immediate likelihood or potential for serious compromise.

Examples:

• actively exploited vulnerability;
• exposed administrator credentials;
• authentication bypass;
• publicly accessible sensitive database.

High

Significant security weakness requiring prompt action.

Examples:

• unsupported critical software;
• administrators without MFA;
• serious access-control flaw;
• executable unrestricted file uploads.

Medium

Meaningful weakness with lower immediate impact.

Examples:

• excessive permissions;
• weak security-header configuration;
• outdated non-critical components.

Low

Hardening or defence-in-depth opportunities.

Examples:

• unnecessary information disclosure;
• minor configuration improvements.

This is much more useful than telling a business:

“Your website has 117 security issues.”

Risk also depends on exposure

Consider two identical software vulnerabilities.

Website A has the affected functionality available anonymously to the entire internet.

Website B has the feature disabled and the server restricted to an internal network.

The theoretical vulnerability may be identical.

The practical risk is not.

Security findings need context.

Automated scanning versus penetration testing

A vulnerability scan automatically looks for recognised weaknesses.

Penetration testing involves human security specialists attempting to exploit or validate weaknesses within an agreed scope.

Penetration testing can identify issues that automated scanners may miss, particularly around:

• business logic;
• authentication;
• authorisation;
• APIs;
• account boundaries.

Not every brochure website requires an extensive penetration test.

A customer portal handling sensitive data may justify one.

The required depth should be proportional to risk.

What should a website security audit report contain?

A useful report should explain each issue clearly.

For example:

Finding

Three former contractors retain WordPress administrator accounts.

Risk

If one of those external accounts is compromised, an attacker could modify the website or install code.

Recommendation

Disable unused accounts and implement a formal user-access review.

Priority

High.

That is more useful than:

Access-control issue detected.

Reports should ideally include:

• issue;
• affected system;
• evidence;
• impact;
• priority;
• remediation;
• verification method.

Security should not end after the audit

A security audit describes the website at a particular moment.

The environment changes.

Tomorrow:

• a plugin vulnerability may be published;
• a new administrator may be added;
• a developer may deploy a feature;
• an API key may change;
• a third-party script may be installed.

This makes security an ongoing process.

The NCSC's guidance similarly treats secure operation and continual testing as ongoing activities rather than one-time certification.

A practical maintenance routine

Depending on the website, ongoing security may include:

Continually

• uptime monitoring;
• security alerts;
• suspicious-login monitoring;
• backup operation.

Weekly

• critical software updates;
• vulnerability review;
• failed automation review.

Monthly

• administrator review;
• plugin/theme review;
• backup verification;
• log review;
• external scan where appropriate.

Periodically

• restoration testing;
• deeper security audit;
• penetration testing where justified;
• supplier review;
• access review.

The right schedule depends on risk.

Security audits and Cyber Essentials

UK businesses may also encounter Cyber Essentials.

Cyber Essentials is broader than website security and covers organisational controls such as:

• firewalls;
• secure configuration;
• security updates;
• user access control;
• malware protection.

A website audit can support elements of broader security maturity, but it is not equivalent to Cyber Essentials certification.

Avoid treating one security badge or scan as proof that every system is secure.

Security and SEO are connected operationally

A compromised website can also become an SEO problem.

Attackers may inject:

• spam pages;
• redirects;
• malicious links;
• phishing pages.

Search engines may detect compromised content.

Users may receive browser warnings.

Security is therefore part of maintaining the integrity and reputation of a website, even though security and SEO remain separate disciplines.

Security and website performance can conflict if implemented badly

Security tools can occasionally affect performance.

For example:

• aggressive firewalls;
• bot challenges;
• excessive scanning;
• multiple security plugins.

The solution is not to remove security.

It is to configure controls properly.

A well-designed architecture should consider:

• security;
• performance;
• usability;

together.

Security and accessibility also need to coexist

CAPTCHAs, MFA systems and bot protection can introduce accessibility barriers.

For example, a difficult image puzzle may stop legitimate users as effectively as it stops bots.

Security controls should provide accessible alternatives where possible.

A secure website that legitimate customers cannot use is not a successful solution.

Questions to ask a website security provider

Before commissioning an audit, ask:

1. What does the audit cover?
2. Is it automated, manual or both?
3. Do you review administrator accounts?
4. Do you inspect hosting configuration?
5. Do you review plugins and dependencies?
6. Do you test custom code?
7. Do you review APIs?
8. Do you review DNS and domain security?
9. Do you review backups?
10. Do you test restoration?
11. Do you review logging?
12. Do you inspect third-party scripts?
13. Do you check staging environments?
14. Do you review ecommerce/payment exposure?
15. Is penetration testing included?
16. How are findings prioritised?
17. Do you provide remediation guidance?
18. Will you retest after fixes?

Make sure you understand whether the service is:

a scan

or:

a security audit.

They are not the same product.

A website security checklist for business owners

Before considering your website well protected, check the following.

Accounts

• Is MFA enabled for administrators?
• Have former users been removed?
• Are individual accounts used instead of shared logins?
• Are permissions appropriate?

Software

• Is the CMS supported?
• Are plugins current?
• Are themes current?
• Are server runtimes supported?
• Are abandoned components removed?

Infrastructure

• Is HTTPS correctly configured?
• Is hosting access restricted?
• Are secure transfer protocols used?
• Is the domain registrar protected?
• Is DNS protected?

Application

• Is input validated?
• Are uploads controlled?
• Are APIs authenticated?
• Are sensitive errors hidden?
• Has custom code been reviewed?

Third parties

• Do you know every external script?
• Are unused integrations removed?
• Are API permissions appropriate?
• Are ecommerce scripts controlled?

Data

• Do you know what customer data the website stores?
• Is old data retained unnecessarily?
• Are backups secured?

Monitoring

• Are important logs available?
• Are suspicious events monitored?
• Is uptime monitored?
• Does somebody receive alerts?

Recovery

• Are backups current?
• Are they stored independently?
• Have they been restored successfully?
• Is there an incident-response plan?

If many of these questions cannot be answered, the business has visibility gaps even if no known breach has occurred.

A security plugin does not make a website secure

This is one of the most important conclusions.

Website security operates across layers.

Consider this chain:

Domain

↓

DNS

↓

Hosting

↓

Server

↓

CMS

↓

Plugins and custom code

↓

APIs

↓

Third-party services

↓

Administrator accounts

↓

Users

A security plugin operates inside only part of that chain.

It can be valuable.

It cannot protect everything.

Security is really about reducing probability and impact

There is no realistic website with zero risk.

The goal is to reduce:

the probability of compromise

and:

the impact if compromise occurs.

Updates reduce the probability of known vulnerabilities being exploited.

MFA reduces the chance that stolen passwords alone lead to administrator access.

Least privilege limits what compromised accounts can do.

Logging improves detection.

Backups improve recovery.

Incident planning reduces confusion.

These controls reinforce one another.

What businesses should fix first

If you have limited time and budget, prioritise the basics.

For many small and medium-sized business websites, a sensible starting point is:

1. Update unsupported and vulnerable software.

Especially vulnerabilities known to be exploited.

2. Protect administrator accounts with MFA.

CMS, hosting, domain and email.

3. Remove unnecessary access.

Former employees, old agencies and unused administrators.

4. Verify backups.

Make sure they exist somewhere independent and can be restored.

5. Review hosting and DNS.

Understand who controls your infrastructure.

6. Inspect custom code and APIs.

Particularly if the website handles accounts or sensitive information.

7. Configure monitoring and alerts.

Know when something changes.

8. Create a basic incident-response plan.

Know who will act.

These improvements generally create more value than chasing a perfect score from a generic online security checker.

When should a website security audit be repeated?

A full review is particularly useful:

• before launching a new website;
• after a major redesign;
• after changing hosting;
• after adding ecommerce;
• after adding customer accounts;
• after integrating major APIs;
• after an incident;
• after acquiring an existing website;
• when responsibility changes between agencies;
• when the site has not been reviewed for a long time.

Security monitoring and software maintenance should happen much more frequently.

Security becomes more important as websites become connected

Modern websites are increasingly connected to other business systems.

A website may interact with:

• CRM;
• Google Ads;
• email automation;
• payment systems;
• ERP;
• analytics;
• AI assistants;
• customer databases.

This makes the website part of a wider business architecture.

A compromised integration credential may create access beyond the website itself.

Security reviews therefore need to follow connections rather than treating the website as an isolated server.

The purpose of an audit is to produce an action plan

A useful website security audit should ultimately tell the business:

What is exposed?

What could go wrong?

How serious would it be?

How likely is exploitation?

What should be fixed first?

How should recovery work if prevention fails?

The output should not simply be a long technical report designed to look impressive.

It should create a practical security roadmap.

For one business, the highest priority may be outdated WordPress plugins.

For another, it may be an insecure custom API.

For another, the largest weakness may simply be that twelve people share the same administrator password and nobody knows where the backups are.

Security needs to reflect the real environment.

London Digital Works provides website security, privacy, accessibility, maintenance and technical support for businesses that need to understand the weaknesses in their existing website and prioritise practical improvements.

A website security audit can provide a useful starting point by reviewing software, hosting, access, integrations, backups, monitoring and recovery as one connected system rather than relying on a single security plugin or automated scan.

Sources

UK National Cyber Security Centre — Building and Operating a Secure Online Service NCSC guidance covering secure operation, software maintenance, APIs, monitoring, data protection and supply-chain considerations for online services.

UK National Cyber Security Centre — 10 Steps to Cyber Security NCSC framework covering major organisational security areas including systems, data, identity and incident preparation.

UK National Cyber Security Centre — Identity and Access Management Guidance recommending multi-factor authentication for administrative accounts, separate privileged accounts and strong control over administrative access.

UK National Cyber Security Centre — Using TLS to Protect Data NCSC guidance covering HTTPS, modern TLS configurations and protection against insecure content.

UK National Cyber Security Centre — Secure Development: Continually Test Your Security Guidance explaining that security reviews and testing should be scoped according to risk and should continue throughout development and operation.

UK National Cyber Security Centre — Small and Medium-Sized Organisation Cyber Security Guidance Current resources covering cyber resilience, incident response and recovery for UK SMEs.

WordPress Developer Resources — Hardening WordPress Official WordPress guidance covering software updates, administrator security, files, logging and defence-in-depth.

WordPress — Security Official information describing WordPress security maintenance and protection against common web vulnerabilities.

WordPress Developer Resources — Security APIs Official developer guidance emphasising validation of untrusted information from users, APIs and databases.

CISA — Known Exploited Vulnerabilities Catalogue The US cybersecurity agency's maintained catalogue of vulnerabilities with evidence of exploitation in real attacks.

PCI Security Standards Council — PCI DSS Official payment-industry security standard covering environments where payment account data is stored, processed or transmitted.

PCI Security Standards Council — E-commerce Security and SAQ A Current guidance covering payment-page script security and external vulnerability scanning requirements for applicable ecommerce environments.