Inzata is committed to security and focused on keeping you and your data safe. Inzata adheres to industry-leading standards while connecting, replicating, and loading data from all of your data sources.
Contact firstname.lastname@example.org if you have any questions or comments..
Web portal connectivity
All connections to Inzata’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).
Standard data access permissions
Databases, Data Warehouses, Data Lakes, and API cloud applications – Inzata only requires READ permissions in order to load data from sources into Inzata.. For data sources that by default grant permissions beyond read-only, Inzata will never make use of those permissions.
Permanent storage of customer data within Inzata for Analytics purposes
All customer data loaded into Inzata is converted into Inzata’s proprietary file-based
data storage format, Inzata does not rely on SQL or other commercially available
databases for permanent customer data storage within the Inzata software. Inzata’s data storage conventions hash and distribute customer data within the customer’s Inzata environment. This storage structure is designed to only be accessed by the Inzata application and it’s administrative back end. It would not be possible for a third party to connect to the Inzata storage infrastructure and retrieve data via standard SQL commands.
Retention of ancillary customer data
All ancillary customer data files, besides what is listed below, is removed from Inzata’s system within 24 hours following a successful load of the data into Inzata’s platform. Inzata retains the required subsets of a customer’s data that are required to provide and maintain Inzata’s solution, and provide Analytics Software Services to your organization’s registered users. This includes only:
Customer access keys – Inzata retains customer database credentials and SaaS OAuth tokens in order to securely and continuously extract data and troubleshoot customer issues. These credentials are stored securely in a key management system backed by a hardware security module managed by our cloud provider.
Customer metadata – Inzata retains data points such as table and column names for each integration so that this information can be shown to your organization in Inzata’s user interface.
Event data from data loading routines (i.e. Webhooks and Snowplow.js) – Inzata stores customer event data for the aforementioned integrations within Inzata in the event that a customer should wish to perform a full resync of their event data.
Temporary data – Some data integration or replication processes may use ephemeral data specific to a data source. This stream of data is essential to the integration process, and is deleted as soon as is possible, though it may briefly exceed 24 hours in rare instances. (Examples of this temporary data may include Binary Logs for PostgreSQL, or the Event Stream for StreamSets.)
Inzata’s infrastructure is protected by a VPN, to which only named Inzata employees have access via 2-Factor Authentication. All Inzata processes operate within a defined Virtual Private Cloud (VPC) or VPC subnet, and connections between the two are further encrypted using SSL.
Connections to customers’ database sources and data warehouses are TLS encrypted by default.
Inzata can support multiple connectivity channels
Connections to customers’ software-as-a-service (SaaS) tool sources are encrypted through HTTPS.
Physical and environmental safeguards
Since Inzata relies on Virtual Private Cloud, physical and environmental security is handled by our Cloud Providers (AWS, DSM, Azure, etc.). Our Cloud Providers offer an extensive list of compliance and regulatory assurances, including SOC 1/2-3, PCI-DSS, HIPAA, CJIS, and ISO27001. See Amazon compliance and security documentation for more detailed information.
Your organization permissions
Only users of your Organization registered within Inzata and Inzata operations staff have access to your organization’s Inzata’s tools and dashboard(s).
Your organization’s Inzata Project provides visibility into the status of each integration, the aforementioned metadata for each integration, and the ability to pause or delete the integration connection.
Organization administrators can request that Inzata revoke an organization member’s access at any point; these requests will be honored within 24 hours or less.
Inzata 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.
Inzata employees are background-checked and required to sign and adhere to Inzata’s internal acceptable use policies.
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.
Networks are strictly segregated according to security level. Modern, restrictive firewalls protect all connections between networks.
Compliance and Privacy
Inzata, in its potential role as data subprocessor, adheres to the principles of the EU94/95 privacy rules as well the GDPR rules.
Under the HIPAA Security Rules, Inzata complies with HIPAA requirements for Protected Health Information (PHI) and will sign a Business Associate Agreement (BAA) with customers who are subject to HIPAA mandates (typically, HIPAA covered entities). Inzata is not a covered entity under HIPAA rules, and therefore cannot be “HIPAA compliant”, since HIPAA itself applies to covered entities (that is, those entities that are subject to regulation by the HHS). Inzata serves as a data pipeline and business associate service provider to covered entities. All transmissions are encrypted using industry best practices (at present, TLS 1.2+). Temporary storage may occur when the amount of data transmitted exceeds the capacity for real-time processing, and as a result, requires short-term caching. Such temporary storage is encrypted and never resides in Inzata systems for more than 24 hours.
Responsible Disclosure Policy
At Inzata, 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 email@example.com. 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 and will attempt to keep you regularly informed of our progress toward resolving the vulnerability. If you have followed the above instructions, we will not take any legal action against you regarding the report.