Business Continuity

The ESM environment is a high-availability solution with high requirements in up-time. 

blabla bla

Information Security requirements


ESM manages sensitive information as the models will represent our customers business processes, information objects and IT-environment. The more information that organisations will document in ESM, the more sensitive it will be (even though our purpose is for the organisations to model on the meta level).

The following security principles are core in developing products at Innovate:

  • Fail-safe defaults - if a system or an application fails, it should fail into a a state that is as secure as possible. 

  • Minimize attack surface - when we design an build systems and application, we should minimize the exposure as far as possible without loosing the over-all functionality.

    • Examples: make sure that technical information is not provided, remove source code that is not in use, remove default configuration, reduce the number of networks services that is running in a system, remove/rename default users etc.

  • Defense in-depth - make sure to have several layers of protection.

ISO/IEC27001 certified

Innovate Security Sweden AB is certified and we have chosen to include all part of our company in the certification process.

Separation and protection of customer's data

Our customers' data in ESM is one of the most valuable and protect-worthy information assets that we handle at Innovate. It includes detailed information about our customers' processes, information, IT applications, partners, security demands and statements about compliance with internal demands and standards. It is therefore classified high both in terms of confidentiality and integrity. To protect the confidentiality and integrity of this data we follow a number of detailed security requirements:


Security measures for confidentiality
  • Each customer has its own separate named database.

  • No credentials are shared between databases.

  • Each customer has its own backend-API.

  • The web client code (the end-user interface of ESM) can only access the backend-API with a JWT token signed by a private key only known to that backend-API.

  • State-of-the art signing algorithm is used (ES512 - elliptic curve signature algorithm using the SHA-512 hash algorithm).

  • Two-factor authentication for user login which results in the correct signed JWT token.

Measures for integrity
  • All changes inside ESM are logged and stored in the database

  • The signed JWT-token that gives a user access to the API contains the level of access for that user has. So a read-only user will never be able to update data even if he/she designed API-requests for that.

  • All communications between the ESM client and Nginx are encrypted with TLS

  • Cryptographic secrets for external services are saved as Kubernetes secrets.

  • User passwords in ESM are one-way hashed with Bcrypt (derived from blowfish)

  • Personal ssh-keys are stored on the respective employee laptop (on encrypted disk), and should be password protected.

  • Cryptographic secrets and Master copies of important cryptographical keys private key for external certificate for * is stored in a secure vault and managed using Key Management Process.


Security in the Software Development process

To support developers in implementing secure coding practices we enforce excessive use of secure coding practises, e.g. OWASP-top 10.

Data Protection by design

ESM only manages information about users in terms of e-mail and mobile number.

Testing Security

Innovate uses regular security testing of web applications as a part of the overall quality assurance process. Specifically we do manual testing at least four times a year with automated tools. The reports from security testing is transformed into issues in the Backlog and prioritized in the product meetings.

We also use automated security scans as-a-service that are run once per week.

Frameworks and external guidelines

We follow as close as possible the following frameworks and guidelines:

Application components


This section provides an overview of the logical components of the ESM SaaS production environment:

ESM client

The ESM client running in a users browser. Javascript application that communicates with its backend tenant in the ESM cluster via the public IP of the external load balancer. Communications goes via an https session and secure web sockets.

Load balancer

Load balancer and firewall separating the internal network from the internet. The firewall only lets in traffic on port 80 and 443 (http and https and http requests are redirected to https)) to the nginx webserver in the Kubernetes cluster.


ESM runs within a Kubernetes cluster currently running on a set of nodes that are virtual servers in Devinix private cloud service. 

Nginx Ingress Controller

Receives and responds to all end-user browser requests via https (http requests are redirected to https). End users surf to https://[tenant_name] Each tenant_name has an associated Ingress resource ( in the Kubernetes cluster, which gives rise to a server block in the Nginx config file, specifying the container which delivers the tenant service.

Tenant N

Custom built functionality that hosts and delivers the client-side javascript code that is run in the end-user's browser. It also provides APIs to create, read, update and delete objects in the tenants' models. Validates the signature of the JWT-token that carries the identity of the end-user and which tenant the user belongs to. Each tenant runs in a separate Kubernetes pod. Each tenant is configured to communicate with its own database, using a tenant-specific Kubernetes secret containing credentials for connecting to the database.

Tenant DB N in PostgreSQL

Each tenant has a separate named database in a Postgres database server. The number of databases are scalable by adding more servers with separate database clusters on them. The model data of a particular tenant will reside in one particular server / cluster / named database.


Services a registration form for new customers (tenants) which it delivers to Admin for (database) validation. Generates a deployment token upon successful registration, which is sent to the email address registered by the customer. Services, with validated deployment token, a deployment page. Deploys (by communicating with Admin internally in the cluster) a registered tenant.


A template is an instance of ESM from which data can be imported into deployed tenants. They publish a secured export api, and are always kept online.


Receives requests to hosts of the form [tenant], which do not have their own ingresses.

Upon receiving a request to [tenant], requests status information about tenant.

  • If tenant is inactive, requests Admin to bring it back up

  • If tenant is archived or registered (but not deployed), services a page informing the requester

  • If tenant does not exist, redirects to