Secure Operations, Monitoring and Incident Response

Introduction

Blockchain systems are often described as trust-minimising technologies, but they do not eliminate the need for operational security. A consensus protocol may protect agreement about transactions while leaving nodes, wallets, cloud accounts, APIs, monitoring systems and administrators exposed. A stolen validator key, an unpatched RPC service, a compromised build pipeline or an unavailable archive node can cause financial loss and operational failure even when the underlying cryptographic algorithms remain sound.

Secure operations therefore connects technical controls with procedures, people and governance. It covers node hardening, secure patching, secrets management, logging, monitoring, vulnerability management, incident response, disaster recovery, business continuity and forensic evidence preservation. These activities are particularly important in blockchain environments because transactions may be irreversible, evidence is distributed across several systems, and attacks can combine on-chain and off-chain techniques.

This chapter presents a practical security operating model suitable for blockchain nodes, validators, exchanges, custodial services, decentralised applications and enterprise blockchain networks.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Harden blockchain nodes and supporting infrastructure using least privilege and secure configuration principles.
2. Design practical patching, secrets-management and vulnerability-management processes.
3. Explain the role of structured logging, monitoring and security analytics.
4. Interpret indicators of compromise and distinguish meaningful alerts from operational noise.
5. Develop incident-response, disaster-recovery and business-continuity procedures.
6. Preserve blockchain and system evidence in a manner that supports investigation and legal scrutiny.
7. Evaluate governance, ethical and regulatory responsibilities associated with crypto-security operations.

1. The Operational Security Model

Operational security is the continuous process of reducing the likelihood and impact of security events. It is broader than perimeter defence. A useful model considers five interacting layers:

Security should be designed as defence in depth. For example, a validator signing key should not be protected by only a password. Access should also be limited by network policy, administrative role, hardware-backed protection, transaction controls, alerting and an emergency key-rotation process.

A security programme commonly uses the cycle: identify assets and risks; protect systems; detect abnormal activity; respond to incidents; recover services; and improve controls using lessons learned. This resembles established risk-management and incident-response frameworks, including the NIST Cybersecurity Framework and NIST incident-response guidance, but the controls must be adapted to the specific blockchain protocol and legal environment.

Assets and threat surfaces

Important assets include private keys, seed phrases, validator identities, node databases, cloud credentials, signing policies, transaction records, logs, source code, customer balances and recovery backups. Threats include:

• malware and ransomware on administration systems;
• theft or misuse of private keys;
• exploitation of vulnerable node clients or web applications;
• denial-of-service attacks against RPC, peer or validator services;
• eclipse attacks that isolate a node from honest peers;
• supply-chain compromise in software dependencies or container images;
• insider abuse or collusion;
• accidental deletion, corruption or misconfiguration; and
• fraud using social engineering or compromised governance credentials.

Risk is not determined only by technical exploitability. A low-probability event involving a hot wallet or validator key may deserve higher priority than a high-volume but low-impact scanning event.

2. Node Hardening

Node hardening is the deliberate reduction of unnecessary functionality, exposure and privilege. It begins with a documented baseline that records the operating system, client version, enabled services, network ports, identities, storage locations, administrators and configuration changes.

Operating-system and host controls

A hardened host should use a supported operating system with security updates enabled, secure time synchronisation, host-based firewall rules and centralised identity management. Administrative access should use individual accounts and phishing-resistant multi-factor authentication where possible. Direct remote root login should be disabled; privileged work should be performed through controlled elevation such as sudo, with commands logged.

Unused packages, compilers, services and default accounts should be removed. Disk encryption protects data at rest, although it does not protect a running system whose keys are already available. Endpoint detection, file-integrity monitoring and resource monitoring can identify unauthorised changes or abnormal processes.

Network and service controls

Only required ports should be exposed. Peer-to-peer traffic, administrative access, RPC and metrics should be separated through firewall zones or separate networks. Public RPC endpoints should not provide administrative methods, wallet operations or unrestricted debugging interfaces. A reverse proxy or API gateway can provide authentication, rate limiting, request filtering and audit logging.

Validators and other consensus-critical nodes should be isolated from general application servers. Management traffic should use a restricted administrative network or private access mechanism. Network segmentation reduces the consequences of compromise but does not replace authentication and authorisation.

Blockchain-client controls

The client software should be obtained from trusted sources, with release signatures or checksums verified where available. Configuration should disable unnecessary APIs and debugging methods. Peer discovery should be controlled according to the protocol’s security model, and operators should monitor peer diversity, block height, finality or confirmation status, synchronisation lag and rejected messages.

A node should not be assumed healthy merely because its process is running. A process may be alive while it is stalled, isolated, following an incorrect chain, unable to write to storage or unable to communicate with the signing service.

Validator and signing-key protection

Consensus keys require special treatment. A validator should use a remote signer, hardware security module or other control that keeps the private key separate from the general-purpose node where the protocol supports it. Signing policies must prevent unauthorised duplicate signing, because some protocols penalise equivocation or double signing.

Access to signing operations should be separated into roles such as node operator, key custodian and transaction approver. Emergency procedures should define how a key is paused, rotated or revoked without creating a second operational failure.

3. Patching and Change Management

Patching reduces exposure to known vulnerabilities, but an uncontrolled update can interrupt consensus or introduce incompatible behaviour. A mature process therefore combines urgency with testing and rollback planning.

A practical patch workflow is:

1. Discover: maintain an inventory of nodes, clients, operating systems, dependencies and versions.
2. Assess: determine whether a vulnerability affects the deployed configuration and estimate exploitability and impact.
3. Prioritise: give immediate attention to actively exploited vulnerabilities, exposed management interfaces and vulnerabilities affecting keys or consensus.
4. Test: reproduce the deployment in a staging or test network and verify synchronisation, APIs, signing behaviour and performance.
5. Approve: record the change, responsible personnel, maintenance window and rollback condition.
6. Deploy progressively: update a canary or non-critical node before broader deployment, while respecting protocol upgrade requirements.
7. Verify: check version, service health, chain state, peer connectivity, logs and security controls.
8. Close and learn: update records and document unexpected effects.

A protocol-level upgrade may require coordinated activation at a particular block height or epoch. Operators must distinguish an ordinary security patch from a consensus-affecting upgrade. Running incompatible versions can cause service disruption or chain divergence.

A service-level objective may specify a maximum patch age, but no single age is universally correct. Internet-facing infrastructure and actively exploited vulnerabilities normally require shorter timelines than isolated test systems. Exceptions should be documented, risk-accepted by an authorised person and accompanied by compensating controls.

4. Secrets Management

Secrets include private keys, seed phrases, API tokens, database passwords, cloud credentials, encryption keys and signing certificates. They must not be placed in source code, public repositories, chat messages, unencrypted configuration files or ordinary issue tickets.

A secrets-management design should provide:

• central storage with encryption at rest and in transit;
• strict identity-based access control;
• short-lived credentials where feasible;
• automated rotation and revocation;
• separation between development, testing and production secrets;
• access logging and review; and
• secure backup and recovery procedures.

Key management must distinguish confidentiality from availability. A key that is perfectly secret but irretrievably lost is also an operational failure. Backups should be encrypted, geographically or logically separated, tested through restoration exercises and subject to dual control for highly valuable assets.

Secret exposure requires more than deleting the visible file. Operators should revoke or rotate the credential, investigate access logs, identify copies in backups and CI/CD systems, and determine whether fraudulent transactions occurred. For blockchain keys, the response may require moving assets to a controlled address or replacing a validator identity according to protocol rules.

5. Logging, Monitoring and Security Analytics

Logging records events; monitoring evaluates system condition; security analytics interprets events to identify threats or policy violations. These functions are related but not identical.

What to log

Useful records include:

• administrator authentication, privilege elevation and configuration changes;
• node start, stop, crash, upgrade and rollback events;
• peer connections, disconnections and unusual peer changes;
• block height, finality, synchronisation lag and consensus errors;
• RPC requests, authentication failures and rate-limit events;
• wallet, signing and transaction-approval actions;
• changes to firewall, cloud IAM, DNS and deployment pipelines;
• operating-system, container and application security events; and
• backup creation, restoration and deletion.

Logs should be structured, timestamped in a consistent time standard, attributable to an identity and protected against unauthorised alteration. Central collection is preferable because an attacker who compromises a node may alter local logs. Write-once or immutable storage, access control and retention policies improve evidential value.

Logs must avoid unnecessary exposure of personal data, seed phrases, private keys and sensitive customer information. Redaction should occur before central storage, not only when reports are produced.

Monitoring indicators

Important operational metrics include node availability, CPU, memory, disk capacity, database growth, peer count, block-processing delay, RPC latency, rejected requests, error rates and signing activity. Security indicators include impossible travel in administrator logins, repeated authentication failures, new privileged accounts, unexpected binaries, unusual outbound connections, changes to validator configuration and transactions inconsistent with approved policy.

A useful measure of synchronisation lag is:

where L is lag measured in blocks, H_network is the trusted network height and H_node is the local node height. The expression is meaningful only when both heights refer to the same network and comparable chain state. A large or continuously increasing L may indicate resource exhaustion, peer failure, storage problems or a consensus issue; it is not by itself proof of compromise.

Alert quality matters. Excessive false positives create alert fatigue, while thresholds that are too permissive delay detection. Each alert should identify an owner, severity, evidence source, expected response and escalation path. Detection rules should be tested using simulations or controlled exercises.

Security analytics and indicators of compromise

An indicator of compromise (IoC) is an observable artefact associated with malicious activity, such as a file hash, domain, IP address, unusual process, suspicious account or unauthorised transaction. Indicators of attack (IoAs) focus more on behaviour, such as repeated privilege escalation or attempted key export.

On-chain analytics can identify unusual transaction velocity, new counterparties, peeling patterns, rapid movement through intermediaries, interaction with known high-risk services or transactions outside an approved business purpose. On-chain evidence should be correlated with off-chain evidence. An unusual transfer may be a legitimate treasury operation, a test transaction or fraud; context and authorisation records are essential.

6. Vulnerability Management

Vulnerability management is a continuing process rather than a one-time scan. It includes asset discovery, scanning, validation, prioritisation, remediation, verification and reporting.

A vulnerability’s severity should be assessed using technical factors such as exposure, required privileges, exploit availability and potential impact, together with business context. A vulnerability in an isolated development node may be less urgent than a moderate vulnerability in a public RPC gateway connected to a production wallet.

The process should cover:

• operating systems and node clients;
• smart contracts and application dependencies;
• container images and infrastructure-as-code;
• cloud identity and storage configuration;
• exposed services and APIs; and
• third-party suppliers and managed infrastructure.

Automated tools are valuable but imperfect. Scanners produce false positives and may miss logic flaws, key-management errors, chain-specific risks and novel attacks. High-value smart contracts require independent review, testing and, where appropriate, formal verification. Remediation must be tracked to closure, not merely recorded as a scan result.

7. Incident Response

Incident response is an organised method for limiting harm and restoring trustworthy operation. A useful lifecycle is preparation; detection and analysis; containment; eradication; recovery; and lessons learned.

Preparation

Preparation includes an incident-response plan, contact lists, authority definitions, communication channels, forensic tooling, backups, tabletop exercises and relationships with legal counsel, regulators, exchanges, cloud providers and law enforcement. Plans should cover loss of keys, malicious transactions, ransomware, node compromise, cloud-account takeover, data breach, consensus disruption and prolonged service outage.

Detection and analysis

The response team should first establish what happened, when it began, which assets are affected and whether the event is continuing. Analysts should preserve volatile evidence before shutting down systems when safe to do so. They should distinguish facts from hypotheses and record decisions with timestamps.

Severity can be based on factors such as financial exposure, customer impact, compromise of signing authority, effect on consensus, regulatory obligations and duration. The first report should be concise and evidence-based rather than speculative.

Containment

Containment may involve isolating a host, disabling a compromised account, blocking malicious infrastructure, pausing withdrawals, restricting RPC access or moving assets under an approved emergency procedure. Blockchain containment is difficult because confirmed transactions may be irreversible. A rapid decision matrix should identify who can pause services and under what conditions.

Containment must avoid destroying evidence or creating a second incident. For example, wiping a compromised node before collecting logs may prevent attribution. If a validator is isolated, operators must consider protocol-specific penalties and coordinate replacement or failover correctly.

Eradication and recovery

Eradication removes malicious persistence, rotates exposed secrets, rebuilds systems from trusted images and closes the exploited weakness. Recovery restores services in a controlled sequence and verifies chain state, configuration, key integrity, balances, permissions and monitoring. Systems should not be declared recovered merely because they respond to a health check.

Lessons learned

A post-incident review should examine technical, human and governance causes without unfairly blaming individuals. It should identify control failures, detection delays, communication problems and improvements with named owners and deadlines. Incident metrics may include mean time to detect (MTTD) and mean time to recover (MTTR). These are management indicators, not complete measures of security quality.

8. Disaster Recovery and Business Continuity

Disaster recovery (DR) restores technology after disruption. Business continuity (BC) maintains critical organisational functions, possibly through alternative processes. Both are needed because a node can be restored while customer service, compliance or treasury operations remain unavailable.

Two important planning measures are:

RTO is a time duration, such as two hours. RPO is also a time duration, such as fifteen minutes, representing how far the organisation may have to recover before the disruption. These are service objectives, not guarantees, and must be defined for each critical process.

For blockchain systems, conventional data-loss assumptions require care. A node can often rebuild state from the network, but local indexes, transaction records, configuration, audit logs and wallet metadata may not be reconstructible. Validator keys and signing policies may be more important than the node database itself.

A DR plan should define primary and secondary sites, backup frequency, immutable backup storage, key recovery, dependency order, responsible roles, communication procedures and restoration tests. Recovery exercises should test realistic failures, including unavailable cloud regions, corrupted databases, lost credentials and compromised backups.

Business continuity may use a read-only service, manual transaction approvals, alternate custody arrangements, a standby RPC provider or a pre-approved withdrawal freeze. The objective is not always to keep every feature operating; it is to preserve essential and trustworthy functions.

9. Evidence Preservation and Blockchain Forensics

Blockchain forensics combines ledger analysis with traditional digital forensics. Relevant evidence may include transaction identifiers, block numbers, addresses, contract events, node logs, cloud audit records, firewall logs, authentication records, memory captures, disk images, chat messages, approval records and exchange correspondence.

Evidence handling should preserve:

1. Integrity: calculate cryptographic hashes of acquired files and record the algorithm, acquisition time and tool used.
2. Provenance: document who collected, transferred, examined and stored each item.
3. Time context: record time zones, clock sources and known clock drift.
4. Repeatability: preserve commands, queries, software versions and analytical assumptions.
5. Minimal alteration: acquire forensic copies and work from copies rather than originals.
6. Legal compliance: follow applicable privacy, employment, financial and evidential requirements.

A transaction hash proves that a particular transaction identifier refers to ledger data under the relevant chain state; it does not by itself prove who controlled an address or why a transaction occurred. Attribution requires corroborating evidence such as exchange records, custody information, access logs, communications or validated investigative intelligence.

Chain reorganisations and different node views must also be considered. Investigators should record the network, block height, confirmation status, node source and retrieval time. Address labels from public sources should be treated as hypotheses, not facts.

10. Illustrative Case: Compromised RPC and Treasury Wallet

Background

A fictional digital-asset firm operates validator nodes and a treasury wallet. Its public RPC gateway was placed on the same cloud network as an administrative service. The gateway used a vulnerable dependency and accepted excessive requests. The treasury service held a token that could be transferred through an automated signing account.

Problem

Monitoring detected a sudden increase in RPC errors and an administrator login from an unfamiliar location. Minutes later, several transfers moved treasury assets to newly created addresses. The node process was still running, so an initial dashboard showed no complete outage.

Analysis

The response team compared cloud audit logs, RPC access logs, transaction records, deployment history and identity-provider events. They found that the attacker exploited the gateway, obtained a service credential from an exposed configuration variable and invoked a treasury API. The blockchain transactions were confirmed, but approval records showed no authorised request.

Approach and solution

The firm restricted the RPC gateway, disabled the compromised service account, paused automated treasury transfers and preserved cloud and node evidence. Investigators captured relevant logs, calculated hashes and recorded the chain height and transaction identifiers. The gateway and treasury service were rebuilt from trusted images. All related credentials were rotated, and the wallet policy was changed to require independent approval and a hardware-backed signing process.

The company notified affected stakeholders according to its legal and contractual obligations. It also separated public RPC infrastructure from treasury systems, introduced short-lived credentials, added alerts for unusual signing activity and conducted a restoration exercise.

Outcome and learning points

The firm could not reverse confirmed blockchain transfers, but rapid containment prevented further loss. The key lessons were that process health is not service trustworthiness; network segmentation limits blast radius; secrets in deployment configuration require protection; and on-chain events must be correlated with identity and approval evidence. The incident also demonstrated why evidence preservation must begin before destructive remediation.

11. Governance, Ethics and Contemporary Practice

Security operations involve significant authority. Administrators may access customer data, freeze transfers, inspect communications or label addresses as suspicious. These powers require least privilege, documented approval, segregation of duties, privacy protection and independent review.

Organisations should comply with applicable financial-crime controls, data-protection law, breach-notification requirements, electronic-evidence rules and sector-specific regulation. Legal duties vary by jurisdiction; technical teams should not assume that a blockchain’s public nature removes privacy obligations.

Artificial intelligence can assist with log correlation, anomaly detection, alert summarisation and code review. However, AI systems may generate false explanations, expose sensitive logs, inherit biased labels or fail to recognise protocol-specific behaviour. Human analysts must validate high-impact conclusions, especially those involving account freezes, attribution or regulatory reporting. Training data, prompts and model outputs may themselves become sensitive evidence.

Contemporary operations increasingly use infrastructure as code, software bills of materials, signed builds, confidential computing, hardware-backed keys, continuous control monitoring and automated policy enforcement. Automation should be fail-safe: an automated response that pauses every unusual transaction may create unacceptable business harm, while one that automatically transfers assets may amplify compromise.

Best-Practice Checklist

• Maintain a complete and current asset inventory.
• Separate public RPC, administration, application and signing networks.
• Use individual accounts, strong authentication and least privilege.
• Protect keys with hardware-backed or remote-signing controls where appropriate.
• Patch according to exposure and exploitability, with testing and rollback plans.
• Centralise, protect and retain structured logs.
• Monitor both operational health and security behaviour.
• Test alerts, backups, failover and incident-response procedures.
• Define RTO, RPO and emergency decision authority for critical services.
• Preserve evidence before rebuilding or deleting compromised systems.
• Review incidents for systemic improvements and verify that corrective actions close.

Chapter Summary

Secure blockchain operations require continuous control of hosts, networks, node software, keys, applications and people. Node hardening reduces unnecessary exposure, while disciplined patching controls known weaknesses without creating unsafe protocol changes. Secrets management protects confidentiality and availability through access control, rotation, backup and recovery.

Logging and monitoring provide the evidence and visibility needed to understand system health and detect attack behaviour. Security analytics becomes more reliable when on-chain activity is correlated with identity, cloud, application and approval records. Vulnerability management must cover infrastructure, dependencies, smart contracts and suppliers, and must continue through remediation verification.

Incident response depends on preparation, evidence-based analysis, proportionate containment, trusted recovery and lessons learned. Disaster recovery and business continuity define how essential services continue during failure, using measures such as RTO and RPO. Blockchain forensics requires careful recording of chain state, transaction context, provenance, integrity and legal authority. Finally, effective security is governed by ethics, privacy, accountability and appropriate human oversight of automation.

Key Terms

Node hardening: Reducing unnecessary services, privileges and exposure on a blockchain node and its host.

Remote signer: A service that performs signing separately from the node requesting the signature.

RPC: Remote procedure call interface through which applications or administrators interact with a node.

Secrets management: Controlled storage, use, rotation and auditing of credentials and cryptographic secrets.

Least privilege: Granting only the access necessary to perform an authorised task.

Structured logging: Recording events in consistent machine-readable fields.

Indicator of compromise: An observable artefact associated with malicious activity.

Indicator of attack: A behavioural sign that an attack may be occurring.

Vulnerability management: The process of discovering, prioritising, remediating and verifying weaknesses.

Mean time to detect: Average time between the beginning of an incident and its detection.

Mean time to recover: Average time required to restore an affected service.

Incident response: Organised actions to detect, contain, eradicate and recover from a security incident.

Disaster recovery: Restoration of technology and data after disruptive failure.

Business continuity: Maintenance of essential business functions during disruption.

RTO: Maximum acceptable time to restore a service.

RPO: Maximum acceptable time-period of data loss.

Chain reorganisation: A change in the locally preferred chain history caused by competing valid chain views.

Chain of custody: Documented history of evidence collection, handling, transfer and storage.

Defence in depth: Use of multiple independent or partially independent security controls.

Alert fatigue: Reduced analyst effectiveness caused by excessive or low-quality alerts.

Review Questions

5 Short Answer Questions

1. Why is a running blockchain process not sufficient evidence that a node is healthy?
2. State two differences between logging and monitoring.
3. What is the purpose of a remote signer?
4. Define RTO and RPO.
5. Why should evidence be preserved before rebuilding a compromised system?

5 Long Answer Questions

1. Explain how a blockchain organisation should harden a validator host, node client and signing process.
2. Describe a complete vulnerability-management and patching lifecycle for a production blockchain environment.
3. Discuss the relationship between structured logs, monitoring, indicators of compromise and security analytics.
4. Explain the incident-response lifecycle and identify blockchain-specific containment challenges.
5. Compare disaster recovery with business continuity and discuss how each applies to a crypto-custody service.

3 Analytical / Application Questions

1. A validator is six hundred blocks behind the network, its disk is nearly full, and its peer count has fallen sharply. Analyse at least three possible causes and propose an evidence-based response.
2. A treasury transfer is confirmed on-chain but has no matching approval record. Design an investigation plan that correlates on-chain, identity, application and cloud evidence while preserving forensic integrity.
3. Design a monitoring and response policy for a public RPC service connected to a wallet application. Include key metrics, alert thresholds or decision criteria, escalation roles and recovery actions.

Multiple Choice Questions with Answers

Question 1

Which control most directly reduces the risk that a compromised blockchain node can access a validator private key?

A. Increasing dashboard refresh frequency

B. Using a remote signer or hardware-backed signing system

C. Allowing unrestricted RPC debugging

D. Disabling time synchronisation

Correct Answer: B. Using a remote signer or hardware-backed signing system

Question 2

What does the expression L = H_network − H_node measure when both heights refer to the same network?

A. Transaction fee

B. Peer diversity

C. Synchronisation lag in blocks

D. Recovery time

Correct Answer: C. Synchronisation lag in blocks

Question 3

Which activity is part of vulnerability management?

A. Deleting all scan results after remediation

B. Discovering assets, prioritising weaknesses and verifying remediation

C. Applying every update immediately without testing

D. Monitoring only the blockchain ledger

Correct Answer: B. Discovering assets, prioritising weaknesses and verifying remediation

Question 4

What is the principal purpose of structured, centralised logging?

A. To expose private keys for investigation

B. To make events consistent, attributable and available for correlation

C. To replace access control

D. To guarantee that no incident occurs

Correct Answer: B. To make events consistent, attributable and available for correlation

Question 5

Which action is normally appropriate during initial incident analysis?

A. Separate facts from hypotheses and record relevant times

B. Erase compromised logs immediately

C. Assume every unusual transaction is fraudulent

D. Publish unverified attribution

Correct Answer: A. Separate facts from hypotheses and record relevant times

Question 6

What does RPO describe?

A. The maximum acceptable time to restore a service

B. The maximum acceptable period of data loss measured in time

C. The number of recovery personnel

D. The age of a vulnerability

Correct Answer: B. The maximum acceptable period of data loss measured in time

Question 7

Why is an on-chain transaction hash insufficient by itself to prove who controlled an address?

A. Transaction hashes are never unique

B. The hash proves ledger reference but not real-world identity or intent

C. Hashes cannot be recorded

D. Addresses do not appear on blockchains

Correct Answer: B. The hash proves ledger reference but not real-world identity or intent

Question 8

Which practice best protects the evidential value of a log file?

A. Editing it to remove irrelevant entries

B. Working only from the original and changing its contents

C. Recording provenance and hashing a forensic copy

D. Relying on memory for collection details

Correct Answer: C. Recording provenance and hashing a forensic copy

Question 9

Which event is a strong security indicator requiring investigation?

A. A scheduled, authorised software upgrade

B. A documented backup test

C. An unexpected privileged account creation

D. A normal block confirmation

Correct Answer: C. An unexpected privileged account creation

Question 10

What is a principal difference between disaster recovery and business continuity?

A. Disaster recovery restores technology, while continuity maintains essential functions

B. Disaster recovery concerns only passwords, while continuity concerns only logs

C. They are identical terms with no operational distinction

D. Business continuity applies only to public blockchains

Correct Answer: A. Disaster recovery restores technology, while continuity maintains essential functions