We go above and beyond legal requirements to protect all of your data. This document outlines additional precautions we take to keep your customers’ data safe.
Our engineering team includes people who have played significant roles in both startups and large organisations, for example, XSellco and Workday. They have experience building Internet-facing applications that house highly confidential and mission-critical data.
In the event of a data security incident, all key personnel are requested to respond immediately. Those in charge of affected parts of our application and infrastructure are notified and assembled to address the incident quickly. Upon notification, incident resolution time is on the order of minutes.
Following a data security incident, a post-mortem analysis is performed. The outcome of our analysis is discussed internally and shared among the relevant personnel. The analysis includes actionable items to help make it easier to detect and prevent the occurrence of similar incidents in future.
We deploy code on our production server tens, and in some cases, hundreds, of times per day. This enables us to respond to data security incidents with code changes within minutes.
We have a semi-automated deployment system, which requires us to peer-review all code changes before being deployed to our production servers. Code changes are reflected across all of our production servers within minutes. We use GitHub and AWS to help automate this process.
All of our services are cloud-based. We do not run our own infrastructure.
All of our own data services are hosted in Amazon Web Services (AWS) facilities across the EU. We do not have control over where our third-party services are hosted, for example, Google Analytics. All of our clients’ customer data is hosted and processed using AWS.
Our infrastructure is spread across 2 AWS data centres (also known as availability zones). This adds redundancy to our system, as should one of the data centres fail unexpectedly, our services will continue to work.
All of our customer data is stored in the European Union.
Customer data is stored in multi-tenant data stores. This means that we do not have individual data stores for each customer. Should you wish to have your own dedicated datastore, please contact us and we can discuss your requirements.
In order to prevent one customer from accessing another customer’s data, we have a number of low-level code checks that fail upon not being provided with the logged-in customer identifier. We employ automated testing prior to every code change being deployed on our production services. Additionally, we periodically perform code audits to prevent this from happening.
Internally, all database entity types have a client identifier field. All queries are required to provide a client identifier. This check has been implemented at a low-level. It ensures that one client cannot access the data of another client.
We have set up a virtual private cloud (VPC). Two subnets live inside our VPC; a public subnet and private subnet. Our database services live inside our private subnet. This means that only servers in the public subnet can communicate with our database servers. All ports (besides HTTP (80) and HTTPS (443)) on servers living inside our public subnet have been restricted to whitelisted IPs defined in a security group. The whitelisted IPs are the addresses that we use internally and are inaccessible from sources outside our network.
We only permit server access to public keys whitelisted on our servers. This prevents SSH server access from computer devices outside of our organisation.
All data sent to and from Aibl is encrypted in transit using state-of-the-art 256-bit encryption.
Our platform and API are SSL-only.
Aibl is served 100% over HTTPS.
We use two-factor authentication (2FA) and stringent password policies across our own and third-party services we use. These include GitHub, AWS, Google, and Aibl.