Can your logs answer the first questions after a breach?

Readiness starts before an alert

NIST’s final SP 800-61 Revision 3, published in April 2025, places incident response within cybersecurity risk management. Its stated scope connects preparation, detection, response and recovery. This is established guidance applied to current operations, not an announcement of a new October 2026 threat. [1]

For a security team, the useful test is whether available evidence can support the next decision. A dashboard that shows successful ingestion does not, by itself, establish that an analyst can reconstruct activity or that anyone has authority to contain it.

Logging is a policy and integrity problem too

CISA’s August 2024 joint guidance on event logging was developed with international partners. The Canadian Centre for Cyber Security’s companion announcement identifies four priorities: approved logging policies, centralised collection and correlation, secure storage and integrity, and detection strategies suited to relevant threats. The guidance covers cloud services, enterprise networks, enterprise mobility and operational technology. [2] [3]

Those priorities are broader than “send everything to a SIEM”. They ask what evidence matters, how it is protected and how people will use it. CISA also notes resource constraints: prioritisation matters when storage, engineering time and analyst attention are limited.

Four questions to test against your own environment

1. Who acted? Can an analyst relate an event to an account, device and privilege context? Identify the gaps created by shared accounts or missing identifiers.
2. What changed? Can the team trace the identity, application and administrative events relevant to the scenario, rather than only the first alert?
3. Can we trust the timeline? Check time handling, access to logs, integrity controls and whether evidence survives the failure or compromise being investigated.
4. Who can act? Agree who investigates, who approves containment and which escalation route applies. A visible event without an owner is not a response capability.

These questions are Vula Connect’s practical synthesis, not a quotation of a numbered NIST requirement. The answers should reflect your actual systems and agreed operating model.

Run one bounded evidence exercise

Choose an approved scenario and a safe test account. Agree the scope, timing, authorised actions and stop conditions with the system owners. Use an ordinary permitted event—such as a controlled test-account access change—to trace the path from collection to detection, investigation and escalation. Do not simulate destructive activity on production systems.

Record which evidence arrived, what could be correlated, who received the alert and what information was missing. Turn the gaps into named actions and repeat the exercise after remediation. An exercise that finds a missing event is useful; hiding the gap behind a successful dashboard is not.

Define the handover between monitoring and response

Data & Application Monitoring, MDR and DFIR address related but distinct work. A scoped engagement should make responsibilities, available telemetry and escalation clear. This article does not promise round-the-clock coverage, a response time or a guaranteed investigative outcome.

Explore more insights →