Is a WAF enough to protect a website?

No. A WAF limits some traffic and known attack patterns, but it does not replace updates, secure code, MFA, access control, application testing, monitoring or a verified backup.

How often should a CMS and plugins be updated?

Critical patches should be assessed and deployed as quickly as possible through a controlled process. Other updates need a regular cycle, non-production testing, a rollback plan and post-deployment verification.

What should a website backup cover?

The database, user files, code or deployment artefact, server and application configuration, passwords and access keys in a secure store, DNS and recovery instructions verified through a practical test.

How does Virtline assess website security?

The scope may include inventory, server and TLS configuration, accounts, updates, WAF, logs, monitoring, backup, vulnerability scanning, application testing, response planning and retesting of important fixes.

Comprehensive business website protection

Website security and business continuity

A business website combines sales, contact and reputation. Effective protection covers updates, accounts, a WAF, TLS, change monitoring, verified backups and a tested recovery procedure for incidents.

Written and maintained by: Virtline team 2026-11-14

Why website security affects business reputation

A compromised website may display unauthorised content, redirect visitors, distribute malware or expose information from forms and accounts. Even a short incident prompts customers to question security, accountability and service quality. The technical scope therefore needs a business owner and a communication plan.

Availability

Monitoring response times, errors, certificates and critical paths shortens outage detection.

Data confidentiality

Forms, accounts, APIs and the administration panel require protection from takeover and disclosure.

Content integrity

Logs, change control and alerts help detect modified files, code, DNS or configuration.

NIST SP 800-44 - securing web servers

NIST’s 2007 guide to secure web-server operations. It is an older source of operational principles, not a current list of TLS versions or application technologies. Check current settings against vendor documentation and contemporary guidance.

The website attack surface

Risk extends beyond website code. An attacker may exploit the CMS, a plugin, an editor account, the server, hosting panel, domain, DNS, email service, external library or an API flaw. An inventory of dependencies is the first step towards assigning owners and priorities.

CMS, framework, libraries, themes and plugins with their versions, update sources and support end dates.
Administrator, editor, developer, hosting, DNS, CDN, repository and deployment-automation accounts.
Forms, sign-in, payments, customer portal, APIs, file uploads and integrations with external systems.
Web server, reverse proxy, database, storage, backups, passwords and access keys, certificates and maintenance access.
Domain, DNS, transactional email, analytics, marketing tags and scripts loaded from third parties.

Minimum website protection control set

No single product addresses every risk. An effective baseline reduces the attack surface, protects accounts, filters traffic, secures deployments and provides a recovery capability. Every control needs an owner, a review frequency and evidence that it works.

Updates and hardening

Supported versions, removed unnecessary services, secure permissions, headers and configuration control.

WAF, segmentation and limits

Traffic rules, rate limiting, separated layers and logging of attempts that require analysis.

MFA and least privilege

Separate accounts, MFA, access reviews and prompt revocation after a role or supplier change.

OWASP Top 10 - web application risks

OWASP groups major web application risk classes and supports risk-based testing priorities.

TLS, backup and monitoring must work together

HTTPS protects traffic, but it cannot restore a deleted database or detect a modified file. Backups should include data, files, configuration, DNS and recovery instructions. Monitoring should cover availability and integrity as well as certificate and domain expiry.

Enforce HTTPS, a correct TLS chain and HSTS after analysing subdomains, with alerts before certificate expiry.
Keep segregated database, file and configuration copies and regularly restore the service in a test environment.
Monitor the home page, forms, sign-in, APIs, payments and other customer-critical paths.
Detect changes to files, administrator accounts, DNS settings, redirect rules and active integrations.
Retain server, application, WAF, CDN, account and deployment logs long enough for incident analysis.

Security acceptance and incident response

The project is complete only when the organisation can show test results and work through an outage or compromise scenario. The report should separate critical risks, short-term fixes and actions that require architectural change.

Scan for vulnerabilities and test key authentication, authorisation, session, API and input-handling controls.
Report TLS, header, WAF, account, permission, component-version and public-service configuration.
Complete a recovery test with measured RTO/RPO and confirmation of database, file and configuration integrity.
Document isolation, account blocking, log preservation, communication, recovery and post-fix retesting.
A remediation plan for website controls, backups and incident response, with owners, deadlines, completion evidence and accepted risks.

Related Virtline services

Website protection can be delivered as a review of an existing service or as part of a new environment project. The scope is matched to the architecture, data, traffic, customer requirements and practical operating model.