Choose a scenario that crosses team boundaries
Use a realistic scenario such as a finance account compromise that affects a supplier conversation and shared documents. Map each system, provider and decision-maker involved. Ask what leadership would need to know about access, impact and recovery. Starting with a scenario reveals gaps that a list of installed security tools may miss. It also makes the readiness exercise relevant to business owners.
Check records, access and retention in practice
For each source, identify the relevant event types, time coverage, export method and person able to retrieve it. Verify a sample rather than relying only on configuration screenshots. Cloud retention can depend on licences, policies and the event involved; Microsoft documents those dependencies for its audit service. Record any limitations and who is responsible for resolving them.
Build a forensic readiness plan from an evidence matrix
A forensic readiness plan identifies which records must be available, who can obtain them and how they can be preserved for an authorised investigation. Start with the questions the organisation may need to answer; buying a logging platform does not establish that every source is covered. The matrix below is a starting point to tailor and test, not a universal retention schedule.
On a small screen, scroll the table sideways to compare all columns.
| Evidence source | Verify before an incident | Acceptance evidence |
|---|---|---|
| Identity and privileged access | Relevant sign-in and role-change events, time coverage, service accounts and export permissions. | A retrieved sample with stable identifiers, source time zone and a documented collection method. |
| Email and collaboration | Message trace, mailbox and file events needed for the scenario; workload, licensing and policy dependencies. | An export that answers a known test question, with its query, limitations and collection record. |
| Endpoints and network services | Available device, EDR, DNS, proxy or firewall records and their relation to the business service. | A controlled event correlated across relevant sources, with clock differences explained. |
| External providers | Named request owner, approval authority, secure transfer route and alternative contact. | A completed sample request and a record of actual delivery limitations. |
Make provider responsibilities explicit
An outsourced provider may hold important records while the client retains the business risk. Review how an evidence request is authorised, what can be exported and which dependencies affect delivery. Identify an alternative contact if the normal administrator is unavailable. For group structures, check whether one entity can authorise access to another’s records instead of assuming that a shared brand means shared authority.
Practise the handling and decision trail
Run a controlled exercise that includes evidence requests, secure exchange, time-zone reconciliation and a record of changes made during response. Test how IT, security, management and advisers coordinate. The aim is to expose practical friction before an incident: unavailable permissions, unclear approval, incomplete exports or reporting that arrives without sufficient context. Assign each gap to an owner with an acceptance test.
Connect readiness to the wider risk programme
NIST SP 800-61 Revision 3 places incident response within cybersecurity risk management, connecting preparation with detection, response and recovery. Use that broader perspective when prioritising improvements. A logging change should support a decision, a response procedure or a recovery check. The exercise is complete when the organisation has both an evidence picture and an actionable improvement plan.
Define when the readiness exercise is complete
Set an acceptance test before the exercise. For example, ask the authorised team to reconstruct a controlled administrative change: what changed, the acting identity, the affected resource, when it occurred and which records corroborate it. Record elapsed retrieval time against an agreed target, missing fields, export errors and any provider dependency. A completed search with no results is not a successful test if the event should have been recorded.
For each source, document the business and investigation need, relevant privacy constraints, selected retention, actual oldest retrievable event and how expiry is monitored. Microsoft explains that audit availability depends on record type, licensing and retention policy; verify the tenant’s real behaviour rather than copying a generic duration into the plan. Longer retention alone does not fix incomplete events or unavailable access.
Deliver the evidence-source register, access and responsibility matrix, preservation procedure, exercise results and a prioritised remediation register. Recheck unresolved gaps after fixes. A backup supports recovery but may lack the event history needed to explain an incident; a SIEM may contain useful copies without every original field. Record these limits so decision-makers know what can be demonstrated.
Sources: Microsoft — Audit log retention policies · NIST SP 800-86 — Forensic techniques and incident response
Repeat after material changes
Acquisitions, tenant migrations, new AI services and provider changes can alter the evidence landscape. Add readiness questions to change review and periodically retest critical sources. Record the date, scope and result so leadership understands what has actually been demonstrated. This produces a more reliable basis for response than a plan whose assumptions have never been exercised.
Further reading
Put the guidance to work
Evidence-source mapping, logging and retention review, preservation procedures and scenario exercises for investigation readiness.
Forensic readiness