https://ethicsportal.eu/policies/EthicsPortal is a secure, anonymous whistleblower reporting platform that helps organizations comply with EU Directive 2019/1937.enMon, 25 May 2026 01:23:15 +0000https://ethicsportal.eu/images/logo.svghttps://ethicsportal.eu/https://ethicsportal.eu/policies/business-continuity/Mon, 01 Jan 0001 00:00:00 +0000https://ethicsportal.eu/policies/business-continuity/How EthicsPortal responds to outages, sub-processor failures, restore events, and operator incapacity. Activation triggers, decision authority, and customer-communication protocol.<h1 id="business-continuity-plan"> Business continuity plan <a href="#business-continuity-plan" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h1> <p><strong>Effective date:</strong> 2026-05-21 <strong>Last reviewed:</strong> 2026-05-21 <strong>Next review:</strong> 2027-05-21 <strong>Owner:</strong> Yaroslav Shmarov, operator <strong>Version:</strong> 1.0</p> <p>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 <a href="/policies/information-security/">Information security policy</a> §6 and by the <a href="/iso-27001/">ISO/IEC 27001:2022 Annex A control map</a> for controls A.5.29–A.5.30.</p> <p>The recovery <em>outcomes</em> this plan produces (recovery point objective, recovery time objective, monthly availability target) are stated in the <a href="/sla/">Service level agreement</a> . This page states the <em>process</em> that produces them.</p> <hr> <h2 id="1-scope-and-objectives"> 1. Scope and objectives <a href="#1-scope-and-objectives" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>This plan covers continuity of the EthicsPortal Service in the event of:</p> <ul> <li>An infrastructure failure affecting the application host, database, file storage, or transactional email pipeline</li> <li>A sub-processor outage that degrades a covered surface (<a href="/subprocessors/">Subprocessors</a> )</li> <li>A security incident requiring a covered surface to be taken offline</li> <li>Operator incapacity, prolonged unavailability, or business cessation</li> </ul> <p>The continuity objectives, in order of priority, are:</p> <ol> <li>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.</li> <li>Restore reporter access to existing cases (status, messaging, follow-up) so that protected reporting under EU Directive 2019/1937 is not silently interrupted.</li> <li>Restore handler and admin access to case management.</li> <li>Restore the marketing site and documentation surfaces.</li> </ol> <hr> <h2 id="2-recovery-objectives"> 2. Recovery objectives <a href="#2-recovery-objectives" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Objective</th> <th>Target</th> <th>Surface</th> </tr> </thead> <tbody> <tr> <td>Recovery point objective (RPO)</td> <td>24 hours</td> <td>Reporter portal, handler portal</td> </tr> <tr> <td>Recovery time objective (RTO)</td> <td>4 hours</td> <td>Reporter portal, handler portal</td> </tr> <tr> <td>Monthly availability target</td> <td>99.5%</td> <td>Reporter portal, handler portal</td> </tr> </tbody> </table> <p>Marketing and documentation surfaces are best-effort and are not covered by an availability target.</p> <p>Backup mechanism, storage location, retention, and restore-testing cadence are documented at <a href="/security/#backups-and-restore">Security#backups-and-restore</a> . The most recent restore drill date is published on the same page.</p> <hr> <h2 id="3-activation-triggers"> 3. Activation triggers <a href="#3-activation-triggers" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>The continuity process is activated when any of the following is observed:</p> <ul> <li>The reporter portal or handler portal is unreachable for more than 15 minutes, confirmed by external monitoring</li> <li>A sub-processor reports an outage that affects a covered surface</li> <li>A security incident is suspected or confirmed, including a credible report from external researchers</li> <li>A personal data breach is suspected (<a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L1937" target="_blank" rel="noopener noreferrer">Art. 4(12)</a> GDPR definition)</li> <li>The operator becomes unable to access production systems for any reason exceeding 4 hours</li> </ul> <p>Activation does not require a formal declaration — the trigger conditions automatically open the response process.</p> <hr> <h2 id="4-decision-authority"> 4. Decision authority <a href="#4-decision-authority" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>The operator (Yaroslav Shmarov) is the sole decision authority for:</p> <ul> <li>Taking a covered surface offline</li> <li>Initiating a restore from backup</li> <li>Notifying affected controllers of a personal data breach under <a href="/dpa/">DPA §6.6</a> </li> <li>Creating an entry in the <a href="/incidents/">incident register</a> </li> <li>Engaging additional sub-processors or alternative infrastructure on an emergency basis</li> </ul> <p>Decisions are recorded in a written incident log retained for audit purposes.</p> <hr> <h2 id="5-customer-communication"> 5. Customer communication <a href="#5-customer-communication" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Event</th> <th>Channel</th> <th>Timing</th> </tr> </thead> <tbody> <tr> <td>Active outage on a covered surface</td> <td>Live status indicator at <a href="https://secure.ethicsportal.eu/up" rel="nofollow">secure.ethicsportal.eu/up</a> ; email to organization admins for material outages</td> <td>Within 60 minutes of detection</td> </tr> <tr> <td>Personal data breach</td> <td>Direct email to affected controllers</td> <td>Within 72 hours of awareness, per <a href="/dpa/">DPA §6.6</a> </td> </tr> <tr> <td>Material incident (post-containment)</td> <td>Preliminary entry in <a href="/incidents/">incident register</a> </td> <td>Within 7 days of containment</td> </tr> <tr> <td>Material incident (final disclosure)</td> <td>Final entry in <a href="/incidents/">incident register</a> </td> <td>Within 30 days of containment</td> </tr> <tr> <td>Planned maintenance</td> <td>Status page and (where it affects business hours) admin email</td> <td>At least 48 hours in advance</td> </tr> </tbody> </table> <p>Communications go to the organization-administrator contact on file. Controllers are responsible for keeping their administrator contact information current.</p> <hr> <h2 id="6-restore-procedure-summary"> 6. Restore procedure (summary) <a href="#6-restore-procedure-summary" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>When a database or full-system restore is required:</p> <ol> <li>The operator declares the incident, takes the covered surface offline if not already down, and freezes write traffic.</li> <li>The most recent encrypted database dump is retrieved from Hetzner Object Storage (Nuremberg, EU; 7-day retention).</li> <li>The dump is restored into a fresh database instance and integrity-checked.</li> <li>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.</li> <li>The covered surfaces are brought back online incrementally, with the reporter portal restored before the handler portal where they are independently recoverable.</li> <li>The event is logged to the <a href="/incidents/">incident register</a> if it meets the register’s scope criteria.</li> </ol> <p>The full restore mechanism, storage locations, retention, and drill cadence are documented at <a href="/security/#backups-and-restore">Security#backups-and-restore</a> . A restore drill is executed into a disposable environment at least quarterly.</p> <hr> <h2 id="7-sub-processor-failure"> 7. Sub-processor failure <a href="#7-sub-processor-failure" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>The Service depends on the sub-processors listed on the <a href="/subprocessors/">Subprocessors</a> page. Continuity posture for each:</p> <table> <thead> <tr> <th>Sub-processor</th> <th>Function</th> <th>Continuity response</th> </tr> </thead> <tbody> <tr> <td>Hetzner (DE)</td> <td>Application host, database, file storage</td> <td>Restore from off-host backup (database dump in Hetzner Object Storage; server-level snapshots). For prolonged Hetzner outage, the application is portable to another EU-based provider; cutover would be coordinated with affected controllers and disclosed in the <a href="/incidents/">incident register</a> .</td> </tr> <tr> <td>Mailjet (FR)</td> <td>Transactional email</td> <td>Handler notifications are delayed during a Mailjet outage; the in-app surface remains functional. No data is lost.</td> </tr> <tr> <td>Stripe (IE)</td> <td>Subscription billing</td> <td>Billing functions are interrupted; the Service itself continues to operate.</td> </tr> <tr> <td>Cloudflare (US)</td> <td>Marketing-site CDN</td> <td>Marketing site degrades to direct origin or is unreachable; reporter and handler portals are not affected (they do not load Cloudflare).</td> </tr> <tr> <td>AppSignal (NL)</td> <td>Error and performance monitoring</td> <td>Loss of telemetry; no customer-facing impact.</td> </tr> <tr> <td>Crisp (FR)</td> <td>Handler-portal chat</td> <td>Loss of in-app chat for handlers; not present on reporter portal, no reporter-side impact.</td> </tr> </tbody> </table> <p>Sub-processor outage affecting a covered surface counts against the <a href="/sla/">SLA</a> target.</p> <hr> <h2 id="8-operator-incapacity-protocol"> 8. Operator-incapacity protocol <a href="#8-operator-incapacity-protocol" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p><strong>Current state.</strong> A formal operator-incapacity protocol — a named legal contact holding emergency credentials with authority to notify customers and execute a controlled wind-down — is <strong>in treatment</strong> (see <a href="/policies/risk-register/">Risk register R-01</a> ). This section states what is in place today, openly, so that controllers can assess the risk and plan accordingly.</p> <p><strong>What is in place today:</strong></p> <ul> <li><strong>Self-service data export.</strong> 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.</li> <li><strong>Customer rights under the DPA.</strong> <a href="/dpa/">DPA §6.8</a> 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.</li> <li><strong>Cloud-hosted infrastructure on standard providers.</strong> 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.</li> </ul> <p><strong>What is not yet in place:</strong></p> <ul> <li>A named legal contact or law firm holding emergency credentials and notification authority</li> <li>A pre-arranged escrow of deployment credentials with a third party</li> <li>A pre-arranged customer-notification mechanism that operates without the operator</li> </ul> <p><strong>Planned addition.</strong> 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.</p> <p><strong>Controllers concerned about this gap</strong> are encouraged to:</p> <ul> <li>Take regular self-service exports of active cases for local archival</li> <li>Configure organization-admin contacts redundantly (more than one admin per organization)</li> <li>Raise the question during procurement review; bespoke arrangements may be available on enterprise terms</li> </ul> <p>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.</p> <hr> <h2 id="9-plan-testing"> 9. Plan testing <a href="#9-plan-testing" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Test</th> <th>Cadence</th> <th>Last performed</th> </tr> </thead> <tbody> <tr> <td>Database restore drill into disposable environment</td> <td>Quarterly</td> <td>See <a href="/security/#backups-and-restore">Security#backups-and-restore</a> </td> </tr> <tr> <td>Failover walk-through (paper exercise)</td> <td>Annual</td> <td>2026-05</td> </tr> <tr> <td>Sub-processor outage tabletop</td> <td>Annual</td> <td>2026-05</td> </tr> <tr> <td>Operator-incapacity tabletop</td> <td>Deferred pending formal protocol</td> <td>—</td> </tr> </tbody> </table> <p>Test results inform the <a href="/policies/risk-register/">risk register</a> and any required updates to this plan.</p> <hr> <h2 id="10-document-control"> 10. Document control <a href="#10-document-control" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Document title</td> <td>EthicsPortal Business Continuity Plan</td> </tr> <tr> <td>Version</td> <td>1.0</td> </tr> <tr> <td>Effective date</td> <td>2026-05-21</td> </tr> <tr> <td>Last reviewed</td> <td>2026-05-21</td> </tr> <tr> <td>Next scheduled review</td> <td>2027-05-21</td> </tr> <tr> <td>Review trigger (interim)</td> <td>Formalization of the operator-incapacity protocol, addition or change of a sub-processor that affects continuity, material restore-drill outcome, material change to the <a href="/policies/risk-register/">risk register</a> </td> </tr> <tr> <td>Owner</td> <td>Yaroslav Shmarov, operator</td> </tr> <tr> <td>Distribution</td> <td>Published on <a href="/policies/">ethicsportal.eu/policies/</a> </td> </tr> </tbody> </table> <p>Signed: Yaroslav Shmarov, on behalf of EthicsPortal — 2026-05-21.</p>support@ethicsportal.eu (EthicsPortal)https://ethicsportal.eu/policies/information-security/Mon, 01 Jan 0001 00:00:00 +0000https://ethicsportal.eu/policies/information-security/EthicsPortal's information security policy. Scope, roles, control commitments, review cadence, and document control.<h1 id="information-security-policy"> Information security policy <a href="#information-security-policy" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h1> <p><strong>Effective date:</strong> 2026-05-21 <strong>Last reviewed:</strong> 2026-05-21 <strong>Next review:</strong> 2027-05-21 <strong>Owner:</strong> Yaroslav Shmarov, operator <strong>Version:</strong> 1.0</p> <hr> <h2 id="1-purpose"> 1. Purpose <a href="#1-purpose" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>This policy states the information-security objectives that govern EthicsPortal, the controls that satisfy them, and the responsibilities that maintain them. It exists so that customers, controllers under GDPR, regulators, and procurement reviewers can refer to a single named document for the security posture of the Service.</p> <p>This policy is the parent document for the <a href="/policies/business-continuity/">business continuity plan</a> , the <a href="/policies/risk-register/">risk register</a> , and the <a href="/iso-27001/">ISO/IEC 27001:2022 Annex A control map</a> .</p> <hr> <h2 id="2-scope"> 2. Scope <a href="#2-scope" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>This policy applies to:</p> <ul> <li>The EthicsPortal Service — the reporter portal, handler portal, and supporting infrastructure listed on the <a href="/security/#infrastructure">Security</a> page.</li> <li>All personal data processed by the Service on behalf of customer organizations (controllers under GDPR), including report content, reporter identity, handler messages, file attachments, and audit-log entries.</li> <li>The operator and all sub-processors listed on the <a href="/subprocessors/">subprocessors</a> page.</li> </ul> <p>This policy does not extend to systems operated by the controller (the customer organization) outside the Service.</p> <hr> <h2 id="3-objectives"> 3. Objectives <a href="#3-objectives" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal commits to three primary security objectives, in order of priority:</p> <ol> <li><strong>Confidentiality of reporter identity.</strong> Personal data identifying or reasonably capable of identifying a whistleblower is protected against unauthorized disclosure to any party — including controller-side personnel who are not designated handlers, sub-processors, and the operator’s own infrastructure providers — to the extent technically feasible.</li> <li><strong>Integrity of the audit trail.</strong> Records of who did what, when, are preserved in an append-only form that cannot be altered by any user, including organization administrators.</li> <li><strong>Availability of the reporting channel.</strong> The reporter portal is available to whistleblowers under the <a href="/sla/">SLA</a> target so that the protected reporting right under EU Directive 2019/1937 is not silently degraded.</li> </ol> <p>Confidentiality takes precedence over availability where the two conflict — the reporter portal will be taken offline in the event of a credible threat to reporter identity, with disclosure under the <a href="/incidents/">incident register</a> .</p> <hr> <h2 id="4-roles-and-responsibilities"> 4. Roles and responsibilities <a href="#4-roles-and-responsibilities" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal is operated by a single named individual, Yaroslav Shmarov, who holds all of the following responsibilities:</p> <table> <thead> <tr> <th>Role</th> <th>Responsibility</th> </tr> </thead> <tbody> <tr> <td>Information security officer</td> <td>Owns this policy and its review</td> </tr> <tr> <td>Data protection officer (functional)</td> <td>Privacy and data-subject-rights inquiries; reachable at <a href="mailto:privacy@ethicsportal.eu">privacy@ethicsportal.eu</a> and <a href="mailto:dpo@ethicsportal.eu">dpo@ethicsportal.eu</a> </td> </tr> <tr> <td>Incident response lead</td> <td>Owns the response process for events meeting the <a href="/incidents/">incident register</a> scope</td> </tr> <tr> <td>Authorized signatory</td> <td>Signs DPAs, security questionnaires, and commercial agreements</td> </tr> <tr> <td>Sub-processor manager</td> <td>Reviews sub-processor relationships and publishes the list on the <a href="/subprocessors/">subprocessors</a> page</td> </tr> </tbody> </table> <p>The single-operator structure is documented openly on the <a href="/trust/#continuity-and-personnel">Trust</a> page. Continuity arrangements that compensate for this structure are stated in the <a href="/policies/business-continuity/">business continuity plan</a> .</p> <hr> <h2 id="5-control-commitments"> 5. Control commitments <a href="#5-control-commitments" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>The technical and organizational measures implementing this policy are documented on the <a href="/security/">Security</a> page and are summarized below. Each commitment maps to one or more ISO/IEC 27001:2022 Annex A controls in the <a href="/iso-27001/">control map</a> .</p> <table> <thead> <tr> <th>Domain</th> <th>Commitment</th> <th>Detail</th> </tr> </thead> <tbody> <tr> <td>Encryption at rest</td> <td>Non-deterministic encryption of all sensitive report data and reporter identity</td> <td><a href="/security/#data-encryption">Security#data-encryption</a> </td> </tr> <tr> <td>Encryption in transit</td> <td>HTTPS/TLS for all connections; unencrypted HTTP is redirected</td> <td><a href="/security/#data-encryption">Security#data-encryption</a> </td> </tr> <tr> <td>Reporter anonymity</td> <td>No raw IP storage; one-way hashing for rate limiting; metadata stripped from uploads</td> <td><a href="/security/#anonymity-and-privacy">Security#anonymity-and-privacy</a> </td> </tr> <tr> <td>Access control</td> <td>Role-based access enforced at the controller boundary via Pundit policies; least-privilege defaults; mandatory two-factor authentication available for handler accounts</td> <td><a href="/security/#access-control">Security#access-control</a> </td> </tr> <tr> <td>Session management</td> <td>14-day idle timeout; per-session revocation; nightly sweep</td> <td><a href="/security/#access-control">Security#access-control</a> </td> </tr> <tr> <td>Audit trail</td> <td>Append-only, actor + action + timestamp, cannot be edited by any user</td> <td><a href="/security/#audit-and-compliance">Security#audit-and-compliance</a> </td> </tr> <tr> <td>Retention</td> <td>Customer-configurable 12/24/36/60-month retention with automatic deletion after closure</td> <td><a href="/security/#audit-and-compliance">Security#audit-and-compliance</a> </td> </tr> <tr> <td>Secure development</td> <td>Documented lifecycle covering design review, code review, static analysis, dependency management, environment separation, vulnerability response</td> <td><a href="/security/#secure-development-lifecycle">Security#secure-development-lifecycle</a> </td> </tr> <tr> <td>Vulnerability management</td> <td>Continuous SCA in CI; weekly Dependabot; no end-of-life components</td> <td><a href="/security/#dependency-and-patch-management">Security#dependency-and-patch-management</a> </td> </tr> <tr> <td>Backup and restore</td> <td>Daily encrypted database dumps + server-level snapshots in EU; RPO 24h, RTO 4h; quarterly restore drill</td> <td><a href="/security/#backups-and-restore">Security#backups-and-restore</a> </td> </tr> <tr> <td>Sub-processor management</td> <td>Published list, 30-day change notice, controller objection right</td> <td><a href="/subprocessors/">Subprocessors</a> , <a href="/dpa/">DPA §6.4</a> </td> </tr> <tr> <td>No AI / LLM processing</td> <td>Personal data covered by the DPA is not transmitted to any LLM, generative-AI, or AI-classifier service</td> <td><a href="/dpa/">DPA §6.10</a> </td> </tr> <tr> <td>No BYOK</td> <td>Customer-managed encryption keys are not supported; deliberate architectural choice</td> <td><a href="/dpa/">DPA §6.11</a> </td> </tr> <tr> <td>Incident response</td> <td>Material incidents recorded publicly within 7 days of containment; final report within 30 days</td> <td><a href="/incidents/">Incident register</a> </td> </tr> <tr> <td>Personal data breach notification</td> <td>Notification to affected controllers within 72 hours of awareness</td> <td><a href="/dpa/">DPA §6.6</a> </td> </tr> </tbody> </table> <hr> <h2 id="6-risk-management"> 6. Risk management <a href="#6-risk-management" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>Information-security risks are assessed against the Service annually and after any material change to architecture, sub-processors, or the threat landscape. The current assessment, treatment, and residual-position decisions are published in the <a href="/policies/risk-register/">risk register</a> .</p> <p>Risks accepted as residual are stated openly with a justification; risks not yet treated are stated openly with a target.</p> <hr> <h2 id="7-sub-processor-management"> 7. Sub-processor management <a href="#7-sub-processor-management" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal engages sub-processors only where the function cannot reasonably be performed in-house and where the sub-processor materially improves availability, confidentiality, or compliance for the customer. The current list, the data each sub-processor receives, and the legal jurisdiction of each are published on the <a href="/subprocessors/">subprocessors</a> page.</p> <p>No large language model, generative-AI service, or AI-based classifier is engaged as a sub-processor. This is a documented product commitment (<a href="/dpa/">DPA §6.10</a> ) and a confidentiality-grade decision (<a href="/directive-coverage/">Coverage map §5</a> ), not a configuration default.</p> <p>Controllers are notified at least 30 days before any sub-processor is added or replaced. A controller that objects to a proposed change may terminate the agreement under <a href="/dpa/">DPA §6.4</a> without penalty.</p> <hr> <h2 id="8-personnel-security"> 8. Personnel security <a href="#8-personnel-security" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal has no employees or contractors. All personal data is processed exclusively by the named operator. ISO/IEC 27001:2022 Annex A personnel controls (A.6.1 screening, A.6.3 awareness, A.6.4 disciplinary process) are therefore marked <strong>Not applicable</strong> in the <a href="/iso-27001/#a6-people-controls">control map</a> , with the substantive concerns addressed through compensating arrangements: privileged-production-access summary available during procurement review, operator self-directed awareness via subscribed security feeds (see ISO 27001 A.5.6), and continuity arrangements stated in the <a href="/policies/business-continuity/">business continuity plan</a> .</p> <p>If EthicsPortal engages additional personnel in the future, this policy will be updated to state the screening, training, and offboarding procedures that apply.</p> <hr> <h2 id="9-physical-security"> 9. Physical security <a href="#9-physical-security" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal does not operate its own physical infrastructure. Server, database, and object-storage hosting are provided by Hetzner Online GmbH in Nuremberg, Germany. Physical security controls (data-center access, environmental controls, media destruction) are inherited from Hetzner and documented in their published certifications. See <a href="/subprocessors/">subprocessors</a> .</p> <p>The operator does not maintain a physical office that processes customer data. Operator workstations used for production access are protected by full-disk encryption and screen-lock controls.</p> <hr> <h2 id="10-compliance"> 10. Compliance <a href="#10-compliance" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>EthicsPortal commits to compliance with:</p> <ul> <li><strong>GDPR (Regulation 2016/679)</strong>, particularly Articles 5, 28, 32, and 33.</li> <li><strong>EU Directive 2019/1937</strong> on the protection of persons who report breaches of Union law.</li> <li><strong>National transpositions</strong> of the Directive in the customer’s country of operation. See <a href="/whistleblower-laws/">whistleblower laws by country</a> .</li> <li><strong>EU Accessibility Act / EN 301 549</strong> for the reporter-facing portal. See <a href="/accessibility/">accessibility</a> and the <a href="/en-301-549-conformance/">EN 301 549 conformance statement</a> .</li> </ul> <p>EthicsPortal does not currently hold ISO/IEC 27001 certification. The platform publishes a structured self-assessment against ISO/IEC 27001:2022 Annex A controls at <a href="/iso-27001/">/iso-27001/</a> . When accreditation is obtained, the certificate scope and date will be published on <a href="/trust/#certification-status">/trust/</a> .</p> <hr> <h2 id="11-policy-violations-and-enforcement"> 11. Policy violations and enforcement <a href="#11-policy-violations-and-enforcement" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>A violation of this policy by the operator is a violation of the contractual commitments to controllers and may trigger:</p> <ul> <li>A reportable entry in the <a href="/incidents/">incident register</a> </li> <li>Notification to affected controllers under <a href="/dpa/">DPA §6.6</a> </li> <li>Notification to the competent supervisory authority where <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L1937" target="_blank" rel="noopener noreferrer">Art. 33</a> GDPR requires it</li> </ul> <p>Where a violation is suspected or reported, the operator is required to record, investigate, remediate, and disclose under the same process as any other security incident.</p> <hr> <h2 id="12-document-control"> 12. Document control <a href="#12-document-control" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Document title</td> <td>EthicsPortal Information Security Policy</td> </tr> <tr> <td>Version</td> <td>1.0</td> </tr> <tr> <td>Effective date</td> <td>2026-05-21</td> </tr> <tr> <td>Last reviewed</td> <td>2026-05-21</td> </tr> <tr> <td>Next scheduled review</td> <td>2027-05-21</td> </tr> <tr> <td>Review trigger (interim)</td> <td>Any material change to architecture, sub-processors, regulatory obligations, or the <a href="/policies/risk-register/">risk register</a> </td> </tr> <tr> <td>Owner</td> <td>Yaroslav Shmarov, operator</td> </tr> <tr> <td>Distribution</td> <td>Published on <a href="/policies/">ethicsportal.eu/policies/</a> </td> </tr> </tbody> </table> <p>This policy is reviewed annually and after any of the interim triggers above. The effective date and version are incremented when the policy is materially revised.</p> <p>Signed: Yaroslav Shmarov, on behalf of EthicsPortal — 2026-05-21.</p>support@ethicsportal.eu (EthicsPortal)https://ethicsportal.eu/policies/risk-register/Mon, 01 Jan 0001 00:00:00 +0000https://ethicsportal.eu/policies/risk-register/EthicsPortal's information-security risk register. Top risks assessed against the Service, current treatment, and residual position.<h1 id="risk-register"> Risk register <a href="#risk-register" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h1> <p><strong>Effective date:</strong> 2026-05-21 <strong>Last reviewed:</strong> 2026-05-21 <strong>Next review:</strong> 2027-05-21 <strong>Owner:</strong> Yaroslav Shmarov, operator <strong>Version:</strong> 1.0</p> <p>This register lists the top information-security risks assessed against EthicsPortal, the treatment in place, and the residual position the operator has consciously accepted. It exists so that a controller, auditor, or procurement reviewer can verify that the most material risks have been thought about, not just the ones convenient to mention.</p> <p>The register is a summary. The substantive treatment for each risk is documented on the <a href="/security/">Security</a> page, in the <a href="/dpa/">Data Processing Agreement</a> , in the <a href="/policies/business-continuity/">Business continuity plan</a> , or in the <a href="/policies/information-security/">Information security policy</a> . The register’s job is to make the trade-offs visible in one place.</p> <hr> <h2 id="assessment-scale"> Assessment scale <a href="#assessment-scale" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Level</th> <th>Impact</th> <th>Likelihood</th> </tr> </thead> <tbody> <tr> <td>Low</td> <td>Single-customer inconvenience; no personal-data exposure</td> <td>Not expected during the review window</td> </tr> <tr> <td>Medium</td> <td>Multi-customer service degradation, or personal-data exposure confined to operational metadata</td> <td>Plausible during the review window</td> </tr> <tr> <td>High</td> <td>Confidentiality breach of reporter identity or report content; or extended unavailability of a covered surface</td> <td>Reasonably foreseeable in absence of treatment</td> </tr> </tbody> </table> <p>The review window is twelve months from the effective date above.</p> <hr> <h2 id="residual-position-vocabulary"> Residual-position vocabulary <a href="#residual-position-vocabulary" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <ul> <li><strong>Accepted.</strong> The residual risk after treatment is acknowledged and accepted by the operator as a deliberate trade-off. The reasoning is stated.</li> <li><strong>Monitored.</strong> The residual risk is acceptable today but is actively watched for change; specific indicators that would trigger re-treatment are stated.</li> <li><strong>In treatment.</strong> The risk is not yet treated to the operator’s target level. The current state, the target, and the timeline are stated openly.</li> </ul> <hr> <h2 id="register"> Register <a href="#register" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <h3 id="r-01-operator-incapacity--single-person-of-failure"> R-01. Operator incapacity / single-person-of-failure <a href="#r-01-operator-incapacity--single-person-of-failure" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Medium</td> </tr> <tr> <td>Treatment</td> <td>Self-service PDF case export available to every organization admin without operator intervention. <a href="/dpa/">DPA §6.8</a> deletion-and-return rights are enforceable independent of operator availability. Application is Kamal-deployed and portable to another EU operator.</td> </tr> <tr> <td>Residual position</td> <td><strong>In treatment.</strong> A formal operator-incapacity protocol with a named legal contact is on the roadmap and not yet in place. See the <a href="/policies/business-continuity/">Business continuity plan §8</a> for the full disclosure of what is and is not in place today. Controllers concerned about this gap are encouraged to take regular self-service exports.</td> </tr> </tbody> </table> <h3 id="r-02-hetzner-outage-primary-infrastructure-provider"> R-02. Hetzner outage (primary infrastructure provider) <a href="#r-02-hetzner-outage-primary-infrastructure-provider" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Low</td> </tr> <tr> <td>Treatment</td> <td>Daily encrypted database dumps to Hetzner Object Storage (separate from compute host) plus Hetzner server-level snapshots; quarterly restore drills into a disposable environment (<a href="/security/#backups-and-restore">Security#backups-and-restore</a> ). Kamal deployment configuration is portable to an alternative EU provider for a prolonged-outage scenario.</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted.</strong> A regional Hetzner outage may consume part of the 99.5% monthly SLA budget. Cross-provider hot failover is not in place because the additional sub-processor footprint, key-distribution surface, and operational complexity outweigh the marginal availability gain at the current customer footprint. Re-evaluated annually against the <a href="/sla/">SLA</a> target.</td> </tr> </tbody> </table> <h3 id="r-03-sub-processor-personal-data-breach"> R-03. Sub-processor personal-data breach <a href="#r-03-sub-processor-personal-data-breach" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>Medium–High (varies by sub-processor and data category)</td> </tr> <tr> <td>Inherent likelihood</td> <td>Low</td> </tr> <tr> <td>Treatment</td> <td>Minimization: each sub-processor receives only the personal-data category required for its function (see <a href="/subprocessors/">Subprocessors</a> for the per-row breakdown). Encryption-at-rest under processor-managed keys means that a sub-processor with database access does not have plaintext access to report content or reporter identity (<a href="/security/#data-encryption">Security#data-encryption</a> ). 30-day sub-processor change notice and controller objection right (<a href="/dpa/">DPA §6.4</a> ).</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted.</strong> No personal data covered by the DPA is transmitted to any sub-processor whose breach would expose reporter identity in plaintext. The reporter portal does not load Cloudflare; the reporter portal does not load Crisp; no LLM sub-processor exists. The residual risk is operational metadata (handler email, billing contact) at sub-processors whose breach would not compromise reporter confidentiality.</td> </tr> </tbody> </table> <h3 id="r-04-operator-credential-theft--account-compromise"> R-04. Operator credential theft / account compromise <a href="#r-04-operator-credential-theft--account-compromise" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Low</td> </tr> <tr> <td>Treatment</td> <td>Hardware-backed two-factor authentication on all operator accounts that have production access (cloud provider, deployment, code hosting, email, password manager). Production database access requires the operator’s authenticated session; credentials are not embedded in code or shared. Append-only audit log records all actions taken by any account, including the operator’s, and cannot be edited by any user (<a href="/security/#audit-and-compliance">Security#audit-and-compliance</a> ).</td> </tr> <tr> <td>Residual position</td> <td><strong>Monitored.</strong> The risk is materially lower than typical SaaS because there are no employee credentials to compromise — the attack surface reduces to one identity. Monitored via AppSignal alerts for anomalous handler-portal authentication patterns. Trigger for re-treatment: a credible phishing attempt against the operator, or a CVE affecting the hardware-key path.</td> </tr> </tbody> </table> <h3 id="r-05-restore-failure-during-disaster-recovery"> R-05. Restore failure during disaster recovery <a href="#r-05-restore-failure-during-disaster-recovery" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Low</td> </tr> <tr> <td>Treatment</td> <td>Two complementary backup layers (database dump and server-level snapshot) in independent retention scopes. Restore drill performed at least quarterly into a disposable environment; drill date is published on <a href="/security/#backups-and-restore">Security#backups-and-restore</a> . Restore procedure documented in the <a href="/policies/business-continuity/">Business continuity plan §6</a> .</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted.</strong> RPO 24 hours and RTO 4 hours are stated in the <a href="/sla/#recovery-objectives">SLA</a> . Data written within the 24 hours preceding a catastrophic failure may be lost; this trade-off is disclosed.</td> </tr> </tbody> </table> <h3 id="r-06-reporter-network-side-attribution-leak-outside-processor-boundary"> R-06. Reporter network-side attribution leak (outside processor boundary) <a href="#r-06-reporter-network-side-attribution-leak-outside-processor-boundary" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>Medium</td> </tr> <tr> <td>Inherent likelihood</td> <td>Medium</td> </tr> <tr> <td>Treatment</td> <td>The Service does not store reporter IP addresses in the database; rate limiting uses a one-way hash that is not reversible. Application logs for reporter routes are scrubbed. File uploads have metadata stripped (EXIF / GPS / author) server-side before storage. See <a href="/security/#anonymity-and-privacy">Security#anonymity-and-privacy</a> .</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted.</strong> Network-side attribution (the reporter’s ISP, the reporter’s employer’s egress proxy, a man-in-the-middle, or a corporate-device endpoint agent) is outside the processor boundary and cannot be controlled by the Service. Reporters are informed of this on the portal and may choose to report from a personal device on an external network, or via Tor. This residual is disclosed to reporters at the point of submission, which is the only place the trade-off can be acted upon.</td> </tr> </tbody> </table> <h3 id="r-07-critical-vulnerability-in-upstream-dependency"> R-07. Critical vulnerability in upstream dependency <a href="#r-07-critical-vulnerability-in-upstream-dependency" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>Medium–High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Medium</td> </tr> <tr> <td>Treatment</td> <td>Continuous SCA on every change: <a href="https://brakemanscanner.org" rel="nofollow">Brakeman</a> for Rails-specific issues, <a href="https://github.com/rubysec/bundler-audit" rel="nofollow">bundler-audit</a> for Ruby advisories, <code>importmap audit</code> for JavaScript imports, <a href="https://docs.github.com/en/code-security/dependabot" rel="nofollow">Dependabot</a> for weekly grouped updates. End-of-life components are replaced before their upstream support window closes. See <a href="/security/#secure-development-lifecycle">Security#secure-development-lifecycle</a> and <a href="/security/#dependency-and-patch-management">Security#dependency-and-patch-management</a> . Documented vulnerability-response timelines: critical 7 days, high 30 days, medium 90 days.</td> </tr> <tr> <td>Residual position</td> <td><strong>Monitored.</strong> The Rails ecosystem is well-staffed for security disclosures. Trigger for re-treatment: a zero-day affecting Rails request-handling, ActiveRecord encryption, or PostgreSQL with no available patch.</td> </tr> </tbody> </table> <h3 id="r-08-audit-log-integrity-compromise"> R-08. Audit-log integrity compromise <a href="#r-08-audit-log-integrity-compromise" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Low</td> </tr> <tr> <td>Treatment</td> <td>Audit-log entries are written append-only and cannot be edited or deleted by any user, including organization administrators. Entries are included in PDF case exports for regulatory review. Database-level access to the audit-log table is not exposed through the application surface. See <a href="/security/#audit-and-compliance">Security#audit-and-compliance</a> .</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted.</strong> A privileged database-level intervention by the operator could, in principle, alter audit-log rows. This is the same intervention that could be used to read encrypted columns and is governed by the privileged-access summary available during procurement review. The append-only contract holds at the application surface, which is where customer trust is placed.</td> </tr> </tbody> </table> <h3 id="r-09-reporter-passcode-loss"> R-09. Reporter passcode loss <a href="#r-09-reporter-passcode-loss" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>Medium</td> </tr> <tr> <td>Inherent likelihood</td> <td>Medium (reporters are anonymous and may not have password-recovery channels)</td> </tr> <tr> <td>Treatment</td> <td>The 6-digit passcode is stored only as a bcrypt digest and cannot be recovered by the operator or by any handler. Reporters are informed at submission that the passcode is non-recoverable. Handlers may invite a reporter to re-submit or continue the conversation by an alternative channel.</td> </tr> <tr> <td>Residual position</td> <td><strong>Accepted by design.</strong> Recoverability of the passcode is incompatible with the reporter-anonymity model: a recovery channel would require an identifier (email, phone) that defeats anonymity, or an operator-side reset that would allow the operator to impersonate the reporter. The trade-off is disclosed to reporters at the point of choosing the passcode.</td> </tr> </tbody> </table> <h3 id="r-10-regulatory-change-requiring-re-architecture"> R-10. Regulatory change requiring re-architecture <a href="#r-10-regulatory-change-requiring-re-architecture" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h3> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Inherent impact</td> <td>Medium–High</td> </tr> <tr> <td>Inherent likelihood</td> <td>Medium (Member-State transpositions and AI-Act delegated acts continue to evolve)</td> </tr> <tr> <td>Treatment</td> <td>Interpretive positions on ambiguous Directive 2019/1937 provisions are documented openly in the <a href="/directive-interpretations/">Directive 2019/1937 interpretations</a> , so a controller can verify alignment with their counsel’s reading before subscribing. Per-country law summaries are published in <a href="/whistleblower-laws/">whistleblower laws by country</a> and reviewed when national-law text changes. Material changes to processing (sub-processors, AI use, transfers) are notified to controllers under <a href="/dpa/">DPA §6.4</a> .</td> </tr> <tr> <td>Residual position</td> <td><strong>Monitored.</strong> Trigger for re-treatment: ECJ judgment on a Directive 2019/1937 question that contradicts a published interpretation; CJEU judgment on international-transfer adequacy affecting an EU sub-processor; AI-Act delegated act extending obligations to AI-free processors.</td> </tr> </tbody> </table> <hr> <h2 id="risks-consciously-not-in-this-register"> Risks consciously not in this register <a href="#risks-consciously-not-in-this-register" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <p>The following are recognized risk categories that this register deliberately omits because they are eliminated by design rather than treated:</p> <ul> <li><strong>AI / LLM exposure of report content.</strong> No LLM, generative-AI, or AI-classifier service is engaged as a sub-processor. Report content is not transmitted to such services for any purpose. The attack surface (prompt injection, hallucinated compliance evidence, unauthorized retention by third parties) is therefore not present. Source: <a href="/dpa/">DPA §6.10</a> .</li> <li><strong>Reporter PII shared with handlers without justification.</strong> The Service does not surface reporter IP, browser fingerprint, or device identifiers to handlers, because none of these are collected or stored.</li> <li><strong>Cross-tenant data leakage at the application layer.</strong> Pundit-policy authorization is checked on every controller action; multi-tenant isolation is enforced at the request boundary, not via row-level visibility filters that can be bypassed.</li> </ul> <p>If any of these design constraints changes, the risk re-enters this register.</p> <hr> <h2 id="review-cadence"> Review cadence <a href="#review-cadence" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Trigger</th> <th>Action</th> </tr> </thead> <tbody> <tr> <td>Annual</td> <td>Full review of every register row; residual positions re-affirmed or revised</td> </tr> <tr> <td>Material architecture change</td> <td>Affected rows reviewed and revised in the same change</td> </tr> <tr> <td>Sub-processor added or replaced</td> <td>R-03 reviewed; new row added if the change introduces a category not already represented</td> </tr> <tr> <td>Material incident in the <a href="/incidents/">incident register</a> </td> <td>Root-cause-relevant rows reviewed; treatment updated if the incident revealed a control gap</td> </tr> <tr> <td>Material change to the <a href="/policies/information-security/">Information security policy</a> or <a href="/policies/business-continuity/">Business continuity plan</a> </td> <td>Affected rows reviewed for consistency</td> </tr> </tbody> </table> <p>Review actions are recorded in the document-control section below.</p> <hr> <h2 id="document-control"> Document control <a href="#document-control" class="ml-1 text-base-content/30 hover:text-base-content/60 no-underline" aria-label="Link to this section">#</a> </h2> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Document title</td> <td>EthicsPortal Risk Register</td> </tr> <tr> <td>Version</td> <td>1.0</td> </tr> <tr> <td>Effective date</td> <td>2026-05-21</td> </tr> <tr> <td>Last reviewed</td> <td>2026-05-21</td> </tr> <tr> <td>Next scheduled review</td> <td>2027-05-21</td> </tr> <tr> <td>Owner</td> <td>Yaroslav Shmarov, operator</td> </tr> <tr> <td>Distribution</td> <td>Published on <a href="/policies/">ethicsportal.eu/policies/</a> </td> </tr> </tbody> </table> <p>Signed: Yaroslav Shmarov, on behalf of EthicsPortal — 2026-05-21.</p>support@ethicsportal.eu (EthicsPortal)