Security

• Least privilege everywhere — engineers don't touch production data by default.
• Defence in depth — no single control is the only thing standing between an attacker and your data.
• Boring, well-tested crypto and libraries over hand-rolled primitives.
• Transparent failure — customers hear about incidents from us, not from Twitter.

In transit. All traffic to AnimationFunnel uses TLS 1.2 or higher, with HSTS enabled on the marketing site, app, and hosted forms. Internal service-to-service traffic runs over private networks or mutually-authenticated TLS.

At rest. Databases, backups, and object storage are encrypted with AES-256. Secrets and API keys are stored in a dedicated secret manager with per-environment scoping.

• Mandatory SSO and two-factor authentication for all employees.
• Production access limited to the on-call rotation, granted just-in-time and audit-logged.
• Role-based access control inside the app (owner / admin / editor / viewer).
• Password hashing with bcrypt or Argon2id — plaintext passwords are never stored.
• Session tokens are rotated on login, logout, and password change.

Primary infrastructure runs on managed cloud providers inside the EU. Workloads run in isolated virtual networks with strict security group rules. Hosts are immutable and rebuilt frequently from versioned images; no SSH into production except through a break-glass audited proxy.

• Every request is authenticated and authorised at the workspace boundary.
• Form submissions are validated server-side — client-side validation is a UX affordance, not a security boundary.
• CSRF protection on all state-changing routes; SameSite cookies by default.
• Strict Content-Security-Policy on the app and hosted form runtimes.
• Output escaping in all template paths to prevent XSS.
• Parameterised queries exclusively — no string-concat SQL.
• Rate limiting on login, password reset, submission, and API endpoints.

We log authentication events, admin actions, access to production systems, and all API calls. Logs are stored in an append-only system with retention aligned to our compliance needs. Anomalies (brute-force login attempts, suspicious exports, unusual API patterns) page the on-call engineer automatically.

Databases are backed up continuously with point-in-time recovery. Backups are encrypted and stored in a region separate from the primary. We test restore procedures on a scheduled cadence — a backup you've never restored is not a backup.

We never see or store full card numbers. Payments are handled by Stripe via Stripe Elements / Checkout, and our systems only receive a token and last-4 digits. That puts us in PCI DSS scope SAQ-A.

We design the platform to support our customers' GDPR and other regional data-protection obligations: we publish a sub-processor list, sign Data Processing Agreements on request, and support data export and deletion from the dashboard. For compliance questions, email [email protected].

• All code changes go through pull request review before merge.
• Automated static analysis, dependency scanning, and secret scanning run on every PR.
• Third-party dependencies are pinned and reviewed before upgrade.
• Periodic third-party penetration tests against the app and hosted form runtime.
• Security-sensitive features (auth, billing, export, webhooks) get extra review.

We review the security posture of every sub-processor before adoption — SOC 2 or equivalent attestations, encryption posture, data residency, and incident history. We re-review annually.

If you believe you've found a security vulnerability, please report it to [email protected]. We ask that you:

• Give us a reasonable window to investigate and remediate before public disclosure.
• Avoid accessing data that isn't yours — stop as soon as you've confirmed the issue.
• Don't degrade the service for other customers (no denial-of-service testing).
• Don't use social engineering or physical attacks.

We acknowledge reports within one business day and commit to keep you updated through remediation. We don't currently pay cash bounties, but we do credit researchers (with your permission) on our security acknowledgements page.

We maintain a written incident response plan with defined severity levels and owners. In a confirmed security incident affecting customer data we will notify affected workspaces without undue delay — and, where applicable, the relevant supervisory authority within the statutory deadline (72 hours under GDPR, or the relevant regional regime).

Security reports: [email protected]. General security questions or compliance requests (DPA, sub-processor list, questionnaires): [email protected].