Business continuity plan #

Effective date: 2026-05-21 Last reviewed: 2026-05-21 Next review: 2027-05-21 Owner: Yaroslav Shmarov, operator Version: 1.0

This document states what EthicsPortal does when the Service, a sub-processor, or the operator themselves becomes unable to deliver the Service at the level customers depend on. It is the named plan referenced by the Information security policy §6 and by the ISO/IEC 27001:2022 Annex A control map for controls A.5.29–A.5.30.

The recovery outcomes this plan produces (recovery point objective, recovery time objective, monthly availability target) are stated in the Service level agreement . This page states the process that produces them.

1. Scope and objectives #

This plan covers continuity of the EthicsPortal Service in the event of:

• An infrastructure failure affecting the application host, database, file storage, or transactional email pipeline
• A sub-processor outage that degrades a covered surface (Subprocessors )
• A security incident requiring a covered surface to be taken offline
• Operator incapacity, prolonged unavailability, or business cessation

The continuity objectives, in order of priority, are:

1. Preserve the confidentiality and integrity of personal data already in the system. The reporter portal will be taken offline rather than continue to operate in a degraded confidentiality state.
2. Restore reporter access to existing cases (status, messaging, follow-up) so that protected reporting under EU Directive 2019/1937 is not silently interrupted.
3. Restore handler and admin access to case management.
4. Restore the marketing site and documentation surfaces.

2. Recovery objectives #

Marketing and documentation surfaces are best-effort and are not covered by an availability target.

Backup mechanism, storage location, retention, and restore-testing cadence are documented at Security#backups-and-restore . The most recent restore drill date is published on the same page.

3. Activation triggers #

The continuity process is activated when any of the following is observed:

• The reporter portal or handler portal is unreachable for more than 15 minutes, confirmed by external monitoring
• A sub-processor reports an outage that affects a covered surface
• A security incident is suspected or confirmed, including a credible report from external researchers
• A personal data breach is suspected (Art. 4(12) GDPR definition)
• The operator becomes unable to access production systems for any reason exceeding 4 hours

Activation does not require a formal declaration — the trigger conditions automatically open the response process.

4. Decision authority #

The operator (Yaroslav Shmarov) is the sole decision authority for:

• Taking a covered surface offline
• Initiating a restore from backup
• Notifying affected controllers of a personal data breach under DPA §6.6
• Creating an entry in the incident register
• Engaging additional sub-processors or alternative infrastructure on an emergency basis

Decisions are recorded in a written incident log retained for audit purposes.

5. Customer communication #

Communications go to the organization-administrator contact on file. Controllers are responsible for keeping their administrator contact information current.

6. Restore procedure (summary) #

When a database or full-system restore is required:

1. The operator declares the incident, takes the covered surface offline if not already down, and freezes write traffic.
2. The most recent encrypted database dump is retrieved from Hetzner Object Storage (Nuremberg, EU; 7-day retention).
3. The dump is restored into a fresh database instance and integrity-checked.
4. The application host is rebuilt from a current Kamal deployment configuration; if the host itself is lost, a Hetzner server-level snapshot (7-day retention) is the fallback.
5. The covered surfaces are brought back online incrementally, with the reporter portal restored before the handler portal where they are independently recoverable.
6. The event is logged to the incident register if it meets the register’s scope criteria.

The full restore mechanism, storage locations, retention, and drill cadence are documented at Security#backups-and-restore . A restore drill is executed into a disposable environment at least quarterly.

7. Sub-processor failure #

The Service depends on the sub-processors listed on the Subprocessors page. Continuity posture for each:

Sub-processor outage affecting a covered surface counts against the SLA target.

8. Operator-incapacity protocol #

Current state. A formal operator-incapacity protocol — a named legal contact holding emergency credentials with authority to notify customers and execute a controlled wind-down — is in treatment (see Risk register R-01 ). This section states what is in place today, openly, so that controllers can assess the risk and plan accordingly.

What is in place today:

• Self-service data export. Every organization admin can produce a full PDF case export from within the Service for any case at any time. This does not require operator intervention and continues to function for as long as the Service is reachable. Self-service export is the primary continuity guarantee against operator unavailability.
• Customer rights under the DPA. DPA §6.8 gives the controller the right to receive or delete all personal data on subscription termination. These rights are enforceable independent of the operator’s availability.
• Cloud-hosted infrastructure on standard providers. The Service runs on Hetzner using Kamal deployment configuration that is portable to an alternative operator. A third party with access to the deployment configuration and customer authorization could, in principle, take over operation.

What is not yet in place:

• A named legal contact or law firm holding emergency credentials and notification authority
• A pre-arranged escrow of deployment credentials with a third party
• A pre-arranged customer-notification mechanism that operates without the operator

Planned addition. A formal protocol with a named legal contact and pre-arranged customer-notification authority is on the operator’s roadmap. When in place, this section will be updated to name the contact, the trigger conditions, and the authority granted. The change will be reflected in this plan’s version number and effective date.

Controllers concerned about this gap are encouraged to:

• Take regular self-service exports of active cases for local archival
• Configure organization-admin contacts redundantly (more than one admin per organization)
• Raise the question during procurement review; bespoke arrangements may be available on enterprise terms

This honest disclosure is itself a control: a controller that knows the limit can plan around it. A controller that assumes a protocol exists and discovers later that it does not is materially worse off.

9. Plan testing #

Test results inform the risk register and any required updates to this plan.

10. Document control #

Signed: Yaroslav Shmarov, on behalf of EthicsPortal — 2026-05-21.

Last updated: May 25, 2026