ICT risk management expectations under DORA: a practical guide for UK SMEs

For many UK SMEs, DORA can feel like a regulation aimed at larger financial institutions. In practice, it matters to a wider group than that. If your business provides technology, support, software, hosting, managed services, or specialist services to financial services firms, you may be asked to show that you understand your ICT risk position and can support your customer’s resilience needs.

ICT means information and communication technology. In simple terms, it covers the systems, networks, applications, data, and suppliers that keep your business running. Under DORA, the focus is not just on having security tools in place. It is on managing ICT risk in a structured, documented, and business-led way.

This guide explains the ICT risk management expectations under DORA in plain English, with a focus on what a smaller organisation can do without turning the work into a large compliance exercise.

What DORA is and why ICT risk management matters

DORA is the Digital Operational Resilience Act, an EU regulation designed to improve how financial services organisations manage technology-related disruption. It is aimed at the financial sector, but the practical impact often reaches suppliers and service providers too.

The key idea is straightforward: if a business depends on technology to deliver important services, it should understand the risks to that technology and be able to keep operating through disruption. That includes cyber incidents, system failures, supplier outages, data loss, and poor change management.

Who DORA applies to in practice

DORA applies directly to many financial entities operating in the EU. UK SMEs are not automatically in scope just because they are based in the UK. However, if you supply in-scope financial organisations, you may be expected to meet contractual, assurance, or operational requirements that reflect DORA principles.

That can include software providers, managed service providers, cloud service intermediaries, fintech suppliers, and specialist consultancies. The practical question is not only whether DORA applies to you directly, but whether your customers need evidence that your ICT risk management is mature enough to support their own obligations.

Why suppliers and service providers should pay attention

Financial services firms are likely to ask more detailed questions about your controls, resilience, incident handling, and subcontractors. They may want to know how you identify critical systems, how quickly you can recover, how you test backups, and how you manage third-party dependencies.

For SMEs, this is best treated as a business readiness issue rather than a paperwork exercise. Strong ICT risk management can reduce downtime, improve customer confidence, and make supplier assurance conversations much easier.

The core ICT risk management expectations

DORA expects organisations to manage ICT risk in a planned and repeatable way. The exact detail will vary depending on the size and complexity of the business, but the underlying themes are consistent: ownership, documentation, control, testing, and improvement.

Governance, ownership, and accountability

One of the clearest expectations is that ICT risk is not left to the IT team alone. Senior leaders should understand the main technology risks, approve priorities, and make sure someone is accountable for managing them.

For a small organisation, this does not need a large committee. It does need clear ownership. Someone should be responsible for the ICT risk register, someone should own incident response, and someone should be able to make decisions about risk acceptance, supplier issues, and remediation priorities.

Good governance also means knowing which services are important to the business. If a system fails, what stops? Which customers are affected? How long can the business tolerate disruption? These are leadership questions as much as technical ones.

Policies, controls, and documented processes

DORA expects ICT risk management to be supported by documented policies and processes. For SMEs, the aim should be clarity rather than volume. A short, well-maintained set of documents is usually more useful than a large policy library that nobody reads.

At a minimum, you should be able to explain how you manage access, changes, vulnerabilities, backups, incidents, and supplier risk. You should also be able to show how those activities are reviewed and updated.

Documented processes help in two ways. First, they make it easier to run the business consistently. Second, they give customers confidence that your controls are not dependent on one person’s memory.

How to assess your current ICT risk position

Before improving controls, it helps to understand where the main risks sit. A simple assessment is often enough to identify the most important gaps.

Identifying critical systems and dependencies

Start by listing the systems and services that matter most to the business. These are the ones that would cause the most disruption if they failed. For many SMEs, that list is short: email, identity services, finance systems, customer platforms, remote access tools, and any hosted application that supports service delivery.

Then map the dependencies behind them. Which systems rely on which cloud services? Which suppliers host or support them? Which staff roles are essential to recovery? This is where many businesses discover hidden concentration risk, such as a single administrator account, a single hosting provider, or one person who knows how a critical system is configured.

A practical way to do this is to ask three questions for each important service: what would break, how quickly would we notice, and how would we recover?

Reviewing third-party and cloud risk

Third-party risk is often one of the biggest issues for SMEs. If a supplier hosts your platform, processes your data, or provides a managed service, their failure can become your problem very quickly.

Review what each supplier is responsible for and what remains your responsibility. Do not assume that a cloud service provider handles everything. In most cases, the customer still owns identity management, configuration, data governance, access reviews, and business continuity planning.

It is also worth checking how your suppliers handle incidents, backups, subcontractors, and service changes. If a supplier changes a control or experiences an outage, you need to know how that affects your own resilience.

Building proportionate controls for a smaller organisation

SMEs do not need enterprise-scale control frameworks to make meaningful progress. The goal is to put sensible controls around the most important risks and make sure they are actually used.

Access control, patching, backup, and recovery

Access control should be based on least privilege, which means people only get the access they need to do their job. Remove dormant accounts, review admin access regularly, and use multi-factor authentication where possible, especially for remote access and privileged accounts.

Patching is another basic control that often makes a significant difference. Keep operating systems, applications, and internet-facing services up to date. Where patching is delayed, record the reason and the temporary risk accepted.

Backups should be tested, not just created. A backup that cannot be restored is not much use in an incident. Check that backups are protected from accidental deletion or ransomware, stored separately where appropriate, and restored on a regular basis to confirm they work.

Recovery planning should be practical. Define what needs to be restored first, who is responsible, and how long each step should take. A simple recovery order is often more valuable than a long business continuity document that has never been exercised.

Logging, monitoring, and incident response basics

Logging helps you understand what happened when something goes wrong. You do not need to collect everything, but you do need enough information to investigate suspicious activity, service failures, and access issues.

Monitoring should focus on the systems that matter most. For a smaller business, this may mean alerts for failed logins, privileged account use, service outages, and backup failures. The point is to detect issues early enough to respond.

Incident response should be simple and clear. Who triages the issue? Who decides whether it is a security incident? Who contacts customers or suppliers? Who preserves evidence? If these questions are answered in advance, the business is less likely to improvise under pressure.

Testing and assurance without overcomplicating it

DORA places emphasis on testing and assurance. For SMEs, this does not have to mean complex exercises. It does mean proving that your controls work in practice.

Practical ways to validate resilience

Useful testing can be lightweight. Restore a backup and confirm the data is usable. Test account recovery for a locked-out administrator. Walk through a service outage scenario with the team. Check whether a critical supplier has a clear incident process and contact route.

You can also test change management by reviewing a recent system change and checking whether it was approved, documented, and rolled back if needed. These small checks often reveal more than a one-off annual review.

If you have a business continuity plan, test the parts that matter most. The aim is not to create a perfect simulation. The aim is to find out whether the business can continue operating when a key system or supplier is unavailable.

How to record findings and track improvements

Testing only adds value if the findings are captured and acted on. Keep a short log of what was tested, what worked, what failed, and what needs to change. Assign an owner and a target date to each improvement.

A simple risk and actions register is often enough. It should show the issue, the impact, the likelihood, the current control, the planned action, and the status. This gives leadership a clear view of progress without requiring a heavy governance process.

Common gaps SMEs should avoid

Most SMEs do not struggle because they lack intent. They struggle because ICT risk is treated as a side task, or because responsibilities are assumed rather than defined.

Treating ICT risk as an IT-only issue

ICT risk affects operations, finance, customer service, legal obligations, and reputation. If it is left entirely to technical staff, important business decisions may be missed. Leaders should be involved in setting priorities and understanding the trade-offs.

A common gap is focusing on tools while ignoring process. For example, a business may buy monitoring software but not define who reviews alerts, or it may have a backup solution but no tested recovery plan. DORA-style expectations are about the whole control environment, not just individual products.

Relying on suppliers without checking responsibilities

Another common issue is assuming a supplier has everything covered. Even when a service is outsourced, the customer usually still has responsibilities for oversight, access, data handling, and continuity planning.

Make sure supplier contracts and operational arrangements reflect reality. Know what service levels matter, what incident notification looks like, and what happens if the supplier changes a key control or subcontracts part of the service.

If a supplier is important to your service delivery, treat them as part of your resilience planning, not as an external detail.

A simple action plan for the next 90 days

If you want to improve readiness without overloading the business, a 90-day plan is a sensible place to start. Focus on the highest-risk systems first and build from there.

Prioritise the highest-risk systems first

Begin with the systems that would cause the most disruption if they failed. Review their access controls, patching status, backup coverage, monitoring, and supplier dependencies. Fix the obvious weaknesses first, especially where a single failure could stop a critical service.

At the same time, identify any immediate gaps in ownership. If nobody is clearly responsible for an important control, assign that responsibility now.

Create a short improvement roadmap

Turn the assessment into a short roadmap with practical actions. Keep it realistic. A few well-chosen improvements are better than a long list that never gets completed.

A useful roadmap might include updating the ICT risk register, reviewing supplier responsibilities, testing a restore, tightening admin access, and rehearsing the incident response process. Once those basics are in place, you can decide whether more detailed work is needed.

For UK SMEs supporting financial services firms, the main objective is to show that ICT risk is understood, owned, and managed in a proportionate way. That is usually more persuasive than trying to mirror a large enterprise control model.

If you would like help turning this into a practical, business-friendly plan, speak to a consultant.

Frequently asked questions

Does DORA apply directly to UK SMEs?

Not usually by default. DORA is an EU regulation and applies directly to in-scope financial entities. However, UK SMEs that supply those organisations may still be asked to meet DORA-aligned expectations through contracts, assurance reviews, and operational requirements.

What is the quickest way to improve ICT risk management readiness?

Start with the basics that reduce the most risk: identify critical systems, confirm ownership, review supplier responsibilities, test backups, tighten privileged access, and make sure incident response steps are written down and understood.

Those actions will not solve every issue, but they create a solid foundation and usually improve resilience quickly.