Why Most SMEs Can’t Meet the New Reporting Timelines — And What Actually Works

The Cyber Security and Resilience Bill sets clear expectations:
initial incident notification within 24 hours, followed by full reporting within 72 hours.

On paper, that sounds reasonable.
In practice, most SMEs cannot meet it today — and pretending otherwise is the real risk.

This is not a failure of intent or professionalism. It is a mismatch between regulatory assumptions and operational reality.

Why the timelines break SMEs first

The reporting clocks assume several things are already in place:

  • continuous monitoring and alert triage,

  • the ability to distinguish “significant” incidents quickly,

  • access to legal and regulatory judgement,

  • clarity on customer impact,

  • and authority to report without escalation paralysis.

Most SMEs do not lack skill — they lack spare margin.

Security teams are small. Roles overlap. Legal support is external. Decision-makers are busy. Incident response is rarely exercised under regulatory pressure.

The Bill does not scale expectations by headcount.
It scales them by dependency and impact.

The hidden problem: decision-making under uncertainty

The hardest part of the 24-hour window is not detection.

It is deciding:

  • Is this reportable?

  • Who is affected?

  • What do we say, and to whom?

  • What if we’re wrong?

For SMEs, these decisions often stall because:

  • authority is unclear,

  • escalation paths are informal,

  • and nobody wants to be the one who “pulls the trigger”.

Delay becomes the default — and delay is now non-compliance.

Why “just buy better tools” doesn’t fix this

More tooling improves visibility.
It does not fix governance.

Many SMEs already detect incidents faster than they can decide what to do with them. The bottleneck is:

  • coordination,

  • judgement,

  • and confidence in defensible action.

Regulation compresses time. Tools compress signals.
Neither resolves responsibility.

What actually works in practice

SMEs that cope well under regulatory pressure tend to do a few things differently.

1. Pre-agree reporting thresholds
They do not decide significance from scratch during an incident. They define:

  • what must be reported,

  • what probably should be reported,

  • and what clearly does not.

This reduces hesitation.

2. Assign decision authority explicitly
One named role owns the reporting decision — informed by others, but not paralysed by consensus.

3. Separate technical response from regulatory judgement
Engineers stabilise systems.
A small, pre-defined group handles reporting and communications.

4. Rehearse with realistic scenarios
Not tabletop exercises about “ransomware in theory”, but rehearsals that include:

  • incomplete information,

  • regulator deadlines,

  • customer notification questions,

  • and uncomfortable trade-offs.

5. Use external support deliberately
Not ad hoc panic calls — but standing arrangements for legal, regulatory and incident-response support that can be activated immediately.

The uncomfortable truth

The Bill does not expect SMEs to become enterprises.
It expects them to be ready.

Readiness is not about size.
It is about clarity, rehearsal and decision discipline.

SMEs that rely on goodwill, heroics or last-minute improvisation will struggle — not because they are careless, but because the regime no longer tolerates ambiguity.

The practical takeaway

If your organisation cannot confidently answer:

  • Who decides to report within 24 hours?

  • What information we must have by then?

  • How customers would be notified in parallel?

then your biggest risk is not an attacker — it is the clock.

Call to action

If you are unsure whether your organisation could meet a 24-hour reporting obligation with defensible judgement and customer awareness, now is the time to test it.
Contact Cyber Tzar to assess your reporting readiness and supply-chain exposure — and identify what actually works for SMEs before timelines become enforcement tools.

View more resources

View more resources