Security

How we keep your ideas safe.

Last updated: May 29, 2026

Report vulnerabilities to support@sparqbox.com. We acknowledge within 2 business days.

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.

ServiceRoleRegion
SupabaseDatabase, authentication, file storageEU (Frankfurt)
RenderBackend hostingEU (Frankfurt)
VercelFrontend hosting, edge deliveryGlobal edge, EU origin
ResendTransactional emailEU + US
StripePayment processingEU + US
AnthropicAI 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.

FrameworkStatus
GDPRCompliant. DPA at sparqbox.com/dpa; privacy policy at sparqbox.com/privacy.
SOC 2Pursued on US enterprise demand. Not pursued today.
Cyber EssentialsNot in scope (UK-only scheme; we are EU-based).
EU-US Data Privacy FrameworkUsed 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