2.1: The 48-hour Audit
The 48-hour Audit
You just got the security hat. Maybe the last person left abruptly, maybe your CEO decided “engineering already handles that,” maybe you raised your hand in a meeting you shouldn’t have. Either way: it’s Monday morning and you own this now.
The temptation in the first week is to do something. Sign a vendor, send a training email, write a policy. Resist that. The first forty-eight hours is discovery, not decision-making. What you commit to this week, you’ll own for the next year.
Here’s a protocol for the first two days that gets you a real picture of the program without locking you into anything.
The four things worth looking at first
1. Who has production access.
Not “who should have it” — who actually has it right now. Pull the admin group memberships from identity (Okta, Entra, Google), pull the role-assignment list from your cloud provider (IAM in AWS, RBAC in Azure, IAM in GCP), pull the break-glass accounts. Put them in one spreadsheet. The rows that make you blink — a stale service account from 2019, three people with PROD root, a contractor who left in March — are the punch list you take to engineering leadership this week.
This is the single highest-signal thing you can do in day one. It costs two hours. It catches real problems. It gives you a concrete artifact to reference when you need to push back on anything else.
2. What logging exists, and where it goes.
Ask the infra team: “Show me a query against production logs from last Tuesday.” If they can do it in five minutes, you have a logging program. If it takes a day, if they ask which system, if they say “we’d have to check” — you have logs but no program. Note the gap. Don’t fix it yet.
What you want to know: does something land in a SIEM or equivalent, who looks at it, and how long is retention. Three data points. Write them down.
3. The last audit or pen-test report — read the exceptions first.
If there’s a SOC 2 Type II in a drawer, skip the opinion letter and go to the exceptions section. The opinion tells you whether the auditor signed. The exceptions tell you what was broken during the audit window. Same for any pen-test report: skip the executive summary, find the “findings” or “issues” list, read severity + status.
You’re looking for acknowledged-but-unfixed risks. Every one of those is something the previous owner decided to live with. You’re about to inherit those decisions. Know what they are before you renew them by default.
4. The incident response runbook — if one exists.
If there’s an IR runbook, read it. If there’s a decision-delegation matrix, read that too. If neither exists, write that fact down. (Module 5 covers IR in depth — for now, just know whether you have one.)
What to ignore in the first forty-eight hours
- Vendor renewals. If a contract is up in the first two weeks, ask for a 60-day extension. You cannot make a good vendor decision without understanding the program the vendor sits in. Module 4 is about vendor calls; you’re not ready yet.
- Compliance deliverables. Unless a deadline is this week, push them. Compliance deliverables produced before you understand the program are theater — they document a state you haven’t assessed.
- Awareness training content. Not urgent. Not in the first two days. Possibly not in the first two months.
The mindset
Discovery, not decision-making. You are not trying to impress anyone this week. You are trying to take an accurate inventory of the program you just inherited, so that the decisions you make in week two through week twelve are made with information instead of pressure.
Write everything down. You’ll reference this audit in every conversation for the next six months, and the version you build in days one and two — when everything is new and you’re noticing things veterans stopped seeing — is the most valuable version you’ll ever have.