Security conversations tend to drift towards the exotic. The compromises we are actually called in after are not exotic. They are an unpatched plugin, a password shared across four people, a backup file left in the web root, or a former contractor whose access was never revoked.

That is good news, because it means most of the risk is addressable with a checklist rather than a specialism.

What actually gets exploited

Ordered roughly by how often we encounter them.

  1. A known vulnerability in a dependency. The advisory was published, the patch existed, nobody applied it. Automated scanning finds these at scale, which is why "we are too small to be a target" does not describe how this works.
  2. Credentials. Shared administrator accounts, no multi-factor authentication, a password reused from a service that was itself breached.
  3. Stale access. Former staff and former suppliers still holding accounts. Offboarding is a process nobody owns.
  4. Exposed configuration. A .env file, a database dump, a .git directory or a backup archive reachable over HTTP because it sits in the web root.
  5. A staging environment, publicly reachable, with production data in it and none of the production hardening.

None of these require skill to exploit. They require a scanner and patience, and both are free.

The checklist that removes most of it

Not comprehensive, and deliberately ordered by return on effort.

  • Patch on a schedule, tested on staging, with a rollback path. This is the single highest-value ongoing security activity for most sites, and it is boring, which is why it lapses.
  • Multi-factor authentication on every administrative account. No exceptions for the person who finds it annoying.
  • One account per person. Shared logins make offboarding impossible and audit trails meaningless.
  • A documented offboarding process that includes third-party accounts and the registrar.
  • Secrets outside the repository, in environment configuration or a secret store.
  • Backups stored separately from the live environment, and restored on a schedule. An untested backup is a hope.
  • Security response headers and a Content Security Policy, which cost a configuration change and remove a category of attack.
  • Remove what you do not use. Every plugin, integration and open endpoint is surface area. Deleting is cheaper than defending.

Design so that a compromise is survivable

Perfect prevention is not available. What is available is limiting the damage and shortening the recovery.

Separate environments so a staging compromise is not a production compromise. Apply least privilege so an application account cannot drop tables it never needs to touch. Keep logs that let you reconstruct what happened, stored somewhere an attacker with application access cannot edit. Keep backups offline, or at least on separate credentials.

The difference between an incident and a catastrophe is almost entirely these four things, and all of them are architectural decisions made long before anything goes wrong.

If it has already happened

The order matters, and the instinct to skip to step three is the reason so many sites are compromised twice.

  1. Contain. Take the site offline or into maintenance. Rotate credentials – all of them, including ones you believe were not exposed.
  2. Assess. What was accessed, what was changed, what data was involved. This determines your legal obligations, and those have deadlines.
  3. Clean and restore, from a backup predating the compromise if you can establish when that was.
  4. Close the route. Find how they got in. Restoring a backup without this gives you a clean site with the same open door.
  5. Review. What would have caught it earlier, and who owns that now.

What we will not tell you

That a site is secure. No system can be guaranteed secure, and a supplier who says otherwise is either misunderstanding the problem or selling.

What an assessment can honestly produce is a list: what was reviewed, what was not, what was found, what was fixed, and what risk remains after all of it. The last item is the one that gets left out of most security reports, and it is the one a board actually needs.