Security & Compliance
Village Labs Security & Compliance Practices
Last updated
Village Labs Security & Compliance Practices
Last updated
Data Security is of utmost importance to the Village Labs team - it's embedded in everything we do.
We're committed to ensuring the confidentiality, integrity, and availability of your data. Here is how we protect information and comply with industry standards and regulations.
Village Labs works with Secureframe on auditing and compliance on an ongoing basis.
We recommend checking out the Village Labs Trust Center, that outlines our continuous monitoring against SOC 2 Type 2 and GDPR standards across 50+ different controls.
We've included a high-level summary of our Data Ingestion & Security below. This summary should be viewed in concert with the Village Labs Trust Center. We also have over 20+ more in-depth Security Policies that are available upon request from support@villagelabs.co
Village in-house data ingestion pipelines. By not relying on external ELT SaaS products (e.g. Fivetran, Stitch), we are able to have better granularity over what data is imported, how it is processed, how it is stored, and most importantly, who has access to what.
When a data connection is created, we will often require credentials, secrets, or OAuth. Sensitive data is handled as such no matter how the connection is created.
While the bulk of the configuration for a data connection is stored within a standard relational database (for example, what kind of connection, what frequency for the data sync, which streams to sync, etc.), sensitive fields are marked as such, and are stored separately.
Secrets are never stored in plain text, in any database, file, or log.
The data connection jobs are executed within a Kubernetes cluster, and sensitive data is only stored (as K8s secrets) within this cluster. The secrets are passed to the execution runtime using best security practices with Kubernetes deployments.
Access to the data connection cluster is heavily restricted with scoped IAM policies. Village uses Google Cloud Platform (GCP) as a cloud service provider, and here again, the best security practices are applied regarding IAM. These roles are regularly reviewed to make sure that only the relevant engineers have access to the infrastructure.
When initializing a data connection, you get to choose which data streams get synchronized. While Village may recommend default settings for business reasons (e.g. some pipelines require specific data to be useful for specific business purposes), Village clients have full control over what data is selected or unselected to be pulled from your sources.
Important: Given the architecture of the Village ELT stack, Village is only able to read data, and never write: Village will never be able to execute write queries, or delete or corrupt your data in any way.
When Village synchronizes from client data sources, the raw data is stored in an ElasticSearch (ES) document store, deployed on GCP. All connections result in the creation of specific indexes (multiple ones, depending on how many streams were selected). The data for different customers is never commingled in any way, and is always stored in isolated indexes.
This ElasticSearch database is a sensitive internal database. Restrictive policies are applied on who may access it; only employees who require access to perform their job responsibilities have access, based on the principle of least privilege. The same IAM rules apply here, with role-based access control.
Very specific roles with restricted IAM policies, only the employees responsible for developing and maintaining the ELT infrastructure have access to the document store and the cluster.
Clients connect their data to Village to leverage Village's product suite, including its Automation Engine and AI stack. Client data will not be shared with any external entity for any reason.
The Village Automation Engine is deterministic, auditable, and flexible, taking action on activity messages created from your data.
In addition to the core engine, some other custom features ensure that the data can never be shared with unauthorized parties. Role-based access control means only Village Clients (or the people authorized by Village Clients) have access to Ledger data.
No PII is ever written to the Village Ledger. Ledger accounts are pseudonymous, created alongside the main user ID.
Village Labs, nor any sub-processor of Village Labs trains AI models using customer data.
Village will remove synced client data immediately upon request. Village will not keep any copy of the synchronized data. Any individual user’s PII data may also be deleted upon request, in accordance with GDPR and similar regulations.
Village’s infrastructure is not exposed to the internet except for limited services whose business purpose requires them to be so. Core databases and document stores are kept on a private network, and Village maintains active security monitoring software to identify potential threats.
Should any issue involving Village Client data be identified, the client will be contacted and notified as soon as possible, and Village will use any and all means necessary to remediate the issue.
Employee access to the key parts of the infrastructure (especially databases) is IP-restricted, in combination with VPN access to reach the internal services. The engineer responsible for the infrastructure maintains the list of authorized IPs using Terraform on all Village environments.
Village requires the use of hardware multi-factor authentication keys wherever possible.
Village is committed to ensuring the confidentiality, integrity, and availability of your data. Here is how we protect information and comply with industry standards and regulations.
Village works with Secureframe on auditing and compliance on an ongoing basis. You can view the Village Labs Trust Center here, that outline the continuous monitoring against SOC 2 Type 2 and GDPR standards across 50+ different controls.
Village Labs maintains over 20 Security Policies available for request from support@villagelabs.co
