Website Security Basics for Businesses: Protection, Incident Response, and Where the Maintenance Contract Draws the Line
Most business owners picture website security the way films do: somebody has singled you out and is working hard to break through your defenses. The reality is far duller — automated programs scan the internet all day looking for sites still running old versions with known vulnerabilities, and compromise them in bulk.
In other words, the reason you were picked is usually not that you matter, but that you had not updated. This article is not about technical detail. It is about what a non-technical owner should ask for, what to confirm, and what belongs in the maintenance contract.
The basics: six things somebody should own
One: HTTPS and certificates
HTTPS is the encrypted connection that puts the padlock in the browser address bar. Its job is to stop data being read or altered in transit. It is now standard equipment: browsers label sites without it as insecure, and visitors abandon them before they fill in a form.
There are only two things to confirm: that the entire site runs over the encrypted connection (not just the checkout page), and who is responsible for renewing the certificate when it expires. Most cloud plans renew automatically, but the responsibility should still be written down.
Two: backups
Backups are the single most important item on this list, because they are the only thing that still helps once the worst has already happened.
What to confirm: how often the backup runs, how many copies are retained, whether one copy lives somewhere other than the web server, and whether the restore procedure has genuinely been rehearsed. Only a backup you have restored counts — an untested backup is, in substance, a file nobody has ever opened.
Three: updates
The operating system, programming language, content management system, and assorted plugins your site relies on all have vulnerabilities discovered and patched over time. Not updating means leaving a publicly documented way in exactly where it is.
What to confirm: who tracks updates, how often they are reviewed, and whether updates are trialed in a test environment first. Updating carries risk — it can break functionality — but the risk of not updating only accumulates in one direction. If a system is so old that it can no longer be updated, that is a problem of a different order; see the legacy system modernization guide.
Four: accounts and permissions
A great many incidents begin not with a vulnerability but with a password that was guessed or leaked.
What to confirm: whether every admin account belongs to one named person (rather than one shared login for the whole company), whether accounts of departed employees have been closed, whether two-step verification is enabled, and whether each person’s permissions extend only as far as their job requires. A colleague who edits content does not need the ability to delete the entire website.
Five: vulnerability scanning and baseline hardening
Scan the site periodically with a tool to surface known misconfigurations and outdated versions. Beyond that, common baseline measures include limiting login attempts on the admin interface, restricting where the admin interface can be reached from, and putting a traffic filtering service in front of the site.
None of this needs doing daily, but it should follow a fixed review rhythm — and it should be re-run after every significant redesign, or after installing a new plugin or third-party service. Newly added components are precisely where new ways in most often arrive.
Six: logs
Logs are the system’s dashcam: who logged in and when, which files were modified, which requests were refused.
Day to day they look entirely useless. When something happens, they are the only thing capable of answering “how long have they been in, and what did they touch”. What to confirm: whether logging is on at all, how long records are retained, and whether they are stored somewhere an attacker cannot alter them.
Common attack types, in plain language
| Type | What it does | Typical consequence |
|---|---|---|
| Database injection | Feeds special commands into form fields to trick the system into fetching or changing data | Member data leaked, admin controls bypassed |
| Cross-site scripting | Plants code in a comment or field so other visitors’ browsers execute it | Visitor accounts stolen, redirects to scam pages |
| Credential brute-forcing | Automated programs try passwords repeatedly, or reuse credentials leaked elsewhere | Admin logins compromised, content altered |
| Known vulnerability exploitation | Uses published attack methods against unpatched systems and plugins | Malware or redirects injected into the site |
| Ransomware encryption | Encrypts the files on the server and demands a ransom | The entire site becomes unusable |
| Social engineering | Impersonates a vendor or a manager to request credentials or change payment details | Accounts leaked, money lost |
The last one deserves a specific warning: it is not a technical problem, and it is the type that succeeds most often. No system, however tightly built, can stop someone handing over a password voluntarily. The countermeasure is process, not tooling — confirm every significant change through a second channel.
Responsibility for personal data: the principles
If your website collects names, phone numbers, email addresses, postal addresses, or purchase histories, you are processing personal data, and a corresponding duty of care comes with it.
A few questions worth asking yourself first:
- Is the data you collect genuinely necessary? Do not collect fields you do not need; data you never collected cannot leak.
- Have you set a retention period? Data should not simply pile up indefinitely.
- Who can see it? Does a support agent need to see a full national ID number or credit card details?
- Is the vendor’s responsibility written into the contract? Responsibility does not transfer just because the data sits on a vendor’s server.
- What are your notification obligations if something happens? This is a legal judgment; consult a lawyer, and defer to the latest guidance from the competent authority.
No specific provisions are cited here, because regulations and their interpretations are updated. The point is to know that the responsibility exists and to factor it in at the planning stage, rather than asking about it after an incident.
The order to follow when an incident happens
In a panic, the easiest mistake to make is to fix the site immediately — which overwrites the evidence, and, with the way in still unpatched, invites a second compromise.
The recommended order:
- Record and preserve: note the time you noticed and the symptoms, and preserve the server and application logs first.
- Stop the bleeding: isolate or temporarily take down the affected service so visitors are not harmed further.
- Change the keys: change every related password, admin key, and third-party service credential.
- Establish the scope: how long they were in, what they touched, whether personal data was involved.
- Patch, then restore: close the hole first, then restore from a clean backup.
- Communicate: where customers are affected, explain honestly what the situation is and what you have done. Where personal data is involved, take legal advice on notification obligations.
- Review afterwards: add this particular hole to the checklist so the same category of problem does not recur.
Writing this sequence down before an incident, and naming the points of contact, is worth far more than working it out in the moment.
The drill matters more than the plan
The usual fate of an incident response plan is to be written, filed, and never opened again. It is worth running a simple tabletop exercise periodically: get the relevant colleagues together, assume “this morning we discovered the website has been replaced with something else”, and walk the sequence above to see where it jams.
The first drill usually exposes several very practical problems: nobody knows where the hosting provider’s emergency contact details are kept, restore permissions for the backup belonged only to a colleague who has left, and the domain management account is registered to a former marketing manager’s personal email. Discovering these things during a drill is merely awkward. Discovering them during an incident is a disaster.
What the maintenance contract should cover
Security is not a one-off piece of engineering; it is continuous work, which is why ownership of it belongs in the maintenance contract. At minimum it should cover:
- The frequency of security updates to the system and its packages, and the testing process before they are applied
- The backup frequency, number of retained copies, storage location, and restore drill arrangements
- Responsibility for certificate renewal on expiry
- The frequency and reporting format for vulnerability scans
- The response time and handling process for a security incident, and emergency contact details
- The log retention period and how logs are retrieved
- The handover of accounts and permissions on termination of the contract
For where these conditions sit relative to ordinary maintenance items, compare what website maintenance actually covers. For which questions to ask when selecting a vendor and which contract terms to watch, see How to Choose a Software Development Company.
NETVANA’s software development process includes security scanning in the testing and launch phase. Our consulting services also cover technical architecture review and technical due diligence, which suits situations where you want to establish the risk in an existing system before deciding how much to invest.
The difficulty with security is not technical depth. It is that it is work nobody praises when it is done well, and only notices when it has not been. That is exactly why it needs to be assigned to a named person and written into a specific contract, rather than left in the state of “somebody is presumably handling it”.
If you are not sure how well your current site is protected, or you want security and maintenance responsibility written down properly as part of a redesign, talk to NETVANA about your requirements. NETVANA’s software services are quoted after an initial consultation; for what each service includes and delivers, see the software services overview.
Further reading: for a full breakdown of maintenance costs and contract models, see what website maintenance actually covers. For judging whether to repair or replace an aging system, see the legacy system modernization guide. And for the baseline of website speed and quality, see the website speed optimization guide. For why unpatched dependencies are a form of debt, see Technical Debt Explained for Business Owners; and for drawing the permission boundary in an integration, see A Guide to System Integration and API Development; and for how hosting models split the security responsibility, see How to Choose Web Hosting. For the certificate and DNS layer underneath all of this, see Domains and DNS in Plain English; and for the legal side of holding personal data, see How to Write a Website Privacy Policy; and for offloading password risk to a trusted identity provider, see Social Login and SSO. Backups are the last line of defense when the rest of your security fails; see Website Backup and Disaster Recovery.
