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/ alongside this page.
Last updated: 2026-05-21.
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 ) 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
- Business continuity plan
- Risk register
- Security (technical and organizational measures)
- Data Processing Agreement
- Subprocessors
- Incident register
A.5 Organizational controls #
| Control | Title | Status | Evidence |
|---|---|---|---|
| A.5.1 | Policies for information security | Implemented | Information security policy |
| A.5.2 | Information security roles and responsibilities | Implemented | IS policy §4 — 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; static analysis enforces non-negotiable invariants at merge (Security#secure-development-lifecycle , Risk register R-04 ) |
| A.5.4 | Management responsibilities | Implemented | Operator is sole management; commitments stated in IS policy §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 ) |
| A.5.7 | Threat intelligence | Self-assessed | Continuous SCA via Brakeman, bundler-audit, Dependabot; no formal threat-intel program. Risk register R-07 states the residual position |
| A.5.8 | Information security in project management | Implemented | Security#secure-development-lifecycle — features with new personal-data flows are reviewed at design stage |
| A.5.9 | Inventory of information and other associated assets | Implemented | DPA §3 lists processed data categories; 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 and the 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 |
| A.5.12 | Classification of information | Implemented | DPA §3 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 and Security#data-encryption |
| A.5.14 | Information transfer | Implemented | All connections use HTTPS/TLS (Security#data-encryption ); transfers to sub-processors are governed by written DPAs (Subprocessors ) |
| A.5.15 | Access control | Implemented | Security#access-control — Pundit policy authorization, RBAC, 2FA, 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 magic-link plus TOTP; no plaintext password storage |
| A.5.18 | Access rights | Implemented | Role-based with least-privilege defaults; periodic review via member deactivation and audit-log review (Security#access-control ) |
| A.5.19 | Information security in supplier relationships | Implemented | Subprocessors page lists each supplier with data category, jurisdiction, and purpose; DPA §6.4 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 ). 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 and 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 defines triggers, decision authority, communication; Incident register defines disclosure timeline |
| A.5.25 | Assessment and decision on information security events | Implemented | BCP §3 defines trigger conditions; operator is sole decision authority |
| A.5.26 | Response to information security incidents | Implemented | BCP §4–7 ; Incident register records every material incident |
| A.5.27 | Learning from information security incidents | Implemented | Incident register 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 preserved in all PDF case exports; per-incident written log retained for audit |
| A.5.29 | Information security during disruption | Implemented | Business continuity plan §1–7 |
| A.5.30 | ICT readiness for business continuity | Implemented | BCP §2 & §6 ; RPO 24h / RTO 4h published in SLA ; quarterly restore drill |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Implemented | Directive coverage map , Directive interpretations , Whistleblower laws by country , GDPR Art. 32 coverage on Security |
| A.5.32 | Intellectual property rights | Implemented | Terms §8 covers customer-content IP; Terms §12 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 ) |
| A.5.34 | Privacy and protection of personal identifiable information (PII) | Implemented | Privacy policy , DPA , Security#anonymity-and-privacy ; 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 . 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 , BCP , and Risk register form the compliance frame; CI-enforced static analysis enforces invariants at merge |
| A.5.37 | Documented operating procedures | Implemented | SDLC documented on Security ; restore procedure documented in BCP §6 ; 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 . 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 ; 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 inbox at security@ethicsportal.eu ; Incident register records confirmed events |
A.7 Physical controls #
EthicsPortal does not operate its own physical infrastructure. The physical controls below are inherited from Hetzner (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 — 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 |
| A.8.5 | Secure authentication | Implemented | Magic-link primary authentication; TOTP-based 2FA for handler/admin accounts; bcrypt-hashed reporter passcodes (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 virus scan on every uploaded file before delivery; infected files blocked and removed (Security#virus-scanning ) |
| A.8.8 | Management of technical vulnerabilities | Implemented | Brakeman, bundler-audit, importmap audit on every change; Dependabot weekly grouped updates; documented response SLA (critical 7d, high 30d, medium 90d) (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/60 months); deletion on subscription termination within 30 days on request (DPA §6.8 , 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 |
| A.8.12 | Data leakage prevention | Implemented | No personal-data egress to external services; no AI/LLM sub-processor (DPA §6.10 ); subprocessor list strictly scoped per-row (Subprocessors ) |
| A.8.13 | Information backup | Implemented | Daily encrypted PostgreSQL dumps to Hetzner Object Storage (separate from compute host); Hetzner server-level snapshots; 7-day retention; quarterly restore drill (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 |
| A.8.15 | Logging | Implemented | Append-only audit trail for every action (timestamp, actor, action type) preserved for the configured retention; AppSignal records handler-portal request telemetry |
| A.8.16 | Monitoring activities | Implemented | AppSignal on the handler portal. Deliberately not present on the reporter portal — reporter-side monitoring would compromise the anonymity model (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 ) |
| 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 ) |
| 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 ). Customer-managed keys not supported and the reason is stated in DPA §6.11 |
| A.8.25 | Secure development life cycle | Implemented | Security#secure-development-lifecycle |
| A.8.26 | Application security requirements | Implemented | Encryption coverage, authorization scope, audit-log emission, and input-validation requirements are checked in code review for every change (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 |
| 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 ) |
| 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 ) |
| A.8.32 | Change management | Implemented | Every production change goes through code review against a written security checklist and CI-enforced static analysis before deploy (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 : 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.
Document control #
| Field | Value |
|---|---|
| Document title | EthicsPortal ISO/IEC 27001:2022 Annex A Control Map |
| Version | 1.0 |
| Effective date | 2026-05-21 |
| Last reviewed | 2026-05-21 |
| Next scheduled review | 2027-05-21 |
| Review trigger (interim) | Material change to the Information security policy , Business continuity plan , or 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 .
Last updated: