Skip to content

Language

Trust

Security

Consent records are evidence. If they can be lost, altered or leaked, they cannot protect you in an audit. This page describes how Cookiesh keeps the service and your data secure. Enterprise customers can request more detailed documentation and completed security questionnaires from security@cookiesh.eu.

Infrastructure

  • The Cookiesh platform runs on Amazon Web Services in Frankfurt, Germany, across multiple availability zones.
  • The consent script is served from Cloudflare’s global edge network, which also absorbs denial-of-service attacks.
  • Production, staging and development environments are fully separated. Customer data is never used in testing.
  • Infrastructure is defined as code, reviewed like application code and deployed automatically.

Data protection

  • Encryption in transit. All traffic uses TLS 1.2 or later, with HSTS on every Cookiesh domain.
  • Encryption at rest. Databases, backups and exports are encrypted with AES-256, with keys managed in AWS Key Management Service.
  • Data minimization. Consent records contain a pseudonymous ID, never a raw IP address. User IDs passed to identify() are stored only as salted hashes.
  • EU residency. Consent records are stored and processed in the EU. Our sub-processors page lists every provider that processes personal data.

Consent records are append-only. Each record includes a SHA-256 hash of its own contents and of the record before it, forming a chain per site. Changing or deleting any record breaks every later hash, so tampering is detectable.

We verify every chain automatically each day. Enterprise customers can export the chain proofs and verify them independently.

Application security

  • All code changes are peer-reviewed before they are merged.
  • Automated checks scan every change for vulnerable dependencies, leaked secrets and common security flaws.
  • An independent firm tests the platform for security weaknesses at least once a year, and we fix findings by severity.
  • The dashboard supports single sign-on with SAML 2.0 and enforces multi-factor authentication for password logins.

Script integrity

The consent script runs on our customers’ websites, so we treat it with extra care:

  • Releases are built in an isolated pipeline and require approval from two engineers.
  • Versioned script URLs support Subresource Integrity (SRI) hashes, so browsers refuse a modified file.
  • The script works under a strict Content Security Policy. It supports nonces and does not use eval().
  • The script does not set any cookie other than cookiesh_consent and does not send data to third parties.

Access control

  • Employees get access to production systems only when their role requires it, and every access is logged.
  • Access to production requires single sign-on with hardware-backed multi-factor authentication.
  • We review access rights every quarter and remove them the day someone changes role or leaves.
  • Employees complete security and privacy training when they join and every year after.

Availability and backups

  • Databases are backed up continuously, with point-in-time recovery for the last 30 days.
  • We test restoring from backups every quarter.
  • If the consent service cannot be reached, the script falls back to the visitor’s stored choice, or to the region’s most protective default for new visitors. It never fails open.
  • Enterprise plans include a 99.99% uptime SLA.

Incident response

We have a documented incident response plan with on-call engineers around the clock. If a security incident affects your data, we notify you without undue delay, and no later than 48 hours after becoming aware of it, as our Data Processing Agreement requires. We then keep you updated until the incident is resolved.

Responsible disclosure

If you believe you have found a security vulnerability in Cookiesh, email security@cookiesh.eu with the details and steps to reproduce it. We will acknowledge your report within two business days and keep you informed as we fix it.

We will not take legal action against researchers who act in good faith. That means you do not access or change other people’s data, do not degrade the service, and give us reasonable time to fix the issue before you disclose it.