GDPR and data processing pack
Description of processing, technical and organisational measures, subprocessors, and international transfers.
Purpose and status
This pack sets out how InstaLILY processes personal data on behalf of its customers. It contains the material that populates the annexes of a data processing agreement: the description of processing, the technical and organisational measures, and the subprocessor list.
The executable data processing agreement is issued separately. This document describes the processing and the measures; it is not itself a contract and does not vary the terms of any agreement between us. Request the DPA through your account team or at hello@instalily.ai.
Roles
| Party | Role | Responsibility |
|---|---|---|
| Customer | Controller | Determines the purposes and means of processing. Decides which systems Lily connects to, which agents run, and which data flows into the platform. Handles data subject requests as controller. |
| InstaLILY | Processor | Processes personal data only on documented instructions from the customer, for the purpose of delivering the contracted service. |
| Subprocessors | Sub-processor | Engaged by InstaLILY under contractual security obligations, risk-classified, and reviewed annually. Listed in section 6. |
Description of processing
Categories of data subjects
- The customer's employees and authorised users of the platform.
- Individuals appearing in the customer's connected business systems, typically contacts at customer accounts, suppliers, distributors, and service organisations.
Categories of personal data
- Business contact details: name, employer, role, business email, business telephone.
- Account and transaction records that reference an individual, such as quotes, orders, service history, and case notes held in the connected system.
- Platform usage and audit data: authentication events, actions taken, approvals given.
Special categories of personal data are not required by the platform and are not sought. Where a customer's connected system contains them, for example protected health information in a healthcare deployment, they are processed under a Business Associate Agreement and the corresponding safeguards.
Nature and purpose
Retrieval and analysis of data from connected customer systems; generation of insights, recommendations, and operational outputs; and execution of workflow actions inside connected enterprise applications according to customer-defined rules. Processing is continuous for the duration of the agreement.
Duration
For the term of the agreement. On voluntary closure of an account, data enters an expired state for 180 days and is then removed. A suspended account carries a 60-day grace period before entering that expired state.
Processing locations and data residency
Each customer is provisioned a dedicated, single-tenant Google Cloud project. Isolation between customers is a property of the infrastructure rather than of application logic, the same boundary the cloud provider uses to separate unrelated companies.
Region is set per deployment and written into the contract. InstaLILY builds each deployment for one business and can place it in any region or cloud where the underlying provider offers service, including regions within the EU. Where a customer’s policy requires it, the platform can instead be deployed inside the customer’s own cloud account or on their own premises, in which case personal data stays in the environment the customer already controls and no transfer to InstaLILY occurs.
Technical and organisational measures
The measures below correspond to Article 32. Each is independently attested in our SOC 2 Type II report for the period 23 February 2025 to 22 February 2026, issued by Johanson Group LLP, in which the auditor reported no exceptions across the controls tested.
| Measure | What we do |
|---|---|
| Encryption | Customer data is encrypted at rest with AES-256 using Google Cloud KMS-managed keys, and in transit with TLS 1.3. No network connection used by the platform carries unencrypted data. |
| Confidentiality and access control | Role-based access control with least privilege across all infrastructure, reviewed and approved by management annually. Multi-factor authentication on every system that supports it. Access removed within three days of termination. Production data access requires approval, is granted temporarily, and is subject to audit logging. Production data is never used in development or test environments. |
| Isolation | Dedicated single-tenant cloud project per customer for both customer data and configuration data. |
| Integrity | Documented SDLC with mandatory peer review, segregation of duties across authorisation, development, testing, and deployment, static analysis in the CI pipeline, and formal change approval. Development and testing environments are separated from production. |
| Availability and resilience | Recovery time objective of 2 hours and recovery point objective of 1 hour for customer production environments. Critical environments use multi-region deployment with automatic failover. Managed backups with point-in-time recovery retained 180 days, encrypted with KMS-managed keys. Infrastructure is defined as code. |
| Network protection | Web application firewall and DDoS protection in front of external endpoints, VPC network isolation, and intrusion detection alerting on unauthorised modification of critical files. |
| Testing and evaluation | Annual SOC 2 Type II examination, annual HIPAA attestation, annual independent third-party penetration testing against network and application, ongoing vulnerability scanning, and annual tabletop exercises of both the disaster recovery and incident response plans. |
| AI-specific measures | No cross-customer models are trained. Agents run on dedicated service accounts under least-privilege RBAC and are included in periodic access reviews. External data is pre-sanitised at ingestion with strict data boundaries to mitigate prompt injection. Agent outputs are rate limited and every action is logged. Prompts are versioned and trained model weights are held in a model registry. |
| Personnel | Background checks as a condition of employment, signed code of conduct and confidentiality agreement on hire, and annual security awareness training. All attested with no exceptions. |
Subprocessors
Every vendor is risk-classified, contractually bound to security requirements, and reviewed annually. We review their audit reports the same way our customers review ours.
The current subprocessor list is published on our security page, showing each subprocessor, its purpose, its processing location, and the category of data it touches. It is maintained there rather than reproduced here so that one list stays authoritative: a copy inside this pack would drift out of date between revisions. The list was last reviewed in February 2026, and is reviewed annually and on any material change.
At the time of writing it covers Google Cloud Platform and Microsoft Azure for infrastructure; Google, OpenAI, and Anthropic for model inference; Datadog and Grafana for monitoring; and Drata, Vercel, GitHub, and Google Workspace for internal operations. Only the first two groups process customer data.
A note on model providers
The platform is model-agnostic. The enabled set of providers and models is not fixed; it can be expanded or restricted per deployment and is enforced by policy, so a customer who requires inference to be limited to a specific provider or region can have that configured.
Retention with model providers is a configuration, not a contractual term. We configure provider settings to the retention policy a deployment requires, including zero retention where the provider supports it. We do not currently hold separate negotiated zero-retention agreements with each provider, and we would rather state that plainly than imply a contractual protection we have not papered. Provider terms for your specific configuration are confirmed during security review.
International transfers
No personal data originating in the EEA has been transferred to the United States by InstaLILY to date. European deployments are beginning now.
Where a deployment is placed in an EU region, or inside the customer's own cloud account or premises, personal data remains in the environment the customer's policy already permits and the transfer question does not arise.
Where a transfer to InstaLILY does become necessary, the mechanism will be the European Commission's standard contractual clauses, executed as part of the data processing agreement, supported by a transfer impact assessment. Staff with authority to approve access to production data are located in the United States; where such access is mediated by InstaLILY at all, it is by exception, temporary, and logged.
Data subject rights
The customer is the controller and receives data subject requests directly. InstaLILY assists as processor.
The platform is not self-service, so requests are raised through your account team or at hello@instalily.ai rather than through a customer-facing portal. We hold ourselves to the standards set by the GDPR and the CCPA and will act within the window the controller needs in order to meet its own statutory deadline. Because each deployment is built for one business, the mechanics of locating and actioning a specific record are agreed during implementation.
Retention and deletion
- Customer data is retained while the account is active.
- On voluntary closure, data enters an expired state for 180 days and is then removed. An export can be requested before closure.
- A suspended account has a 60-day grace period, after which it is closed and the expiry clock starts.
- Backups are retained 180 days with point-in-time recovery, encrypted with KMS-managed keys.
- Log data is stored with defined retention and automatically removed at the end of its lifetime.
One caveat we would rather state than bury. Automated tracing can occasionally capture customer data in application logs. We scrub logs of sensitive customer data before persistence, log data carries a limited lifetime with automatic removal, and this is disclosed in the system description of our SOC 2 report.
Personal data breach
Affected customers are notified directly, without undue delay, and in time to support the controller's own regulatory reporting obligations. Notification is direct rather than by status page alone.
Behind that commitment: a documented incident response plan owned by a named Head of Security, severity classification, mandatory internal reporting within 24 hours of discovery, immediate containment for critical and high severity incidents, forensic evidence preservation, and post-incident review. Where protected health information is involved, the HIPAA breach notification requirements apply in addition.
No significant security incidents occurred in the services provided to customers during the SOC 2 observation period ending 22 February 2026, and none have occurred since.
Audit rights and available documentation
The following are available to customers and qualified prospects, under NDA where indicated.
- SOC 2 Type II report. Johanson Group LLP, period 23 February 2025 to 22 February 2026, security criteria, issued 1 April 2026. Under NDA.
- HIPAA compliance attestation. Point in time as of 22 February 2026, covering the Security and Breach Notification protocols. Under NDA.
- Penetration test summary.
- Incident response plan and other policies on request.
- This pack and the EU AI Act overview.
We complete customer security questionnaires. Send yours to hello@instalily.ai.
What is not yet in place
Stated so that a reviewer does not have to discover it.
- InstaLILY does not hold ISO/IEC 27001 or TISAX, and neither has been scoped.
- We do not hold separately negotiated zero-retention agreements with model providers; retention is set by configuration, as described in section 6.
- Standard contractual clauses have not yet been executed with any customer, because no EEA transfer has yet been required.
- SOC 2 examinations are annual. The next report will cover the period following 22 February 2026.
Questions about anything in this document go to hello@instalily.ai. We would rather answer them before procurement than during it.
EU AI Act overviewHow the platform's controls correspond to the Act, and where responsibility sits between provider and deployer.