Security Practices

We take the security of your data very seriously at 21RISK. As transparency is one of the principles on which our company is built, we aim to be as clear and open as we can about the way we handle security.

If you have additional security questions, we are happy to answer them. Please write to [email protected] and we will respond as quickly as we can.

Overall system architecture

For a better understanding of this document, it’s helpful to understand the overall architecture.


21RISK is built with Sveltekit, outputting static HTML files like the one you are currently reading, combined with server-side rendered content.


To implement the highest level of security, we have partnered with WorkOS . WorkOS provides secure and frictionless authentication, making sure our enterprise customers can use SSO (single sign-on).

Our standard authentication solution uses email magic links.

Single Sign-on (SS0)

Enterprise customers can all enjoy SSO. This is done through our identification platform WorkOS, and we can therefore offer a wide range of enterprise connections including:

  • Active Directory / LDAP
  • ADFS
  • Azure Active Directory Native
  • Google G Suite
  • OpenID Connect
  • SAML
  • PingFederate
  • Azure Active Directory

For a more detailed report, please contact us.


We understand that you rely on 21RISK services to work. We're committed to making 21RISK a highly-available service that you can count on. Our infrastructure runs on systems that are fault tolerant, for failures of individual servers or even entire data centers. You can track our uptime on our status page


21RISK maintains an extensive, centralized logging environment in its production environment which contains information pertaining to security, monitoring, availability, access, and other metrics about the 21RISK services. These logs are analyzed for security events via automated monitoring software, overseen by the security team.

Incident Management, Bugs & Response

In the event of a security breach, 21RISK will promptly notify you of any unauthorized access to your Customer Data.

We monitor our software using Sentry, a Javascript library included both in our client and server code. Sentry both reports uncaught errors and handled errors, and reports them to a centralized platform. The type of errors are categorized with different labels:

  • What level is the error, “error”, “warning” or simply just “info”
  • Breadcrumbs; metadata about the user's latest activity (including UI clicks, HTTP requests etc).
  • What GraphQL request payload did the user provide when making the request?
  • Was the use authenticated, and what permissions did the user have?
  • Any extra debug information if needed, including meta-data about the current URL, query params etc.

If 21RISK developers categorize an incident as a bug, we then open, track and fix the issue using Github.

Deployment schedule

Our deployment schedule is daily, and we use web sockets to communicate any new versions of our application. This guarantees that no users will be left on old versions of the application running. Combined with “dependabot”, we ensure that we automatically release new versions of our dependencies to minimize the risk of exposing vulnerabilities through outdated 3rd party libraries.

Automatic testing

All code changes in 21RISK follow this pattern:

  • A developer in 21RISK opens a new PR (pull request) against our master branch with the requested changes
  • Other developers at 21RISK must review this code, and accept the changes.
  • Automatic tests run unit tests, e2e tests and linting (using Github actions).
  • A review application is created for the specific application, where it’s possible to validate and confirm the changes work as expected “in a real environment” (e2e tests are executed in an isolated test environment).
  • If all tests are passed, the PR is manually merged.
  • Every night, we automatically run QA e2e tests that validate the new code against our QA environment. The QA environment restores data from production on a regular basis, and ensures the suggested changes also work on production data.
  • If all the QA tests pass, the code is automatically merged and deployed.

This ensures our end-users always use the latest and most secure version of our application - in fact, we don’t maintain older versions, only the current newest version.

Product Security Practices

New features, functionality, and design changes go through a security review process facilitated by the security team. In addition, our code is audited with automated static analysis software, tested, and manually peer-reviewed prior to being deployed to production. The security team works closely with development teams to resolve any additional security concerns that may arise during development.

Data protection

21RISK uses MongoDB Atlas as a database provider. The underlying data center we are currently using is AWS data center in Ireland (eu-west-1), through MongoDB Atlas. MongoDB guarantees, no matter the underlying hosting provider:

  • Network Isolation ; MongoDB Atlas only uses dedicated clusters in a unique Virtual Private Cloud (VPC) with dedicated firewalls. Important features of the platform are protected by IP access list or VPC Peering.
  • Role-based access management; Access to our database is protected with role best practices. This is one of the key features that ensure the separation between production, stage, environment and other environments.
  • End-to-end encryption; All network traffic is encrypted using Transport layer Security (TLS). Data at rest is encrypted using encrypted storage volumes.
  • Granular database auditing ; Systems activity is easily monitored and logged in MongoDB.
  • Two factor authentication; All services are two-factor authentication protected.

The features above is an contributing factor to MongoDB being certified with:

  • GDPR
  • SOC
  • EU-US Privacy Shield
  • ISO/IEC 27001:2013

On our application server, we also enforce role-based access management. This makes it possible to guarantee that a user will only have access to the data necessary to complete his tasks. For example, we offer our customers to use view-only roles. A user with the view-only role only has access to view data, but can’t add new, update or delete data.

Application hosting

Our Node.js application is hosted at Heroku. Heroku internally uses Amazon (AWS), and is credited with:

  • ISO 27001
  • SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
  • PCI Level 1
  • FISMA Moderate
  • Sarbanes-Oxley (SOX)
  • Fire detection and suppression systems (Wet-pipe or double-interlocked pre-action or gaseous sprinkler systems)
  • Power; all data centers are protected with UPS (Uninterruptible Power Supply.
  • Climate and temperature control; All data centers provide atmospheric conditions at optimal levels

Heroku also provides excellent firewalls, protecting against applications establishing localhost connections over the loopback network interface. TCP Syn cookies help protect the Heroku network against DDoS attacks, which is further protected through our CDN provider Cloudflare. The Heroku-managed firewalls also prevent IP, MAC and ARP spoofing, and packet sniffing is prevented by infrastructure including the hypervisor which will not deliver traffic to an interface to which it is not addressed to.

The fundamental fact that environments at Heroku are separated, is documented further here .

Disaster Recovery

Backup of data

21RISK ensures that we have a continuous backup of both the application code and all data stored in our database. This makes it possible to recover after an unexpected failure, with a minimum of interruption.

On a regular schedule, we make sure to back up to a different region, to ensure data is stored in multiple AWS regions.