How we keep your ideas safe.
Last updated: May 29, 2026
1. Overview
Sparqbox handles internal company ideas. This page describes how we keep that data confidential, available, and intact. For procurement teams: pair this with our DPA, our sub-processor list, and our privacy policy. Security researchers: please email support@sparqbox.com — we acknowledge within 2 business days.
2. Infrastructure
Customer data is stored at rest in the European Union. Out-of-EU processing is limited to specific functions and is covered by Standard Contractual Clauses or the EU-US Data Privacy Framework, per sub-processor. Full list at sparqbox.com/subprocessors.
| Service | Role | Region |
|---|---|---|
| Supabase | Database, authentication, file storage | EU (Frankfurt) |
| Render | Backend hosting | EU (Frankfurt) |
| Vercel | Frontend hosting, edge delivery | Global edge, EU origin |
| Resend | Transactional email | EU + US |
| Stripe | Payment processing | EU + US |
| Anthropic | AI processing (Claude API) | US |
3. Encryption
- In transit: TLS 1.2+ with modern cipher suites on every public endpoint. HSTS on production hosts.
- At rest: AES-256 on the underlying database and object storage.
- Secrets: stored in encrypted environment variables managed by our hosting providers, never committed to source control. Rotated on schedule and after any personnel change.
4. Tenant isolation
We use a defence-in-depth model with three independent layers, so a failure in any single layer cannot expose another workspace's data:
- Layer 1 — Identity: every authenticated request carries a JWT signed with ES256 that includes the tenant identifier. Tokens are short-lived; refresh tokens are revocable.
- Layer 2 — Application: the backend derives tenant scope exclusively from the verified JWT. Client-supplied tenant identifiers in request bodies or query strings are ignored.
- Layer 3 — Database: row-level security policies on every business table re-enforce tenant scope at the storage layer.
5. Access control
- Production access is restricted to a small named group; every access is logged and reviewed.
- Routine support does not require access to customer data; when customer-data access is necessary, it requires customer permission and is logged.
- MFA is enforced on all internal accounts (hosting, code forge, email).
- Credentials are rotated on schedule and after any personnel change.
6. Authentication
- Email + password by default, with strong password rules and brute-force protection (rate limiting + lockout).
- SSO (SAML or OIDC) on the Scale tier via setup with our team.
- Session tokens are short-lived; refresh tokens are revocable. Session sharing across subdomains is disabled.
7. AI processing
AI-assisted features are powered by Anthropic's Claude API. When enabled in your workspace, idea content is sent to Anthropic for processing. Anthropic processes data under their commercial terms and does not use Sparqbox customer data to train models. AI is a recommender only: it never makes the final decision on an idea. AI features can be disabled at the workspace level, in which case no idea content is sent to Anthropic.
8. Backups and disaster recovery
- Daily encrypted backups with 30-day retention.
- Point-in-time recovery available within a 7-day window.
- Cross-region encrypted backup copies.
- Recovery procedures are documented and tested on a regular schedule.
9. Vulnerability management
- Automated dependency scanning on every pull request.
- Code review required before merge to main; production deployments are auditable.
- High-severity patches applied within 7 days; medium-severity within 30 days.
- Annual independent penetration test planned, Q4 2026.
10. Logging and monitoring
- Centralised application and infrastructure logs.
- Anomaly alerts for sign-in patterns, payment events, and AI-cost spikes.
- Immutable audit log for destructive and administrative actions (idea deletion, user removal, workspace closure, admin role changes).
11. Incident response
We have a documented incident response process with clear roles and a 24-hour triage commitment for active customer environments. Affected customers are notified without undue delay. Where required, the competent supervisory authority is notified within 72 hours of becoming aware, per GDPR Article 33. Every incident is followed by a post-incident review, with lessons fed back into engineering and operations.
12. Compliance
We do not claim certifications we do not hold. Where attestation is in progress, we say so plainly.
| Framework | Status |
|---|---|
| GDPR | Compliant. DPA at sparqbox.com/dpa; privacy policy at sparqbox.com/privacy. |
| SOC 2 | Pursued on US enterprise demand. Not pursued today. |
| Cyber Essentials | Not in scope (UK-only scheme; we are EU-based). |
| EU-US Data Privacy Framework | Used where US sub-processors are certified; see sub-processors. |
13. Responsible disclosure
Security researchers: email support@sparqbox.com. Please include the affected URL or endpoint, a clear reproduction path, and the impact you observed. We acknowledge within 2 business days and commit to a fix timeline. With your consent we credit researchers on this page once the fix is deployed. We do not pursue legal action against good-faith research that stays within these guidelines: no data exfiltration beyond what is needed to demonstrate the issue, no privacy violations, no service disruption, no use of social engineering against staff or customers.
14. Sub-processors
The full sub-processor list, including purpose, data category, location, and transfer mechanism, is at sparqbox.com/subprocessors. Workspace admins are notified by email at least 30 days before we add a new sub-processor that processes personal data.
15. Contact
- Security incidents and disclosure: support@sparqbox.com
- Privacy and data subject requests: support@sparqbox.com
- Procurement and questionnaires: support@sparqbox.com