Our approach
We design our security programme around recognised frameworks so that customers can map our practices to the controls they already expect. We use GDPR, SOC 2 and ISO 27001 as reference points.
We have not yet completed a SOC 2 audit or ISO 27001 certification. We do not hold any third-party security certification or attestation today. If that changes, we will update this page.
Access control
Access to systems and data is designed around least privilege. People get only the access they need for their role or project, and access is removed when it is no longer needed.
- Single sign-on and multi-factor authentication for internal systems where supported.
- Role-based access to project data.
- Periodic review of who has access to what.
Encryption
Data is encrypted in transit using current TLS protocols and encrypted at rest using industry-standard methods provided by our infrastructure.
Encryption keys are designed to be managed through our hosting providers' key management services, with limited administrative access.
Expert confidentiality
Every expert who works on customer projects signs a confidentiality agreement before receiving access. Experts are vetted through AI voice interviews, real-world work tests and skills assessments before they are staffed on projects.
Experts are trained on how to handle project data and are told what tools they may and may not use.
Project data handling
Customer project data is segregated by customer and by project. We process it only for the purposes the customer has instructed.
At the end of a project we delete or return data in line with the customer's agreement and instructions.
Secure development
Our engineering practices are designed to catch problems early. Our process calls for peer review of code changes, monitoring of dependencies for known vulnerabilities and keeping secrets out of source code.
Production and development environments are designed to be kept separate.
Vendor review
We review the security and privacy practices of service providers before we use them, and we put data protection terms in place where they handle personal data. Our subprocessors are listed at /legal/subprocessors.
Incident response and continuity
We maintain an incident response process for detecting, containing and recovering from security incidents. Where an incident affects customer personal data, we notify affected customers without undue delay.
Our business continuity planning is designed so that we can restore critical systems and data from backups if something goes wrong.
Training
Employees and experts receive security and privacy training when they join and periodically afterwards. Training covers handling confidential data, recognising phishing and reporting concerns quickly.
Responsible disclosure
If you believe you have found a security vulnerability in Saolabs systems, please report it to security@saolabs.ai. Our contact details are also published at /.well-known/security.txt.
We will not pursue legal action against anyone who researches and reports a vulnerability in good faith, follows this policy and avoids harm to our users, customers and systems. Please do not access, modify or keep data that is not yours, and stop and tell us if you come across personal or customer data.
- A description of the issue and where it is.
- Steps to reproduce it, including any proof-of-concept code.
- The potential impact as you understand it.
- How we can contact you, and whether you would like to be credited.
Disclosure timing
Please give us a reasonable chance to investigate and fix the issue before you disclose it publicly. We will keep you informed of our progress and let you know when it is resolved.
Denial-of-service testing, social engineering and physical attacks are out of scope.
Contact
To report a vulnerability, email security@saolabs.ai. For security questionnaires or questions about our programme, email info@saolabs.ai.