Skip to the page

Incidents and resilience

Ready before it happens, and the record after.

Eurus starts the legal clocks an incident sets, keeps what was done and who was told, and holds the incident open until its root cause and lessons are written. The continuity plan, each system's recovery objectives and the restore tests that show they hold are kept beside it.

What the law asks

The incident workflows

  1. GDPR

    A personal data breach is reported to the Data Protection Commission within 72 hours of becoming aware of it, unless it is unlikely to put people at risk, and every breach is documented (Article 33).

  2. NIS2

    A significant incident gets an early warning within 24 hours, a notification within 72 hours and a final report within a month (Article 23). Business continuity, backups and crisis management are among the measures of Article 21(2)(c).

  3. DORA

    A financial entity classifies ICT-related incidents and reports the major ones (Articles 17 to 19), and keeps ICT business continuity and response and recovery plans, tested at least once a year (Articles 11 and 12).

  4. ISO/IEC 27001

    Annex A's controls 5.24 to 5.30 cover incident management, learning from incidents, and ICT readiness for business continuity; control 8.13 covers backups.

An incident, from the first hour

  • The clocks

    The incident starts the clocks the law sets: GDPR's 72 hours for a personal data breach, NIS2's reports for a significant incident, and DORA's for a major one.

  • A timeline

    What was done, who was told and by which channel, when it was contained and recovered, kept as written. A critical incident nobody updates for 8 hours is raised, a high one after 24.

  • Closed with its lessons

    A closed incident stays raised until its root cause and lessons are both written.

  • Actions checked by someone else

    Each corrective or preventive action is raised when late, and then until someone other than its owner checks it held.

Try this in a copy of your own, for two hours, with nothing to sign up for.

Open your own copy

Rehearsed before it is real

Tabletop exercises from five scenarios: ransomware on the file server, customer data emailed to the wrong person, a critical supplier down for a day, a staff account taken over by phishing, and a major ICT incident at a financial firm. Each shows the clocks a real one would start, and an exercise never starts one. A year with no exercise is raised, and the gaps it finds become actions.

Continuity, kept and tested

  • The plan

    What it covers, who invokes it and how, who does what and how people are told, approved by someone other than its last editor and reviewed on its cycle.

  • The impact assessment

    Each system on the business's map is given a tier, how long the business can stand it down, and its recovery time and recovery point. A system nobody has assessed is counted as not assessed.

  • Restores, tested

    A critical system's restore is tested every 92 days and an important one's every year. Each test is judged against the system's objectives: met, missed or unknown.

  • The suppliers underneath

    Which suppliers each system rests on. A supplier leaving or out of contract under a needed system is raised, and several critical systems on one supplier is shown.

Want it on your own systems?

We start with an audit: how your operations really run, mapped to the controls you keep.