Security portal
Georgian is committed to safeguarding your data as we roll Grow out to your organization.
Product Overview
Georgian Grow’s Lead Qualification module helps Georgian companies determine which leads are most likely to convert at various stages of their outbound, inbound, and/or cross/upsell funnels, so that the sales team can prioritize them for outreach and ultimately improve conversion rates and team efficiency. To do this, the product orchestrates the creation of custom specific machine learning models using Customer data.
Product Architechture
Deployment model
Georgian provides this software to its companies at no cost. Our deployment model is a managed and hosted solution. The rationale for providing a managed solution to our customers is specifically about overcoming resource limitations, and enabling rapid adoption — along with limited risk and limited investment from our customers.
Georgian’s hosted solution has two key integration points:
- Portfolio Company Data Sources
- Portfolio Company Recommendation Destination
In this approach, Georgian’s infrastructure will be leveraged for extracting data, training models, and serving recommendations – minimizing management of infrastructure for portfolio companies to data source/destination connections (refer to product architecture above).
The Georgian engineering team will be monitoring the solution’s performance and stability, and pushing software updates live in response to any detected drift or stability issue, should they arise.
Network security
All traffic and access to the Integration Platform is only over secure protocols (typically HTTPS). TLS 1.2 or later is used for connections, and strong encryption algorithms with a key length of at least 128 bits are supported.
Access Restrictions
Access to production environments is restricted on an as-needed basis to research and development staff. Detailed background checks are performed on staff members, and the principle of least privilege is used to ensure access is only given when necessary and removed when staff move on to other projects.
Non-human entities (ie. Service Accounts) are provisioned for each Customer in order to run production workloads and restrict customer access to data.
Network Segregation
Our hosted product uses a multi-tier architecture which segregates internal components from the public internet. Public traffic passes through a Web Application Firewall (WAF), which is then routed to interior systems that are segregated on private subnets.
Application security
Data Encryption
All data stored in the mentioned Object Storage and BigQuery components are encrypted at rest using AES-256.
Configuration Management
All configuration changes are reviewed, tracked, and managed through a change management process. Our configuration files are stored as YAML files in secure buckets and the docker image itself. The configuration files only reference data sources (paths) and pipeline steps (ie. no credentials or sensitive information is stored here -- capabilities are inherited via the service account/IAM role).
Logging and Monitoring
Metadata regarding statistics, performance reports, and logs are sent back to our infrastructure monitoring and logging provider, DataDog, for product analytics and monitoring. The data contains no personally identifiable information, or customer data.
Static Code Security Scanning
Our team leverages a static code scanning tool for vulnerability detection on container images, OS packages, misconfiguration detection to provide a comprehensive approach to both application dependencies, and runtime vulnerabilities. These scans are conducted as a part of our CI/CD processes, as well as periodically on a monthly basis.
Authentication and Credential Management
We recommend that companies share credentials with the Grow team via a company-specific 1Password Vault, provided by Georgian. Access to the 1Password Vault is restricted to research and development staff only. More information on the 1Password security model can be found here.
These credentials are then used to set up the data integration workflow in Airbyte (refer to product architecture above). Airbyte stores and retrieves any credentials utilizing Google’s Secrets Manager. Supported authentication methods include OAuth, API keys, Service Account keys or IAM roles (depending on the data source).
User authentication for managing Airbyte is managed with Google SSO, and is restricted to research and development staff only.
Service account keys (GCP) and/or access keys (AWS) may be utilized depending on implementation. These keys are only accessible via provisioned access roles available to the environment machines. The permissions on these keys are restricted to read/write on object storage only.
Data masking and Personally Identifiable Information
Our solution does not require any Personally Identifiable Information (PII) to deliver recommendations; however, a unique and persistent identifier is required to join data from various customer systems. In the event a unique and persistent ID is not available, business email addresses may be used.
Although providing a persistent identifier is preferred, completely eliminating any PII exposure to our systems; however, post-extraction data scrubbing can be arranged in the event of technical restrictions or limitations.