> Self-assessment of EthicsPortal against the 93 controls in ISO/IEC 27001:2022 Annex A. Status and evidence for every control. Not an accredited certification.

Source: https://ethicsportal.eu/hr/iso-27001/
Updated: 2026-08-24

---

# ISO/IEC 27001:2022 Annex A control map

EthicsPortal does not currently hold accredited ISO/IEC 27001 certification. This page is a structured self-assessment of EthicsPortal against the same control set an external auditor would evaluate --- all 93 Annex A controls --- so a procurement reviewer can verify the substance directly.

The self-assessment is published openly. Where a control is not in place, that fact is stated openly with a target. Where a control does not apply given the structure of the Service (for example, personnel controls in a zero-employee organization), that fact is stated openly with the reasoning.

When EthicsPortal pursues accredited certification, the certificate scope and date will be published on [/trust/](/trust/#certification-status) alongside this page.

Last updated: 2026-08-15.

---

## How to read this page

| Status | Meaning |
|---|---|
| **Implemented** | The control is in place and operating; evidence is published or available during procurement review |
| **Self-assessed** | The control is in place and operates substantively as ISO/IEC 27001:2022 describes, but has not been independently audited |
| **Compensating** | The primary form of the control does not apply (typically because of the sole-operator structure), and an alternative arrangement achieves the same security objective |
| **Inherited** | The control is provided by a named sub-processor (typically [Hetzner](/subprocessors/)) under its own certification regime |
| **Not applicable** | The control does not apply given the structure of the Service; the reason is stated |
| **In treatment** | The control is not yet in place at the operator's target level; the current state, the target, and the planned action are stated openly |
| **Inherited + Implemented** | The control has both an infrastructure layer (provided by a named sub-processor under its own certification) and an application layer (implemented in EthicsPortal); both are in place. In the summary tally below, such hybrids are counted under **Implemented** |

The companion documents this page cites:

- [Information security policy](/policies/information-security/)
- [Business continuity plan](/policies/business-continuity/)
- [Risk register](/policies/risk-register/)
- [Security](/security/) (technical and organizational measures)
- [Data Processing Agreement](/dpa/)
- [Subprocessors](/subprocessors/)
- [Incident register](/incidents/)

---

## A.5 Organizational controls

| Control | Title | Status | Evidence |
|---|---|---|---|
| A.5.1 | Policies for information security | Implemented | [Information security policy](/policies/information-security/) |
| A.5.2 | Information security roles and responsibilities | Implemented | [IS policy §4](/policies/information-security/) --- single named operator holds all security roles |
| A.5.3 | Segregation of duties | Compensating | Sole-operator structure makes traditional duty segregation inapplicable. Compensating arrangement: append-only audit log records every action; the automated suite and static analysis enforce non-negotiable invariants before deploy, and every commit is cryptographically signed so authorship is attributable rather than asserted ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle), [Risk register R-04](/policies/risk-register/)) |
| A.5.4 | Management responsibilities | Implemented | Operator is sole management; commitments stated in [IS policy](/policies/information-security/) §3 |
| A.5.5 | Contact with authorities | Self-assessed | Direct contact with Polish supervisory authority (UODO) and customer-side DPAs through the breach-notification path; no standing liaison |
| A.5.6 | Contact with special interest groups | Self-assessed | CVE feeds, Rails security mailing list, Ruby Advisory Database subscribed via tooling ([Security#dependency-and-patch-management](/security/#dependency-and-patch-management)) |
| A.5.7 | Threat intelligence | Self-assessed | Continuous SCA via Brakeman, bundler-audit, Dependabot; no formal threat-intel program. [Risk register R-07](/policies/risk-register/) states the residual position |
| A.5.8 | Information security in project management | Implemented | [Security#secure-development-lifecycle](/security/#secure-development-lifecycle) --- features with new personal-data flows are reviewed at design stage (e.g. the oral-reporting voice channel was designed to anonymize audio locally and purge the raw recording, introducing no new sub-processor) |
| A.5.9 | Inventory of information and other associated assets | Implemented | [DPA §3](/dpa/) lists processed data categories; [Subprocessors](/subprocessors/) lists external assets; privileged-access summary available during procurement review |
| A.5.10 | Acceptable use of information and other associated assets | Compensating | No employees; operator's own use is governed by the [IS policy](/policies/information-security/) and the [Terms](/terms/) §7 |
| A.5.11 | Return of assets | Not applicable | No employees, no joiner/leaver process. Customer-side asset return (data export and deletion) is governed by [DPA §6.8](/dpa/) |
| A.5.12 | Classification of information | Implemented | [DPA §3](/dpa/) classifies each data category (reporter identity, report content, communications, attachments, operational data, audit-log) and states encryption status |
| A.5.13 | Labelling of information | Implemented | Encryption status of each field is identified in [DPA §3](/dpa/) and [Security#data-encryption](/security/#data-encryption) |
| A.5.14 | Information transfer | Implemented | All connections use HTTPS/TLS ([Security#data-encryption](/security/#data-encryption)); transfers to sub-processors are governed by written DPAs ([Subprocessors](/subprocessors/)) |
| A.5.15 | Access control | Implemented | [Security#access-control](/security/#access-control) --- Pundit policy authorization on every controller action; three-role RBAC (admin/member/viewer); opt-in TOTP 2FA; sliding session lifecycle |
| A.5.16 | Identity management | Implemented | Magic-link authentication; per-user identity tracked through the membership lifecycle; deactivation cuts access at the request boundary |
| A.5.17 | Authentication information | Implemented | Reporter passcodes bcrypt-hashed and non-recoverable; handler authentication via passwordless magic-link with opt-in TOTP 2FA (recommended at onboarding, not enforced); operator production accounts use mandatory hardware-key 2FA ([Risk register R-04](/policies/risk-register/)); no plaintext password storage |
| A.5.18 | Access rights | Implemented | Three roles (admin, member, viewer) with least-privilege defaults; read-only viewer role for auditors and legal counsel; periodic review via member deactivation and audit-log review ([Security#access-control](/security/#access-control)) |
| A.5.19 | Information security in supplier relationships | Implemented | [Subprocessors](/subprocessors/) page lists each supplier with data category, jurisdiction, and purpose; [DPA §6.4](/dpa/) governs the relationship |
| A.5.20 | Addressing information security within supplier agreements | Implemented | Written DPA in place with each sub-processor under GDPR Art. 28 |
| A.5.21 | Managing information security in the ICT supply chain | Self-assessed | SCA on every dependency change; sub-processor change notice on additions ([DPA §6.4](/dpa/)). No formal upstream-supplier audit program |
| A.5.22 | Monitoring, review and change management of supplier services | Self-assessed | Sub-processor SLAs and security disclosures monitored informally; no formal annual supplier-review program |
| A.5.23 | Information security for use of cloud services | Implemented | EU-only cloud hosting documented on [Security#infrastructure](/security/#infrastructure) and [Subprocessors](/subprocessors/); Standard Contractual Clauses in place for the one named non-EU sub-processor (Cloudflare, marketing-site CDN only) |
| A.5.24 | Information security incident management planning and preparation | Implemented | [Business continuity plan §3--5](/policies/business-continuity/) defines triggers, decision authority, communication; [Incident register](/incidents/) defines disclosure timeline |
| A.5.25 | Assessment and decision on information security events | Implemented | [BCP §3](/policies/business-continuity/) defines trigger conditions; operator is sole decision authority |
| A.5.26 | Response to information security incidents | Implemented | [BCP §4--7](/policies/business-continuity/); [Incident register](/incidents/) records every material incident |
| A.5.27 | Learning from information security incidents | Implemented | [Incident register](/incidents/) final entry includes root cause, remediation, and lessons learned within 30 days of containment |
| A.5.28 | Collection of evidence | Implemented | Append-only audit log: PostgreSQL triggers reject changes to core audit content and table truncation while permitting required foreign-key nullification; application deletion paths are limited to retention and GDPR Art. 17 erasure flows; privileged database intervention remains a documented residual risk ([Risk register R-08](/policies/risk-register/#r-08-audit-log-integrity-compromise)). The trail is preserved in all PDF case exports; per-incident written log retained for audit |
| A.5.29 | Information security during disruption | Implemented | [Business continuity plan](/policies/business-continuity/) §1--7 |
| A.5.30 | ICT readiness for business continuity | Implemented | [BCP §2 & §6](/policies/business-continuity/); RPO 24h / RTO 4h published in [SLA](/sla/#recovery-objectives); automated monthly restore-verification drill in CI |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Implemented | [Directive coverage map](/directive-coverage/), [Directive interpretations](/directive-interpretations/), [Whistleblower laws by country](/whistleblower-laws/), GDPR Art. 32 coverage on [Security](/security/) |
| A.5.32 | Intellectual property rights | Implemented | [Terms §8](/terms/) covers customer-content IP; [Terms §12](/terms/) provides IP indemnification with standard carve-outs |
| A.5.33 | Protection of records | Implemented | Append-only audit log; retention-based deletion ([Security#audit-and-compliance](/security/#audit-and-compliance)) |
| A.5.34 | Privacy and protection of personal identifiable information (PII) | Implemented | [Privacy policy](/privacy/), [DPA](/dpa/), [Security#anonymity-and-privacy](/security/#anonymity-and-privacy); GDPR Art. 14 notice to third parties named in a report is documented as the controller's (customer's) responsibility, not automated by the platform; data-subject rights including portability (Art. 20) and complaint to a supervisory authority (Art. 77) documented; GDPR Art. 32 measures documented |
| A.5.35 | Independent review of information security | In treatment | No external penetration test or independent audit currently on record. Stated openly on [Trust#certification-status](/trust/#certification-status). Target: external pen test once post-revenue budget permits; published here when on record |
| A.5.36 | Compliance with policies, rules and standards for information security | Implemented | This control map plus the [IS policy](/policies/information-security/), [BCP](/policies/business-continuity/), and [Risk register](/policies/risk-register/) form the compliance frame; the automated suite and static analysis enforce those invariants on every change and block the deploy on failure |
| A.5.37 | Documented operating procedures | Implemented | SDLC documented on [Security](/security/#secure-development-lifecycle); restore procedure documented in [BCP §6](/policies/business-continuity/); deployment via versioned Kamal configuration |

---

## A.6 People controls

| Control | Title | Status | Evidence |
|---|---|---|---|
| A.6.1 | Screening | Not applicable | No employees or contractors. Sole-operator structure disclosed on [Trust#continuity-and-personnel](/trust/#continuity-and-personnel). Operator screening (identity, tax registration) is verifiable through the published registry information |
| A.6.2 | Terms and conditions of employment | Not applicable | No employees |
| A.6.3 | Information security awareness, education and training | Not applicable | No employees. Operator self-directed via the special-interest-group subscriptions noted at A.5.6 |
| A.6.4 | Disciplinary process | Not applicable | No employees |
| A.6.5 | Responsibilities after termination or change of employment | Not applicable | No employees |
| A.6.6 | Confidentiality or non-disclosure agreements | Implemented | Operator's confidentiality obligation to controllers is in [DPA §6.2](/dpa/); customer-facing NDAs available on request during procurement review |
| A.6.7 | Remote working | Self-assessed | Operator works remotely; workstation hardened with full-disk encryption, screen-lock, and OS auto-update; production access only via the operator's authenticated session. No separate remote-working policy document |
| A.6.8 | Information security event reporting | Implemented | [Responsible disclosure](/security/#responsible-disclosure) inbox at security@ethicsportal.eu; [Incident register](/incidents/) records confirmed events |

---

## A.7 Physical controls

EthicsPortal does not operate its own physical infrastructure. The physical controls below are inherited from [Hetzner](/subprocessors/) (Nuremberg, Germany --- ISO 27001-certified data centers under Hetzner's own scope) for hosting controls, or fulfilled at the operator-workstation level for endpoint controls.

| Control | Title | Status | Evidence |
|---|---|---|---|
| A.7.1 | Physical security perimeters | Inherited | Hetzner Nuremberg data center under Hetzner certification scope |
| A.7.2 | Physical entry | Inherited | Hetzner Nuremberg data center |
| A.7.3 | Securing offices, rooms and facilities | Not applicable | No EthicsPortal office processes customer data |
| A.7.4 | Physical security monitoring | Inherited | Hetzner Nuremberg data center |
| A.7.5 | Protecting against physical and environmental threats | Inherited | Hetzner Nuremberg data center |
| A.7.6 | Working in secure areas | Not applicable | No EthicsPortal physical secure areas |
| A.7.7 | Clear desk and clear screen | Self-assessed | Operator workstation has automatic screen-lock and clear-desk practice for any printed materials touching customer data (rare in practice) |
| A.7.8 | Equipment siting and protection | Self-assessed | Operator workstation; production equipment is at Hetzner |
| A.7.9 | Security of assets off-premises | Self-assessed | Operator workstation = primary off-premises asset; full-disk encryption, screen-lock, hardware-key 2FA on production-access accounts |
| A.7.10 | Storage media | Self-assessed | No removable media is used for production data. Backups exist only in EU cloud object storage |
| A.7.11 | Supporting utilities | Inherited | Hetzner Nuremberg data center |
| A.7.12 | Cabling security | Inherited | Hetzner Nuremberg data center |
| A.7.13 | Equipment maintenance | Inherited | Hetzner Nuremberg data center |
| A.7.14 | Secure disposal or re-use of equipment | Self-assessed | Operator workstation is full-disk encrypted, so destruction of the encryption key on re-use suffices. Hetzner handles its own equipment disposal under its certification |

---

## A.8 Technological controls

| Control | Title | Status | Evidence |
|---|---|---|---|
| A.8.1 | User end point devices | Self-assessed | Operator workstation: full-disk encryption, screen-lock, OS auto-update, hardware-key 2FA on production-access accounts |
| A.8.2 | Privileged access rights | Implemented | Only the operator has production access; access requires the operator's authenticated session with hardware-key 2FA; privileged-access summary available during procurement review |
| A.8.3 | Information access restriction | Implemented | [Security#access-control](/security/#access-control) --- Pundit policy authorization on every controller action; RBAC; least privilege |
| A.8.4 | Access to source code | Implemented | Private repository on Git hosting with hardware-key 2FA enforced on the operator's account; no shared credentials. Commits and tags are signed with an SSH key and verified against a pinned allowed-signers list, so the authorship of every revision is cryptographically attributable |
| A.8.5 | Secure authentication | Implemented | Magic-link primary authentication with encrypted pending-auth token and sliding session expiry; opt-in TOTP 2FA for handler/admin accounts (not enforced); bcrypt-hashed reporter passcodes ([Security#access-control](/security/#access-control)) |
| A.8.6 | Capacity management | Self-assessed | AppSignal performance monitoring on the handler portal; informal capacity planning. No formal capacity-management plan document |
| A.8.7 | Protection against malware | Implemented | ClamAV scan on every uploaded file via a swappable AntivirusScanner client; uploads are gated from delivery (HTTP 403) until scanned clean, and infected files are purged ([Security#virus-scanning](/security/#virus-scanning)) |
| A.8.8 | Management of technical vulnerabilities | Implemented | Brakeman, bundler-audit, importmap audit on every change plus a daily dependency-audit CI cron to catch new CVEs on unchanged dependencies; Dependabot weekly grouped updates; documented response SLA (critical 7d, high 30d, medium 90d) ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.9 | Configuration management | Implemented | All infrastructure configuration is version-controlled (Kamal deployment configuration); no out-of-band production changes |
| A.8.10 | Information deletion | Implemented | Retention-based automatic deletion (12/24/36/48/60 months, country-minimum enforced); 18-month inactivity auto-close starts the retention clock; organization soft-delete with retention-aware auto-purge; deletion on subscription termination within 30 days on request ([DPA §6.8](/dpa/), [Security#audit-and-compliance](/security/#audit-and-compliance)) |
| A.8.11 | Data masking | Implemented | Compliance-report PDF excludes sensitive report content; handler-portal views display "Case handler" rather than handler identity to reporters; admin-side views surface only authorized fields; EXIF/metadata stripped from uploaded images, PDFs, audio and video (libvips + exiftool); oral-report audio pitch-shifted locally and the raw recording purged |
| A.8.12 | Data leakage prevention | Implemented | No personal-data egress to external services; no AI/LLM sub-processor ([DPA §6.10](/dpa/)); subprocessor list strictly scoped per-row ([Subprocessors](/subprocessors/)) |
| A.8.13 | Information backup | Implemented | Daily PostgreSQL dumps via a Kamal accessory to Hetzner Object Storage (separate from the compute host), with 21 current daily backups and permanent deletion of noncurrent versions after 7 additional days; dumps protected by Hetzner Object Storage at-rest encryption, and application-layer field encryption persists inside the dump; automated monthly lifecycle-drift and restore-verification checks plus on-demand `bin/backup-restore-test` ([Security#backups-and-restore](/security/#backups-and-restore)) |
| A.8.14 | Redundancy of information processing facilities | Self-assessed | No cross-provider hot failover at current customer footprint. Backups and restore procedures provide a documented recovery path within RTO. Trade-off stated openly in [Risk register R-02](/policies/risk-register/) |
| A.8.15 | Logging | Implemented | Append-only audit trail for every action (timestamp, actor, action type) preserved for the configured retention; AppSignal records request telemetry with reporter session data and PII excluded (see A.8.16) |
| A.8.16 | Monitoring activities | Implemented | AppSignal APM across the application, configured to preserve reporter anonymity: session-data transmission is disabled and request parameters are filtered, so reporter PII and IP addresses are never shipped to or logged by the APM ([Subprocessors](/subprocessors/)) |
| A.8.17 | Clock synchronization | Implemented | NTP via the host operating system; all timestamps recorded in UTC |
| A.8.18 | Use of privileged utility programs | Self-assessed | Operator has shell access to production for non-routine maintenance; use is recorded in the operator's incident/maintenance log. No shared admin accounts |
| A.8.19 | Installation of software on operational systems | Implemented | Production installations only via the Kamal deployment configuration. No manual package installation on production hosts |
| A.8.20 | Networks security | Inherited + Implemented | Network-level protection inherited from Hetzner; application-level TLS termination and rate-limiting implemented in the application ([Security#rate-limiting](/security/#rate-limiting)) |
| A.8.21 | Security of network services | Inherited | Hetzner network services |
| A.8.22 | Segregation of networks | Self-assessed | Production is isolated from operator workstation by network boundary; non-production environments do not contain production personal data ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.23 | Web filtering | Not applicable | No employee egress network to filter |
| A.8.24 | Use of cryptography | Implemented | Non-deterministic encryption at rest via Rails ActiveRecord Encryption; HTTPS/TLS in transit; bcrypt for passcodes ([Security#data-encryption](/security/#data-encryption)). Customer-managed keys not supported and the reason is stated in [DPA §6.11](/dpa/) |
| A.8.25 | Secure development life cycle | Implemented | [Security#secure-development-lifecycle](/security/#secure-development-lifecycle) |
| A.8.26 | Application security requirements | Implemented | Encryption coverage, authorization scope, audit-log emission, and input-validation requirements are on the pre-deploy checklist for every change and are covered by automated tests that block the deploy on failure ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.27 | Secure system architecture and engineering principles | Implemented | Encryption boundary, append-only audit log, RBAC at the request boundary, and reporter-anonymity properties are architectural commitments documented on [Security](/security/) |
| A.8.28 | Secure coding | Implemented | Framework-level defaults (parameterized queries, strong parameters, output escaping, CSRF) are the floor; static analysis enforces non-negotiable items ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.29 | Security testing in development and acceptance | Implemented | Brakeman + bundler-audit + importmap audit on every change; automated test coverage of authorization paths, encryption invariants, audit-log emission, and rate-limit enforcement |
| A.8.30 | Outsourced development | Not applicable | All development is by the sole operator; no outsourced development |
| A.8.31 | Separation of development, test and production environments | Implemented | Production is isolated; non-production environments use synthetic fixtures; no production personal data is used outside production ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.32 | Change management | Implemented | Every production change is committed to version control, passes the full automated suite and static analysis before deploy, and is recorded --- deploy path in the CI run history, rationale in a per-change decision log. A failing suite blocks the deploy. Approval follows the documented pre-deploy checklist; approval roles are described during procurement review ([Security#secure-development-lifecycle](/security/#secure-development-lifecycle)) |
| A.8.33 | Test information | Implemented | Non-production environments use synthetic data only |
| A.8.34 | Protection of information systems during audit testing | Not applicable | No third-party audit currently scoped. When an audit is conducted, the controls protecting customer data during the audit (read-only access where possible, scoped credentials with expiry, audit-log review post-engagement) will be documented in a per-audit plan |

---

## Summary

Of the 93 controls in ISO/IEC 27001:2022 Annex A:

| Status | Count | Read as |
|---|---|---|
| Implemented | 55 | In place and operating; evidence published or available during procurement review |
| Self-assessed | 16 | In place and operating substantively as the control describes, but not independently audited |
| Inherited | 8 | Provided by named sub-processor (primarily Hetzner) under its own certification regime |
| Not applicable | 11 | Does not apply given the sole-operator structure (most A.6 People controls and one-off cases) |
| Compensating | 2 | Primary form not applicable; alternative arrangement achieves the same objective (A.5.3 segregation of duties, A.5.10 acceptable use) |
| In treatment | 1 | Not yet in place at the operator's target level; target stated openly (A.5.35 independent review) |

The single **In treatment** control --- independent review of information security (A.5.35) --- is the gap that an accredited certification or an independent penetration test would close. The operator's position on this is stated openly on [Trust#certification-status](/trust/#certification-status): no external pen test or audit is currently on record, and the scope, date, and remediation summary will be published here when one is performed.

---

## Changes in this revision (v2.5, 2026-08-15)

This revision codifies the backup lifecycle and aligns the published retention statement with the enforced policy.

- **A.8.13** --- the repository now defines the complete Object Storage lifecycle, production is checked for drift during the monthly restore workflow, and PostgreSQL backups have 21 days of current versions followed by 7 days of recoverable noncurrent versions. The 28-day maximum policy window leaves room inside the DPA's 30-day deletion commitment.

No control changed status; the tally is unchanged from v2.4.

---

## Changes in this revision (v2.4, 2026-08-15)

This revision narrows the audit-integrity wording to the control the Service actually operates.

- **A.5.28 and A.8.15** --- PostgreSQL triggers reject changes to core audit content and table truncation, while deliberately allowing foreign-key nullification when a related record is erased. Application deletion paths remain limited to retention and GDPR Art. 17 erasure flows, but a privileged database operator could disable the triggers or issue a direct deletion. That residual risk is now stated explicitly rather than calling the rows unconditionally immutable; this supersedes the broader audit-integrity wording recorded in v2.2.

No control changed status; the tally is unchanged from v2.3.

---

## Changes in this revision (v2.3, 2026-08-15)

This revision follows a change to how the test suite gates a deploy, and corrects the rows that described the previous arrangement.

- **A.5.3 and A.5.36** --- both stated that static analysis enforces invariants *at merge*. There are no merges: changes go to the main branch directly and the gate is the deploy, not a merge. A.5.36 additionally said "CI-enforced"; the suite now runs either on a hosted runner or on a developer workstation, with the completed run recorded as a commit status that the pipeline verifies before it will skip the hosted run. Both rows now describe the deploy gate. A.5.3 is the compensating control standing in for segregation of duties, so its accuracy carries weight.
- **A.8.4** --- commits and tags are now signed with an SSH key and verified against a pinned allowed-signers list. Authorship of a revision is cryptographically attributable rather than asserted, which also strengthens the evidence position under A.5.28 and A.8.32.
- **A.8.26 and A.8.32** --- restated in the same pass. Both previously described peer "code review", which the operating structure does not provide; they now describe the written pre-deploy checklist with the automated suite as the enforcing gate. The checklist is a maintained document, available during procurement review.

No control changed status; the tally is unchanged from v2.2.

---

## Changes in this revision (v2.2, 2026-07-18)

This revision re-verified every control against the running code and the companion documents. One correction was found:

- **A.8.13** --- database-backup retention is **30 days**, not the 7 days stated in v2.1 (`BACKUP_KEEP_DAYS=30` in the Kamal backup accessory, matched by the prune step in the backup script). The restore-verification cadence (automated monthly in CI) and every other backup statement are unchanged and re-confirmed.

Every other technical claim was re-confirmed against code: the non-deterministic ActiveRecord encryption model (A.8.24) and the encrypted fields it covers (A.5.12--A.5.13); the append-only audit log enforced by Postgres triggers, with DELETE permitted only for the Art. 17 erasure cascade (A.5.28, A.8.15); the three-role admin/member/viewer RBAC with a read-only viewer (A.5.15, A.5.18); Pundit authorization on every controller action (A.8.3); the retention lifecycle --- 12/24/36/48/60-month options, country-minimum enforcement, 18-month inactivity auto-close, and retention-aware organization purge (A.8.10); asynchronous ClamAV scanning with 403 delivery-gating until clean (A.8.7); libvips + exiftool metadata stripping and local pitch-shift anonymization of oral-report audio (A.8.11); the AppSignal anonymity configuration --- session-data transmission disabled and parameters filtered (A.8.16); and the no-AI/LLM-sub-processor position (A.8.12). No control changed status; the tally is unchanged from v2.1.

---

## Changes in this revision (v2.1, 2026-06-18)

This revision corrects one overstatement found during a documentation accuracy review:

- **A.5.34** --- GDPR Art. 14 notice to third parties named in a report is documented as the **controller's (customer's) responsibility**, not a platform feature. The v2.0 wording below ("Art. 14 third-party notice handling ... added") overstated it; the control row now states the accurate position.

---

## Changes in this revision (v2.0, 2026-06-17)

This revision re-verified every control against the running code and the companion documents. Substantive changes since v1.0:

- **A.8.7** --- malware scanning re-described accurately: the ClamAV scan runs asynchronously after upload through a swappable AntivirusScanner client, and uploads are gated from delivery (HTTP 403) until scanned clean. The earlier "scanned before delivery" wording was imprecise.
- **A.5.17 / A.8.5 / A.5.15** --- handler TOTP 2FA is **opt-in and recommended at onboarding, not enforced** (it is no longer a hard gate on report handling). Mandatory hardware-key 2FA remains on operator production accounts.
- **A.5.15 / A.5.18** --- RBAC now has three roles: admin, member, and a read-only **viewer** role for auditors and legal counsel.
- **A.8.10** --- a **48-month** retention option was added (now 12/24/36/48/60); 18-month inactivity auto-close and retention-aware organization soft-delete/auto-purge were added.
- **A.8.11** --- metadata stripping (libvips + exiftool) and local pitch-shift anonymization of oral-report audio were added.
- **A.8.13 / A.5.30** --- backup wording corrected: dumps are protected by Hetzner Object Storage at-rest encryption (no application-managed dump encryption), and the restore-verification drill is **automated monthly in CI**, not quarterly.
- **A.8.16 / A.8.15** --- AppSignal APM runs across the application; reporter anonymity is preserved by disabling session-data transmission and filtering parameters, not by excluding the reporter portal from instrumentation.
- **A.5.34** --- Art. 14 third-party notice handling and documented data-subject rights (Art. 20 portability, Art. 77 complaint) were added. *(Superseded by v2.1 above: Art. 14 third-party notice is the controller's responsibility, not a platform feature.)*

The status tally is unchanged from v1.0: the single **In treatment** control remains A.5.35 (independent review). No new control moved into or out of scope.

---

## Document control

| Field | Value |
|---|---|
| Document title | EthicsPortal ISO/IEC 27001:2022 Annex A Control Map |
| Version | 2.4 |
| Effective date | 2026-08-15 |
| Last reviewed | 2026-08-15 |
| Next scheduled review | 2027-07-18 |
| Review trigger (interim) | Material change to the [Information security policy](/policies/information-security/), [Business continuity plan](/policies/business-continuity/), or [Risk register](/policies/risk-register/); addition or replacement of a sub-processor; engagement of external review |
| Owner | Yaroslav Shmarov, operator |

This page is not an attestation of certification. It is a self-assessment that lets a procurement reviewer evaluate the same evidence an external auditor would. Material discrepancies between this page and the actual operation of the Service should be reported to [security@ethicsportal.eu](mailto:security@ethicsportal.eu).