Trust Center
Swedish-owned. Data stored in Sweden. Certified security. Open standards. Here you will find information about how we protect data, meet regulatory requirements and build a platform trusted by organizations with the highest demands for security, compliance and control.
Why organizations trust Elastx
Digital Sovereignty
Swedish jurisdiction and free from the U.S. CLOUD Act.
Data Stays in Sweden
Data is stored and managed in Sweden.
Certified Security
ISO 27001, ISO 27017, ISO 27018 and ISO 14001 certified.
High Availability
Built with redundancy, continuous monitoring and expert support around the clock.
No Vendor Lock-In
Open standards and full control over your data.
Do we as a customer have the right to audit you?NIS2GDPRDORA
Yes, the right to audit follows from your agreements with us and can arise in several ways. If we process personal data on your behalf, our Data Processing Agreement (DPA) gives you the right to conduct annual audits of the processing covered by the agreement, yourself or through a third party you appoint, at your own expense (GDPR Article 28.3(h)). For customers covered by DORA, audit and access rights are regulated in a dedicated contract addendum, and for those of you with supplier oversight requirements under Cybersäkerhetslagen (NIS2), we provide the documentation you need. In many cases, the need can also be met by our certificates and summaries of completed security reviews, which can be shared on request. Contact us and we will help you plan an audit.
What does your exit strategy look like if we want to leave?Digital sovereignty & independenceDORADigital sovereignty
The goal is that you should never feel locked in. We build on open standards and open source (including OpenStack and Kubernetes), which means you can move your applications and data to another environment. You can export your data ahead of a termination, and we apply no mandatory lock-in periods, in line with the EU Data Act.
ICT risk managementRegulatory complianceDORA
We ensure and maintain an adequate level of digital operational resilience, and risks within information and communication technology (ICT) are managed within our risk management process.
How do you report serious ICT incidents?Regulatory complianceNIS2DORA
We have a documented, communicated and tested process for reporting serious ICT incidents and cyber threats to customers and competent authorities. Reporting follows applicable rules, including Cybersäkerhetslagen (which implements NIS2) and, for incidents affecting financial entities we deliver to, DORA. For a significant incident we apply the NIS2 model: early warning within 24 hours, an incident report within 72 hours and a final report no later than one month thereafter.
Testing of digital operational resilienceRegulatory complianceDORA
We carry out recurring tests of our resilience. Penetration tests are performed by an independent external party, while continuity exercises are conducted internally. Tests are documented and followed by a plan for remediation and upcoming tests.
How do you share information about threats and vulnerabilities?Regulatory complianceDORA
We continuously monitor and identify cyber threats and vulnerabilities via established sources and have a procedure for sharing relevant threat information, both internally and with affected customers and collaboration partners where appropriate. The aim is to be able to act quickly on new threats and to contribute to stronger shared resilience.
Management of ICT third-party riskRegulatory complianceDORA
Appropriate controls are applied at procurement and on an ongoing basis throughout the contract term to reduce risks linked to critical subcontractors.
Exit strategy and migration planRegulatory complianceDORA
Contracts with critical subcontractors contain exit clauses and a documented process that secures continued delivery during a migration. We validate that the process works through recurring reviews and scenario-based tests of the exit and migration plan, so that it can be carried out in practice if a supplier needs to be replaced.
How do you avoid vendor lock-in?Data protection & encryptionDORADigital sovereignty
We build on open standards and open source (including OpenStack and Kubernetes) so that you can move your applications if you want. We apply no mandatory lock-in periods, and you pay for the resources you allocate. As a Swedish company we operate under Swedish and European jurisdiction and are not subject to third-country legislation, and we comply with the EU Data Act to counteract lock-in effects.
How do you develop secure software?Secure developmentNIS2
Our in-house development follows a secure development procedure. Security requirements are defined early, code undergoes mandatory peer review and automatic static security analysis (SAST) of container images, and no secrets or keys are stored in source code. The source code resides in access-controlled repositories with MFA, where permissions are governed by developer role and branch protection is applied. Build and deployment pipelines are automated, and changes are tested in isolated test environments before they reach production. No real customer data or personal data is used in development or test environments.
Do you contribute to the open projects you build on?Secure development
Yes. We are active and contribute continuously to OpenStack and Kubernetes, the projects we ourselves build on and use. Our contributions concern, among other things, OpenStack (compute, identity and networking) and Kubernetes, including Cluster API. Other contributions occur more sporadically. This gives us early insight into security updates and the ability to influence upcoming standards.
Separation of development, test and production environmentsSecure development
Development, test and production environments are separated to reduce the risk of unauthorized access or changes in the production environment.
How do you govern system changes during development?Secure development
Changes to systems during the development lifecycle are governed by formal change control procedures. This means, for example, that changes are documented and approved, that code is peer reviewed before merging, that automated tests are run and that there are documented procedures to roll back if something goes wrong.
How do you engineer secure systems?Secure development
Our in-house development is based on the principle of Defense in Depth across all technical layers and on established security guidelines, including the OWASP Top 10. We apply secure coding principles, for example parameterized database queries against SQL injection and context-based escaping against scripting attacks (XSS), and the source code is scanned automatically in our build pipelines. Configuration is managed as code from reviewed, immutable baselines, and sessions are protected with secure cookie settings.
Secure development environmentSecure development
Secure development environments for system development and integration are established and protected throughout the development lifecycle. Business-critical applications are reviewed and tested carefully after platform changes, so that changes to operating platforms do not adversely affect the business or security.
Outsourced developmentSecure development
We generally do not outsource system development and avoid it as far as possible. Where it does occur, the work is supervised and follows the organization's standards and regulatory requirements.
De-identified test dataSecure development
No real customer or personal data is used in testing. Test data is de-identified or synthetic and is therefore not handled with the same protection requirements as production data.
How quickly do you inform us of an incident or personal data breach?Incident managementNIS2GDPRDORA
In the event of an incident affecting you, we inform you without undue delay, and at the latest within 24 hours of becoming aware, so that you have time to meet your own obligations. In the event of a significant incident, we follow Cybersäkerhetslagen (NIS2) in reporting to the competent authority (MCF): early warning within 24 hours, an incident report within 72 hours and a final report no later than one month after the incident report.
How do you report material events to authorities?Incident managementNIS2GDPRDORA
Material events are reported according to applicable rules. Serious incidents covered by Cybersäkerhetslagen (NIS2) are reported to Myndigheten för Civilt Försvar (MCF), and for incidents concerning financial entities we deliver to, we follow DORA. In the event of a personal data breach, we as a data processor inform the affected data controller without undue delay under GDPR, so that they can fulfill their own notification obligation.
Do you test your continuity capability?Continuity & recoveryNIS2DORA
Yes. We exercise our continuity plan (Business Continuity Plan, BCP) through recurring, full-scale continuity exercises as part of our ISO/IEC 27001 work. The exercises are typically unannounced for the majority of the organization in order to give a realistic result, and they test the crisis management team's decision-making, the technical containment procedures and our communication channels under high pressure.