A privacy service needs a plan for outages and safe fallback

An unavailable privacy service should not force an operator to invent a policy at the counter. The application needs a defined response before the outage occurs.

That response may differ by workflow. Capturing a customer’s instruction, sending promotional messages and displaying a restricted case record have different consequences when the current decision cannot be obtained. One global “fail open” or “fail closed” setting is unlikely to express those differences adequately.

Decide what may continue

A hypothetical retailer uses a central service to manage promotional preferences. If the service is unavailable, staff still need a way to receive a customer’s withdrawal. The campaign system also needs a decision about messages that are waiting to be sent.

The design could allow a minimal instruction to be captured in an approved pending queue while suspending sends whose permission cannot be established. That is a proposed operating choice, not a universal legal rule. The business must assess the specific purpose, available evidence and consequences.

Write the decision for each operation. Include what the customer sees, what staff may do and which data is retained while work waits.

NIST’s privacy-engineering objectives include manageability and predictability. In an outage plan, those objectives support clear control over processing and understandable behaviour under failure.

Preserve instructions without overcollecting

A fallback form should capture the minimum information needed to identify and apply the instruction. It should not become an unrestricted spreadsheet of customer profiles because the normal interface is down.

Protect the pending store, assign an owner and define how it will be drained after recovery. Make the pending state visible to the customer or operator without claiming that every downstream system has already changed.

If the fallback cannot safely establish identity, record what is known and route the case for the appropriate verification. Avoid collecting a new identity dossier simply to compensate for an outage.

Give each pending instruction a reference the operator can use later without copying its content into another channel. The reference should let authorised staff check progress and connect a repeated enquiry to the existing work.

Test the fallback under the conditions staff will face, including limited connectivity and repeated submissions.

Plan for uncertain outcomes

An outage can occur after a downstream action succeeds but before its acknowledgement returns. The recovery worker must distinguish an unknown result from a definite failure.

AWS’s guidance on idempotent APIs explains how stable request identity can make retries safer. Use the relevant integration’s capabilities to avoid turning repeated recovery attempts into conflicting state changes.

Record the original instruction and its operation reference. A new worker should be able to continue the same work rather than creating an unrelated duplicate case.

Define what happens when the downstream system cannot support safe automatic reconciliation. That may require a restricted manual check before another action is attempted. The operator needs an explicit procedure and evidence, not a generic retry button.

Control the temporary shortcuts

During an outage, people may be tempted to send customer records through personal messaging accounts, grant broad access or enable full payload logging. The runbook should provide a workable alternative to those shortcuts.

Give staff a clear contact, an approved place for pending work and a short explanation they can provide to customers. Keep technical diagnostics separate from customer evidence.

OpenTelemetry’s sensitive-data guidance supports limiting sensitive telemetry even when troubleshooting. An outage does not make unrestricted logging harmless, and emergency debug settings need an owner and an end condition.

Track temporary permissions and configuration changes so they can be removed during recovery.

Reconcile before declaring recovery

The service being reachable again is only the start of recovery. Pending instructions, delayed webhooks, stale caches and uncertain downstream actions may remain.

For the retailer, compare the queued withdrawal instructions with the central state and relevant sending systems. Resolve mismatches using the defined state rules, then remove temporary operating measures.

A rehearsal should cover:

• Failure before an instruction is captured.
• Failure after capture but before downstream application.
• Success with a lost acknowledgement.
• Repeated customer submissions during the outage.
• Recovery with stale cached permissions.
• Removal of temporary access and diagnostics.

Record the outcome for each operation and the time or effort needed to reconcile it, without inventing service promises from a single exercise.

A usable outage plan protects both continuity and the customer’s instruction. It makes pending work visible, limits what may proceed and gives the team a concrete route back to a trustworthy state.