Why knowing your technology matters before a cyber-attack

Most large businesses would struggle to say exactly how many laptops, servers, and other devices they have. Fenix24, a recovery specialist we work with regularly, finds that even well-run organizations tend to work from an estimate.

The difference between that estimate and reality usually only becomes clear during a cyber incident. When the Fenix24 team maps an organization’s systems during a recovery, it is not uncommon to find assets that no one knew existed or that were supposed to have been retired years earlier.

Some of them may be quietly supporting systems the business relies on, which affects how quickly those systems can be brought back. In several cases, they have also turned out to be relevant to understanding how the attack unfolded.

Why technology estates are hard to map

Technology usually goes unrecorded for understandable reasons. Many businesses grow through acquisition. Each deal brings systems, suppliers, and ways of working that were built for a different organization. Combining them takes years, and the people who understood the original arrangements often move on before the work is finished.

Operational technology adds a further layer. These are the systems that run physical systems such as production lines and warehouses. Many now rely on the wider corporate network to function. A production line may need the ordering system to know what to make, or a warehouse may need it to know what to ship. Those links often cross the boundary between the teams that run physical operations and the teams that run IT. Each side may know its own systems well, but it’s often the case that no one sees the whole chain until an incident tests it.

The age of this equipment brings a further challenge. Machinery is often built to run for many years and the software that controls it can be just as old. Updating this software risks putting the equipment out of action, while replacing the equipment can mean pausing operations or redesigning the processes built around it. For many businesses, keeping older technology running is an unavoidable part of operating at all.

Even where a business knows its own systems well, part of what it relies on is run by others through integrations, shared accounts, and outsourced services. Detailed knowledge of how those services are set up often sits with the provider, too. How quickly that knowledge can be obtained when it is needed often depends on what was agreed with the provider at the outset.

The pace of change increases the complexity. Businesses add new systems to stay ahead of competitors, to serve customers in new ways and increasingly to make use of AI. Each choice makes sense on its own. Over time, though, the estate grows faster than any record of it.

Recovery depends on the whole chain

This matters most in an incident. Bringing a critical application back is rarely a question of restoring one system. It depends on the chain of systems beneath it. The recovery time for that application is the time needed to restore the entire chain. Some systems sit beneath many services at once. The system that controls who can sign in is a common example. If attackers reach it, services that appear separate can be affected together.

The same is true of data. Knowing what data the business needs to keep operating and where it sits makes it far more likely that the right information is protected and can be brought back.

Critical knowledge often sits with people

More often than not, that knowledge sits with people rather than in any single record. The first questions in a recovery are practical ones about which systems come back first, how they connect, where the backups are and who holds the credentials. The answers often sit with the people who built or maintain the systems; they could be a small number of key individuals, and/or spread across internal teams or outsourced providers. The summaries that reach senior leaders are by necessity simpler than the detail beneath them. Bringing it all together under pressure takes time.

Responsibility can be similarly informal. Who looks after a particular part of resilience is often understood rather than written down in contracts or role descriptions. Where a task falls between two teams, each may reasonably assume the other owns it. That assumption is rarely tested until a crisis hits.

What regulators expect to see

Regulators increasingly look at the same things after an incident. They want to know whether an organization understood which systems supported which services and whether its recovery planning reflected that. Who was accountable for what is often part of the same inquiry.

Building a complete and current picture is achievable, but it rarely happens by default. It takes deliberate planning, and tends to work best when it starts with the services that matter most and works outward.

Automated discovery helps, but its results still need checking against the knowledge of the people who run those services. Capturing that knowledge as part of ordinary business means recovery does not hinge on any one person or provider being available.

Our cyber and employment teams developed the BRACE (Building Resilience and Accountability in Cyber and Employment) toolkit with this in mind, which draws on what we have seen across multiple incidents to translate regulatory requirements into practical, enforceable documentation. The picture is never finished and there is no single fix, but it is far easier to build before an incident than during one.