Service area

Preparedness, continuity and resilience

What happens when something breaks – and who does what? Incident preparedness, continuity plans that have been exercised, recovery that has been tested, and the reporting the regulations require while it is happening.

  • Incident preparedness
  • Continuity
  • Recovery
  • Exercises
  • Cybersecurity Act
  • DORA

Risk analysis answers what could happen. This area answers what you do when it does. We help organisations know which processes and systems they cannot do without, have an incident process that works at three in the morning, continuity plans that have been exercised rather than archived, and a recovery that has actually been tested. It all connects to information security work, where the risk assessment lives, and to IT operations, where the backups and monitoring do the job.

For many regulated organisations, preparedness is an explicit requirement. The Swedish Cybersecurity Act requires, among other things, incident handling, continuity and crisis management. DORA requires ICT business continuity, recovery and recurring testing. The CER Directive covers the physical and operational resilience of critical entities and is being transposed into Swedish law, with entry into force proposed for 1 January 2027. We help you meet the requirements with work that holds, as when we reviewed the outsourced IT operations of an insurance company. Read more about how we work.

We work with critical services and their dependencies – people, premises, IT, communications and suppliers – so that the business can continue even when one part of the chain fails.

We work from our office in Bjärred with organisations in Malmö, Lund, Helsingborg and across Sweden.

In brief

Who
Organisations that cannot stand still – and that must be able to show management, customers and supervisors that they have prepared
What
Business impact analysis, incident preparedness, continuity and crisis plans, recovery verification, exercises, supplier dependencies and reporting under the regulations
How
First what is critical, then the plans, then the exercise that shows whether they hold – together with the people who will act when it happens
Geography
Skåne, Sweden, based in Bjärred outside Malmö/Lund. Engagements across Sweden.

Common situations

This is how it usually starts. If you recognise yourselves in one of them, we know roughly where to begin.

Offers in preparedness and continuity

Six ways to start. Each offer can be bought on its own or combined into coherent preparedness work.

Business continuity

Business continuity management and exercise

What happens if a critical service is down for three days? Business impact analysis, continuity plan and an exercise carried out.

You get: ranked processes, a continuity plan with roles and restart order, and a documented exercise.

Scope: a few days to a week depending on scopeRead more →
Incident plan

Incident preparedness and tabletop exercise

An incident plan that works when it matters, and an exercise that shows it does.

You get: an incident process with roles, contact routes and decision mandates, playbooks for the most likely scenarios and a tabletop exercise carried out.

Scope: defined engagement, a few daysRead more →
Review

Backup and recovery verification

You know the backup job is green. But do you know the business can actually be recovered?

You get: a review of the backup setup against business requirements, a restore test and an action list.

Scope: defined engagement, with restore testsRead more →
Supply chain

Supplier and third-party review

Your suppliers handle your systems and your information, but your requirements only count if someone follows them up. What happens if one of them falls away?

You get: risk-assessed suppliers, requirements and exit routes in contracts, and a follow-up routine.

Scope: defined engagement, usually about a weekRead more →
DORA

Annual DORA review and maintenance

DORA does not get finished. The recurring review of the ICT risk management framework, the testing programme and the reporting, brought together as one usable piece of maintenance work.

You get: an annual review report, updated policies and registers, and a basis for management.

Scope: defined engagement per period, recurringRead more →
Management

Management cybersecurity training

The Cybersecurity Act makes security a management responsibility, and during an incident it is management that decides on shutdown, communication and notification.

You get: half a day with management on accountability, decisions during an incident and reporting requirements, documented.

Scope: defined engagement, half a day plus preparationRead more →

See all offers →

Not sure where to start? We normally begin by identifying the business’s critical processes, dependencies and recovery requirements. From there it is quick to decide whether the next step should be continuity planning, incident preparedness, a restore test or an exercise.

Regulations that require preparedness

A closer look at each regulation: who is affected, what is required and how we help.

How we work with preparedness and continuity, in detail

Six parts that together are preparedness. Jump to a section in the menu, or read from the top. About 6 minutes of reading

What is critical: business impact analysis

Not everything can be recovered first. A business impact analysis (BIA) goes through your processes and asks what an outage costs per hour and per day – in money, in customer trust, in regulatory breaches – and which systems, people, premises and suppliers each process depends on. The result is a ranking: what must be up within an hour, what can tolerate a day, what can wait a week. It provides the basis for the recovery objectives – RTO for how quickly something must be back and RPO for how much data may be lost – keeping the business impact analysis separate from the technical recovery requirements. It is the only foundation that makes the rest of the work proportionate, and it is the first question an auditor asks about the continuity plan.

In brief

  • Processes ranked by what an outage costs
  • Dependencies on systems, people, premises and suppliers
  • Recovery-time and acceptable-data-loss targets per process

Incident preparedness

An incident plan is worth exactly as much as it works at three in the morning when the person who wrote it is on holiday. We build an incident process with clear roles, contact routes that exist outside the systems that may be down, decision mandates to shut services and contact authorities, and playbooks for the scenarios most likely for you: ransomware, data leakage, an outage at a critical supplier, lost access to the cloud environment. The process is coordinated with operational incident support so the technical and the organisational move in step. The offer Incident preparedness and tabletop exercise delivers the plan and the exercise together.

In brief

  • Roles, contact routes and decision mandates that work under stress
  • Playbooks for your most likely scenarios
  • Coordinated with technical incident support

Continuity planning

The incident plan handles the first hours. The continuity plan handles the days after: how the business carries on when a system, a site or a supplier does not come back for a long time. It builds on the impact analysis and describes fallback modes, manual routines, alternative suppliers and the order in which services are restarted. We write it with the people who will use it, short enough to be read in a crisis, and connect it to a crisis plan for management’s decisions and communication. The Cybersecurity Act requires business continuity management, while DORA requires documented ICT business continuity arrangements and response and recovery plans. ISO/IEC 27001 contains controls for information security during disruption and ICT readiness for business continuity. The offer Business continuity management and exercise produces the plan and exercises it.

In brief

  • Fallback modes, manual routines and restart order
  • Connected to a crisis plan for management decisions and communication
  • Short enough to use, maintained so it stays true

Recovery: backup and disaster recovery

A backup that has never been restored as a test is an assumption. We review the backup setup against the impact analysis – what is backed up, how often, how long it is kept, whether the copies sit outside the environment that can be attacked – and carry out a restore test that answers two questions: how long does it take, and is the data complete? Where IT operations are outsourced we verify that the supplier’s recovery commitments have actually been tested, as in our review of outsourced IT operations at an insurance company. The backup service itself is delivered within IT services; here we check that it holds what the business needs. The offer Backup and recovery verification is exactly that check.

In brief

  • Backup setup reviewed against business requirements
  • Restore test: time and completeness
  • Supplier commitments verified, not assumed

Exercises and testing

Plans that are not exercised are documents. A tabletop exercise gathers the people who will act – management, IT, communications, whoever speaks to the authority – around a realistic scenario and walks through it hour by hour: who detects, who decides, who calls, what do we tell customers, when do we notify. The exercise finds what the plan missed: the contact list that is out of date, the mandate nobody holds, the system that turned out to be critical though nobody wrote it down. We document the findings and update the plans, so the exercise yields a better plan and not just a completed activity. DORA additionally requires resilience to be tested regularly, from vulnerability assessments to coordinated tests, and we help you set up that programme.

In brief

  • Tabletop exercises with the people who will act
  • Findings fed back into the plans
  • A digital resilience testing programme where DORA requires it

Crisis leadership and reporting during an incident

During a significant incident management has two jobs at once: lead the business through it, and report it to the right recipient in time. For a significant incident under the Cybersecurity Act, an early warning must be given within 24 hours of becoming aware and, for most entities, an incident notification within 72 hours. The final report is normally due no later than one month after the incident notification; if the incident is still ongoing, a progress report is given instead, and the final report one month after the incident has been handled. Notifiable personal data breaches must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours. DORA has its own requirements for classifying and reporting major ICT incidents, and entities covered by DORA follow those instead of the Cybersecurity Act’s reporting rules – one regime, not two. We build it into the incident process: who assesses whether the incident is reportable, who writes, who sends, and which templates and contact details are ready before they are needed. Management cybersecurity training walks through exactly those decisions, and the interim CISO is there when you need someone to lead the work over time.

In brief

  • Reporting deadlines built into the incident process: 24 hours, 72 hours, one month
  • Notifiable personal data breaches to the supervisory authority within 72 hours
  • Roles, templates and contact details ready in advance

Want to know whether your business withstands an outage – and be able to show it before anyone asks? Contact us, and we start with what is critical.

Frequently asked questions

What is the difference between incident preparedness and continuity planning?

Incident preparedness is about the first hours: detect, assess, contain, decide and report. Continuity planning is about the days after: how the business carries on when a system, a site or a supplier does not come back for a long time, and in which order services are restarted. Both build on the same business impact analysis.

How often should the continuity plan be exercised?

Our recommended minimum is once a year, and always after major changes in the business, systems or suppliers. A tabletop exercise takes half a day and almost always finds something the plan missed. For entities covered by DORA it is an explicit requirement: ICT business continuity and recovery plans must be tested at least yearly.

What deadlines apply for reporting an incident?

Under the Swedish Cybersecurity Act: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours and a final report no later than one month after the incident notification. Notifiable personal data breaches are notified to the supervisory authority without undue delay and where feasible within 72 hours. DORA has its own rules for major ICT incidents. Which apply to you depends on which regulations you are affected by.

Our IT operations are outsourced. Is preparedness then the supplier’s responsibility?

Parts of the execution can be, but the responsibility for the business functioning is yours, and it is you who report to the supervisory authority. We verify that the supplier’s recovery and incident commitments are tested and match your requirements, and that you have a way out if the supplier falls away.

We are a smaller organisation. How much preparedness do we need?

A proportionate amount: a one-page impact analysis, an incident plan with roles and contact routes, a continuity plan for the two or three processes you cannot do without, one restore test per year and one exercise. What does not scale is lacking it the day it is needed.

Want preparedness that is exercised – not just documented?

Contact us