Security Policy

Access control and organizational security

All our employees and contractors (workers) sign confidentiality agreements before gaining access to our codebase and data. Every employee is trained and made aware of security concerns and best practices for their systems, during onboarding as well as on a periodic basis. We log all access to all accounts by IP address. Access is granted to production servers only as required and is provisioned on an as-needed basis. Access to servers is limited by role based access through IAM that enforces segregation of duties and 2 factor authentication.

Data Location

Factors.AI servers that persistently store customer data are hosted by Google Cloud Platform (GCP). GCP’s data center is SOC 1, SOC 2 and SOC 3 compliant. GCP also logically isolates each customer’s Cloud Platform data from that of other customers and users. All data is stored and processed in GCP’s ‘us-west-1b’ zone located in the United States.

All GCP data center facilities include

Strict Access Security

• Custom-designed electronic access cards
• Alarms
• Vehicle access barriers
• Perimeter fencing
• Metal detectors
• Biometrics
• Data Center floor features laser beam intrusion detection

Monitoring

• 24/7 high resolution interior and exterior cameras that can detect and track intruders
• Access logs
• Activity records
• Camera footage is available in case of incident

Personnel

• Patrolled by experienced security guards
• Rigorous background checks and training

Power Availability

• Redundant Power Systems
• Environmental controls
• Diesel engine backup generators
• Cooling systems
• Fire Detection and Suppression equipment

For further information on GCP Security and Compliance refer the following links

• Security Whitepaper
• Compliance and Certifications
• Cloud Security FAQ

Data Isolation and Encryption

Customer data is secured  in transit using TLS and encrypted at rest within the application. Factors also logically separates data across accounts and access to your data is protected by strong authentication and authorization controls. 

Data at Rest

Your data is encrypted using the 256-bit Advanced Encryption Standard (AES-256), or better, with symmetric keys: that is, the same key is used to encrypt the data when it is stored, and to decrypt it when it is used. These data keys are themselves encrypted using a key stored in a secure keystore, and changed regularly. Further details may be found below

https://cloud.google.com/sql/faq#encryption-manage-rest

https://cloud.google.com/security/encryption-at-rest/default-encryption

Data in Transit

When a user visits a website or application which has instrumented the FactorsAI SDK, details of their interactions are captured and sent to FactorsAI through API calls secured over HTTPS/HTTP, based on configurations set by the customer. All of our other APIs and websites use HTTPS exclusively. All data transferred over HTTPS is encrypted. FactorsAI uses SHA-2 compliant cipher suites to secure data in transit.  Further, the data is encrypted and authenticated in transit at one or more network layers when data moves outside physical boundaries not controlled by Google or on behalf of Google. All our servers are hosted within a Virtual Private Cloud with fine grained security control. Within our datacenter VPC’s, data may be transferred unencrypted. Further details may be found below

https://cloud.google.com/security/encryption-in-transit

https://cloud.google.com/vpc-service-controls

Multitenancy

All customer data is tagged with a project-specific token, and a customer must have access to the corresponding API key and secret in order to retrieve that data via API (access to the web UI is controlled via username and password). This provides logical separation between data belonging to multiple clients. FactorsAI is the sole tenant on our infrastructure. A customer’s data may reside on database systems which house data belonging to other customers, but our logical controls (token, key and secret) separates one client from another client’s data.

Application Security

We maintain a robust application security program, covering the following

1. During software design through security reviews and risk assessment
2. During implementation through security development training for employees and secure code review guidelines
3. During deployment through strict manual and automated code review requirements
4. Customer passwords are hashed and stored using the bcrypt algorithm

Incident management and disaster recovery

Factors Incident Management policy requires that any and all suspected or confirmed Data Security incidents must be immediately reported to the Data Protection Officer.  An ‘incident’ is defined as any event that compromises the integrity, confidentiality or availability of an information asset. The DPO will engage with the Incident Response Team and coordinate with the management and the legal counsel to take appropriate actions to meet our obligations and mitigate the impact to consumers, employees or the Company from the incident. 

Our disaster recovery plans require that data in the production environment be frequently snapshotted and stored durably in multiple geographic locations in the US. Backups  are maintained  for  the  duration  of  the  customer  relationship  and  for  one  year  after  the termination of an agreement unless otherwise specified or required by law.