Services · Support · Hosting & maintenance
Website security. The goal is for nothing to happen.
Patching, access, backups and hardening, done on a schedule. Almost every breach we are called about was a known issue with an available fix.
Security is a maintenance habit, not a product
The website breaches we get called about are rarely sophisticated. They are an unpatched plugin, a shared admin login that outlived the contractor who used it, or an out-of-date dependency with a published exploit and an available fix nobody applied.
So we treat security as routine maintenance rather than a product: dependencies patched on a schedule, access reviewed and individual, backups taken and, the part people skip, periodically restored to prove they work.
Headless architecture helps, which is one reason we favour it. There is no public admin panel to brute-force and a much smaller attack surface than a self-hosted CMS with thirty plugins. Where you are still on that, the honest fix may be a replatform.
How we actually do it
Boring, scheduled, verified.
- 01 · Patch on a schedule, not on the news
- Dependencies reviewed and updated on a defined cadence, tested before they ship. Reacting only when something makes the news means running known-vulnerable for months.
- 02 · Make access individual and reviewed
- Named accounts with appropriate roles, multi-factor where it matters, and an offboarding step that actually happens. Shared logins are the most common weakness we find.
- 03 · Test the backups
- A backup nobody has restored is a hypothesis. We restore periodically to a staging environment to prove the recovery path works and to know how long it takes.
- 04 · Harden appropriately to the platform
- Headers, rate limiting, form spam protection and the platform-specific hardening that matters. Proportionate, security theatre wastes budget that patching would have used better.
What you get
Deliverables, not adjectives.
- Scheduled dependency patching, tested before release
- Access review, individual accounts, MFA and an offboarding process
- Automated backups with periodic tested restores and a stated recovery time
- Security headers, rate limiting and platform-appropriate hardening
- A short quarterly report on what was patched and what changed
Questions, answered straight
No fluff, as promised.
Is a headless site more secure than WordPress?
Generally yes, because the attack surface is smaller and there is no public admin panel to attack. It is not immunity, dependencies and access still need managing, but there is far less to get wrong.
How often should dependencies be updated?
Monthly as routine, immediately for a critical advisory affecting something you run. The point is that it is scheduled rather than remembered.
What happens if we do get compromised?
Contain, restore from a tested backup, close the route in, then write up the cause. The tested backup is what turns a crisis into an afternoon.
Related services
This never works in isolation.
Proof from real work
Clients where this was the job.
When did you
last patch?
Tell us what you're working on. You'll get an honest answer about whether we can help, and exactly how.
Prefer email? hello@saigon.digital