This article serves to provide a high-level summary of the security practices in place in the Comply Group platform. For simplicity purposes, there are 10 core areas of security that we'll run through in this guide:

  • Transit security

  • Traffic screening

  • Server level security

  • Data encryption

  • Data backups

  • Database record ID management

  • Account security

  • Email security

  • Penetration tests

Note, we also have a high-level Incidence Response (IR) plan - available here

Transit security (SSL)

We strictly enforce encryption on all traffic at multiple layers;

  • An edge SHA256 SSL certificate managed and distributed by Cloudflare (our CDN and external WAF).

  • An origin SHA256 SSL certificate managed by Cloudflare and installed directly into our servers.

  • We enforce all requests to be secure (HTTPS) using TLS 1.2 or greater and by enabling HSTS with a 6 months maximum age.

  • We have 24/7 monitoring of the production and distribution of certificates using our domain name, comply.group.

CDN & External WAF

We use Cloudflare to filter bad actors from using the platform.

  • Enforce JS Captcha scripts for all traffic outside of our primary supported countries (UK, Ireland, Australia, United States, Canada).

  • Block countries with a high rate of bad request attempts (Russia, Nigeria, Pakistan, India, Ukraine, China, North Korea, and more).

  • DOS & DDOS protection (with escalation polices) enabled.

  • OWASP Top Ten filters enabled (and other platform-specific recipes)

Internal WAF & request monitoring

We use Sqreen to filter bad actors within the application.

  • Automatically blocked IP addresses behaving strangely within the platform architecture.

  • Direct integration into the authentication library to monitor; failed login attempts, password reset attempts, non-human authentication behaviour, etc.

  • DOS protection (with escalation policies) enabled.

  • OWASP Top Ten filters enabled (and other platform-specific recipes).

Server security & compliance standards

We use AWS as our exclusive hosting provider.

  • Data centre compliance (ISO 27001, SOC 1, SSOC 2, PCI Level 1, FIDMA Moderate, SOX).

  • Automated application and infrastructure vulnerability monitoring and server operating system security updates management.

Data encryption

  • Databases (and their backups) are encrypted at rest.

  • All data is encrypted in transit (described above in "Transit security").

  • Check-in data that is personally identifiable (email, phone, address, identification number, etc) is encrypted within the database.

  • Check-in data downloaded for a location is stored in a password-protected Zip file with a different, random password for each download.

Data backups

  • All databases are backed up on a 30-day rolling basis with Point in Time Restores.

  • All s3 buckets (used to store files) are fully versioned controlled (since creation) and are fully recoverable when updated or deleted.

  • We have our servers and database distributed across two independent zones in Sydney providing real-time geographic/zonal-based failure redundancy.

Database record ID management

  • Each record in our database has a unique ID.

  • These unique IDs are not exposed to the web. RESTful requests using database record IDs in the URL are rejected.

  • Each record's ID is obfuscated with a unique, 12 character minimum, alphanumeric hashid which is uniquely salted and peppered.

Account security

  • Account passwords are salted and peppered.

  • Account passwords must be alphanumeric and a minimum of 8 characters.

  • Every account authentication interaction is recorded and logged.

  • Every check-in data download is recorded and logged.

  • Every change to a location is recorded and version controlled.

  • All actions throughout the platform have authentication and authorization RBAC policies documented, implement, and tested.

  • Multi-Factor Authentication is available for all users (read feature guide).

Email security

  • Send Policy Framework (SPF) is configured and enforced

  • DomainKeys Identified Mail (DMARC) is configured and enforced

Penetration tests

  • We conduct penetration tests when it makes sense for us to do so, most typically on an annual schedule or sooner if large changes are made to critical areas.

  • If you'd like to conduct a specific penetration test to get a specific report type, if you pay for it we will commit to conducting any necessary remediation.

  • If you'd like to request a copy of our most recent penetration test report, we'd be happy to oblige, but only after the commercial discussion has begun.

For a more nuanced, detailed conversation on data security, feel free to email [email protected] directly.

Did this answer your question?