The Annual Security Review SOP

Purpose

This review guarantees that, once a year, the shop's security setup matches the shop as it actually is: the people who work here, the devices they carry and the accounts that hold the money and the customer list. Without it, drift accumulates silently. A tech who left in March still logs into the scheduling app in November, a backup that stopped in the spring is discovered the day the office computer dies, and the "yes" on the cyber insurance renewal describes a shop that no longer exists. Each step below has a pass condition you can check, so the review either passes or produces a dated fix list.

Scope

Covers: the account inventory, user access on every listed account, multifactor authentication, admin roles, the shop's devices, a restore test of the backups, outgoing-money controls, and the domain and email setup. It runs once every 12 months, and also within 30 days of a change of ownership or a move to a new main business system.

Does not cover: responding to a live incident, which belongs to The First Hour After a Suspected Breach SOP and stops this review until it is closed; removing a single departing employee, which belongs to The Employee Offboarding Digital Access SOP; and building the account inventory from nothing, which belongs to The Account Inventory Every Shop Should Keep. If the inventory does not exist yet, build it first and run this review the following month.

Roles and responsibilities

In a shop without an IT person, the office manager runs step 6 with the backup service's own restore instructions, and the owner sits in on it.

Procedure

1. Open last year's record and the account inventory side by side. Confirm every fix item from last year shows a completion date. Then confirm the inventory is dated within the last 12 months and that every row has an owner name, the login email used, whether it is critical (holds money, customer data or the domain), and a recovery email. Pass: zero open fix items from last year and zero inventory rows missing any of those four fields. If wrong: an open item from last year goes to the top of this year's fix list with a new date and its original date kept beside it, so the record shows it slipped twice; a blank field gets filled before step 2. Hazard: the inventory says where credentials live, never what they are; if you find a password written in it, move it to the password manager and delete it from the document before continuing.

2. Reconcile people against every account's user list. Take the current payroll roster plus any active contractors. Open the user list on every account in the inventory and compare. Pass: zero active logins belonging to anyone not on the roster, and zero shared logins except those the inventory explicitly records as shared with a named reason. If wrong: any active login for a departed person is a stop: suspend it now, then check that account's activity log for sign-ins after the person's last day and, if you find any, stop this review and open the breach procedure. Hazard: suspend, do not delete; deleting a user on many platforms deletes their mailbox, files or job notes with them, so transfer what they owned first and delete only once the transfer is confirmed.

3. Check multifactor authentication on every critical account, for every user. Open each critical account's security or user settings and read the status per user, not just whether the setting exists. Pass: 100 percent of users on 100 percent of critical accounts show multifactor authentication enrolled, and each account's recovery codes are stored in the password manager under that account's entry. If wrong: turn it on for that user the same day; an account the platform will not allow it on gets a note on the fix list and a compensating control (a unique long password and alerts on sign-in). Hazard: enforcing multifactor on an account before its recovery codes are saved can lock the shop out of it; save the codes and enroll a second method first. See related: Turning On Multifactor Authentication Without Locking Yourself Out.

4. Count the admins on each critical account. Record how many people hold the owner or top admin role, and who they are. Pass: at least 2 and no more than 3 people at the shop hold the top role on each critical account, and no outside vendor holds the owner role. If wrong: with one admin, add a second person the same day, because one departed or compromised person can orphan the account; with four or more, step the extras down to a lower role; a vendor as owner goes on the fix list with a 30-day date to transfer ownership. Hazard: removing the only other admin while you are fixing roles can leave you as a single point of failure; add before you remove, never the reverse.

5. Match the device list to the devices. For every phone, tablet and computer on the inventory, see it, or have the person holding it show it on a video call. On each, confirm the screen lock, that storage encryption is on, and the date of the last operating-system update. Pass: every listed device located, every device locked and encrypted, every update applied within the last 30 days, and no unlisted device signed into a shop account. If wrong: a device that cannot be located within 2 business days is lost, and goes to The Lost or Stolen Field Device SOP; an unlisted device gets listed or signed out. Hazard: do not wipe a device you merely cannot find yet until the lost-device SOP says to, because a remote wipe also destroys photos and job notes not yet synced.

6. Restore a real file and a real export, to a separate place. Pick one folder of current working files and the most recent export or backup of the main business system. Restore both to a different folder or a spare computer, then open three files and one record by name. Pass: every opened file opens without error and the newest restored item is no older than the backup schedule promises, for example 24 hours for a daily backup. If wrong: the review is not closed; the fix goes on the list with a 14-day date and a second restore test is scheduled for that date. Hazard: restoring into the live folder overwrites the current day's work with older copies; always restore to a separate location and compare before copying anything back. See related: Testing a Restore Before You Need One.

7. Test the outgoing-money controls. Confirm bank alerts are on for outgoing payments and for changes to account details, by triggering one small, harmless event and seeing the alert arrive. Confirm dual approval is still required for outgoing transfers. Then compare the last four digits of the payout account shown in the payment processor with the bank statement. Pass: alert received within 15 minutes, dual approval prompt seen, digits match. If wrong: a mismatch on the payout account is a stop; go straight to The Payout Account Change Alert SOP. Hazard: test approval with an amount small enough to lose, and never by sending money to an outside account to see whether it arrives.

8. Check the domain and email setup. In the registrar account, confirm the domain is registered to the shop, auto-renew is on, the renewal card is current and the expiry is more than 60 days out. Then confirm the email authentication records are still in place with the shop's email provider's checker. Pass: all four domain conditions true and the records report as valid. If wrong: an expiry inside 60 days with auto-renew off is renewed the same day; failed records go on the fix list with a 14-day date. Hazard: editing DNS records to fix one thing can break mail or the website; change one record at a time and confirm both still work before the next. See related: Setting Up Email Authentication So Nobody Can Send as You.

9. Close the review. Write the fix list with an owner and a date per item, schedule any retest from step 6, and set next year's review date. The owner signs. Pass: the record is signed and saved where last year's is, and every fix item has a named person and a date. If wrong: a review with an unsigned record or an undated item is not complete; the office manager holds it open and raises it at the next weekly meeting.

The record this produces

One page or one form per year, saved with prior years in the same folder, never inside an account it describes. Fields: review date; who ran each step; the inventory version reviewed; per step, pass or fail with the evidence (counts, dates, the four digits, the restore item names); every finding; the fix list with owner and due date; retest dates and results; the owner's signature. It is read at three times: by the next year's reviewer at step 1, by the owner when the cyber insurance renewal asks what controls are in place, and by anyone reconstructing an incident, who will want to know what was true at the last check.

Worked pass: a twelve-person electrical shop

Run in the second week of January, office manager running, owner signing, an outside IT person for step 6.

1. Pass. One open item from last year (a second admin on the bank portal) shows completed in June. Inventory dated last February, 23 accounts, 9 marked critical, no blank fields.
2. Fail, then contained. Roster is 12 people. The scheduling app shows 13 active users: an apprentice who left in August. Login suspended at 9:20 a.m. Activity log shows his last sign-in on his final day, nothing after, so no breach procedure. His job photos were already on shared jobs, so the account is marked for deletion after 30 days.
3. Pass after fix. 8 of 9 critical accounts fully enrolled. The fuel card portal shows the owner without multifactor. Recovery codes saved, enrolled the same morning. Recorded 9 of 9.
4. Fail. The payroll service has one admin, the owner. A second admin, the office manager, added that afternoon. No vendor owners found.
5. Pass. 14 devices listed, 14 located (two techs showed tablets on a video call), all locked and encrypted, all updated within 30 days.
6. Fail; review held open. The IT person restores the jobs folder. The newest file is 47 days old. The backup service's storage had filled in late November and the job had been failing every night since, with the alert going to the email of the apprentice suspended at step 2. The export of the business system restores and opens correctly, dated yesterday. Fix item: clear storage, move alerts to the office manager, due in 14 days. Retest scheduled for the fourth week of January.
7. Pass. Test alert arrived in about 4 minutes, dual approval prompt seen, payout digits match the statement.
8. Pass. Domain in the shop's name, auto-renew on, card current, expiry in 8 months; email records valid.
9. Held, then closed. Record signed with two fix items (the backup repair and deleting the apprentice's account after 30 days), the restore retest pending. The retest on the scheduled date restores a file dated the previous night. Record updated with the retest result and closed.

Read back against the procedure. Step 6 failed for a reason step 2 had already exposed: the departed apprentice's address was the backup's alert destination. That is why step 2 says to transfer what a person owned before deleting them, and why every alert destination belongs in the inventory as a field, which this shop added to its inventory as a third fix item.

References

• NIST Cybersecurity Framework 2.0, the Identify, Protect and Recover functions this review checks against
• See related: The Account Inventory Every Shop Should Keep
• See related: The Employee Offboarding Digital Access SOP
• See related: Testing a Restore Before You Need One
• See related: What Cyber Insurance Applications Actually Ask