Daasity Data Security Overview

This page outlines Daasity's security policies and procedures.

Daasity Security Overview

The Daasity Platform is a data platform for consumer brands that need to Extract, Load, Transform and Visualize their data.

We enable merchants to become data-driven organizations by helping them implement ELTVO. Daasity is the only data platform built specifically for brands. Brands have the flexibility to use Daasity for one component of their analytics stack, or all of it.

Daasity processes and stores end-user data on behalf of its customers

Infrastructure

The Daasity platform is hosted on the Amazon Web Services (‘AWS’) Infrastructure as a Service (IaaS) platform and Snowflake Data warehouse PaaS.

Daasity uses the AWS resources located in the US West (Oregon, us-west-2) region.

The components which make up the Daasity System are made available across different AWS Availability Zones to ensure redundancy at every tier of the Daasity Platform.

Daasity uses Reserved and On-Demand instances for all its compute requirements.

Ownership and Management of the hardware are within Amazon’s span of control as an IaaS provider. Daasity will use commercially reasonable efforts to make each Service available with an uptime of 99.8% of each calendar month ("Target Availability").

Security and Encryption At Daasity

Keeping our Customers' Data secure is a critical component of the Daasity infrastructure and Daasity policies and procedures. We go through considerable lengths to ensure that all Data sent to Daasity is handled securely - keeping Daasity secure is fundamental to the nature of our business.

At Daasity we follow a number of best practices that improve our security posture.

Security & Encryption Procedures & Policies

• We have functioning, frequently used automation in place so that we can safely and reliably rollout changes to both our application and operating platform within minutes. We typically deploy up to multiple times a week, so we have high confidence that we can get a security fix out quickly when required.

• All data sent to Daasity is encrypted in transit. Our API and application endpoints are TLS/SSL only and score an "A+" rating on SSL Labs' tests - meaning that we only use strong cipher suites and have features such as HSTS and Perfect Forward Secrecy fully enabled. We encrypt data at rest.

• We regularly engage with well-regarded third-party auditors to audit our code-base and infrastructure, and work with them to resolve potential issues.

• We use technologies such as Datadog, PaperTrail and AWS Cloudtrail to provide an audit trail over our infrastructure and the Daasity application. Auditing allows us to do ad-hoc security analysis, track changes made to our setup and audit access to every layer of our stack.

• We use two-factor authentication whenever possible. We ask vendors to enforce two factor authentication in all their accounts.

• We also encourage the use of two-factor authentication logins for our application to our merchants, so as to protect their user accounts.

• We discourage the use of shared accounts on any system – when we have the option to support multiple user accounts.

• Daasity uses 1Password to securely store and share logins. We review which accounts can access our systems and the permissions they have regularly.

• We have a documented incident response plan and educate all staff on security procedures and policies.

Extract and Load Process

Replicating Data from our Customers’ Data Sources and loading them into a database is a core component of the Daasity platform. To ensure data is secure, the Daasity platform extracts and loads data as follows:

1. Data is replicated from the source system (API or Database Replication) by connecting via TLS/SSL (API) or SSH (Database if available) to the source system

2. Data is extracted and temporarily stored as encrypted files in the Daasity AWS S3 bucket. The Daasity AWS account is in a private VPC, which is NOT publicly accessible.

3. Data is loaded into the merchant database (Snowflake if using the Daasity database) via a TLS/SSL connection.

4. Data is available for up to seven (7) days to ensure the data is loaded properly. Once the data is loaded, it is removed from the Daasity AWS bucket.

Transformation Daasity

Transformation Code is stored in Github in a Private Repository that can only be accessed by Daasity employees who are required to have two-factor authentication enabled.

The transformation code is referenced from the private repository and then executed on the customer database.

All Transformation operations are performed via Secure Connections within the Daasity platform.

Selected Daasity employees can connect directly to the database but can only retrieve keys to login into the customer database by utilizing the Daasity platform which requires two-factor authentication and connecting via SSH.

Customers that utilize the Daasity Snowflake instance are required to access the database via secure connection. Customers that provide their own database may enable their own security protocols, however Daasity highly recommends customers implement two-factor authentication and SSH to access the database.

Visualization

Daasity restricts the ability of a Visualization tool to access a database via IP address permissions and secure connections. Daasity managed Visualization instances will have two-factor authentication required for users to sign into the visualization platform. Specific roles are created to restrict access to the database.

Customers that manage their own visualization instance may implement their own security protocols; however Daasity recommends that customers utilize two-factor authentication and restrict user access where appropriate.

Privacy

Information on the Daasity Privacy Policy, the EU-U.S. Data Privacy Framework (EU - U.S. DPF) and the UK Extension to the EU-U.S. DPF, the Data Processing Addendum and Subprocessor List can all be found in our Daasity Privacy Policy

Daasity does NOT need to be PCI compliant because we do NOT store Credit Card or Debit Card Information

Customer PII Redation in Daasity App

Background

Daasity supports the ability to redact a merchant's customer's PII information (email, address, etc.) This feature may be enabled for Growth and Enterprise merchants. However, there is a functionality difference - noted below. Also note: this service works for Snowflake and Redshift. BigQuery is currently not supported.

To be able to utilize the redaction features, the Daasity support team must enable the redaction feature for your account. Please reach out to [e-mail] and ask them to enable the Redaction feature for your account.

Automated / Self Serve data redaction

Merchants and Daasity team members may submit an email redaction request within the Daasity app. The new UI allows a user to enter one email or a list of emails to be processed. The submitted emails will then be processed automatically.

To get this going, simply follow the Setup instructions below and refer to the Using Redaction section for a description of the UI features.

Using Redaction

Submit a request to have one email be processed

The user may enter the email into the Customer Email field.

Then the user must click the Request Redaction button to submit the email.

Submit a list of emails to be processed

The user may drop a file which contains a list of emails.

File format notes:

• the emails must be on individual lines - DO NOT add multiple emails per line

• the file MUST NOT include a header row

• the file is just a list of emails - it is also possible to download a sample file

The user may drop the file into the File selection area - or - click to browse the local disk for a file. Once the file is uploaded it will display the contents of the file in the "Emails to be processed from list" section. This provides a preview of the emails that will be processed.

Then the user must click the Request Redaction button to submit the emails.



Check Status by Email

The user may check to see if an email has been submitted and processed.

Upon entering the email and pressing the Check status button, the system will return one of three different messages:

1. The email was not found - which typically means it was not submitted to be processed

2. The email was found and is "pending" aka not processed yet - it will likely be processed when the redaction job will run. It will return when it was submitted and by whom.

3. The email was processed - it will return when it was processed and by whom.

Technical details

How does it work?

1. any un-redacted emails are gathered from the platform.redacted_emails table and inserted into a staging table platform.emails_to_redact table.

2. the standard redactions are performed

3. any custom redactions are performed

4. cleanup - platform.redacted_emails are marked as processed and the staging table platform.emails_to_redact table is truncated.

Standard Redactions

The standard redactions are located in either

https://github.com/Daasity/platform-sql-v2/tree/master/scripts/base/9990_customer_redaction

https://github.com/Daasity/platform-sql-internal/tree/master/scripts/base/9990_customer_redaction

They are maintained by the transform team.

Custom Redactions (per merchant)

NOTE: custom redactions are ONLY available for Enterprise merchants, not Growth merchants.

Custom Redactions are located in the merchant's client folder or github folder. These files are maintained by the Daasity team or a Merchant's team. Custom Redaction Processing requirements:

• a script manifest file, named customer_redaction.yml must exist in the root folder

• the script manifest file is similar in syntax to other manifest files

• a sample starting file may be:

# # configuration file for redacting customer emails # version: '2.0.0'

sections:

#------------------------------------------------------------------------------------------------ # Description: This is the merchant supplied shopify information # Dependencies: Shopify #------------------------------------------------------------------------------------------------ custom: scripts: - "redactions/my_redaction.sql"

In this case the root folder contains the customer_redaction.yml manifest file and a subfolder redactions contains the scripts to run.

Daasity Data Retention Policy

All Merchant Data stored in the Daasity Database is available throughout the term of the contract. Once the contract has been terminated, the data may be available for up to 30 days for the merchant to download the data.

The merchant may request data to be deleted at any time during the 30 days.

However, once 30 days have expired from contract termination, the data is deleted from the Daasity platform.