Most breaches are not sophisticated. They exploit an unpatched component, a reused password, or an admin panel open to the internet with a weak login. The basics genuinely cover most of the risk.
Patch, on a schedule
The largest single factor. Vulnerabilities are published with fixes, and attackers scan for the versions that have not applied them. Unattended security updates on the server and a routine for dependency updates in the application cover the bulk of it.
An application untouched for a year is not stable, it is behind.
HTTPS everywhere, and actually everywhere
A certificate is table stakes. Beyond it: redirect all HTTP to HTTPS, send HSTS so browsers refuse to downgrade, and make sure no page pulls a script or image over plain HTTP.
Treat the admin panel as the front door
It is the most valuable target on the site. Long unique passwords, no shared accounts, sessions that expire, and rate limiting on the login so an automated attempt is slowed rather than merely logged. If a member of staff leaves, their access should end that day.
Take only the data you need
Every field you collect is a field you have to protect and, under PDPL, account for. A contact form does not need a national ID number. The safest data is the data you never stored.
If you take payments, let a payment provider handle card details so they never reach your server.
Headers and uploads
Security response headers cost nothing and remove whole categories of attack. And any file upload should be validated by what the file *is*, not what it claims to be — re-encoding an uploaded image is a reliable way to ensure an image is an image.
Backups are a security control
The realistic ransomware answer is a good, off-site, versioned backup you have tested. See is your business data actually backed up.
How we approach it
Patching, headers, access control and backups are part of how we run servers, not a hardening exercise sold afterwards.
Ask us for a review if nobody has looked at yours in a while.