Security Council
The ISMS governing body, made up of the three managing partners. It approves in a minuted session with a quorum of two of the three members; wider-reaching decisions require unanimity. Every policy carries a record of approval.
A management system with a decision-making body
Security at Opendome is managed through an ISMS aligned with ISO/IEC 27001:2022 and with SOC 2 criteria, with a set of formally approved policies subject to periodic review.
Information Security Coordinator
Responsible for day-to-day operation of the system: maintaining the risk register, incident management, third-party assessment, and handling security and privacy enquiries.
Documentary record
Policies, risks, incidents, vulnerabilities and exceptions are recorded in a single compliance management system. Every approved exception is recorded with an owner and an expiry date.
Given the size of the team there is no strict segregation of duties. The compensating control is collegiate oversight: every relevant decision requires the agreement of at least two of the three Council members and is minuted. We state it this way because it is the actual situation, and because an auditor will ask.
Controls that operate even if nobody configures them
The relevant difference between a security policy and a secure architecture is that the first describes an intention and the second enforces a behaviour. The four controls below are properties of the system, not settings.
One dome per customer
Each customer's data resides in an isolated environment. There is no shared storage between customers and no possibility of cross-access through a misconfigured query.
A single policy enforcement point
Every read of data passes through the semantic layer and its policy enforcement point, which operates fail-closed: on any doubt or failure, it denies. No data backend and no inference model is exposed directly.
The operational consequence is deliberate: an outage degrades towards «no access», never towards «ungoverned access».
An audit log by construction
Every access is recorded: which identity queried which data, for what purpose, at what moment, and whether it tried to operate outside its scope. The log does not depend on anyone switching an option on.
A single gateway for models
Language model consumption is channelled through a governed gateway, which reduces the exposed surface. Whether a datum is personal is declared in the semantic layer; it is not inferred automatically.
Strong authentication and least privilege
Access to systems and to data is granted on a need-to-know basis, reviewed periodically and revoked effectively.
| Identity | Single sign-on over an in-house identity provider, with mandatory multi-factor authentication through TOTP and WebAuthn keys. |
| Authorisation | Least privilege and need to know. Access to production is named and traceable. |
| Secrets | Held in a dedicated manager, with access protected by MFA. Any exposed secret is treated as compromised and rotated: removing the commit is not accepted as remediation. |
| Encryption | In transit through TLS and at rest. Full disk encryption on every workstation. |
| Endpoints | Personal devices authorised under a documented policy: full-disk encryption, system protections active, verified software signing, and no disabling of the operating system's security mechanisms. |
| Offboarding | Revoking access is part of the exit procedure and covers revoking credentials, not merely deleting them. |
Verifiable provenance for every artefact
Software that gets deployed must be able to establish where it came from and what it contains. That matters especially in an open source product, where the customer can check it themselves.
Mandatory peer review
Every code change goes through review by another person and through the automated checks in the pipeline. Urgency does not waive review: a critical fix follows the same flow.
SBOM and artefact signing
Dependency scanning and static analysis, generation of a component inventory, and cryptographic signing of artefacts. Versions are pinned explicitly; moving tags are not deployed.
Synthetic data, without exception
Development, testing and demonstration environments always use synthetic data. Real customer data is never used outside production, and credentials are not reused across environments.
Prioritised by severity, with exceptions that expire
Vulnerabilities — from dependencies, from static analysis or reported externally — are recorded with a severity, an owner and a deadline. Patching is prioritised by severity, and a critical vulnerability exploitable in production is handled as an incident.
Where no fix is available or the risk is judged acceptable, temporary acceptance requires Security Council approval and is recorded as a traceable exception with an expiry date. An exception without a date is a forgotten vulnerability.
Classification, phased response and blameless review
Every incident is classified by severity at triage. Severity determines response times and the level of escalation, and is readjusted as the real scope becomes known. When in doubt, it is classified upwards.
| Severity | Description | Activation |
|---|---|---|
| S1 · Critical | Confirmed or imminent breach affecting customer data or isolation between environments, or a full production outage | Coordinator and the full Security Council, immediately |
| S2 · High | Significant impact on security or service, with no confirmed data breach | Coordinator and at least one Council member, within hours |
| S3 · Medium | Limited or potential impact, mitigable without extreme urgency | Coordinator; reported to the Council at the next meeting |
| S4 · Low | Minor anomaly or suspicious event under investigation | Coordinator; recorded and tracked |
Six phases
Detection, triage, containment, eradication, recovery and post-incident review. Containment limits the damage without destroying evidence; recovery is performed from infrastructure declared as code, verifying artefact integrity before closure is declared.
Regulatory deadlines
Personal data breaches are notified to the supervisory authority without undue delay and, where feasible, no later than 72 hours. Where Opendome acts as processor, notification to the controlling customer is immediate.
Post-incident review for the higher-severity cases is carried out without attributing blame, focused on the system and the process.
Operating controls and the roadmap
The controls that sustain the service operate today; the certification milestones have dates. Publishing both clearly is more useful to whoever is assessing us than presenting them without nuance.
- ISMS policies approved and in force
- In placeApproved by the Security Council in a minuted session, with an annual review scheduled.
- Mandatory multi-factor authentication and secrets management
- In placeOn an in-house identity provider, with TOTP and WebAuthn.
- Vulnerability scanning, SBOM and artefact signing
- In placeIntegrated into the build and release pipeline.
- Governed-consumption audit log
- In placeEvery data access is recorded from day one, with a verifiable integrity chain.
- Backups outside the cluster with restore testing
- In placeIn place for every database, with continuous archiving and a restore test passed on 4 August 2026. A backup never restored is not considered a backup; ours has also been restored in production.
- ISO/IEC 27001:2022 certification
- November 2026The ISMS operates normally; the certification audit starts in November 2026.
- SOC 2 attestation
- Autumn 2026Type I scheduled for autumn 2026, on a management system already in operation.
The detail of controls, policies and evidence, together with the current state of each, is published at trust.opendome.eu. How responsibilities are split between Opendome and the customer in each deployment model is set out in the shared responsibility matrix.
Vulnerability reporting channel
Opendome welcomes the responsible disclosure of vulnerabilities in its website, its services or its software, and undertakes to acknowledge receipt and report on the status of their handling.
Coordinated disclosure
Contact: mailto:security@opendome.eu
Expires: 2027-05-06T23:59:59.000Z
Preferred-Languages: es, ca, enAlso published at /.well-known/security.txt in accordance with RFC 9116. Testing that degrades the service, accesses third-party data, alters information or involves social engineering is not authorised. Full terms in the legal notice.
Security review
A technical session to review the access control architecture, the applicable deployment model and the documentation your security team needs to complete its assessment.
Request a technical meeting