The real test of cybersecurity is not whether an incident happens, but whether critical operations can continue and systems can be restored in a known, tested sequence.
Recent cyberattacks (see, in August 2026, the case of California's Suisun City Hall or Romania's Land Registry) show that organizations only discover their true recovery capabilities, or lack thereof, when operations grind to a halt.
You might have your data perfectly intact and safely stored off-site. However, if it takes weeks to rebuild the environment, verify dependencies, and safely restore workflows without re-infecting the network, your business remains paralyzed. This harsh reality confirms a fundamental rule in cybersecurity: Backup ≠ Continuity.
Why cyber resilience? If we had a major incident tomorrow, which activities would continue, who is responsible, and how long would it take to return to normal operation on clean systems?
An organization can have its data, even multiple copies of it (e.g., the 3-2-1 principle). But without prior planning, it can take weeks to rebuild applications, identities, integrations, and workflows, as seen in recent public cases. A cyber resilience program defines the order of steps and the acceptable timeframes, and tests them.
In this article we illustrate a resilience program, structured for clarity into six phases carried out over approximately 12 weeks. Our analysis draws on principles from the risk frameworks and applicable regulations used by OPTI (in short: NIST, CIS Controls, ISO 27001, ISO 22301 and ISO/IEC 27031, GDPR, and NIS2 - where applicable). The concrete implementation varies case by case.
What Are the Six Proposed Phases?
| Phase | Weeks |
|---|---|
| 0. Stabilization + Responsibilities | first 2-3 days |
| 1. Inventory + Business Impact Analysis | weeks 1-2 |
| 2. Reducing the Attack Surface (Hardening) | weeks 2-6 |
| 3. Restore + Continuity | weeks 3-8 |
| 4. Incident Response + Training | weeks 6-10 |
| 5. Recurring Operations | weeks 10-12 |
Phases partially overlap, to maintain the implementation team's pace and save time. For example, fixing obviously vulnerable accounts (part of hardening) can begin before the full inventory is complete.
Phase 0: Stabilization and Responsibilities
In the first 2-3 days, the objective is to avoid organizational chaos in case a serious incident were to occur "tomorrow morning." All other phases build on the organization's fundamental responsibilities, before any audit, tools, or technologies.
First, establish the emergency team: management, IT, legal (including the DPO), a communications lead, and all technical vendors who would be involved in a potential attack. For critical roles, backups should also be defined (who takes over responsibility in case of temporary unavailability).
Verify:
- the accessibility of backups, including a copy outside the current IT infrastructure.
- essential administrative access
- the existence of break-glass accounts (emergency administrative access)
- the existence of an alternative communication channel separate from the organization's infrastructure (e.g., not depending on official e-mail to coordinate).
NIST CSF 2.0 states the principle:
"Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced." (GV.RR-02)
A useful deliverable is a one-page physical sheet: "The First 60 Minutes in Case of an Attack".
In a simplified version:
| 0-15 minutes | 15-30 minutes | 30-60 minutes |
|---|---|---|
| Isolate the affected system Do not delete or reinstall without instructions from the technical team Note the time and symptoms, create evidence (e.g., a photo) Activate the incident owner | Determine severity Identify suspicious systems and identities Protect the backups Open the incident log | Separate clean systems from compromised ones Preserve IT logs Assess the impact on data Establish the recovery point before any restore. |
The exact actions depend on the type of incident. What matters is that the actions are decided and disseminated across the organization before the incident, not improvised under pressure.
Phase 0 Result: The organization knows who decides and what responsibilities apply in the first minutes of an incident.
Phase 1: Inventory and Dependencies (Business Impact Analysis)
In weeks 1-2, the organization must understand its own process architecture and IT infrastructure.
The inventory must include, at minimum, endpoints, servers, cloud applications, networks, special equipment, privileged accounts, keys, vendors, APIs, and external integrations.
A purely technical inventory is not enough. A server can be critical if an important organizational process depends on it, regardless of its specifications or cost.
Business Impact Analysis (BIA) is defined by ISO 22301 as:
"process of analysing the impact over time of a disruption on the organization." (3.5)
For each critical process, at least four elements must be established:
- RTO: how quickly the service must be restored
- RPO: how much information the organization can afford to lose
- Workaround: how to temporarily continue operations
- Restoration order: which system must be started before another.
Management will answer questions that are not, in fact, IT questions: What can be missing for four hours? What can be missing for a day? What can never be missing?
Surprises usually show up here too: single points of failure you wouldn't have suspected are discovered — a program written 30 years ago that's needed to close the daily accounting, a laptop used as a server, an external service the organization depends on.
Phase 1 Result: The organization has an inventory, plus a map of the flows between processes, technology, and employees, plus the acceptable downtime intervals.
Responsibility is shared in the cloud.
A common mistake in the inventory and hardening phases is the false sense of security given by the cloud. Whether you use SaaS applications or have data in serverless architectures, the same basic rule applies: the Shared Responsibility Model.
Responsibility is shared — for example, the provider secures the infrastructure (the data center, the physical network), but you are responsible for the security of the data, identities, and client-side configurations. The boundary differs depending on the service used (e.g., IaaS vs. SaaS); in Google Cloud, this collaboration is also called Shared Fate.
A trivial scenario: an employee opens a malware attachment. The ransomware encrypts local files, and the cloud client automatically syncs the encrypted or modified files, which can affect the entire team, including the ability to restore.
If the organization uses the Google ecosystem, native security tools must be activated and configured: - For documents and identity (Workspace): Implement Context-Aware Access policies. You can condition access to Google Drive or e-mail on the security of the endpoint used. - For serverless/cloud infrastructure: Google Cloud Security Command Center (SCC) provides centralized visibility, detecting misconfigurations and vulnerabilities before they are exploited.
OPTI implements turnkey Google Cloud solutions or extends your team
Phase 2: Reducing the Attack Surface (Hardening)
In weeks 2-6, we can take the technical measures required following the inventory and BIA.
In most organizations, real progress comes from consistently executing the basic controls:
- named accounts
- least-privilege access
- MFA
- separate administration of privileged accounts
- centralized patching and EDR
- endpoint encryption and network segmentation
CIS Controls v8.1 recommends:
"Establish and maintain a documented secure configuration process for enterprise assets … and software." (Safeguard 4.1)
Web exposure checks are added: APIs, access tokens for IT resources, DNS records for domains and e-mail (e.g., SPF, DKIM, and DMARC), as well as inventorying software components that have reached end-of-life or are known to have vulnerabilities (e.g., WordPress plugins still present on institutional websites).
For Windows workstations, a reasonable protection baseline includes: Windows still under support, a local software inventory, a patching tool with an SLA for critical vulnerabilities, EDR with isolation capability, disk encryption, and separating the standard account for daily work from the administrative account on the workstation.
Detection and monitoring are done continuously through EDR. The concrete deliverables of the IT department will include: critical log sources and indicators of compromise, triage manager with associated SLA, retention rules, escalation flows and procedures for isolating compromised endpoints. After these stages, the Incident Response process is triggered.
Network segmentation adds protection: A compromised workstation should not be able to freely communicate with servers, special devices, printers, and all other endpoints.
A SIEM (Security Information and Event Management) can bring visibility, without compensating for unmanaged endpoints, forgotten privileged access, or restore points that haven't been tested (see below).
A pragmatic hardening order (which may vary depending on methodology):
inventory ▷ patching ▷ EDR ▷ segmentation ▷ recurring scanning ▷ SIEM
Phase 2 Result: The organization's attack surface has decreased, and the IT department has a repeatable control and remediation process for similar resources.
Phase 3: Restore and Continuity Tested End-to-End
In weeks 3-8, the difference emerges between a resilience program on paper and an effective, demonstrable one. What must be demonstrated is that systems can be restored within the timeframes (RTO / RPO) defined by management in Phase 1.
GDPR requires periodic testing of the effectiveness of technical and organizational measures, together with:
"the ability to restore the availability and access to personal data in a timely manner." (art. 32)
Restore exercises can follow this path:
The path of a restore exercise
Last clean copy (backup)
│
▼
Placement in an isolated environment (clean room)
│
▼
Restarting technical services (DB, storage, DNS, certificates)
│
▼
Restarting integrations (API, e-mail, identity, external services)
│
▼
Business validation (operational workflow tests)
│
▼
Documentation (for repeatability) 
A documented test example
Restore start: 09:00 Service functional: 13:20 RTO achieved: 4h20 RPO achieved: 6h Business validation: successful / unsuccessful Issues found: LIST
The business validation step is essential — a normal user of the organization must be able to execute the process the system exists for (e.g., issuing an invoice or responding to customers). It is not enough for the server to start and the database to respond in order to have organizational continuity.
Phase 3 Result: The organization can demonstrate that services can be rebuilt and knows the actual recovery time.
Phase 4: Incident Response and Training (Tabletop Exercises)
In weeks 6-10, measures focus on the human factors. A major attack affects all departments:
- Management determines severity and makes risk decisions
- The technical team isolates, investigates, and restores
- Legal and the DPO assess legal implications / implications for personal data
- Communications prepares internal and external messages
- Critical vendors are included in the escalation procedure
NIS2 explicitly includes, among the cyber risk management measures:
"incident handling" and "business continuity, such as backup management and disaster recovery, and crisis management" (Art. 21(2)(b)–(c))
In this phase, playbooks are prepared per attack type: ransomware, compromise of an e-mail account, theft of a laptop, unavailability of a critical service, or compromise of a privileged account, and staff training takes place, followed by tabletop exercises.
How is a tabletop exercise organized?
In a tabletop, IT systems generally don't need to be shut down. The team receives the scenario in stages: "At 08:35, two workstations can no longer access the file share." "At 08:50, a ransomware note appears." … Open discussion follows: Who declares the incident, who isolates the network? Can we talk to each other if e-mail is compromised? Who calls the vendor? What information must we preserve for the investigation?
Training and tabletop exercises reveal problems that a documentary audit can miss. For example, a missing phone number or access known to only one person in the organization.
Phase 4 Result: Staff know what to do in different scenarios, reducing the risk of chaos.
Phase 5: Resilience Becomes a Permanent Process
In weeks 10-12, the resilience file is completed, but more importantly, long-term operational discipline is defined through a calendar of recurring activities carried out by the organization.
ISO/IEC 27031:2025 affirms the role of ICT services in supporting business continuity, and links to ISO/IEC 27001 and ISO 22301:
"… information and communication technology (ICT) is prepared to support business continuity. It outlines a framework for ICT readiness that aligns with broader business continuity objectives …" (ISO/IEC 27031:2025)
A permanent calendar might look like this, simplified for a mid-sized organization:
| Interval | Tasks | Owner and Controls |
|---|---|---|
| Monthly | patching, EDR, backup, and alerts | Name, date, document |
| Quarterly | access recertification, restore test, partial BIA review | Name, date, document |
| Semi-annual | tabletop, technical exercise, and continuity plan update | Name, date, document |
| Annual | full BIA, architecture, vendors, budget, and investment priorities | Name, date, document |
An option in this phase is involving an external audit or certification authority to align procedures with one or more standards. First, the organization spends 12 weeks preparing, then it is ready to be verified transparently.
Phase 5 Result: Every cyber resilience activity has an owner, a frequency, controls, and proof of execution.
What Should Concretely Exist After 12 Weeks?
At the end of the program, there should be a usable set of documents and evidence:
- Executive report with risks prioritized by management
- Asset register and BIA with RTO/RPO
- Risk register with owner, deadline, and residual risk
- Business continuity and disaster recovery plan
- Playbooks for the most important incident types
- Minutes of actual restore tests
- A baseline/checklist for endpoints and network
- Incident response exercise report
- Technical and budget roadmap for the next 12 months
Contracting an external audit or certification is a plus for the organization.
What did the organization gain?
The organization's resilience program went far beyond the idea of backup. While it is not a guarantee against attacks, it allowed the organization to know its risks and defense methods and to react in a planned way on an already tested basis.
Recent press incidents have shown the difference between the existence of information and the availability of the service (Backup ≠ Continuity). The same is true for a 30-employee company, a hospital, a factory, or a business that depends on an ERP/CRM and a few cloud applications.
OPTI Software is ISO 27001 certified and has operated software systems and IT infrastructure for organizations in Romania and abroad for over 20 years.
Sources and Standards
- NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond, Recover
- CIS Critical Security Controls v8.1
- ISO 22301:2019: Business Continuity Management Systems
- ISO/IEC 27031:2025: ICT Readiness for Business Continuity
- Regulation (EU) 2016/679: GDPR, Article 32.
- Directive (EU) 2022/2555 (NIS2)
