Every site I take over from a previous developer gets a security audit before anything else. Not a quick look. A real audit. There is no way to know what has been left behind without checking.
The client whose site went down while I was on the road is a concrete example. She had transitioned to my company recently. The platform was not one I built. I had completed the audit. The issue was not something I had missed.
The site had been built and maintained by a large firm using automated tooling. Those tools were out of date. The vulnerability lived at the platform level, and I was not yet in full control of the system. A completed audit and full control of a system are not the same thing.
What Accumulates in an Unaudited Site
Sites pick up risk over time in ways that do not surface visibly. A plugin that stopped being maintained two years ago but is still installed and active. A user account created for a vendor during a project that was never removed. Login credentials set at launch and never rotated. A staging environment left accessible. File permissions set permissively during a debug session and never restored.
None of these show up as obvious problems. The site looks fine. It loads, the forms work. The vulnerability is quiet until something finds it.
What the Audit Covers
- All user accounts reviewed, who has access, at what level, and whether they should still be there
- All plugins and themes inventoried, version checked against current release, maintenance status confirmed, unused ones removed
- Login paths assessed, default paths flagged for change where the platform allows it
- File permissions reviewed against standard secure settings
- Backup status verified, confirming working backups exist before any changes are made
- SSL confirmed and enforced, no mixed content, no unencrypted pages
- Core software version checked, with a plan for updates if the site is running behind
Each item corresponds to a category of attack that bots probe for. Working through it systematically means I know what I am working with before anything else changes.
The Conversation With the Client
Part of the takeover process is an honest account of what the audit found. If a site has been running for three years without updates, the client needs to know what that means. Decisions about what to prioritize require accurate information.
Sometimes the audit turns up something that needs immediate attention. Sometimes the site was maintained carefully and there is little to address. The audit is how you find out which situation you are actually in.
What the Audit Costs Versus What a Hack Costs
A security audit at the start of a site takeover takes time. That time has a cost. Cleaning up after a hack, removing malware, restoring from backup, identifying the entry point, hardening against re-entry, takes significantly more time. The audit is the smaller expense in every case I have seen.
Need a plan? Book a one-hour strategy session and walk away with a clear direction for your website, security, or digital strategy. All sessions are recorded with full transcription. $250 — Book a Strategy Call
Want to get to know me first? Book a free 15-minute intro call. No pitch, just a conversation. Book a 15-Minute Call
Cybersecurity Series
- The Hack I Couldn’t Fix Between Matches
- The Same Tools Powering AI Are Being Used to Attack Your Website
- 7 Signs Your Website May Already Be Compromised
- Why Small Business Websites Get Hacked (And Why It’s Usually Not Personal)
- What It Actually Costs to Clean a Hacked Website
- How Bots Actually Find Your Website
- Taking Over a Website Means Taking Over Its History
