Protecting enterprise data during wartime

The full-scale war has forced Ukrainian businesses to rethink the very foundations of information resource management. Systems that were evaluated yesterday based on performance, functionality, and economic efficiency must today primarily ensure business survival. Data preservation, restoration of access to corporate systems, and support for critical processes have become matters of business continuity.

War Has Changed Corporate IT Priorities

On February 24, 2022, Russia launched a full-scale invasion of Ukraine. Combat operations, missile strikes, infrastructure destruction, forced population displacement, and disruption of logistics links presented Ukrainian businesses with threats that traditional disaster recovery plans for information systems did not always anticipate.

Before the invasion, the corporate IT infrastructure of many organizations developed according to fairly predictable scenarios. Companies modernized ERP systems, implemented electronic document management, built corporate data warehouses, automated reporting, and gradually migrated individual services to cloud platforms.

Business continuity planning typically involved server hardware failure, power outage, administration errors, database corruption, or cyberattacks. However, the probability of simultaneous loss of a physical data center, unavailability of an office, staff evacuation, and disruption of several telecommunications operators was often assessed as low. In the context of war, such risks are no longer theoretical.

The situation proved particularly challenging for businesses with centralized information infrastructure. If the ERP server, customer database, electronic document management system, and backups are located in the same premises, damage to this facility can lead to the cessation of most management processes.

The cyber component of the war is added to the physical threats.

On April 12, 2022, a large-scale cyberattack attempt on a Ukrainian energy company using Industroyer2 and destructive CaddyWiper malware became known. According to CERT-UA and ESET researchers, the attackers planned to disrupt the energy infrastructure on April 8, but the implementation of their intent was prevented.

This case demonstrated that a corporate information system can be a target not only for information theft or ransomware. The goal of the attack can be physical disruption of production processes and destruction of the information infrastructure necessary for its recovery. The main question for the IT director is changing accordingly.

If previously it often sounded like ‘How to make the system more efficient?’, then today it is ‘What functions will the enterprise be able to continue to perform if the main site becomes unavailable tomorrow?’

The answer requires not a separate backup server, but comprehensive management of information resilience.

1. Enterprise Critical Systems: What Needs to Be Saved First

The first mistake when organizing disaster recovery is trying to ensure the same level of protection for all information systems.

In practice, an enterprise has limited financial resources, backup site capacity, communication channel bandwidth, and number of specialists.

Therefore, an accelerated Business Impact Analysis (BIA) is necessary – an analysis of the impact of information system unavailability on the organization’s activities.

The key goal of BIA is not to assess the cost of servers. It is necessary to determine which business functions will cease as a result of a specific system failure and how long the enterprise can exist without them.

For a manufacturing enterprise, the production planning system, inventory accounting, and shipment management may prove critical.

For a distributor - ERP, warehouse management system, and order exchange with partners.

For a financial organization - transactional systems, liability accounting, access control, and information resources necessary for regulatory compliance.

Corporate Information System Criticality Matrix

The classification is a conditional example. For a specific enterprise, an analytics system might have a higher priority than CRM if critical operational decisions depend on its results. It is important to distinguish between the criticality of a software product and the criticality of specific data.

For example, an analytical platform can be redeployed. However, if its information content was created over years, and the source data has been partially destroyed, data recovery might be more complex and expensive than recovering the platform itself.

This is precisely why the inventory should cover:

• application systems and their business functions;
• databases, file storage, and information flows;
• dependencies between systems;
• user accounts and authentication mechanisms;
• server configurations and network equipment;
• cryptographic keys, certificates, and licenses;
• backups and recovery mechanisms;
• responsible employees and external vendors.

The absence of any of these components can render a technically preserved system practically unusable.

2. RPO and RTO: How Much Data and Time Can a Company Lose

In disaster recovery planning, there are two fundamental metrics.

Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss, expressed as the time interval between the last usable recovery point and the moment of the incident.

Recovery Time Objective (RTO) defines the target time within which a system must be restored to an agreed-upon level of functionality.

These parameters are not technical specifications of a specific server. They need to be established together with business process owners.

For example, for a company with intensive warehouse operations, losing two hours of ERP transactions might mean the need for manual recovery of hundreds of documents. At the same time, losing two hours of management analytics updates might be acceptable.

Example Target Metrics

These are for illustrative purposes only, not universal standards or guarantees. Their achievability depends on the chosen architecture, funding, and test results.

For correct RTO interpretation, the final recovery state must also be defined.

Is ERP considered recovered if the database server starts? Obviously not.

ERP can only be considered recovered when authorized users can perform defined critical operations and their results are stored correctly.

Similarly, Data Warehouse recovery is not just about successful DBMS startup, but also about the availability of consistent datasets, reports, and update mechanisms.

Recommendations for impact analysis, recovery strategies, and testing of such plans are systematized, in particular, in NIST SP 800-34 Rev. 1, published back in 2010.

3. Backup is not equal to backup infrastructure

It is common practice to back up databases to separate disk storage or NAS.

For typical emergencies, this can be an effective solution. But if the backup device is in the same room as the main servers, it remains in the same physical risk zone.

Even more dangerous is the situation when the backup system uses the same administrative domain as the production infrastructure.

Compromise of a privileged account can give an attacker access to both production systems and their backups simultaneously. Therefore, an enterprise needs to differentiate three concepts:

Backup — saving information for recovery after loss or damage. Replication — transferring changes between system instances to maintain data relevance.

Disaster Recovery — a set of infrastructure, procedures, personnel, and resources necessary for service restoration.

Replication helps reduce RPO but does not replace backups. Accidental deletion of records or data corruption can be quickly propagated to the replica.

Enterprise Data Protection Architecture

• Primary Site
• ERP · CRM · DWH · MDM · ECM
• Operational databases and transaction logs
• Asynchronous Replication
• Backups
• Backup Site
• Separate geographical location
• Backup servers and network services
• Controlled activation
• Isolated archive
• Independent credentials
• Immutable or offline copies
• Versions from different dates
• Copy status monitoring · integrity check · regular recovery tests

Key principle: a backup must survive not only the failure of a single disk or server, but also the loss of the entire primary site.

To achieve this, it is advisable to apply the 3-2-1 rule as a minimum guideline: three copies of data, two types of media or independent storage, and at least one copy offsite.

In conditions of increased cyber threats, it is necessary to additionally provide for an isolated copy that cannot be modified or deleted by regular production accounts.

In this case, geographical separation must correspond to real risks. Placing servers in two buildings of the same industrial complex does not ensure independence from large-scale physical damage.

4. Server Relocation or Cloud Migration

For Ukrainian businesses in March-April 2022, the issue of the physical location of information systems became particularly important. The situation is complicated by the fact that moving server equipment is not always possible.

Servers may be located in a combat zone. Access to the data center may be restricted. Shutting down equipment is not always permitted by the production process, and its transportation carries the risk of damage and data loss.

In such conditions, several alternatives need to be considered.

It is important that cloud migration is not identical to copying a virtual machine. A corporate ERP system may depend on a local domain controller, license server, file resources, integration service, and on-premises hardware. If only the ERP server is migrated, the system might launch but will not perform its functions.

Additionally, it is necessary to assess storage requirements for personal, confidential, and other protected data, provider contract terms, and applicable industry restrictions. In March 2022, the Verkhovna Rada adopted legislative changes aimed at protecting state information resources during martial law, particularly regarding the possibility of using foreign cloud infrastructure for specific state systems and registries. This is an important change in the legal environment, but it should not be interpreted as an automatic cancellation of all data protection requirements.

For a commercial enterprise, the decision to migrate data must consider technical feasibility, security, contractual obligations, and the legal status of the relevant information simultaneously.

5. ERP: Restore Transactions, Not Just the Server

ERP is a complex transactional system where data forms an interconnected structure. An order is linked to a customer, inventory, shipment, invoice, and payment. Restoring only a part of the data can disrupt the integrity of business operations.

Assume a hypothetical manufacturing enterprise uses an ERP system based on Microsoft SQL Server. The last full backup was created at 02:00. The differential backup was at 06:00. Transaction logs were backed up every 15 minutes. At 10:23, the primary server became unavailable.

If the last usable log backup completed at 10:15, the system can potentially be restored to that point, provided there is a complete, unbroken chain of backups and a consistent recovery model. This means that transactions after 10:15 will have to be identified and, if necessary, re-entered.

For an ERP, it is important not only to restore the database but also to perform several checks:

1. Establish the last guaranteed consistent recovery point.
2. Verify the availability of dependent systems and integrations.
3. Prevent simultaneous writes to the primary and backup databases after failover.
4. Restore logs or external message queues.
5. Check for incomplete orders, payments, goods movements, and other critical operations.
6. Confirm system readiness with the responsible business representative.

It is particularly dangerous to re-transmit external messages without verifying their uniqueness.

For example, ERP integration with a banking system or warehouse equipment should include mechanisms to prevent duplicate operations.

In general, a unique message identifier, a log of processed operations, and re-execution control can be used.

Thus, ERP Recovery is the restoration of a consistent state of processes, not just the database.

6. Data Warehouse: preserving the enterprise’s historical memory

A corporate data warehouse has a different nature of risks.

In many enterprises, a Data Warehouse contains information for several years: sales history, material flow, changes in financial indicators, customer base structure, production indicators, and data from external sources.

Some of this data may already be missing from the source operational systems.

For example, ERP stores detailed transactions for the last three years, and older records are moved to an archive. If the archive exists only within the DWH, its loss means the loss of the only available source of historical information.

Therefore, the recovery strategy for an analytical platform must distinguish between three information levels:

The first is primary historical data. These are records that cannot be guaranteed to be re-obtained from operational systems.

The second is the results of integration and transformation. They can be reproduced if the sources, ETL code, transformation rules, and relevant directories are available.

Third are prepared data marts and reports. They can often be regenerated if the preceding layers are preserved.

The most important task is to ensure the preservation of non-reproducible information.

DWH Recovery Priorities

Data Lineage plays an important role here — a description of the origin and transformation of data.

If an enterprise knows where each dataset came from, what rules were applied, and which systems depend on the outcome, recovery becomes much more controlled.

7. ETL After a Disaster: How Not to Corrupt Recovered Data

After restoring the information infrastructure, there is often a temptation to immediately launch all integration processes to eliminate data update delays.

This can be dangerous.

If the ERP is restored to 10:15, and the DWH contains information received at 10:20, a discrepancy already exists between the systems.

If the ETL uses simple incremental loading by timestamp, restarting it may skip some data or create duplicates.

Therefore, before resuming integration, a consistent control point for the source and destination must be determined.

Example of Batch Load Control

A hypothetical Data Warehouse system uses PostgreSQL to store the ETL log.

CREATE TABLE etl_batch_control (
    batch_id BIGSERIAL PRIMARY KEY,
    pipeline_name VARCHAR(100) NOT NULL,
    source_from TIMESTAMP,
    source_to TIMESTAMP,
    started_at TIMESTAMP,
    finished_at TIMESTAMP,
    status VARCHAR(20) NOT NULL,
    source_rows BIGINT,
    loaded_rows BIGINT
);

After an emergency recovery, the operator can determine the last successful batch:

SELECT
    pipeline_name,
    MAX(source_to) AS last_loaded_point
FROM etl_batch_control
WHERE status = 'SUCCESS'
GROUP BY pipeline_name;

However, the result of this query does not always mean that all required records are present.

Additionally, you need to check:

• whether the source state has changed after the restore;
• whether there are gaps between batches;
• whether the log integrity is violated;
• whether all batches with the SUCCESS status were actually recorded in the target DB;
• whether ETL allows operations to be safely retried.

For critical flows, it is desirable to ensure idempotency of loading: re-executing the same batch should not change the final result or create duplicates.

For this purpose, stable business keys, UPSERT operations, control tables, and separate reconciliation procedures can be used.

8. Data Quality: when a restored system does not yet mean restored data

Restoring a database from a backup does not guarantee its business readiness.

The physical integrity of database files and the logical correctness of information are different concepts.

After recovery, situations may arise where:

• the CRM has a client that is missing in the restored ERP;
• the DWH contains sales records that are not present in the current transactional database;
• a portion of the product inventory does not account for the latest shipments;
• one reference data set is restored to an earlier date than another;
• documents are re-imported from an external system;
• records modified during a failure conflict with the state of the backup.

Therefore, after technical recovery, a separate data quality verification process is necessary.

This process is particularly important for MDM.

If the central counterparty reference data is restored to a previous state, operational systems may contain new codes or changed attributes. Simply overwriting one reference data set with another can cause additional problems.

It is more correct to create a controlled reconciliation process:

1. Collect changes from all available systems.
2. Identify identifier conflicts.
3. Compare timestamps and change sources.
4. Apply rules for determining the authoritative source.
5. Escalate ambiguous cases to responsible personnel.
6. Record the results in the recovery log.

Key Quality Indicators After Recovery

The decision to restore normal operation should be based on verifying these characteristics, not solely on the administrator’s notification of a successful DBMS startup.

9. Remote Administration and Access Control

In wartime conditions, enterprise IT specialists can work from different cities and countries.

At the same time, some servers remain in physically inaccessible premises. Therefore, remote administration transforms from a convenience tool into a critical mechanism for maintaining operations.

However, open access to administrative services over the internet creates additional risks.

For critical systems, it is advisable to use a secure VPN, multi-factor authentication, separate administrative accounts, and controlled access nodes.

The principle of least privilege and the separation of administrative functions are of particular importance.

An employee responsible for running ETL processes should not necessarily have the right to delete ERP backups.

And a production environment administrator should not automatically receive full access to an isolated backup archive.

A scenario for losing authentication methods must also be foreseen. If the only hardware token or phone with a second factor remains in an inaccessible office, the company may lose the ability to manage its own infrastructure.

Thus, an emergency access procedure must be prepared in advance, protected from abuse, and regularly tested.

10. Scenario: Restoring the Information System of a Distribution Company

Let’s consider a hypothetical Ukrainian enterprise with a central office, three regional warehouses, and approximately 400 corporate system users.

Key information resources:

• ERP on Microsoft SQL Server;
• CRM integrated with ERP;
• electronic document management system;
• corporate data warehouse;
• ETL processes for consolidating sales and inventory balances;
• centralized authentication services.

The main server site is located in a city that is under threat of hostilities.

The enterprise has backups, but most of them are stored locally.

Stage 1. Defining minimally required functions

Management agrees on the list of operations without which the company cannot operate:

• order acceptance;
• inventory check;
• goods shipment;
• primary document processing;
• payment accounting.

Analytical reports and complex planning procedures are temporarily moved to the second recovery phase.

Phase 2. Creation of an independent backup environment

A virtual infrastructure sufficient for critical services is deployed at a remote site.

The company transfers backup copies of databases, application configurations, and necessary authentication tools there.

A separate copy of the information is stored independently of the main administrative accounts.

Phase 3. Operating system recovery

The minimal user identification infrastructure is launched first.

After that, the ERP and main integrations are restored.

User access may be restricted until checks are completed to prevent the emergence of new uncoordinated transactions.

Stage 4. Resuming Document Flow and CRM

Systems are connected to the new ERP. Before resuming automatic exchange, the document log is checked for any documents that may have been created after the last backup point.

Resubmission is performed only after verifying the identifiers and status of operations.

Stage 5. Restoring DWH and Reporting

After stabilizing the operational systems, the status of the corporate data warehouse is checked.

Historical information is preserved, and updates for the downtime period are performed in controlled batches.

Business gains access to critical analytical reports after reconciling key performance indicators with the ERP.

In this scenario, the greatest effect is achieved not by the power of backup servers, but by the presence of a coordinated sequence of actions.

11. Roadmap for the First 30 Days

Under limited resources, it is advisable to divide the work into short stages.

This is an approximate sequence for an enterprise with sufficient access to its systems. In case of physical danger, the safety of employees’ lives absolutely takes priority over the relocation of equipment.

If the primary site is already lost, the plan should start with an inventory of available backups, credentials, and independent information sources.

12. KPI: How to measure enterprise recovery readiness

Indicators should assess the actual recoverability of information services.

The targets provided are design guidelines, not universal industry standards.

It is also important to assess the incident detection time, the ability to contact responsible persons, and the availability of up-to-date documentation.

If an organization has a backup but lacks a specialist capable of restoring it, or if necessary passwords are unavailable, a formally high backup success rate will not ensure business resilience.

13. Risks and Common Mistakes

The most common mistake is to perceive disaster recovery as solely an infrastructure project.

Purchasing backup servers does not solve the problem if it is unknown in what sequence business processes should be restored.

The second mistake is relying on replication as the sole means of information preservation. A replica automatically inherits some logical corruption from the primary system.

The third is the lack of backup verification. The fact that a backup task completed successfully does not guarantee recoverability.

The fourth is ignoring inter-system dependencies. An ERP might function but remain inaccessible due to the absence of a domain controller or license server.

The fifth is restoring data without reconciliation. Such a system may generate documents and reports with erroneous balances or financial indicators.

The sixth is insufficient protection of administrative access. During active cyberattacks, remote administration must be accompanied by enhanced control over authentication, privileges, and logging.

And finally, it is dangerous to build a plan on the assumption that the enterprise will be able to physically return to the primary data center within a few days.

The architecture must provide for the long-term operation of the backup environment.

14. Intecracy Group Competencies

Ensuring the continuity of corporate information systems requires a combination of several technological disciplines: data management, system integration, server infrastructure, and cloud technologies.

Within Intecracy Group, these areas are represented by the specializations of individual companies.

Data Management IG (dmig.com.ua) operates in the domain of corporate data management: ETL, Data Warehouse, MDM, Data Quality, Data Governance, and corporate analytics. In disaster recovery tasks, the definition of critical information resources, recovery of integration flows, data quality verification, and ensuring consistency between sources are particularly important.

IQusion IT (iqusion.com) specializes in system integration, electronic document management, and business process automation. These competencies can be useful during the recovery of processes that span multiple information systems, as well as in building temporary approval and document processing workflows.

Softline IT (softline.kiev.ua) represents the infrastructure domain: server systems, network equipment, storage systems, and other corporate IT infrastructure components. For the implementation of a recovery plan, proper design of backup computing resources, network connectivity, and storage systems are important.

SL Global Service (sgs4business.com) specializes in cloud integration, virtualization, and hybrid infrastructure. Relevant technologies allow for considering backup system placement, creating isolated environments, and migrating part of the workloads beyond the main site.

The combination of these specializations illustrates a comprehensive approach: from the physical availability of computing resources to the logical integrity of business data.

At the same time, each enterprise requires an individual plan that considers its systems, risks, budget, and priorities.

Information resilience becomes a condition for business preservation

The full-scale war has forced Ukrainian enterprises to rethink the role of corporate information infrastructure.

ERP, CRM, Data Warehouse, MDM, and electronic document management systems are not just a set of software products. They provide the connection between financial operations, production, suppliers, employees, and customers.

The loss of such infrastructure can halt an enterprise even when the production equipment is physically preserved.

However, the mere existence of a backup does not guarantee the ability to resume operations.

The enterprise needs to understand which data is irreproducible, which systems should be launched first, which business operations need to be reconciled after recovery, and who is authorized to make decisions in a crisis situation.

It is especially important to maintain the independence of backup resources. Data, equipment, administrative accounts, and access channels should not have a single point of failure.

For data management systems, the ability to restore not only files and databases but also integration logic is of additional importance: transformation rules, reference data, update history, checkpoints, and quality assurance mechanisms.

The recovery of corporate systems is not completed when the server is launched, but when the enterprise can again safely and controllably perform its critical functions.

The main conclusion of April 2022 is that business continuity can no longer be considered a secondary IT project. It is becoming part of the enterprise’s survival strategy.

Ukrainian companies that continue to operate need to form an architecture today that can withstand the physical loss of an individual site, prolonged unavailability of personnel, and targeted cyberattacks.

And the main resource of such an architecture remains not servers, but reliable, secure, and recoverable corporate data.