The annual security review for small teams

Big companies do security reviews because an auditor demands one. Small companies skip them because nobody demands one — and then the one moment the answer matters arrives anyway: the insurance renewal application, a customer's security questionnaire, or the morning of an incident, when "how long since we tested our backups?" becomes the most expensive question nobody wrote down. An annual review is just the habit of answering those questions before someone asks under deadline.

This is a one-morning exercise, not a project. Block half a day once a year — a fixed date you'll remember (the insurance renewal, fiscal year end, the week after the holidays) works better than a floating intention. You finish with a one-page summary of what you checked, what you fixed, and what you're consciously accepting. That page is the deliverable: it satisfies the underwriter, briefs the next hire, and becomes exhibit A in your own defense if something breaks anyway.

1. Prove the recoveries, not just the backups

Start with the question that ends businesses: can you actually get your data back? Not "do backups exist" — does a restore work:

• Run one live restore. Pull a file, a mailbox, or a database from backup onto a different machine. Time it. If it takes three hours and a support ticket, that's your real RTO — write down the number, not the brochure number. Full ritual in the backup restore test.
• Test the human recovery paths too. One person "loses" their phone and recovers every critical account. This is where passkey and MFA rollouts quietly break — see the passkeys rollout recovery step.
• Check the break-glass account. The admin recovery account: does it work, does it have a strong unique credential, and does exactly one person know where its backup factor physically lives?

2. Rotate the things that rotate

Secrets age like milk, not wine. Once a year, walk the secrets rotation schedule end to end:

• API keys and tokens. Every integration, webhook, and script — including the ones a departed employee set up. Anything unused gets killed, not rotated; a dead key is the only truly safe key.
• Shared passwords and Wi-Fi. The shared inbox password, the router, the printer admin panel. Rotate, then push the new values through the password manager — never email.
• Recovery and backup codes. Printouts from three years ago in a drawer are a liability, not a backup. Regenerate, re-vault.

3. Audit who can get in — and who still could

Access drifts. People join, leave, change roles; vendors come and go; the exception granted during a crunch becomes permanent. The annual pass:

• Active accounts vs actual people. Every admin account maps to a current employee. Anything else is disabled today — the offboarding checklist catches leavers; the annual review catches everyone the checklist missed.
• Privileged roles. Who is admin on each system, and do they need to be? Every account you demote from admin is an account a phisher can't use to destroy your week.
• Vendor doors. Re-screen the critical vendors with the vendor security review questions. Verify the ones you fired last year are still actually gone.
• Authentication strength. MFA on everything that supports it, passkeys where the vendor allows, SMS-only recovery eliminated where a stronger option exists. The MFA rollout page has the order.

4. Test the humans before the phishers do

The cheapest security control you own is a staff that recognizes a fake invoice. Once a year, deliberately:

• Send one internal phish. A fake "invoice overdue" or "MFA code" email to the team. Not to punish anyone — to measure. Report rate matters more than click rate: did anyone flag it, and did anyone forward it to finance?
• Walk the response once. If a click had happened, who gets called in what order? Rehearse the first hour of the phishing response runbook on paper. Ten minutes of table talk now beats improvising it during the real thing.
• Refresh the one-page rules. "We pay invoices only after the callback number is verified from the website." One page, six rules, everyone initials it. If it doesn't fit on one page it won't be remembered.

5. Check the machinery nobody looks at

• Patches and updates. One pass of the patch management checklist: laptops, phones, router firmware, the NAS in the cupboard. Reboot the things that "have been running fine."
• Certificates and domains. Expiry dates for SSL certs and domain registrations — both belong on the renewal calendar, because an expired certificate looks identical to a hack from the customer's side. The SSL expiry checklist covers the mechanics.
• Logs and retention. Confirm the log retention policy matches reality: are logs actually kept for as long as you claim, and would they answer "who logged in?" six months ago?
• The incident plan itself. Phone numbers change, people leave. Verify every contact in the incident response plan is still reachable — including the external ones (IT support, insurance broker, lawyer).

6. Write the one page, accept the rest

A review that produces no record is a conversation. Close it out with a single page:

• Tested: what was verified working this year (restore test date, recovery drill date, phish exercise date).
• Fixed: what changed because of this review (keys rotated, accounts demoted, vendor doors closed).
• Accepted: the risks you know about and are choosing not to fix this year — named, owned, with a revisit date. "We accept the shared printer admin password until March" written down is a decision; the same thing unwritten is a surprise.

Then put next year's date in the calendar before you close the laptop. The review that gets scheduled recurs; the one that "we should do this again sometime" doesn't. Twelve months from now, the underwriter's renewal form, the customer's security questionnaire, or an incident at 2AM will ask these questions — and you'll have a page with answers dated, signed, and boring. That's the whole point: security that is documented and dull is the kind that works.