“You can’t protect what you don’t know.”

It’s a simple truth. And in today’s complex digital environments, it’s also a major risk.

Most organisations are dependent on a web of interconnected systems, services, vendors, and platforms. These support everything from critical business operations to regulatory reporting. But when asked to name their critical IT assets, many organisations hesitate, not because they don’t care, but because the task is far more complex than it appears.

We believe clarity starts with structure.

Why it matters: from risk to resilience

Cyberattacks are evolving. Attackers are faster, more focused, and increasingly target high-value assets like identity providers, cloud infrastructure, or core line-of-business applications. Simultaneously, regulations such as NIS2, DORA, and industry-specific compliance frameworks demand clear documentation of critical processes and their supporting IT such as systems and services.

Failure to meet these expectations doesn’t just increase cyber exposure, it may result in legal, financial, and reputational consequences.

From an operational perspective, lack of visibility into what’s critical:

• Hinders effective incident response and recovery planning
• Increases risk during system outages or supplier disruptions
• Leads to inefficiencies in resource prioritization and risk mitigation

Moreover, when “everything is critical,” nothing really is. Without prioritization, risk registers become cluttered, investment strategies scatter, and business continuity plans become diluted and ineffective.

Our approach: a structured start that delivers clarity

We work with organisations to establish a practical and repeatable method for identifying their critical IT assets. Our framework is rooted in five clearly defined steps:

1. Understand strategic and regulatory context

Begin by clarifying what truly matters: your mission, your customers, and your compliance obligations. Engage stakeholders who understand the broader strategic and legal landscape, including regulators if you're in a highly governed sector (e.g., energy, finance, healthcare).

Some critical processes may already be predefined by law or sector-specific guidelines (e.g., Energistyrelsen’s NIS2 sector guidance). Use these as a starting point for your initial shortlist.

Recognise that full visibility takes time. Your first priority is to identify the most strategically significant areas where a disruption would cause unacceptable impact.

2. Define candidate critical business processes

Identify the business processes most likely essential to delivering your mission, meeting compliance obligations, and sustaining core operations.

While all processes depend to some extent on confidentiality (is sensitive data at risk?), integrity (can the process be trusted to behave correctly?), and availability (can the service be delivered?) (CIA), focus only on those with potential for significant impact in at least one of these areas.

A process does not need to score high across all three. Substantial impact in just one (for example, availability or confidentiality) can warrant further analysis. Conversely, processes that depend on all three CIA elements but where a loss or disruption would not cause significant impact, should not be categorised as critical.

Remember: it’s the real-world consequences of failure and not theoretical dependencies, that determine criticality.

At this stage, you are shortlisting, not confirming, processes as candidate critical business processes. This prioritisation:

• Limits time and resources spent on deep analysis
• Relies on professional judgment and early input from business stakeholders
• Ensures focus on the most likely impactful areas

Assess potential consequences of failure, including:

• Financial loss
• Legal or regulatory penalties
• Customer or stakeholder harm
• Operational disruption
• Health and safety risks
• Impact on public services or critical societal functions (if applicable)

Identify relevant process owners for these shortlisted processes. They will provide detailed input later during the Business Impact Analysis (BIA) in Step 4.

A practical note on scope:

In theory, a comprehensive BIA would cover all business processes to fully understand organisational risk.

However, ask yourself:

Do we have the resources, framework, processes, and tools to do this today?

If not, and most organisations don’t initially, start by applying the BIA to your shortlisted, high-impact processes.

As your organisation matures in its BIA capability, expand the analysis over time to cover additional processes and refine your understanding of business-critical assets.

This staged approach helps balance thoroughness with available resources and organisational readiness.

3. Set your baseline for scope and depth

Here’s where many organisations struggle: How deep should we go?

With a provisional list of candidate critical business processes, determine how deeply to map their supporting IT assets.

Avoid exhaustive mapping at this stage. Instead, select an abstraction level that balances practicality and decision-making value, often at the system or platform level (e.g., ERP, IAM, CRM), while highlighting particularly critical subsystems or integrations where appropriate.

Define what qualifies as a critical IT asset for your organisation, considering:

• It’s support to a shortlisted business process
• Regulatory designations
• Preliminary recovery objectives (MTD, RTO, RPO)

Note: The final determination of criticality for both processes and assets will happen after completing the BIA in Step 4.

Align your approach with:

• Regulatory expectations
• Leadership’s needs for prioritising investments in risk mitigation and recovery initiatives.

4. Conduct a Business Impact Analysis (BIA)

For each shortlisted business process, conduct the BIA to confirm or adjust criticality based on detailed data and business impact assessments.

Key activities:

• Engage process owners through interviews or workshops to gather real-world impact data.
• Assess financial, operational, reputational, legal, and societal consequences of disruption.
• Define Maximum Tolerable Downtime (MTD), Recovery Time Objective (RTO), Recovery Point Objective (RPO), and acceptable workarounds.
• Link each process to its supporting IT assets and assess the impact of failure.

This step finalises:

• Which business processes are truly critical
• Which supporting assets qualify as critical IT assets

This creates a robust foundation for prioritising business continuity planning, technical recovery strategies, and the allocation of resources and investments in resilience initiatives, ensuring they deliver the most meaningful impact on your organisation’s overall cyber resilience.

5. Align ownership and maintain overview

Criticality is meaningless without accountability and without mechanisms for ongoing review.

Document clear mappings between processes, assets, and owners. Assign responsibility for:

• Ongoing risk management
• Technical resilience
• Compliance reporting

Use dashboards and visual overviews to foster shared understanding across business, IT, and compliance.

Make the results actionable for recovery testing, security prioritisation, and board-level decision-making.

As your BIA practice matures, regularly revisit and update criticality assessments to reflect changes in business priorities, technology, and regulatory demands.

The hidden layer: third-party risk is core risk

One of the most overlooked aspects in identifying critical IT assets is the growing reliance on third parties. Your systems are increasingly dependent on cloud providers, SaaS platforms, outsourcing partners, and managed service vendors.

That means:

• You don’t fully control the stack your services run on.
• Their downtime is your downtime.
• Their vulnerabilities are part of your threat surface.

Questions like: Who runs your core systems? Who owns your data? Who acts when things go wrong? need clear, documented answers.

Third-party risk is not a side issue, it’s a core element of resilience. And it’s already embedded in regulatory expectations. Recognising and managing these dependencies is a critical part of any modern IT asset mapping.

Clarity before control

Knowing what’s critical is the starting point for everything else:

• Robust cybersecurity
• Effective incident response
• Reliable compliance reporting
• Strategic investment in resilience
• Focused governance and risk reduction

Clarity doesn’t happen by accident. At Kopenhagen Konsulting we help organisations take a structured, informed approach to understanding what’s truly critical, so decisions can be made with confidence.

Because before you can protect, recover, or govern your critical IT assets, you need to know what they are.

‍