Stitch gives you the power to secure, analyze, and govern your data by centralizing it into your data infrastructure. Our most important job is to keep your data safe along the way.
- Stitch’s servers are hosted in Amazon Web Services (AWS), which provides assurances for their physical and virtualized computing environments including SOC 1, 2, and 3, and ISO/IEC 27001. The servers used to process replicated data for your account will be located in the AWS region associated with your Stitch data pipeline region.
- Stitch operates within an Amazon Virtual Private Cloud (VPC), with subnets segregated by security level, and firewalls configured to restrict network access.
- Stitch regularly performs automated vulnerability scans and installs security updates and patches.
- Stitch’s application and environment are protected by dedicated firewall services to prevent unauthorized access and regularly audited by third-party security professionals conducting specialized penetration tests.
Data access policies
- Stitch strictly controls access to data and credentials and requires them to be encrypted using industry-standard methods both at rest and in transit within our environment.
Stitch’s secure infrastructure is a closed network protected by multi-factor authentication and accessible only to qualified members of our engineering team. On the rare occassion that a Stitch engineer needs to read or move data to investigate an issue, your data will never leave our infrastructure.
Additionally, all members of the Stitch team - not just engineers - have signed non-disclosure agreements.
- Stitch’s data centers are protected by electronic security, intrusion detection systems, and a 24/7/365 human staff.
- Stitch monitors application, system, and data access logs within its production environment for anomalous behavior.
- Stitch will never access data in your destination without your explicit permission. We’ll ask every time this is required and notify you when it’s happening.
PII stored by Stitch
Stitch stores some PII (Personal Identifiable Information) related to your account. This PII is provided during signup and includes:
- First and last name
- Email address
- Company name
- Country and state
- Phone number
- Billing address
The only PII that goes through Stitch is the data sent from your source. This data is not stored outside of our retention window. Additionally, Stitch collects performance metrics, but these do not include any customer-provided information. Stitch also stores table names for functional reasons.
Stitch account access
Stitch supports Single Sign-On (SSO), which allows you to securely grant members of your team access to Stitch by internally managing their credentials. Stitch currently supports the following Identity Providers (IdP):
The SSO feature is available on all Stitch plans.
- All plans include SSH tunnels and IP whitelisting for integrations and destinations that support these features.
- For Premium plans, additional advanced connectivity options - such as VPNs, reverse SSH tunneling, and Amazon Web Services Private Link - may be available.
Permissions for integrations and destinations
Stitch’s integrations use the minimum permissions that allow read access to necessary data and can be configured by users to replicate only a subset of available data.
However, the permissions Stitch requires to successfully pull your data will depend on the database or SaaS application’s permission structure. In some cases, we only need read-only permissions to pull all the data required - in others, we need what amounts to full access.
Regardless of the level of permissions we request for an integration, we will only ever read your data. Any permissions beyond the scope of read-only will not be used.
To ensure Stitch remains visible in logs and audits, we recommend creating a dedicated Stitch user as a best practice.
Stitch’s destinations use the minimum permissions that allow Stitch to successfully load data into your destination. In most cases, Stitch requires the ability to create schemas, tables, columns, and to read and insert data.
The specific permissions Stitch requires are different for each destination. Refer to the documentation for your destination for more info.
The following table contains info about Stitch’s level of compliance or certification with various security regulations and programs:
- - Indicates Stitch is fully compliant/certified
- - Indicates Stitch may be compliant/certified, but with caveats
- - Indicates Stitch isn’t currently compliant/certified
Stitch isn’t currently certified with the Federal Risk and Authorization Management Program (FedRAMP).
Stitch is fully compliant with the European Union’s Global Data Protection Regulation, or GDPR.
Additionally, Stitch supports selecting the region in which you’d like your account’s replicated data to be processed. Refer to the Data processing section for more info.
Stitch can replicate data in a HIPAA-compliant manner as part of an Advanced or Premium plan. To learn more about replicating data subject to Health Insurance Portability and Accountability Act (HIPAA) regulations with Stitch, contact the Stitch Sales team.
Note: There are requirements outside of Stitch configuration that must be completed to ensure compliance. Reach out to Stitch Sales before replicating any sensitive data.
Stitch doesn’t currently support replicating data in a PCI-compliant manner. To log feedback about replicating data subject to PCI requirements, reach out to our support team.
However, all payment information submitted through Stitch’s billing interface to pay for your subscription is handled in a PCI-compliant manner.
|Privacy Shield||All plans||
Stitch is certified under the US-EU and US-SWISS Privacy Shield Programs, meaning any EU or Swiss data transfer will be handled in accordance with the principles laid out in the Privacy Shield Framework.
For more information on Privacy Shield, check out the previous link or this FAQ on the program.
|SOC 2||All plans||
Stitch has been certified compliant with the SOC 2 security, availability, and confidentiality principles by an independent auditor.
The audit report can be requested by contacting Stitch Sales.
- Stitch’s web application enforces SSL to ensure communication remains secure.
- All credentials used to access other systems (i.e., your database or a SaaS integration) are encrypted before Stitch stores them.
- Data is always encrypted in transit and at rest within the Stitch environment. At rest, Stitch uses AES-256 to encrypt data.
Stitch offers several secure options for creating connections to integrations and destinations:
Refer to the Data encryption guide for more info.
Data processing and retention
The Data pipeline region setting, defined when you create a Stitch account, controls the region where Stitch-hosted data centers process replicated data.
Note: The Data pipeline region setting only affects the replication of data in your Stitch account, specifically extracting, preparing, and loading data into your destination. All other processes and data, such as billing, reporting, and other metadata, are not affected by your account’s data pipeline region. Data and metadata related to these processes will be processed using Stitch’s
Refer to the Supported Data Pipeline Regions documentation for more info.
To ensure we meet our most important service-level target - don’t lose data - replicated data may be retained in Stitch’s system for a short period of time. Stitch automatically deletes data when it is no longer needed for replication.
During the Preparing phase of the replication process, Stitch buffers extracted data in its internal data pipeline and readies it for loading. This phase consists of the following steps:
|Step name||Maximum retention period||Description|
Stitch uses Apache Kafka and Amazon S3 systems spanning multiple data centers to durably buffer the data received by the Import API. Data is always encrypted at rest, and automatically deleted from the buffer before the maximum retention period for this step.
The Streamery reads data from the Pipeline and separates, batches, and prepares it for loading. Prepared data is encrypted, separated by tenant (Stitch account) and data set, and written to Amazon S3 to be loaded.
Most data is loaded within minutes, but if a destination is unavailable, it can stay in S3 for up to 30 days before being automatically deleted.
To summarize, all data that Stitch processes for customers will be deleted from our systems within 30 days.
Protocols and recommendations
- Create a dedicated user for Stitch whenever possible. This applies to any integration or destination. Refer to the Permissions for integrations and destinations section for more info.
- For database connections, utilize Stitch’s built-in support for SSH and SSL/TLS connections to encrypt data in transit. Refer to the Data encryption guide for more info.
- For SaaS data, keep any credentials or sensitive information such as passwords, API keys or tokens, etc. secure.
If your database(s) or SaaS account(s) have been hacked, we recommend that you:
- Immediately recycle any credentials used to access your system or service,
- Generate new credentials, and
- Update the credentials for the appropriate integration(s) in Stitch.
Our team can help you remediate any data issues that might have occurred as a result of the breach.
Issue reporting and handling
If our team verifies a security vulnerability in our system, our first priority is to prevent its exploitation. After it’s contained, we do a thorough analysis to determine the scope of impact and notify affected users within 24 hours.
If you believe you’ve found a security vulnerability in Stitch, we encourage you to let us know right away by emailing firstname.lastname@example.org. We request that you do not publicly disclose the issue until we have a chance to address it. We won’t pursue legal action as long as you make a good-faith effort to avoid privacy violations and destructive exploitation of the vulnerability.
We will respond as quickly as we can and reward the confidential and non-destructive disclosure of any design or implementation issue that could be used to compromise the confidentiality or integrity of our users’ data (such as bypassing our login process, injecting code into another user’s session, or acting on another user’s behalf) with some swag. Other issues may be rewarded at our discretion.