When a Digital Service Cannot Operate Normally: Designing a Safe Degraded Mode

RTO, RPO and similar continuity metrics answer necessary questions. They do not describe the operating policy of a partially functioning service.

A service with a four-hour RTO may still need to do something useful during those four hours. In another service, continuing any transactional function without a missing dependency may be worse than stopping.

The correct answer is service-specific.

That is why degraded operation should be designed before the incident rather than discovered during it.

Infrastructure monitoring tends to favour binary language: up or down.

A public-facing or regulated service often needs a richer model. In the 2026 Latvian proposal I used six operating states as a design tool.1 They are not legal categories and should not be presented as an EU standard.

The exact number of modes is less important than three properties: entry criteria, permitted behaviour and exit criteria.

Without those, “degraded mode” is simply incident-time improvisation.

A minimum service should not be defined as “keep 30% of the features”.

The starting point is the purpose and legal nature of the service.

Which actions must remain available? Which can wait? Which depend on an authoritative identity, register, payment or trust service? Which functions become unsafe if data freshness is uncertain? Which actions have legal effect that cannot be recreated casually through a manual workaround?

A useful minimum-service definition therefore has at least three classes:

continue — the function can safely operate under predefined controls;

defer — input may be accepted or queued, but the authoritative action is delayed;

stop — the function cannot be performed safely or lawfully without the missing control.

Latvian law already contains a narrower precedent. Cabinet Regulation No. 397 requires ICT critical infrastructure, in the specific context of national threat planning, to identify critical services and the minimum level that must be maintained.2 That does not create a universal obligation for every public information system. It demonstrates that minimum-service thinking already exists within a defined legal scope.

A separate Latvian critical-infrastructure framework uses similar continuity concepts for another legal category while expressly excluding ICT critical infrastructure from its scope.3 The lesson is methodological, not that these regimes can be merged.

A digital service is rarely just an application and a database.

Its critical path may depend on identity, authorisation, authoritative registries, APIs, DNS, telecommunications, cloud services, payment rails, timestamping or trust services, messaging providers, supplier support and privileged staff access.

An application can be technically healthy while the service is operationally unusable.

For each material function, ask:

What does this function depend on?

What happens when that dependency is unavailable, delayed or untrustworthy?

Is there an approved alternative?

What must happen to the temporary state when the dependency returns?

The fourth question is where many continuity designs become vague.

“Operate manually” can be a legitimate continuity strategy. It can also create a second, poorly controlled information system made of spreadsheets, paper, shared accounts and assumptions.

A manual or offline process should preserve the controls that still matter.

If normal processing verifies identity, representation authority, signatures, account status or an authoritative registry entry, loss of the automated check does not automatically make the check optional.

The service needs an explicit policy for what can be done through an alternative verification method, what can be accepted but held pending verification, and what must stop.

Data protection has the same problem. Temporary local data is still data. Confidentiality, integrity, access control, minimisation and retention do not disappear because the primary platform is unavailable.4

A continuity mechanism that restores availability by silently discarding the controls that make the transaction trustworthy is not a safe degraded mode.

Continuity discussions often jump from “online” to “manual processing”.

A read-only state may be safer and more useful.

If a trusted local copy of information remains available, some services can continue to provide information while clearly communicating its freshness boundary. Other services cannot safely do even that because stale information creates unacceptable consequences.

An advisory-only mode can also be useful: the system may continue to guide a user or operator without making an authoritative decision.

These options are deliberately narrower than full service. That is the point.

Degraded operation is not about preserving every feature. It is about preserving the functions whose value still exceeds their risk under the changed conditions.

Consider a two-hour outage of an authoritative dependency.

During that period a service accepts a bounded set of transactions locally. When connectivity returns, there are now two histories: the authoritative system and the temporary record.

“Synchronise them” is not a sufficient control.

The service may need to detect duplicate execution, concurrent conflicting changes, uncertain ordering, expired authority, missing signatures, stale balances or transactions whose external result is unknown.

Reconciliation should answer:

• which temporary actions are already reflected in the authoritative state;
• which remain valid and can be committed;
• which conflict with later authoritative changes;
• which outcomes are unknown;
• which cases require human review;
• what happens to the temporary evidence after the process completes.

This is why I treat reconciliation as an operating mode rather than a final line in a recovery script.

The risk is especially obvious in payments and ledgers, but it exists in registries, permits, benefits, case-management systems and many other public or regulated workflows.

A dependency responding to health checks does not mean the service is ready for unrestricted operation.

For the categories of NIS2 entities within its defined scope, Commission Implementing Regulation (EU) 2024/2690 requires business-continuity and disaster-recovery plans to address activation and deactivation conditions, recovery sequencing, required resources and restoration from temporary measures.5

The Regulation is not a universal rulebook for every European service. The control logic is nevertheless useful.

Before leaving degraded operation, an organisation should know whether:

• the original cause has been resolved;
• the restored dependency is stable;
• data integrity has been checked;
• temporary and queued activity has been reconciled;
• unknown transaction outcomes have been resolved or isolated;
• emergency credentials and temporary access have been revoked or normalised;
• monitoring supports a controlled increase in workload.

Return to normal is therefore a governance decision supported by technical evidence, not just a green dashboard.

The European Commission’s July 2026 guidance on the Critical Entities Resilience Directive provides a useful comparison within its own legal scope.6

It encourages critical entities to identify the sub-services that should be restored first, preserve a manual capability when automated or AI-driven systems fail or are tampered with, base continuity planning on business impact analysis, and use phased restart protocols with validation of data integrity and functionality before normal operation is restored.

These are non-binding guidelines for the CER framework, not a general degraded-mode law for every digital service.

Their value here is conceptual. European resilience policy is increasingly interested not only in whether an organisation can recover, but in how it controls temporary operation and resumption.

Imagine a Monday morning service outage.

At 09:20 a public digital service loses access to a central electronic-identity dependency. The web application and its database remain available. Existing sessions still work, but new identity assertions cannot be validated.

An improvised organisation has one incident channel and a technical objective: restore connectivity. Individual departments decide for themselves whether to keep serving users.

A service with an explicit degraded-mode design behaves differently.

The authorised owner declares the predefined mode. Existing authenticated users may continue only with functions that do not require fresh identity or representation checks. Transactions requiring new authority are stopped or placed in a controlled pending state where the legal framework permits it. Users see a clear limitation notice. Temporary actions receive unique identifiers and evidence. Engineering continues to restore the dependency, but operational decisions no longer depend on engineering improvisation.

When the identity service returns, full functionality is not immediately restored. Pending actions are checked, conflicts are resolved and the system state is validated first.

There are many possible implementations. The important distinction is between designed degradation and ad hoc exception handling.

The Latvian proposal suggested a small operational artefact rather than a new parallel continuity-document regime.1

A service continuity card can point to existing BCP, risk and technical documentation while recording the decisions needed during a dependency failure.

The format is not the important part.

Its purpose is to force decisions to be made before the conditions are degraded and information is incomplete.

Latvia already has several relevant pieces rather than a blank policy landscape.

The National Security Law gives the Crisis Management Centre responsibilities that include coordinating sector continuity and resilience plans, supporting crisis planning, coordinating national crisis exercises and coordinating follow-up evaluation after crises and exercises.7

Cabinet Regulation No. 397 sets minimum cybersecurity requirements for the entities within its scope and, for ICT critical infrastructure in national-threat planning, requires identification of critical services and their minimum level.2

Cabinet Regulation No. 399 defines the holder of a state administration service as the institution or other legal subject competent to ensure that service.8 That matters because a degraded-mode methodology cannot move responsibility to a central technology authority: the service owner or other legally competent body still has to determine the lawful and operational minimum.

My August 2026 proposal therefore suggested a pilot, not a new universal mandate: select a small number of services with different dependency patterns, create a concise continuity card, exercise loss of a shared or external dependency, require a reconciliation phase, and decide only afterwards whether common guidance adds value.1

That remains the useful sequence. Map, exercise, measure, then regulate only if a real gap remains.

NIS2 includes business continuity, backup management, disaster recovery and crisis management in its cybersecurity risk-management measures.9

Commission Implementing Regulation (EU) 2024/2690 provides more detailed operational requirements for specific categories of NIS2 entities, including recovery order and resumption from temporary measures.5

The CER framework addresses a different legal population and a broader all-hazards resilience problem, but its 2026 guidance also emphasises service prioritisation, manual capability and validated phased restart.6

None of these sources defines the six-state model used in this article.

What they collectively support is a narrower proposition: continuity planning must deal with more than the final recovery deadline. It must deal with the behaviour of the service during disruption and the controlled transition out of temporary measures.

A tabletop exercise is more revealing than another policy review.

Choose one service with meaningful dependencies. Remove one of them in the scenario. Do not let the team assume that it will return in ten minutes.

Then ask who can change the service mode, what functions remain available, how users are told, how temporary actions are identified, what happens after four hours, what happens if the dependency returns only intermittently, how conflicting records are handled and who authorises the final return to normal.

If most answers begin with “we would decide during the incident”, the organisation may have recovery documentation but it does not yet have an executable degraded mode.

Continuity architecture is often drawn as a jump from normal operation to recovery.

The difficult part is the space between them.

That is where a service must decide which functions remain trustworthy, which controls cannot be waived, what can be deferred, how temporary activity is recorded and how it will later be reconciled with the authoritative state.

A safe degraded mode is therefore not “keep as much running as possible”.

It is a predefined operating boundary: what may continue, what must stop, who can decide, what evidence must be preserved, and what must be true before normal operation resumes.

Legal and policy sources were checked on 25 September 2026. The six operating modes and service-continuity-card structure are the author’s proposed methodology, not statutory requirements.

This article is an analysis of technical, organisational and public-governance practice, not individual legal advice.