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.
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.
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:
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.
In the event of a security breach, 21RISK will promptly notify you of any unauthorized access to your Customer Data.
If 21RISK developers categorize an incident as a bug, we then open, track and fix the issue using Github.
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.
All code changes in 21RISK follow this pattern:
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.
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.
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:
The features above is an contributing factor to MongoDB being certified with:
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.
Our Node.js application is hosted at Heroku. Heroku internally uses Amazon (AWS), and is credited with:
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 https://devcenter.heroku.com/articles/dyno-isolation .
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.