Run the quarterly security audit of the company

When to use

The quarterly scheduled audit. Not for rotating a single password after a scare — use tech.password-rotation. Not for a suspected phishing e-mail — use tech.phishing-report, which may escalate into an out-of-cycle audit. Not for a lost laptop — use tech.lost-device, which is an incident, not a review.

Before you start

• The employee/contractor list is current — reconcile it with people.offboard-employee records first; an audit against a stale list finds nothing.
• The owner has confirmed which paid services count as in scope this quarter.
• The agent has read access to the domain, DNS and mail modules; it never needs to see password values, only their state.

What a run requires2

The trail8 steps

1. S1

   Build the inventoryagent

   List from the modules: every mailbox, every domain with its DNS records, every device registered to a person, every paid service or login the company holds.

   Done when the inventory is written down with a count per category.

2. S2

   Check access against peopleagent

   For every login, mailbox and device, name the person who holds it. Anything held by a leaver, a shared "info@" with no owner, or an unknown person goes on the findings list.

   Done when every access item maps to a current person, or is listed as a finding.

3. S3

   Check passwords and MFAagent

   For each service: does it enforce MFA, and when was each password last changed? Flag services with no MFA and passwords older than the company's rotation rule. Record states only — never copy password values into the report.

   Done when each service shows MFA yes/no and last-change date, or is flagged "unknown".

4. S4

   Check the external surfaceagent

   Run bc dns per domain: SPF, DKIM, DMARC present and sane (tech.dmarc-review handles deep changes; here only flag what is missing). Check HTTPS certificates against tech.ssl-expiry-check results. Run bc mail search for forwarding rules to outside addresses — a hidden forward is a classic breach sign.

   Done when each domain has a pass/fail line for SPF, DKIM, DMARC, certificate and forwarding rules.

5. S5

   Check backups and recoveryagent

   Read the latest tech.backup-restore-drill record. If none exists in this quarter, that is itself a finding — a backup nobody has restored is a hope, not a backup.

   Done when the report states the date of the last successful restore test.

6. S6

   Review findingsownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Present findings ranked: leaver access first, then no-MFA, then external records, then everything else. The owner marks each finding: fix now, file as task, or accept as risk with a reason.

   Done when every finding has one of the three marks and the owner's name next to the decision.

7. S7

   Execute approved fixesagentneeds approval · owner

   Approval · S7 · owner — the run stops until a named person records the decision

   Apply the "fix now" items: remove leaver access, disable dead mailboxes (tech.remove-mailbox covers deletions), turn on MFA where the owner approved it. For "task" items, run bc tasks add with the finding, the owner and a date.

   Done when each "fix now" item is verifiably done and each "task" item exists as a task.

   ⛔ Removing access or a mailbox is treated as irreversible — only what the owner marked in S6, nothing else.

8. S8

   Write the report and schedule the next runagent

   One page: date, inventory counts, findings with their marks, fixes applied, accepted risks with reasons. Link the report from the audit calendar entry; set the next quarterly date.

   Done when the report is filed and the next date is in the calendar.

Checks — how we know it worked

• Re-read the report against the systems: the leaver marked "removed" no longer appears in any access list.
• Every finding has a mark and, for tasks, an owner and a date — no orphan findings.
• The previous quarter's findings are each either closed or carried forward with a reason.
• The next audit date exists in the calendar.

If it goes wrong

What each step leaves behind

1. S1the inventory is written down with a count per category.
2. S2every access item maps to a current person, or is listed as a finding.
3. S3each service shows MFA yes/no and last-change date, or is flagged "unknown".
4. S4each domain has a pass/fail line for SPF, DKIM, DMARC, certificate and forwarding rules.
5. S5the report states the date of the last successful restore test.
6. S6every finding has one of the three marks and the owner's name next to the decision.
7. S7each "fix now" item is verifiably done and each "task" item exists as a task.
8. S8the report is filed and the next date is in the calendar.

Evidence to keep

The dated report · inventory counts · the owner's decisions in S6 (who, when) · before/after state for each fix · task ids for open findings · the accepted risks with reasons.

How this playbook improves

After every 4 runs (one year) ask: what share of findings were closed within the quarter, and did any finding repeat three times? Did any accepted risk later cause an incident? Is S1 inventory-building drifting from reality — if a check in S2 found something the inventory missed, the inventory method needs a new check, and the change note says which step changed.