Security
Technical and organisational measures Eddy Works uses to protect customer data.
1. Data residency
Primary data residency is Frankfurt, EU (DigitalOcean managed PostgreSQL and Vercel fra1 serverless region).
File uploads are stored in the EU via UploadThing (AWS S3, EU region).
New Zealand is recognised as an adequate country by the European Commission.
2. Encryption
Data in transit. All connections to Eddy are served over TLS 1.2 or higher. Vercel enforces HTTPS at the platform edge; HTTP requests are redirected.
Data at rest. The primary database (DigitalOcean PostgreSQL, Frankfurt) uses AES-256 encryption at rest via the managed hosting provider. File storage (UploadThing / AWS S3) uses server-side encryption (SSE-S3).
3. Access control
Authentication. User identity is managed by Auth0 (Okta), a managed authentication service. Multi-factor authentication is supported by the platform and can be enabled for all users (not yet enabled — activation planned before go-to-market).
Authorisation. Eddy uses a role-based access control model. Organisation Owners, Admins, Members, and External Participants have distinct permission sets enforced at the API layer. Session data is access-controlled by workspace membership and session role assignments.
Staff access. Eddy Works staff access to production data follows a least-privilege principle. Direct database access is limited to named individuals with a documented operational need.
4. Availability and backups
The primary database is hosted on DigitalOcean's managed PostgreSQL service with automated daily backups and point-in-time recovery. Vercel's infrastructure provides platform-level redundancy for serverless function execution.
5. Incident response
Eddy Works maintains a written incident response procedure. In the event of a personal data breach, affected customers will be notified within 72 hours of becoming aware, consistent with GDPR Article 33 obligations.
Security disclosures can be sent to security@eddy.works.
6. Development practices
Changes to the Eddy application go through peer code review before deployment. Automated test suites run on each pull request. Dependencies are monitored for known vulnerabilities.
7. Monitoring
Application errors and exceptions are tracked using Sentry. Eddy maintains application-level audit logs for key operations (user authentication, membership changes, session state transitions).
8. Provider security statements
Eddy runs on managed infrastructure. Each provider publishes its own security statement covering the controls at its layer.
| Provider | Role in Eddy | Security statement |
|---|---|---|
| Vercel | Application hosting and serverless functions | vercel.com/security |
| DigitalOcean | Primary database (managed PostgreSQL) | digitalocean.com/security |
| Auth0 (Okta) | Identity and authentication | auth0.com/security |
| AWS | File storage layer (S3, via UploadThing) | aws.amazon.com/security |
| Ably | Realtime messaging | ably.com/data-protection |
| Inngest | Background job processing | inngest.com/security |
| PostHog | Product analytics | trust.posthog.com |
| Mailgun | Transactional email | mailgun.com/security |
| Sentry | Error monitoring | sentry.io/trust |
See Subprocessors for what data each provider processes and where.
9. Certifications and assessments
We do not currently hold SOC 2 or ISO 27001 certifications. We are planning to pursue both later this year.
Data Processing Agreement
Eddy Works DPA — counter-draft applying the redraft guide (Kindrik draft set, 29 May 2026). Automatic addendum mechanism; named subprocessors; Guests and Contacts in Schedule 1; dual controller/processor framing. British spelling.
Subprocessors
Third-party vendors Eddy Works uses to deliver the service, their purpose, and data residency.