When a device is compromised, a security team needs to answer three questions, fast. What is happening? What happened? And can the device still be trusted? That is the core idea behind forensic observability.
If you have not heard the term before, it is because it is a new thing, recently emerged from UK National Cyber Security Centre (NCSC) guidance. They are calling for network devices to provide reliable, trustworthy ways for defenders to understand their behaviour before, during and after an incident.
This is especially important if your business runs complex estates across IT, cloud, OT, IoT and physical infrastructure, because the evidence needed to investigate an attack is often scattered across different systems. By the time an incident is discovered, important logs may have disappeared, a compromised device may no longer be trustworthy, and your cyber security team may be left trying to reconstruct events from incomplete information.
Forensic observability takes a different approach: make the evidence available continuously, retain it for long enough to be useful, and bring it together so that an incident can be investigated as a complete story. Let us look in more detail at how that works.
Forensic observability, defined
Forensic observability means having reliable ways to understand what a system is doing, what it has done and whether it can still be trusted after a compromise. Logs alone will not cut it. You need trustworthy telemetry, configuration and state information, with evidence available when an incident actually occurs, not something cobbled together retrospectively under pressure.
Network forensics vs forensic observability
They might sound similar, but network forensics and forensic observability are two different things. Network forensics is the established discipline of investigating security incidents using evidence from network traffic, systems and devices. The distinction from forensic observability lies in when and how the evidence becomes available.
Traditional network forensics is largely a retrospective investigation. An incident happens, investigators gather whatever evidence remains and attempt to reconstruct the sequence of events.
Forensic observability provides the capability that makes that investigation possible. Telemetry, logging and other evidence are collected continuously, retained centrally and correlated across the environment, giving investigators reliable evidence to work with when an incident occurs. It does not make network forensics obsolete. It simply provides the foundation for more effective forensic investigation.
Why does forensic observability matter for network devices?
Network devices such as firewalls and VPN gateways sit in particularly sensitive positions. They control traffic between different parts of an environment and often sit directly on trust boundaries, which makes them valuable targets for attackers.
This also creates a difficult question following a compromise: can you still trust the device itself? If an attacker has gained control of it, then relying entirely on evidence stored on that device can be problematic. It may have been altered, wiped or reset. Forensic observability addresses this by making trustworthy evidence available outside the device itself, with centrally retained telemetry remaining available even if the original system is no longer accessible or trustworthy.
The NCSC's approach makes clear that this is a shared responsibility. Manufacturers need to build appropriate forensic capabilities into network devices, while organisations need the infrastructure and retention required to make that evidence useful.
What does good forensic observability look like?
Here are some of the hallmarks of good forensic observability.
1. Retain enough history to reconstruct an incident
Intrusions are not always discovered quickly. An attacker could remain inside an environment for months before their activity is detected. That means that retaining a few weeks of logs may not be enough to understand the full timeline.
Observability247 can retain up to ten years of data, giving organisations the historical depth needed to investigate incidents that would otherwise extend beyond conventional log retention periods.
2. Capture the warning signs
Forensic investigation should not begin only once something has gone badly wrong. Small changes in behaviour can provide valuable context. A rise in resource usage, an unusual network connection and an out-of-hours configuration change might each look insignificant in isolation. Add them up and they could tell a very different story.
Observability247's predict and prevent capability correlates early indicators to provide earlier warning while retaining the context around what was happening before an incident. That gives security and operations teams an opportunity to investigate the run-up to an event rather than looking only at the aftermath.
3. See the whole estate
Attackers do not usually have much respect for the boundaries between IT systems. An incident might begin with a compromised network device, move to a server and eventually affect an operational technology controller. In environments containing IoT devices, physical security systems and cloud infrastructure, important evidence can exist across several different layers.
A network event might become much more meaningful when correlated with an OT controller change, a login or a physical access event. That is why forensic observability needs to extend beyond traditional network telemetry. Observability247 brings IT, cloud, OT, IoT and physical environments into a single view, allowing events across those boundaries to be considered together.
4. Correlate events into incidents
Thousands of individual alerts do not necessarily tell you what happened. In fact, they can make it harder to see the causal chain. Observability247's Event Intelligence correlates related events into incidents, helping responders understand connected activity as a sequence rather than investigating thousands of disconnected alerts.
5. Prioritise what matters
Not every event has the same operational impact. A security event affecting a critical production system may require immediate attention, while another can safely wait. Context-aware prioritisation helps put the most important affected systems at the top of the queue by considering live business impact. The result is a more practical starting point for incident response and triage.
6. Keep evidence away from the compromised device
A fundamental principle of forensic observability is that the evidence used to investigate an incident should not depend entirely on the system being investigated. As we saw earlier, if a device has been compromised, wiped or reset, information stored locally may no longer be available or trustworthy. Centrally retaining telemetry means you still have an independent record of what the system was doing before the incident. Observability247 does exactly this, so evidence remains available even when the original device can no longer be trusted.
7. Understand what normal looks like
Finding something unusual is much easier when you know what normal behaviour looks like. A retained behavioural history for each monitored system can help establish a baseline and identify when its behaviour changed. That might be a configuration change, unexpected resource usage, unusual traffic or activity at a time when the system would not normally be in use. That can help narrow down the point at which an incident began and distinguish genuine anomalies from routine activity.
8. Do not overlook the devices at the edge
Forensic observability should not be limited to servers and endpoints. As we have noted, the devices sitting around the edges can be particularly important to an investigation. Firewalls, VPN gateways and switches control traffic and connectivity, while IoT and OT devices can introduce additional routes into environments that were historically treated separately from mainstream IT.
The NCSC's focus on network devices reflects this. If these systems are compromised, understanding their behaviour can be critical to understanding the wider incident. That is why Observability247 monitors these environments alongside conventional IT infrastructure, giving you visibility across network, IoT and OT systems rather than treating them as separate worlds.
9. One platform, one place to look
During an incident, the last thing responders need is to have to move between disconnected monitoring systems, each showing just one piece of the picture. In disparate systems, a firewall event, server activity, OT alerts and physical security information might all be in different places. It means valuable time is lost moving between systems and manually joining the dots. A unified observability platform, like Observability247, brings those sources together, allowing teams to query the wider environment in one place.
10. Consider where forensic evidence is stored
Forensic evidence is sensitive. Where that data is stored, who controls it and which jurisdiction it sits within can therefore all be important considerations when dealing with compliance, governance and incident investigations. Observability247 is UK-owned and gives you a choice over data residency. Keeping forensic evidence within a jurisdiction the organisation understands and controls can support wider requirements around trust, compliance and chain of custody.
Does more telemetry create more risk?
It is reasonable to ask whether collecting more information could give attackers more opportunities. The answer is not to avoid observability, but to ensure that it is designed securely. Well-designed, authenticated and structured observability can be safer than forcing investigators to rely on undocumented behaviour or improvised methods to extract evidence after an incident. Forensic observability is about creating a trustworthy, supported way to capture the information defenders need, while treating that information as part of the security architecture itself.
How long should you retain forensic data?
There is no single retention period that is right for every organisation. A more useful question is: how long could an attacker realistically remain undetected in your environment? If an intrusion could persist for months, retaining only a few weeks of logs creates an obvious gap. You may be able to investigate when an incident was discovered, but not necessarily the activity that led up to it.
Longer retention gives investigators a better chance of reconstructing the complete timeline, from initial access to discovery and response. Retention should therefore be considered alongside the sensitivity of the systems being monitored, your business's risk profile and the potential value of historical evidence.
What should forensic observability cover?
If you are assessing your current monitoring and security infrastructure, here is a checklist for what you will be needing:
- Trustworthy telemetry and logging from the systems that matter most
- Sufficient retention to investigate realistic attack timelines
- Coverage across IT, cloud, OT and IoT, rather than monitoring each environment in isolation
- Evidence retained away from individual devices, so a compromised system cannot take your historical evidence with it
- Correlation and prioritisation, so responders can identify relationships between events rather than searching through disconnected alerts
- Controllable data residency, particularly where forensic evidence has regulatory, contractual or governance implications
The value of forensic observability is easiest to see after something has gone wrong. Detecting the event is one thing, but do you have enough trustworthy evidence to understand it? While traditional network forensics is still an important discipline for investigating incidents, forensic observability adds the always-on capability that makes those investigations more complete, by collecting, retaining and correlating evidence before anyone knows an incident is coming.
If you want to learn more about how Observability247 approaches long-term retention, cross-environment visibility and forensic investigation, get in touch or compare your options.