Layer 1
Menu

Qwilr Security and Compliance FAQ

This FAQ is supplied Commercial in Confidence to customers or potential customers. We are constantly refining our practices in this regard, so if there are any further questions please contact Qwilr.


Version date: November 14, 2022

General Security at Qwilr

What are Qwilr's security policies?

At Qwilr, we define internal policies governing how we manage and protect customer data, production systems and manage (prevent, detect, respond and learn from) security issues. We also use security best practices in the technical architecture of our product itself via stateless sessions, TLS, Encryption and Token-based authentication. Periodic reviews are undertaken to review policies and further improve our security posture.

How does Qwilr manage security operations?

At Qwilr, Engineering security operations are structured around the following pillars:

  1. 1.Operations - Security features strongly in our incident management and response process. At Qwilr we have a permanent Infrastructure team and a rotation of Engineers that are on call for security and operational issues.
  2. 2.Maintenance - Key maintenance and monitoring tasks are required to maintain security protection. At Qwilr we have a "Security Warden" rotating role that is responsible for these tasks.
  3. 3.Prevention - Security features strongly in our quality standards for software development and is woven into our approaches for building and testing software throughout its development. We also perform period security reviews and penetration testing with subsequent action to protect from vulnerabilities.

How does Qwilr manage security incidents?

The Qwilr Engineering team has a permanent infrastructure team and rotation of Engineers on-call to respond to production incidents related to security or reliability in general. Our incident management includes best practices such as:

    • Observability to assist with detection and diagnosis of issues.
    • Internal escalation to troubleshoot and resolve incidents in a timely manner.
    • Post incident reviews and actions to prevent reoccurrence.

Who is responsible for investigating security incidents at Qwilr?

The Qwilr Engineers on-rotation to respond to support production incidents are responsible for investigating, resolving and reviewing security incidents similar to other incidents. Engineers on rotation call upon other expertise as necessary to protect Qwilr and our customers in a timely fashion.

How and when does Qwilr communicate to customers about security breaches?

Qwilr actively communicates to customers when providing technical support and if particular customers are impacted by a severe incident, security or otherwise.

The timing of communications is a best-efforts basis and can be affected by impact and root-cause analysis.

Who do customers contact if they become aware of a security breach?

Contact our 24x5 support via the email [email protected] immediately if they become aware of a real or potential security breach.

How do customers track the status of information security incidents?

If Qwilr has been taken offline wholly or partially, the availability of Qwilr can be monitored via status.qwilr.com or directly via email. For security incidents, Qwilr may also initiate direct contact with affected customers for protection purposes.

What does Qwilr do to protect against security vulnerabilities?

Qwilr performs the following activities to protect against Security Vulnerabilities:

    • Monitoring: Qwilr relies on observable analytics for the detection of abnormal usage patterns. Rate limiting applies across key endpoints and emails, triggering actions to protect against intrusion attempts and severity.
    • Maintenance: Qwilr performs regular automated security vulnerability check in our systems on 3rd party dependencies and addresses them if possible. Our containers have a combination of automatic security updates and manual update checks.
    • Review: Qwilr periodically implements security reviews and improvement actions.



General Compliance at Qwilr

Is Qwilr PCI-DSS Compliant?

Yes, Qwilr is PCI-DSS compliant and accredited via Stripe. Please contact us to view a copy of our accreditation. Further:

  • We use Stripe for processing of financial transactions, who are themselves fully compliant.
  • We use TLS to serve all webpages related to billing.
  • We keep our servers secure with a role dedicated to security management.

For updates on Qwilr compliance status, please see https://qwilr.com/trust-and-security

Is Qwilr ISO 27001 Compliant?

Qwilr is not certified as ISO 27001 compliant. However, we do proactively follow these core practices:

  1. 1.Assess security risks and put appropriate controls in place to manage those risks.
  2. 2.Internal policies and controls for data classification and protection.
  3. 3.Internal policies and controls for the prevention, detection and resolution of security vulnerabilities and issues.
  4. 4.Periodically review our security risk and make changes to policies and controls where appropriate.

For updates on Qwilr compliance status, please see https://qwilr.com/trust-and-security

Is Qwilr SOC2/SOC II Compliant?

Qwilr is in-progress for being certified as SOC2/SOC II compliant and has broad coverage of equivalent policies and controls. Related information:

    1. a.We are PCI-DSS compliant to manage risks associated with customer billing data.
    2. b.Our primary infrastructure providers, e.g. Amazon Web Services and Mongo Atlas, are SOC2 compliant (https://aws.amazon.com/compliance/soc-faqs/).
    3. c.Internal policies and controls cover a broad range of areas including code of conduct, data classification and protection, internal security, vulnerability management, problem and incident management and vendor management.

For updates on Qwilr compliance status, please see https://qwilr.com/trust-and-security

Is Qwilr GDPR and CCPA Compliant?

Qwilr is fully compliant with GDPR requirements. We have established and closely follow internal controls and policies that address the requirements of that regulation insofar as they apply to Qwilr.

The CCPA is not applicable to Qwilr.

For updates on Qwilr compliance status, please see https://qwilr.com/trust-and-security


Production Data at Qwilr

If Qwilr and a Customer enter into a binding Data Processing Agreement (DPA), the conditions of the DPA take precedence over these practices.

What customer data does Qwilr store?

Qwilr stores data in order to provide and improve our SaaS service to customers. Specific data Qwilr stores includes:

  • Customer information: Commercial information is stored in Stripe, a PCI-DSS compliant system. General customer information may be stored in Qwilr to customise its functionality.
  • User information: Personal Identifying Information (PII) is stored as necessary to create and manage user accounts.
  • Content: User Generated Content (UGC) is stored in Qwilr as configured and used by Qwilr users.

Customer data is hosted on MongoDB Atlas which is PCI, GDPR and SOC2 compliant. Diagnostics and usage analytics are also stored in supporting SaaS systems. Anonymous identifiers are used wherever possible and practical.

How does Qwilr collect and process Personal Information?

Qwilr may Process Personal Data on the Customer’s behalf, only insofar as the processing is necessary to facilitate the purchase of, provide the features of the Qwilr product/service and to improve the Qwilr product/service as per our terms of service, except where otherwise permitted or required by an Applicable Data Protection Law. Specific processing activities are:

  • For delivery and provision of the Services.
  • For customer support and technical troubleshooting.
  • For Qwilr business operations.
  • To create new and improve existing products and services.
  • To market to Users and Customers.
  • For research and analytics.
  • To comply with the law, including law enforcement requests.
  • To prevent fraud and mitigate risk to Qwilr and others.

How is Production data backup and retention managed?

Qwilr uses the default backup policy provided by MongoDb Atlas, described here: https://docs.atlas.mongodb.com/backup/legacy-backup/overview/#snapshot-schedule Data is retained according to the defaults of the above policy, i.e.

  • Base snapshots are taken every 6 hours and stored for 2 days
  • Daily snapshots are stored for 7 days
  • Weekly snapshots are stored for 4 weeks
  • Monthly snapshots are stored for 13 weeks

How are requests for data restoration initiated?

In the unlikely event of a recoverable disaster (see “recoverable disaster definition”), Qwilr will treat the restoration of customer data as a top-priority. Qwilr Engineers and Support will perform the restoration with care, testing and communication with the customer.

Qwilr may, at its discretion, perform emergency restoration upon a customer request.

Recoverable disaster definition

A “disaster” refers to an event that renders system data lost or corrupted for a customer and was not caused by intended system behaviour in response to a customer action.

It is “recoverable” provided the incident did not impact stored backups. The amount of data lost following a backup will depend on the time of the most recent backup used for restoration.

Auxiliary data such as analytics may or may not be recoverable depending on the nature of the disaster.

How does Qwilr manage data disaster recovery (DR)?

Customers can expect a data recovery from a backup to be completed within 3 business days AEST of a request/incident.

Qwilr periodically tests data recovery and procedures at its own discretion. Data recovery is also exercised by occasional support requests. Where there is a loss of or damage to Customer Data, we will use our best endeavours to restore or reconstitute Customer Data from the last available backup using industry-standard techniques. The cost of data restoration will be borne:

  • by us, if we are responsible for the loss of or damage to Customer Data; or
  • otherwise by the customer.

How is data deletion initiated?

Qwilr will accommodate reasonable requests to delete customer data and related backups, except as required for legal purposes. This may exclude analytics and diagnostics stored in supporting systems. Timing of actioning these requests are on a best-efforts basis.

Is Production data used in other environments for testing?

Qwilr's policy is to avoid this wherever possible and use diagnostics tooling. If however, we are unable to reproduce a problem in relation to a particular customer, we inform them we are using a copy of their data for testing in a testing environment and delete it as soon as it is no longer required.



Access control at Qwilr

Who can access Production data?

Members of the Qwilr Engineering team with at least 6 months tenure are allowed to access the production environment for technical support purposes only, via a controlled process.

How are system credentials managed?

System credentials are stored in a password manager that is only accessible to eligible staff according to our production data policy, is only accessed in accordance with our product access process, and requires 2FA to access.

How are production data backups protected from unauthorised access?

Backups are hosted in MongoDB Atlas platform which provides its own protection: https://www.mongodb.com/cloud/atlas/security

What SSO authentication options are available for user access to Qwilr?

Qwilr supports SSO access for Google, Microsoft, HubSpot and Salesforce.

Is 2FA supported for user access?

At this time, 2FA is not supported for user access to Qwilr, except via SSO sign-on methods as described above.

What authentication options are available for administrator access to Qwilr?

Admin is an assigned role within Qwilr. Access options for this role are the same as for all Qwilr users.



Security and Qwilr's software process

What is Qwilr's SDLC, patch management and CI/CD process?

Qwilr uses an agile product development framework with clear boundaries at the start and finish of development projects. Mandatory quality standards for shipping code to production are defined in a company-wide "Definition of Done". All product source code, and Infrastructure-as-Code, is stored in our VCS, GitHub, and all changes are peer-reviewed. CI/CD enforces deployment of reviewed code only, successful automation test execution and consistent deployment processes. Patches comply with the same quality standards and shipping criteria as planned releases.

What controls are used for changes to production systems?

All code and infrastructure changes go through peer review. Where possible, the process is enforced by the system (e.g source code change via a VCS - GitHub and a preference for Infrastructure as code) or otherwise limited to Engineering admins only.

What is Qwilr's policy for applying patches to production systems?

Bug fixes are applied using the same process as features with prioritisation from leadership across engineering and support and deployment by Engineers on bugfix duty with peer review. Security patches are identified and prioritised by a dedicated Engineer on rotation, whose role includes identifying and applying security patches.

How are customers notified of new releases and updates?

As a modern SaaS product, Qwilr releases changes frequently that result in updated documentation (https://help.qwilr.com). Noteworthy changes have additional communications such as in-app notifications and announcement blogs. An example is https://qwilr.com/blog/product-polish-building-blocks-for-building-docs/.

How are customers notified of maintenance windows?

Most system updates require zero downtime. In the exceptional circumstance where downtime is required, we select low impact times for the downtime, communicate with customers affected and will provide relevant updates on our status page https://qwilr.statuspage.io.


Infrastructure and systems at Qwilr

How does Qwilr protect endpoints from viruses or malware?

Qwilr uses Intego VirusBarrier for endpoints protection.

How does Qwilr protect production systems from viruses or malware?

Qwilr's production services are hosted on Cloud66 and Amazon Web Services who maintain the integrity of their servers. Container images are Linux based and maintained with security updates.

Where is Production data hosted? What options are provided?

Qwilr production data is hosted in the Sydney region of Amazon Web Services regardless of where Qwilr is accessed from. We use AWS global CDN infrastructure to optimise performance, and do not currently provide further options of hosting in different regions.

Does Qwilr support encryption at rest?

Yes, all production data is encrypted at rest in our MongoDB Atlas hosted service. Secrets such as passwords are also stored in secret stores encrypted at rest and unencrypted for runtime use.

What level of encryption is used at the database layer?

AES256-CBC

How does Qwilr manage encryption keys for data encrypted at rest?

Volume (disk) encryption is used to encrypt data at rest on our production infrastructure. As such Qwilr does not manage encryption keys for this purpose.

Please provide a description of your key management procedures.

n/a - Qwilr does not manage encryption keys for the purpose of at-rest encryption.

What level of encryption is in use for data transmissions?

All data transmissions through the public internet are encrypted with at least TLS v1.2

What time source is used to synchronize time across the third party infrastructure?

Our distributed systems make use of default operating system NTP timestamp synchronisation.

What activity logs are available to customers?

Qwilr does not provide a user-facing Activity Log feature listing detailed user activity.

If you have any further questions, please contact our 24/7 support via the email [email protected].