Overview

Stacksync is committed to security and focused on keeping you and your data safe. Stacksync adheres to industry-leading standards while connecting your apps together.

Updated July 31, 2023

Stacksync is committed to security and focused on keeping you and your data safe. Stacksync adheres to industry-leading standards while connecting, replicating, and loading data from all of your data sources.

Contact [e-mail] if you have any questions or comments.

---

TL;DR

Stacksync does not store any customer data, data is only processed at Stacksync but never persisted. Even during transit, all data is encrypted with AES encryption (military-grade protocol). Only the credentials to access the Salesforce instance or database, and some minimum metadata about the tables and columns synced are stored (not all columns, only the ones that are selected to be synced). The metadata is stored in a custom Stacksync format, which removes most of the tables and columns attributes, keeping only the name of the column (or identifier) and datatype.

All credentials are encrypted with regularly rotating keys in a fully autonomous way, such that no one can access it in production. Stacksync stands at the top standard in terms of security and privacy.

Stacksync lets you choose the region where your data is processed. This enables for maximum compliance and system performance (due to proximity with client’s data sources).

---

Detailed security policies

Web portal connectivity

• All connections to Stacksync's web portal are encrypted by default using industry-standard cryptographic protocols (TLS 1.2+).

• Any attempt to connect over an unencrypted channel (HTTP) is redirected to an encrypted channel (HTTPS).

• To take advantage of HTTPS, your browser must support encryption protection (all versions of Google Chrome, Firefox, and Safari).

---

Connectors

• Connections to customers' database sources and destinations are SSL encrypted by default.

• Stacksync can support multiple connectivity channels

• Connections to customers' software-as-a-service (SaaS) tool sources and destinations are encrypted through HTTPS.

---

Permissions

• Databases and API cloud applications - Stacksync requires READ and WRITE permissions.

• Connected Applications - Stacksync requires the READ and WRITE permission. This permission allows Stacksync to CREATE a schema within your destination, CREATE tables within that schema, and WRITE to those tables.

---

Retention of customer data

How long we retain customer data depends on the data type:

Customer data (in flight processing)	a few seconds (< 1 hour in rare conditions, usually)	We purge customer data as soon as it is successfully written to the destination, except in the cases below. The operations should last, in most cases, only a couple of milliseconds or seconds since we sync data in real-time but some technical conditions and data volumes might require longer processing, usually up to one hour. -> In-flight data is fully encrypted and is never persisted plain text. We are compatible with the highest security standard for in-flight data processing.
Customer data (synced)	Persistent	In order to detect changes when customers edit data in their app, Stacksync needs to keep a hashed version (fingerprint only) of each synced record. The hashed copy is stored permanently (or until it is deleted in the synced apps) in our regional storage, in the region you have chosen in your Base configuration. The data is hashed using various algorithms so it cannot be reversed in any case. This hashed record image is also stored in our most secure storages. This technical design is fully approved by highest security and privacy standards and regulations.
Customer data where sync errors are detected.	Varies	Stacksync detects errors when syncing one-way or bidirectionally between apps. These errors most often result from differences in schemas between synced apps. These differences are authorized and are normally handled by Stacksync automatically. However, customers might insert data in one app that cannot be replicated on the other synced app. When this is the case, Stacksync detects the error and stores the encrypted data to display it to the user (for troubleshooting) and then tries to re-sync it. When the error is fixed by the user or is overridden by another valid (i.e. non-error) update, the error is deleted from our storage. The retention period depends on the time taken to fix the issue.
Event data from the Webhooks connector and other connectors using webhooks	< 3 minutes	If you sync webhooks or event data, we do not retain data since data is processed immediately when it is received on your servers.
Customer access keys	Persistent	We retain customer database credentials and SaaS OAuth tokens to securely and continuously extract data and troubleshoot customer issues. These credentials are securely stored in a key management system, which is backed by a hardware security module managed by our cloud provider.
Customer metadata	Persistent	We retain configuration details and data points (such as table and column names) for each connector so that this information can be displayed in your Stacksync dashboard and be used to process data as well.

In the following two cases, customer data is purged as soon as it is successfully written to the destination. If the data writing process takes longer than usual, the data is however kept for object lifecycle management:

• Destination outage: If your destination is down, we maintain the data that we've read from your source so we can resume the sync without losing progress once the issue is resolved.

• Schema information for column blocking or hashing purposes: If you choose not to sync a column before syncing your new connector, we queue your data while we read the full schema. We only write the data to the destination that you approve.

---

Encryption and Hashing

Stacksync uses best-in-clash algorithm to encrypt and hash your data.

Encryption: AES encryption with autonomous rotating keys. Encryption keys are frequently updated ensuring effective partitioning of data on several keys as well as perfect forward secrecy. AES is a military-grade standard.

Hashing: various algorithm, often coupled with byte compression.

---

Solution infrastructure

Access to Stacksync production infrastructure is only allowed via hardened IAM (identity and access management) policies. Further access to the environment and enforcement of least privilege is controlled by IAM policies. Privileged actions are captured in audit logs for review and anomalous behavior detection.

---

Physical and environmental safeguards

Physical and environmental security is handled entirely by our cloud service providers. Each of our cloud service providers provides an extensive list of compliance and regulatory assurances, including SOC 1/2-3, PCI-DSS, and ISO27001.

Google

See the Google Cloud Platform compliance, security, and data center security documentation for more detailed information.

Amazon

See the Amazon Web Services compliance, security, and data center security documentation for more detailed information.

Azure

See the Azure compliance, security, and data center security documentation for more detailed information.

Scaleway

See the Scaleway compliance, security and data center security documentation for more detailed information.

OVH

See the OVH compliance, security and data center security documentation for more detailed information.

---

Stacksync data residency

Stacksync runs data connectors on servers such as in the United States (US), Canada, European Union (EU), United Kingdom (UK), Australia, Singapore (non-exhaustive list). You can select your preferred data processing location when configuring your Base. All connectors configured in a destination run in the destination's designated location. This means that your data will not leave our region-specific servers during processing. For example, if you configure your destination to use our EU servers, your data will not leave the EU during processing or storage. See our Base and Connected Apps documentation to learn how to configure your data processing location.

Stacksync runs services on Google Cloud Platform (GCP), Amazon Web Services (AWS), and Azure. The following table lists regions supported by Stacksync for each service provider:

GEOGRAPHY	GCP REGIONS	AWS REGIONS	AZURE REGIONS	Scaleway	OVH
Americas	us-east1 (South Carolina)* us-west1 (Oregon) us-central1 (Iowa) us-east4 (Northern Virginia)	us-east-1 (N. Virginia)* us-west-2 (Oregon)	N/A		Beauharnois (Canada)*
EU	europe-west1 (Belgium)* europe-west3 (Frankfurt, Germany) europe-west6 (Zurich, Switzerland)	eu-central-1 (Frankfurt)*	N/A	Paris*
Asia	asia-southeast1 (Singapore)*	ap-southeast-1 (Singapore)*	N/A

*NOTE: Default region for a given cloud provider / geography combination.

IMPORTANT: Google Cloud Platform is the default cloud service provider. You can select a different cloud service provider and region if you are on a plan that allows that option.

---

Your organization permissions

• Only users of your organization registered within Stacksync and Stacksync operations staff have access to your organization's Stacksync dashboard.

• Your organization's Stacksync Dashboard provides visibility into the status of each integration, the aforementioned metadata for each integration, and the ability to pause or delete the integration connection - not organization data.

• Organization administrators can revoke immediately an organization member’s access to a workspace at any time from the Workspace Settings page. Otherwise, Organization administrators can request that Stacksync revoke an organization member's access at any point; these requests will be honored within 24 hours or less.

---

Company policies

• Stacksync requires that all employees comply with security policies designed to keep any and all customer information safe, and address multiple security compliance standards, rules and regulations.

• Two-factor authentication and strong password controls are required for administrative access to systems.

• Security policies and procedures are documented and reviewed on a regular basis.

• Current and future development follows industry-standard secure coding guidelines, such as those recommended by OWASP.

---

In the event of a data breach

To date, Stacksync has not experienced a breach in security of any kind. In the event of such an occurrence, Stacksync protocol is such that customers would be made aware as soon as the compromise is confirmed.

---

Responsible disclosure policy

At Stacksync, we are committed to keeping our systems, data and product(s) secure. Despite the measures we take, security vulnerabilities will always be possible.

If you believe you’ve found a security vulnerability, please send it to us by emailing [e-mail]. Please include the following details with your report:

• Description of the location and potential impact of the vulnerability

• A detailed description of the steps required to reproduce the vulnerability (POC scripts, screenshots, and compressed screen captures are all helpful to us)

Please make a good faith effort to avoid privacy violations as well as destruction, interruption or segregation of services and/or data.

We will respond to your report within 5 business days of receipt. If you have followed the above instructions, we will not take any legal action against you regarding the report.

---

Diagnostic data access

IMPORTANT: Stacksync cannot access your data without your approval.

When working on a support ticket, we may need to access your data to troubleshoot or fix your broken connector or destination. In that case, we will ask you to grant Stacksync access to your data for the next 21 days. You can allow or deny data access. If you grant us data access, you can revoke it at any moment before the 21-day diagnostic period has expired.

See our support documentation for more details.

---

Questions?

We're always happy to help with any other questions you might have! Send us an email at [e-mail]