Our approach
Security is a product decision, not a checklist. Every Daisy customer operates in a regulated industry with real-world consequences — shipment-level production data, commercial forecasts, supplier relationships. We design the platform around three principles: keep tenants strictly isolated, encrypt data everywhere, and make security decisions auditable.
Platform security
Infrastructure
Daisy runs on managed infrastructure with EU and US regional presence. We rely on providers with strong baseline compliance postures rather than operating our own servers.
Encryption
All traffic to and from Daisy is encrypted with TLS 1.2 or higher. Data at rest is encrypted with AES-256. Secrets and environment variables are held in a dedicated secret manager, scoped per environment, encrypted at rest, and never logged.
Network and headers
Every response from daisy.inc is served with a strict Content Security Policy, HSTS, and the baseline security headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
Tenant isolation
Every customer is a separate tenant. Tenant isolation is enforced in the database itself — not just at the application layer — so that a bug in application code cannot expose one customer’s data to another.
- Row-Level Security policies on every tenant-scoped table, keyed on an identifier that is never client-controlled.
- Hardened database functions restricted to elevated roles where appropriate, with explicit permission grants on each function.
- Aggregated and per-tenant views so the LLM layer only sees the data the tenant is authorised to see.
Authentication and access
Customer sign-in
Customers sign in with Single Sign-On (SAML / OIDC) or with email and password. Password reset uses server-side one-time codes; no JWT is ever placed in a browser URL.
Authorisation
We use least-privilege role-based access control. Each user is bound to a single processor organisation; cross-tenant access is impossible without administrator intervention, which is itself audited.
Internal access
Daisy employees access customer data only under a documented break-glass procedure. Every break-glass event is recorded in an append-only audit log.
Auditing and monitoring
- Authentication events (successful logins, failures, SSO provisioning, identity linking, break-glass use) are recorded in an append-only audit table.
- Abuse-resistant endpoints — sign-up validation, password reset, authentication policy lookups — are rate-limited with per-identifier buckets.
- Continuous dependency scanning on every commit. Transitive vulnerabilities are patched via explicit overrides.
Data protection
- EU data residency available for European customers. US residency by default for US customers.
- Backups are encrypted and retained in accordance with customer agreements.
- Personal data can be corrected or deleted on request, in accordance with GDPR Articles 16 and 17.
- We sign a Data Processing Agreement (DPA) with customers processing personal data through Daisy.
Compliance roadmap
We are building toward SOC 2 Type II and ISO 27001 in parallel with customer deployments. The security controls in this document are the operating model we run today — compliance attestations will certify what is already in place.
Responsible disclosure
If you believe you have found a security vulnerability in Daisy, we want to hear about it. We commit to acknowledging every report within two business days and keeping you updated until the issue is resolved.
Please include a clear description, steps to reproduce, the affected URL or account, and any proof-of-concept material. We ask that you do not access data beyond what is strictly necessary to demonstrate the issue, and that you give us reasonable time to fix it before public disclosure.
Report to chirag@daisy.inc.
Contact
Security questions: chirag@daisy.inc. General enquiries: andrew@daisy.inc.