ISO/IEC 27001:2022 self-assessment #
EthicsPortal does not currently hold accredited ISO/IEC 27001 certification. This page is a structured self-assessment against the same evidence an external auditor would evaluate, so a procurement reviewer can verify the substance directly.
Certification is awarded against two things: the mandatory management-system requirements in Clauses 4–10, and an Annex A control set justified by the risk assessment. This page covers both — the clause-by-clause position first, then all 93 Annex A controls in the form Clause 6.1.3 d) requires of a Statement of Applicability.
The self-assessment is published openly. Where a requirement or control is not in place, that fact is stated openly with a target. Where it 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-09-23.
How to read this page #
| Status | Meaning |
|---|---|
| Implemented | The control is in place and operating; evidence is published or available during procurement review |
| Partial | Some measures operate, but a material part of the asserted control remains unverified or absent |
| 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
- Internal audit record
- Management review record
- Security (technical and organizational measures)
- Data Processing Agreement
- Subprocessors
- Incident register
- Self-conducted security testing
ISMS requirements (Clauses 4–10) #
Clauses 1–3 of the standard are informational. Clauses 4–10 are the mandatory requirements an accredited certification body confirms before it will certify anything, and they govern the management system itself rather than any individual control. Annex A is selected and justified by that system, not the other way round.
| Clause | Requirement | Status | Position and evidence |
|---|---|---|---|
| 4.1 | Understanding the organization and its context | Self-assessed | Regulatory, threat and supplier context is carried by the risk register rows it produces (R-03 supplier chain, R-07 upstream dependencies, R-10 regulatory change), together with Subprocessors and the Directive coverage map . There is no separate context-analysis document |
| 4.2 | Understanding the needs and expectations of interested parties | Self-assessed | Interested parties are addressed per relationship rather than in a single register: controllers in the DPA , reporters in the Privacy notice , supervisory authorities at A.5.5, sub-processors on Subprocessors |
| 4.3 | Determining the scope of the ISMS | Implemented | IS policy §2 states the boundary — reporter portal, handler portal, supporting infrastructure, all personal data processed on behalf of controllers, the operator and the named sub-processors — and states that controller-operated systems fall outside it |
| 4.4 | Information security management system | Self-assessed | The ISMS is the published document set indexed on Trust#public-documents plus this page. It operates and is versioned; it has not been certified |
| 5.1 | Leadership and commitment | Implemented | The operator is sole top management. Commitments are stated and signed in the IS policy |
| 5.2 | Policy | Implemented | Information security policy — published, dated, versioned, signed, reviewed annually |
| 5.3 | Organizational roles, responsibilities and authorities | Implemented | IS policy §4 assigns all five security roles to the named operator and states that concentration openly rather than implying separation |
| 6.1.1 | Actions to address risks and opportunities | Self-assessed | IS policy §6 sets the assessment trigger and cadence; the risk register records the output |
| 6.1.2 | Information security risk assessment | Implemented | Risk register — defined impact and likelihood scale, ten assessed risks, and an explicit list of risk categories deliberately excluded with the design reason |
| 6.1.3 | Information security risk treatment | Implemented | Treatment is recorded per risk in the register, control selection is the Statement of Applicability below, and the treatment plan gives every In treatment risk a named action and a completion date, with a stated rule for what happens when one is missed |
| 6.2 | Information security objectives and planning to achieve them | Implemented | IS policy §3 states three objectives, each with a measure, a target, and the source the result is read from |
| 6.3 | Planning of changes | Self-assessed | Changes to the Service run through the pre-deploy checklist and the deploy gate (A.8.32). Changes to the ISMS are versioned in each document’s control block and recorded in the corrective-action log below |
| 7.1 | Resources | Partial | The ISMS is resourced by one person’s time. That constraint is the subject of risk register R-01 and is disclosed on Trust#continuity-and-personnel |
| 7.2 | Competence | Self-assessed | IS policy §8 records the operator’s competence basis and the feeds that maintain it. Self-declared; no third-party certification is claimed |
| 7.3 | Awareness | Compensating | There are no personnel to make aware. The operator’s own awareness is maintained through the security feeds listed at A.5.6 |
| 7.4 | Communication | Implemented | Security events follow the incident register disclosure timeline; sub-processor changes carry 30-day notice under DPA §6.4 ; inbound reports reach security@ethicsportal.eu (Security#responsible-disclosure ) |
| 7.5 | Documented information | Implemented | Every policy document carries a version, effective date, next-review date, owner and signature, and is published rather than held privately |
| 8.1 | Operational planning and control | Implemented | Security#secure-development-lifecycle — the automated suite and static analysis gate every deploy and block it on failure; the written pre-deploy checklist governs approval |
| 8.2 | Information security risk assessment (performed) | Self-assessed | Register last reviewed 2026-09-05 on the annual cadence plus the interim triggers in IS policy §6 |
| 8.3 | Information security risk treatment (implemented) | Self-assessed | The selected controls operate — see the tally below — and the five open items now run against the dated treatment plan . The first cycle of results against those dates is reported at the 2027-09 management review ; until then the plan is executing rather than evidenced |
| 9.1 | Monitoring, measurement, analysis and evaluation | Self-assessed | A production check set runs continuously and is published at secure.ethicsportal.eu/up . It verifies, among other things, that the append-only audit triggers are present on the deployed database, that the latest PostgreSQL dump is under 36 hours old, and that the GDPR retention, deadline and inactivity-close jobs completed within 26 hours. Availability against the 99.5% target is measured per SLA#measurement . Analysis of the collected data is periodic, at the review points below, rather than continuous |
| 9.2 | Internal audit | Partial | A programme and a first audit are published at Internal audit record ; it found no control failures and five documentation defects, all corrected before close. The requirement that the audit process be objective and impartial cannot be met under a single-operator structure, since the auditor is the person who built the system. That is the same limit recorded at A.5.35, and an independent review is what closes it |
| 9.3 | Management review | Self-assessed | Management review record — conducted against the Clause 9.3 input list, dated, with conclusions and five decisions recorded. Single-person review; not independently witnessed |
| 10.1 | Continual improvement | Self-assessed | Evidenced by the corrective-action log below and by the dated revisions of each policy document |
| 10.2 | Nonconformity and corrective action | Implemented | Security events are recorded and closed out through the incident register ; ISMS nonconformities — inaccurate or incomplete assertions found during review — are recorded with their correction and re-verification in the corrective-action log below |
Statement of Applicability #
Clause 6.1.3 d) requires a Statement of Applicability: the controls determined necessary, the justification for including each, whether it is implemented, and the justification for excluding any Annex A control. The four control tables below are that statement.
Basis for inclusion. All 93 Annex A controls are treated as applicable by default. A control is excluded only where the structure of the Service makes it meaningless — nine of the 93 — and every exclusion carries its reason in its own row. Inclusion is not asserted control by control against a single risk, because most controls treat several. The mapping below shows which controls carry the treatment for each assessed risk; the controls it does not name are included as baseline hygiene for the three objectives in IS policy §3 .
| Assessed risk (register ) | Treatment carried by |
|---|---|
| R-01 Operator incapacity | A.5.2, A.5.4, A.5.24, A.5.29, A.5.30, A.8.13 |
| R-02 Hetzner outage | A.5.23, A.5.29, A.5.30, A.7.1–A.7.13 (inherited), A.8.13, A.8.14 |
| R-03 Sub-processor personal-data breach | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23, A.8.12, A.8.16 |
| R-04 Operator credential theft | A.5.15, A.5.17, A.5.18, A.8.2, A.8.4, A.8.5 |
| R-05 Restore failure | A.5.30, A.8.13, A.8.14 |
| R-06 Reporter network-side attribution leak | A.5.34, A.8.11, A.8.15, A.8.16 |
| R-07 Upstream dependency vulnerability | A.5.7, A.5.21, A.8.8, A.8.19, A.8.29 |
| R-08 Audit-log integrity compromise | A.5.28, A.5.33, A.8.2, A.8.15 |
| R-09 Reporter passcode loss | A.5.17, A.8.5, A.8.24 |
| R-10 Regulatory change requiring re-architecture | A.5.31, A.5.36, A.8.25, A.8.26 |
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. Defined events are recorded in an append-only audit log, including which handler viewed which report; reads of other resources are not logged. The automated suite and static analysis gate deploy, and signed commits make authorship attributable (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 (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 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 | Partial | Customer-facing connections use HTTPS/TLS (Security#data-encryption ). Public supplier terms describe DPAs, but executed account-specific terms, onward access and restricted transfers have not been verified (Subprocessors ) |
| A.5.15 | Access control | Implemented | 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 ); 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 ) |
| 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 | Self-assessed | EU hosting for the reporting service is documented on Security#infrastructure and Subprocessors . Separate US processing for the public site is disclosed in the Privacy Notice . This self-assessment does not itself prove that a particular transfer mechanism or supplier contract is sufficient. |
| 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: 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 ). 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 §1–7 |
| A.5.30 | ICT readiness for business continuity | Partial | BCP §2 & §6 ; RPO 24h / RTO 4h are published objectives in the SLA . The monthly drill now proves the restored database is readable by the application, not only that the rows returned. It still does not measure the end-to-end RTO, off-provider recovery or operator-incapacity response |
| 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 addresses ownership of the Service and customer content; Terms §12 states that the standard terms do not include IP defence or indemnity |
| 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. 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 . First-party testing is performed and published at Self-conducted security testing , which does not carry the independence this control requires. Scope, date, and remediation summary will be published here when one is performed |
| 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; 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 ; restore procedure documented in BCP §6 ; deployment via versioned Kamal configuration |
A.6 People controls #
| Control | Title | Status | Evidence |
|---|---|---|---|
| A.6.1 | Screening | Compensating | There is no hiring process to screen, but the operator is the only person with access and is therefore the subject this control exists to assure. The equivalent assurance is identity verifiability: contracting party, registry number and tax registration are published on Trust#contracting-party , and the registry extract is available during procurement review. Sole-operator structure disclosed on Trust#continuity-and-personnel |
| A.6.2 | Terms and conditions of employment | Not applicable | No employees |
| A.6.3 | Information security awareness, education and training | Compensating | No employees to train, but Clause 7.2 makes the operator’s own competence a requirement rather than an exemption. The competence basis and the feeds that maintain it are recorded in IS policy §8 ; the subscriptions are listed at A.5.6. Self-directed and self-declared |
| 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. 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 ) |
| 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 ) |
| 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 ); vulnerabilities found by manual testing are tracked with their remediation at Self-conducted security testing |
| 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; post-Service return or deletion follows the Controller’s instruction and the documented production/backup lifecycle (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; 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 | Partial | No AI/LLM sub-processor is used for report content (DPA §6.10 ). Mailjet receives email addresses and access-code notifications when enabled; AppSignal receives application telemetry. Actual downstream access, telemetry content and restricted transfers require account-level verification (Subprocessors ) |
| A.8.13 | Information backup | Partial | Two layers, both in the EU: daily PostgreSQL dumps via a Kamal accessory to Hetzner Object Storage (separate from the compute host), encrypted with GnuPG symmetric AES-256 on the host before upload, with 21 current daily backups and deletion of noncurrent versions after 7 additional days; and full-disk snapshots of the application host retained 7 days in Hetzner Cloud. Backup freshness is checked continuously and alerts if the latest dump exceeds 36 hours. The monthly drill decrypts, restores, compares every table against production and boots the application against the restored data to confirm an encrypted column decrypts (Security#backups-and-restore ). Remaining gap: file attachments are neither encrypted at rest nor carried in the dump, so the database is covered and attachment objects are not |
| 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, but the published RTO has not been demonstrated end to end. Trade-off stated in Risk register R-02 |
| A.8.15 | Logging | Implemented | Append-only audit trail for defined report and account events (timestamp, actor, action type). Report reads are covered: each handler’s view of a given report is logged, deduplicated to one entry per handler per report per 24 hours, and reporter follow-up views are logged the same way. Reads of other resources, and actions outside the defined event set, are not logged. AppSignal records application telemetry subject to the restrictions and remaining verification in A.8.16 |
| A.8.16 | Monitoring activities | Partial | AppSignal APM is active; reporter controllers use an ignored namespace and session-data transmission is disabled. On 2026-09-23 the namespace exclusion was checked from the supplier side rather than from our configuration: an inventory of every action AppSignal holds for the production app returned 27 web actions and 13 background jobs, all of them handler, organization, admin or public-widget paths, with no reporter-portal controller among them. Not yet verified: the contents of individual stored samples — request parameters and headers — which the supplier’s API does not expose under the token used. Attachment delivery and supplier-side logs also remain unverified (TP-01, 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 on the pre-deploy checklist for every change and are covered by automated tests that block the deploy on failure (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; periodic manual testing with scope, findings, and remediation published at Self-conducted security testing |
| 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 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 ) |
| 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 | 50 | In place and operating; evidence published or available during procurement review |
| Partial | 5 | Material scope or evidence still outstanding (A.5.14, A.5.30, A.8.12, A.8.13, A.8.16) |
| 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 | 9 | Does not apply given the sole-operator structure (the remaining A.6 People controls and one-off cases) |
| Compensating | 4 | Primary form not applicable; alternative arrangement achieves the same objective (A.5.3 segregation of duties, A.5.10 acceptable use, A.6.1 screening, A.6.3 awareness) |
| In treatment | 1 | Not yet in place at the operator’s target level; target stated openly (A.5.35 independent review) |
The In treatment control (A.5.35) lacks independent security review. The five Partial controls require supplier-chain, backup-encryption and end-to-end continuity evidence. First-party testing is published at Self-conducted security testing ; it does not establish independence or close the partial controls.
Against Clauses 4–10, two positions remain open and both are structural: the ISMS is resourced by one person (7.1), and internal audit cannot be impartial while the auditor is the person who built the system (9.2). Neither is closed by adding a control. Both are properties of the single-operator structure and are disclosed as such; an independent external review is what moves 9.2, and it is dated at TP-05 of the treatment plan .
Nonconformity and corrective-action log #
Clause 10.2 requires that a nonconformity be recorded with the correction applied and the effect of that correction verified. The entries below are that record. Each revision states what was found inaccurate, incomplete or unsupported, what was changed, and what was re-verified. Entries are retained rather than overwritten, so a reviewer can see what the page used to claim.
v3.2 — 2026-09-23 #
- Clauses 6.1.3 and 8.3 — both were Partial because treatment was recorded per risk with no completion date against any of it, so an item being worked was indistinguishable from an item being tolerated. The risk register now carries a treatment plan: five dated items covering the supplier chain, attachment encryption, the operator-incapacity protocol, a measured off-provider restore, and the independent review. 6.1.3 moves to Implemented; 8.3 to Self-assessed, because the plan is executing and its first results are due at the 2027-09 review. Closes audit finding OFI-01.
- The plan states what happens when a target slips: it is recorded as missed at the next management review with a reason and a new date. Dates that move quietly would make the plan worse than its absence.
v3.1 — 2026-09-23 #
A control change rather than a documentation correction. The open item at A.8.13 was closed for the database and is restated precisely for what remains.
- A.8.13 and A.5.30 — database dumps were uploaded to Object Storage in plaintext apart from the application-encrypted columns inside them, which every version of this page since v2.0 has disclosed as an open gap. Dumps are now encrypted with GnuPG symmetric AES-256 on the host before upload. The backup process fails closed without the key, so the failure mode is a missing backup that the 36-hour freshness alarm catches, not a silent plaintext one.
- The monthly drill now proves the restored data is readable. It compared table sets and row counts, which cannot distinguish a usable backup from ciphertext whose key no longer matches — an encryption-key mismatch would have passed every assertion while every report was unrecoverable. The drill decrypts, restores, compares, and then boots the application against the restored database to force an encrypted column to decrypt. Verified end to end against a production backup on 2026-09-23.
- What did not change. File attachments are still uploaded without encryption at rest and are not carried in the dump. A.8.13 stays Partial for that reason, which is a different reason than it carried before. Cross-provider recovery is still unmeasured, so risk register R-02 stays In treatment.
v3.0 — 2026-09-23 #
This revision closes the largest gap in the document itself: it assessed only Annex A, and said nothing about the Clauses 4–10 requirements that certification is actually awarded against.
- Scope of the page — Clauses 4–10 are now assessed sub-clause by sub-clause, and the Annex A tables are framed as the Statement of Applicability that Clause 6.1.3 d) requires, with the basis for inclusion and the risk-to-control mapping stated. Assessing the control set without the management system that selects it was the defect.
- A.6.1 and A.6.3 — both were marked Not applicable on the grounds that there are no employees. That is the right answer for a hiring process and the wrong one for the operator, who is the person these controls exist to assure and whose competence Clause 7.2 requires regardless of headcount. Both are now Compensating with the substitute assurance named. The tally moves two controls from Not applicable to Compensating; no control changed its substantive position.
- A.8.13 — the row described only the object-storage dump layer. The host-snapshot layer and the continuous 36-hour backup-freshness check were already operating and already documented on Security#backups-and-restore ; this row understated the control.
- Restore-drill cadence — the business continuity plan §9 said quarterly and risk register R-05 said “at least quarterly”. The drill has been running monthly, as R-02, this page and Security#backups-and-restore all state. Both documents now say monthly. Two published documents had understated a control that was already stronger than claimed.
- Clause 6.2 objectives — the three objectives in IS policy §3 were qualitative. Each now carries a measure, a target and the source the result is read from, which is what Clause 6.2 asks for and what makes a management review capable of concluding anything.
- A.5.3 and A.8.15 — both stated that individual reads are not logged. Report views are logged, per handler, deduplicated to one entry per report per 24 hours, and reporter follow-up views with them. Three further surfaces carried the same understatement and are corrected with it: the Privacy notice , the DPIA template and the DORA map . On the privacy surfaces this was an under-disclosure of processing as much as an understated control.
- Clauses 9.2 and 9.3 — neither an internal audit nor a management review existed in any form. Both are now published at Internal audit record and Management review record . The first audit found no control failures; the impartiality limit of a single-operator audit is stated on the page and holds 9.2 at partial.
v2.6 — 2026-09-05 #
This revision cites the newly published record of first-party security testing from the controls it bears on.
- A.5.35 — the control stays in treatment, and the new page does not change that: testing scoped, run and reported by the operator carries no independence. The row now names it so a reviewer sees what does exist alongside what does not.
- A.8.8 and A.8.29 — both described automated scanning and test coverage only. Periodic manual testing has been performed since May 2026, and its scope, findings and remediation are now published, so both rows cite it.
No control changed status; the tally is unchanged from v2.5.
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. That enforced lifecycle supports the DPA’s description of backup expiry no later than 28 days after production deletion.
No control changed status; the tally is unchanged from v2.4.
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.
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.
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=30in 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.
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.
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 — historical backup-encryption assertion withdrawn: Hetzner does not encrypt Object Storage objects at rest by default, and the backup upload does not request it. 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 Self-Assessment and Statement of Applicability |
| Version | 3.2 |
| Effective date | 2026-09-23 |
| Last reviewed | 2026-09-23 |
| Next scheduled review | 2027-09-23 |
| 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; a finding raised by the internal audit or management review |
| Owner | Yaroslav Shmarov, operator |
This page is not an attestation of certification. It is a self-assessment covering the Clause 4–10 requirements and the Annex A control set, published so a procurement reviewer can 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: