Contents
On September 11, 2001, nearly 3,000 people lost their lives in the attacks on New York, Washington D.C., and Pennsylvania. Before any lesson for businesses, it's worth pausing to remember them: the people themselves and everyone who still misses them each year around this date.
That day, many companies operating in the World Trade Center lost their offices within minutes. Some of them, however, kept operating as a business that same day. Not because they had better offices, but because their data, systems, and critical processes already existed, replicated somewhere else.
That contrast marked a turning point. Until then, business continuity was a document many companies kept filed away "just in case." From that day on, it stopped being theory.
In the years following 9/11, an entire disaster recovery industry emerged and became professionalized. Financial and technology companies began demanding redundant data centers, geographically separated, able to take over operations if the primary one went down.
Backups stopped being a maintenance task and became a strategic decision. Companies started talking about recovery time, recovery points and regularly testing those plans. Having a backup was no longer enough — you had to prove it worked when it mattered.
Today, most companies don't depend on a building. They depend on their software. A server outage, a ransomware attack, a cloud provider disruption or a breach at a third party you work with can paralyze your operation just as effectively as a physical disaster, only far more often.
The lesson from 9/11 still holds, only the scenario has shifted: it's no longer about having a backup office, but about having systems that can keep running or recover quickly, when something fails.
The European Union has turned that lesson into law. The NIS2 Directive (EU Directive 2022/2555) was adopted in January 2023 and member states were required to transpose it into national law by October 17, 2024, the point from which its enforceability began.
Its goal is to raise the common level of cybersecurity across the EU, requiring companies in sectors considered essential or important to demonstrate they can manage digital risk and keep operating through an incident, not just try to prevent one.
Beyond the legal language, Article 21 of the directive sets out a set of minimum measures that covered companies must implement. Among them:
Risk analysis and management: identifying what can fail and what the impact would be.
Incident handling: clear procedures to detect, respond and report.
Business continuity: tested backups, crisis management and recovery plans.
Supply chain security: assessing the risk introduced by your vendors and tools as well.
Access control and encryption: basic hygiene measures that remain, surprisingly, the most neglected.
Early reporting: an obligation to notify authorities within 24 hours of detecting a significant incident.
The directive doesn't mandate a specific technology. It requires an "all-hazards" approach, proportional to each company's size and activity, but it must exist, be documented and be demonstrable.
NIS2 covers medium and large companies across numerous sectors: energy, transport, healthcare, banking, digital infrastructure, cloud providers and also manufacturers and service providers operating within regulated supply chains. As a common reference point, the threshold sits around 50 employees or €10 million in annual turnover within regulated sectors, though it's worth verifying each specific case.
Non-compliance is not a warning without consequences. Fines can reach €10 million or 2% of global annual turnover, whichever is higher and for the first time, company management can be held personally liable in cases of gross negligence.
It's easy to confuse the two, but they serve different purposes. Security works to prevent the incident from happening in the first place: access control, encryption, updates, good development practices. Resilience assumes that, sooner or later, something will fail anyway and focuses on the business being able to keep operating when it does.
Software can be very secure and still not be resilient: if it goes down, it takes weeks to recover. And it can be resilient without being secure: it recovers fast, but remains vulnerable to the same attack. Companies that manage risk well work on both dimensions at once, not as separate phases.
For a development team, this isn't legal theory, it's concrete architecture and process decisions:
Automated backups, stored outside the primary environment, with restores tested periodically rather than configured and forgotten.
Environments with real redundancy, so a single component failing doesn't take down the whole system.
Active monitoring and alerting that can catch an incident in minutes, not days.
A documented incident response procedure, with clear roles for who does what.
Access control based on least privilege and encryption of sensitive data both in transit and at rest.
Evaluating the third-party vendors and libraries in your stack, because their vulnerability is also yours.
In many projects, security and resilience get addressed at the end, as an extra added if there's leftover budget or time. It's exactly the opposite of how it should be approached.
The most common red flags: there's no plan for what to do if the system goes down, no one has ever tested a real restore from backups, more people than necessary have access to critical systems or there's no process to assess the risk a new integration or vendor introduces before it goes into production.
None of these things are expensive to fix when addressed from the design phase. All of them are very expensive to fix after an incident.
You don't need a bank's budget to apply the spirit of NIS2. Proportionality is built into the directive itself: what's required of an SME isn't the same as what's required of critical infrastructure, but the principle is the same.
Start with a simple inventory: which systems are critical and what would happen if they stopped working for a full day.
Make sure backups actually exist, live outside the primary system and have been genuinely restored at least once.
Review who has access to what and remove access that's no longer needed.
Keep a short document, even a single page, outlining the steps to follow if a key system fails.
Build these questions into every development decision or vendor choice, not only after a problem has already happened.
9/11 taught companies that business continuity can't be improvised on the day you need it. NIS2 turns that lesson into a legal obligation for the software world, with deadlines, fines and direct accountability for the people making the decisions.
The question that really matters isn't whether your company will face an incident. It's whether, when it happens, your software is built to keep running.
Tell us which systems your business depends on and we'll help you build them to withstand it.
It's a system's ability to keep running or recover quickly, when something fails: a server outage, human error, a cyberattack. It matters because it determines whether an incident costs you minutes or weeks.
It's the EU cybersecurity regulation requiring companies in key sectors to implement risk management, business continuity and incident reporting measures. It affects medium and large companies across numerous sectors, not just critical infrastructure.
You may be indirectly affected if you supply a regulated company or directly if you operate in a covered sector above the size thresholds. It's worth checking case by case.
Security aims to prevent an incident from happening. Resilience assumes it will happen and focuses on the business being able to keep running anyway. Both are necessary and complement each other.
Fines can reach €10 million or 2% of annual global turnover, whichever is higher, plus personal liability for management in cases of gross negligence.
Start with the basics done properly: backups that are actually tested, access control, a simple plan for what to do when something fails and an architecture that doesn't depend on a single point of failure.
Our clients' satisfaction is our best introduction.
"Tengo un negocio de Paquetería, en el que vienen muchas personas diariamente, tanto para recoger como para dejar paquetes. Llevábamos años gestionando muchos de nuestros procesos de paquetería de forma manual, y gracias a Blimbur Technologies hemos dado un salto enorme. Nos desarrollaron una app móvil y una web totalmente adaptadas a nuestro flujo de trabajo, con las que ahora tenemos todo automatizado, trazable y mucho más rápido. Ahora, el cliente sabe si tenemos el paquete y al estar todo mucho más organizado, es mucho más rápido y ágil, lo que hace que los clientes vengan y se vayan con otra cara y sin esperas. El trato ha sido impecable y el resultado, todavía mejor. Un equipo serio, técnico y que se implica de verdad."
