Trust Center

Answers to common questions about security, compliance, operations, and how we handle your data.

Why organizations trust Elastx

  • Digital Sovereignty

    Swedish jurisdiction and free from the U.S. CLOUD Act.

  • Data Stays in Sweden

    Customer data is stored in Swedish data centers.

  • Certified Security

    ISO 27001, ISO 27017, ISO 27018 and ISO 14001 certified, with regular independent audits.

  • 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.

  • 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 unauthorised 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 parameterised 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 organisation'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.