Forensic Readiness Grid
When a vendor tells you it has been breached, the first questions are about your logs: which identity used the key, from which network, and what did it touch? Grade each log source, see the questions you could not answer, and get the fixes in priority order plus a tabletop prompt for rehearsing the trace. Everything runs in your browser.
For each log source, tick what is true today. Nothing is assumed: an empty grid scores zero. Ticks are kept in this browser only.
Many questions could not be answered at all, so the notification decision would have to assume the worst.
A qualitative band, not a forecast. It rests on one responder's observation (magoo, Starting Up Security, Oct 2026) that log readiness predicted whether response took days or weeks. The score is a PlayCISO prioritisation heuristic.
Coverage at a glance
| Source | Log exists | Centrally searchable | Retention | Tamper-resistant copy | Collection failures monitored | Standard fields |
|---|---|---|---|---|---|---|
| Identity and SSO | No | No | No | No | No | No |
| Cloud control plane | No | No | No | No | No | No |
| Endpoint | No | No | No | No | No | No |
| Network | No | No | No | No | No | No |
| Application | No | No | No | No | No | No |
| Database | No | No | No | No | No | No |
| Source host and CI/CD | No | No | No | No | No | No |
| Critical vendors and SaaS | No | No | No | No | No | No |
| AI platforms | No | No | No | No | No | No |
Incident questions you could not fully answer
Tick what exists above to see which questions your logs could answer.
- Which identity used the exposed credential, and from where?Not answerable
- Identity and SSO: no log
- Cloud control plane: no log
- What did the credential do in our cloud accounts, and what did it create or change?Not answerable
- Cloud control plane: no log
- Which repositories, secrets or pipelines were read or changed, and by which token?Not answerable
- Source host and CI/CD: no log
- Did the credential come from a network we do not recognise?Not answerable
- Network: no log
- Identity and SSO: no log
- Which records or files were read, exported or changed?Not answerable
- Database: no log
- Application: no log
- What did the breached vendor's access to us look like from our side?Not answerable
- Critical vendors and SaaS: no log
- Which AI platform keys were used, and what did they reach?Not answerable
- AI platforms: no log
- What ran on the affected hosts or build agents?Not answerable
- Endpoint: no log
- Can we follow one actor from the first event to the last across systems?Not answerable
- Identity and SSO: no log
- Cloud control plane: no log
- Application: no log
- Can we trust the logs: were they altered, switched off or silently missing?Not answerable
- Identity and SSO: no log
- Cloud control plane: no log
- Source host and CI/CD: no log
Fix first
Ordered by the weight of the source and how much each gap costs. The same sources also appear in Cloud Logging Gap Checker (cloud detail) and Audit Log Integrity Checker (tamper evidence).
- Identity and SSO: Turn the log on at the source. If a platform cannot produce one, record that as a known blind spot and ask the vendor for the log.
- Cloud control plane: Turn the log on at the source. If a platform cannot produce one, record that as a known blind spot and ask the vendor for the log.
- Source host and CI/CD: Turn the log on at the source. If a platform cannot produce one, record that as a known blind spot and ask the vendor for the log.
- Identity and SSO: Forward it to one searchable store, so an investigator does not need ten consoles and ten logins.
- Cloud control plane: Forward it to one searchable store, so an investigator does not need ten consoles and ten logins.
- Source host and CI/CD: Forward it to one searchable store, so an investigator does not need ten consoles and ten logins.
- Identity and SSO: Extend retention (or archive older data cheaply) to cover how far back you may need to look.
- Cloud control plane: Extend retention (or archive older data cheaply) to cover how far back you may need to look.
Tabletop prompt: trace one incident across systems
Tabletop: trace one simulated incident across systems Scenario (fictional): a vendor that holds credentials for several of your systems tells you it has been breached. Among the exposed items are a source-host token, a long-lived cloud access key and an AI platform API key. Your own alerts show nothing unusual. Ground rules: pick ONE credential. Everyone works from real logs in the real tools, not from memory. Time how long each step takes and write down every question you could not answer. 1. Identity and SSO: Find every sign-in, token grant and app authorisation tied to the credential's owner or service identity. Which field lets you join this to the next system? 2. Source host and CI/CD: Find every clone, secret read and pipeline run by that token. Which repositories and secrets were in reach? 3. Cloud control plane: Find every API call by the key, including identities or resources it created. From which network addresses? 4. Network: For those addresses, what else did they touch? Were any unfamiliar to you? 5. Application and database: Which of your services and records did the same actor touch? Can you tell reads from exports? 6. Critical vendors and AI platforms: What does each vendor's own log say about the same actor and window? Who do you call to get it, and how long does that take? 7. Endpoint: What ran on the hosts or agents involved? Debrief questions - Where did the trail go cold, and why (no log, not searchable, too short, no shared ID)? - Which two systems could you not join, and what single field would fix it? - Could you prove the logs had not been changed? - Who would have had to be woken up, and who held the access you needed? Expect friction at: Identity and SSO, Cloud control plane, Endpoint, Network, Application, Database, Source host and CI/CD, Critical vendors and SaaS, AI platforms (scored low in your grid). Outputs: a list of blind spots with an owner and a date, and a rerun of this grid afterwards.
TL;DRWhat this tool is
5 points
- A coverage grid for nine log sources: identity and SSO, cloud control plane, endpoint, network, application, database, source host and CI/CD, critical vendors and SaaS, and AI platforms.
- For each source you tick whether the log exists, is centrally searchable, how long it is kept, whether a tamper-resistant copy exists, whether collection failures are monitored, and which standard fields it carries (timestamp, identity, action, resource, outcome, correlation ID).
- You get a readiness score, the incident questions you could not answer, a qualitative band for how long a vendor-disclosure call would take, prioritised fixes and a tabletop prompt for tracing one simulated incident across systems.
- The disclosure-call band is qualitative (hours, days, weeks) and rests on one practitioner's observation, not on measured data. The score is a prioritisation heuristic.
- Runs in your browser. Nothing is uploaded; ticks stay in this browser.
Log readiness decides the shape of the response
In “Black October: Lessons From the Downstream Breaches” (Starting Up Security, October 2026), magoo reports that how ready an organization's logs were predicted how long its response took: days for some, weeks for others. That is one practitioner's observation, which is why this tool gives a qualitative band and no number of days.
His advice, which the grid follows, is to log centrally, with consistent timestamps, identities, actions, resources, outcomes and correlation IDs; to set a retention, rotation and archiving policy; to log identity, cloud, endpoint, network, application, database and critical vendor activity; to restrict who can change logging, keep tamper-resistant copies and monitor collection failures; and to run a tabletop that traces a simulated incident across systems.
Do the tabletop with the real tools. The first time most teams try to follow one credential through five consoles is the first time they find that two of them use different time zones and a third cannot be searched by identity.
Frequently asked questions
What is forensic readiness?
How well prepared you are to investigate an incident before one happens: whether the logs you will need exist, can be searched from one place, are kept long enough, cannot be quietly changed, and use fields that let events from different systems be joined. It is separate from detection. You can have good alerts and still be unable to answer "what did that key do last month?".
Which logs do I need to investigate a breached vendor or leaked credential?
Identity and SSO sign-ins, cloud control plane audit logs, source host and CI/CD audit logs, network logs, application and database access logs, endpoint telemetry, and the audit logs of the vendors and AI platforms that hold your credentials or data. The grid covers all of them and shows which questions each one lets you answer.
How long should we keep logs?
Long enough to cover how far back you might need to look, which is usually longer than the time to detect. A common baseline is 12 months retained with the last 3 months quickly searchable; regulated sectors may need more. The grid lets you pick 90 days, 180 days or a year as the look-back target and scores retention against it.
Does log readiness really change how long response takes?
One responder, magoo, writing in Starting Up Security (Oct 2026), observed in serial downstream breaches that log readiness predicted how long response took: days for organizations with it, weeks for those without. That is an observation from one practitioner, not a measured rate, and this tool does not predict a number of days. It only gives a qualitative band.
What standard fields should every log carry?
Consistent timestamps, the identity that acted, the action, the resource, the outcome, and a correlation ID that links events across systems. These are the fields the grid asks about, following the logging advice in the same retrospective.
What is a tabletop that traces one incident across systems?
An exercise where the team picks one credential from a simulated vendor breach and follows it through identity, source host, cloud, network, application, vendor and endpoint logs using the real tools, timing each step and writing down where the trail goes cold. The grid generates a prompt for it, with a note on where your lowest-scoring sources are likely to slow you down.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.