Security Measures
Version 1.0
About this page
This page sets out the technical and organisational measures we use to protect customer data on the Insightology Platform. It is referenced in our Data Processing Addendum and forms part of our contractual commitments to customers.
We are an early-stage company building towards ISO/IEC 27001 and SOC 2. We would rather be accurate than impressive. Where a measure is in place, we say so. Where it is being implemented, we say that. Where we do not do something, we say that too, and explain what we do instead. Nothing on this page is aspirational.
We will update this page as our programme develops, and we will not reduce the overall level of protection during the term of a customer agreement.
1. Architecture in brief
The Platform is fully serverless and runs entirely on Google Cloud. It uses Firebase Hosting, Firebase Authentication, Firestore, Cloud Storage, Secret Manager and Cloud Run. We operate no physical data centre, no servers of our own and no traditional network of routers, subnets or load balancers.
Production is deployed separately in a European region and a United States region, and the service that brokers AI requests is stood up in both. Each customer is assigned a home region at onboarding and that customer's data remains in its home region. The two deployments are independent and do not provide automatic cross-region failover.
The whole infrastructure is defined and version-controlled as code using Terraform, so every change is reviewable and auditable.
2. Governance and compliance
| Measure | Status |
|---|---|
| Security owned at executive level, with continuous control monitoring through Vanta | In place |
| Risk assessment completed | In place |
| Cyber insurance | In place |
| Documented information security, access control and incident response policies, with an employee read-and-acknowledge process | In progress |
| Dedicated full-time information security personnel | Not in place. Security is owned at executive level, supported by Vanta and by Workstreet as our implementation partner |
| SOC 2 Type II report. Observation period is running | In progress |
| ISO/IEC 27001 certification | In progress |
We are not currently certified to ISO/IEC 27001 and we do not currently hold a SOC 2 report. We will say so plainly until we do.
3. Access control
| Measure | Status |
|---|---|
| Corporate identity managed through Microsoft Entra ID | In place |
| Multi-factor authentication enforced for corporate accounts, including elevated privileges, and for production system access | In place |
| Role-based access control on a least-privilege basis; production access restricted to personnel supporting the service | In place |
| Unique, non-shared user IDs. Group, shared and generic accounts are prohibited | In place |
| Password length and complexity enforced through policy, including protection against common and breached passwords. Passwords are salted and hashed and never stored in plaintext | In place |
| Self-service password reset requires multi-factor verification before completion | In place |
| Access revoked immediately on termination; inactive accounts disabled at least every 90 days | In place |
| Formal scheduled access reviews with a documented cadence | In progress |
| Customer-configurable single sign-on and SCIM provisioning on the Platform | Planned |
4. Encryption
| Measure | Status |
|---|---|
| Data in transit encrypted using TLS 1.2 or higher | In place |
| Data at rest encrypted using AES-256, through Google Cloud managed encryption | In place |
| Encryption keys are Google-managed, using envelope encryption with automatic key rotation | In place |
| Service credentials held in Google Secret Manager, provisioned through Terraform, and never exposed in the browser or committed to source control | In place |
| Firebase configuration values visible in the browser are public client identifiers by design, not secrets | In place |
| Customer-managed encryption keys | Not offered |
5. Separation of customer data
This matters more than most for us, because the value of the Platform depends on an agency's own material staying its own. Separation is enforced at two independent layers.
| Measure | Status |
|---|---|
| Database layer: security rules enforce access control so one organisation cannot reach another organisation's data | In place |
| Application layer: every query is additionally scoped by workspace identifier | In place |
| Chats are private to their owner | In place |
| Client-specific content is walled off from other clients, with automated tests pinning that separation | In place |
| Every backend request requires a verified login token, so anonymous traffic cannot reach backend services | In place |
| AI requests pass through a gateway that verifies the user's identity on every request before the request reaches the provider | In place |
| Agency-specific fine-tuning and Agency Vault content are held per customer and are never shared with, or made available to, any other customer | In place |
| Customer data is not used to train the core platform model, and the core platform model does not learn from customer prompts or behaviour | In place |
| Independent penetration test covering multi-tenancy and authorisation | Planned |
6. Application security and change control
| Measure | Status |
|---|---|
| Code changes managed through version control with pull-request review | In place |
| Infrastructure defined and version-controlled as code using Terraform; changes made through the codebase and auditable | In place |
| Vulnerability management and security patching. Google patches the underlying infrastructure; application and dependency vulnerabilities are monitored | In place |
| Bot protection on sign-up and sign-in | In place |
| Formal documented change-management process | In progress |
| Documented secure development lifecycle with risk assessment | In progress |
| Web application firewall | Not in place. The Platform is serverless and does not use the load balancer a WAF requires. Google provides edge-level DDoS protection, and every backend request requires a verified login token |
| Data loss prevention tooling | Not in place. Compensating controls are encryption in transit and at rest, credentials in Secret Manager, least-privilege access, verified authentication and customer data isolation |
7. AI and model governance
We use third-party AI models to deliver the AI features of the Platform, and we select the model best suited to each stage of the research workflow. A model may be reached directly from its developer or through a cloud platform that hosts it. Either way the request is routed through our own authenticated gateway rather than called from the browser, and every organisation that may process customer content is named on our sub-processor page.
| Measure | Status |
|---|---|
| AI requests are brokered through an authenticated gateway that verifies identity before forwarding | In place |
| Every AI provider is engaged under terms that prohibit the use of customer data to train its models | In place |
| Every AI provider is named on our sub-processor page, with notice before we engage one that is not already listed | In place |
| Provider due diligence documented as part of supplier assessment | In progress |
| Input validation and controls against prompt injection on retrieval and tool use | In progress |
| Logging sufficient to reconstruct an AI output after the fact: input, model version, configuration and output | In progress |
| Documented model lifecycle governance covering evaluation, deployment, rollback and retirement | In progress |
8. Endpoints and people
| Measure | Status |
|---|---|
| Company devices run anti-malware with real-time protection and automatic definition updates | In place |
| Endpoint security posture monitored centrally through the Vanta agent | In place |
| Background and right-to-work checks at onboarding | In place |
| Written confidentiality obligations for all personnel authorised to process personal data | In place |
| Personal or employee-owned devices are not used to access customer data | In place |
| Security awareness training at onboarding and annually thereafter | In progress |
9. Logging, monitoring and incident response
| Measure | Status |
|---|---|
| Cloud audit logs and platform logs captured centrally, identifying individual users | In place |
| Security alerts monitored and triaged by the engineering team | In place, alert-driven |
| We notify affected customers of a personal data breach without undue delay, and in any event within 72 hours of becoming aware | In place |
| Documented incident response and escalation procedure | In progress |
| Formal log review cadence and defined retention period | In progress |
| Dedicated 24/7 incident response team | Not in place. Incident response is owned at executive level |
| Independent penetration test covering multi-tenancy and authorisation | Planned |
10. Backup, availability and continuity
| Measure | Status |
|---|---|
| Encrypted backups created automatically every day and retained for 30 days, then automatically deleted | In place |
| Backups inherit Google Cloud managed AES-256 encryption | In place |
| Platform resilience relies on Google Cloud regional redundancy and managed services | In place |
| Automatic cross-region failover | Not offered |
| Board-approved business continuity and IT service continuity policy | Planned |
| Documented and tested restore procedure with published recovery objectives | Planned |
| Public status page | Planned |
11. Data retention and deletion
| Measure | Status |
|---|---|
| Retention of customer data is governed by the customer agreement | In place |
| On termination or expiry, uploaded data is deleted or returned within 30 days on the customer's instruction, with deletion confirmed in writing | In place |
| Deletion on request during the term | In place, currently a manual process |
| Automated deletion and a scheduled retention process for live customer data | In progress |
| Removable media is not used for customer data, so there is no physical media to destroy | In place |
We would rather flag this than dress it up. Deletion on request works today and is carried out manually. An automated retention schedule is being built, and until it is in place we rely on the manual process and on the contractual commitments in the customer agreement.
12. Supplier and sub-processor management
| Measure | Status |
|---|---|
| Current sub-processors published, with prior written notice of any addition or change | In place |
| Sub-processors that process customer personal data are engaged under written data processing terms | In place |
| Documented security and data protection due diligence before a supplier is brought into service | In progress |
| Independent penetration test covering multi-tenancy and authorisation | Planned |
See the current list on our Sub-processor page
13. What we ask of customers
Security is shared. We ask customers to manage their own user accounts and remove access promptly when a person leaves, to avoid uploading personal data that is not needed for the research, to confirm a lawful basis before uploading special category data, and to tell us straight away if they think an account has been compromised.
14. Contact
Security questions and vulnerability reports: security@insightology.ai. Privacy questions: privacy@insightology.ai.