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.

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

• Do you support Single Sign-On (SSO)?Access & authorization#

  Yes. Our platform supports SSO login via the industry standards OpenID Connect (OIDC) and SAML2, allowing you to integrate with your own identity provider (IdP) and manage access centrally according to your own policies. Users are identified by unique user IDs decoupled from their email addresses. Multi-factor authentication is supported, and sessions automatically end after a period of inactivity.

• How do you handle changes in the environment?Change management#

  Every change follows our policies, instructions and SLAs. The greater the risk a change may entail, the higher the requirements we place on risk assessment, planning and approval. Changes are tested before and after implementation and have documented rollback procedures. We inform customers via our status page and announce changes according to our SLAs.

• How do you give notice of planned maintenance?Change management#

  We announce planned maintenance windows at least ten days in advance on our status page, and emergency maintenance as soon as possible, sometimes with shorter notice. Changes affecting a specific service are also published on that service's announcement page in our documentation (docs.elastx.cloud), and for material changes affecting a service you use we may additionally inform your authorized contacts by email. We also notify you in the event of elevated risk. Planned maintenance windows are not covered by the availability SLA.

• How do you handle incidents?Incident managementNIS2#

  We deliver services around the clock and therefore have troubleshooting and incident handling around the clock, year-round, with continuous monitoring of the platform and alarm reception. When an event is identified it is classified and prioritized based on severity and impact on the services, and it is escalated according to defined procedures to the right technical expertise. A serious problem can be escalated to a critical incident, which activates a dedicated crisis management team with a mandate to make rapid decisions. After a remediated incident, a root cause analysis is carried out to capture permanent improvements in the platform and our working methods. Our documented incident management procedure can be shared with customers on request.

• How are we informed during an ongoing incident?Incident management#

  We keep customers informed via our status page during an ongoing problem. When a problem is resolved we send an incident report to affected customers on request. Our procedures include the incident reporting requirements in Cybersäkerhetslagen (NIS2).

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

• Responsibility and procedures in the event of incidentsIncident management#

  Management responsibility and procedures are established for a fast, effective and orderly response to privacy and information security incidents. The incident team works from predefined playbooks for, among other things, ransomware, DDoS and data breaches, and immutable logging secures evidence for forensics.

• How are security events and threats reported internally?Incident management#

  Security events and suspected threats are reported through established internal channels as quickly as possible, so that they can be assessed and, where needed, escalated without delay. All employees and consultants have a responsibility to report, and the procedure is part of our security training.

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

• Reporting of weaknessesIncident management#

  Employees and consultants are to note and report observed or suspected weaknesses in systems or services, and there are established escalation paths for how the reports are handled.

• How do you assess whether an event is an incident?Incident management#

  Reported security and privacy events are assessed in a structured way and classified according to defined criteria, including impact on confidentiality, integrity and availability (the CIA triad), how many systems or customers are affected, whether personal data is involved and whether the event may trigger a reporting obligation. Based on the assessment, a decision is made on whether the event should be handled as an incident and what severity it is assigned.

• Learning from incidentsIncident management#

  After an incident we conduct a thorough review (retro) and capture lessons that we share internally and translate into improved procedures and controls. How thorough the review is depends on the scope of the incident, and incident reports are shared with customers who request them.

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

• What did this year's continuity exercise show?Continuity & recovery#

  Exercises confirm our crisis preparedness and technical resilience. The crisis management team establishes structure quickly, and we can if needed isolate an entire availability zone to protect customer environments in the other zones. Identified areas for improvement are followed up in a structured way and managed over time, including clearer crisis mandates, a dedicated communications lead, more formalized procedures for endurance during prolonged incidents and improved traceability and reporting in line with Cybersäkerhetslagen (NIS2) and DORA.

• How is the platform built for redundancy and recovery?Continuity & recoveryNIS2DORA#

  The platform is distributed across three active availability zones in the Stockholm area (STO1, STO2 and STO3), geographically separated so that a physical or environmental disruption in one zone does not take down the service. Services are replicated between the zones for automatic redundancy. For critical backups and logs we offer The Vault- an immutable, ransomware-resistant storage that additionally sits in a separate region around 350 km from the Stockholm area, in a protected underground facility. It is based on Object Lock (WORM - Write Once, Read Many), which means data cannot be changed or deleted during the configured lock period, even if permissions are compromised.