TLDR: A security review of a consent management platform should check where consent records live, how they are encrypted, who can reach them and how incidents are handled. This post walks through those questions and answers them for GetCookies with the controls we actually run. The current, authoritative list is always on our security page.
Read full summary
What to ask a consent management vendor during a security review, and GetCookies' answers: Railway hosting in the United States behind Cloudflare, HTTPS with HSTS, encryption at rest at the infrastructure level, bcrypt password hashing, hashed API keys, TOTP MFA, organization-scoped roles, an audit log, signed webhooks, Dependabot dependency monitoring and GDPR Article 33 breach notification. GetCookies holds no SOC 2 or ISO 27001 certification and does not offer SSO today.
The Security Questionnaire Problem
Every enterprise vendor evaluation starts the same way: a long security questionnaire. Does your vendor encrypt data at rest? Do they have incident response procedures? Where is the data hosted?
For a consent management platform, these questions are especially important. You're trusting a vendor with:
- Consent records (your evidence of consent under GDPR)
- User interaction data (potentially personal data)
- Website integration (code running on your pages)
This article describes GetCookies' security posture so your security team can evaluate us efficiently. It only lists controls that are in place. The security page is the authoritative, maintained version: if this post and that page ever disagree, the security page is correct.
Certifications
GetCookies holds no SOC 2 or ISO 27001 certification today, and we do not have an audit report to share. When a questionnaire asks for one, we say so plainly and answer the underlying control questions instead.
Where Your Data Lives
- Customer data is hosted on Railway, a US-based infrastructure provider.
- Cloudflare sits in front of getcookies.co for DNS, edge filtering and DDoS mitigation.
- International transfers are covered by data processing agreements with Standard Contractual Clauses, in line with GDPR Chapter V.
- The full list of providers, with purpose and location, is on the subprocessors page. Our processor terms are in the Data Processing Addendum.
Data Protection
Encryption in Transit
- All traffic to getcookies.co and app.getcookies.co is served over HTTPS.
- HSTS is enabled with a two-year max-age, includeSubDomains and preload.
- Plain HTTP is upgraded automatically.
Encryption at Rest
- PostgreSQL and Redis run on Railway, which encrypts data at rest at the infrastructure level.
- Managed backups inherit the same encryption.
Credentials
- Passwords are hashed with bcrypt and never stored in plaintext.
- API keys are stored as SHA-256 hashes. The plaintext key is shown once, when you create it.
Access Control
Authentication
| Method | Notes |
|---|---|
| Email and password | Standard login |
| Magic link | Optional single-use link sent by email |
| Sign in with a Google account | |
| TOTP MFA | Available on every account (Google Authenticator, Authy or compatible apps) |
Single sign-on (SAML or OpenID Connect) is not available on any plan today.
The dashboard authenticates with JWT bearer tokens instead of ambient session cookies, which removes a class of CSRF exposure.
Authorization
Domains, consent logs and API keys belong to one organization. Roles control what each teammate can do:
- Owner
- Admin
- Editor
- Viewer
Audit Log
Sensitive account and configuration changes are recorded, so you can see who changed what, and when.
Consent Record Retention
Consent logs are kept for a fixed period that depends on the plan of the account that owns the website, after which a background job deletes them. The current period for each plan is listed on the security page.
Infrastructure and Application Security
- Private networking: the database and cache are not exposed to the public internet. Only the application reaches them over Railway's internal network.
- Separate environments: production and development run as separate services with separate credentials.
- Rate limiting: authentication and public API endpoints are rate-limited to slow down brute-force attempts and abuse.
- Input validation: request payloads are validated against strict schemas, and database access goes through an ORM with parameterized queries.
- Output sanitization: user-supplied HTML, such as blog content, is sanitized with DOMPurify before it is rendered.
- Security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and HSTS are set on responses.
- Signed webhooks: outbound webhooks are signed with HMAC-SHA256 so you can verify they came from GetCookies.
Vulnerability Management
- Dependabot monitors our dependencies for known vulnerabilities and opens update pull requests.
- Changes are reviewed before they reach production.
Incident Response
If a personal data breach affects you, we notify you without undue delay and, where GDPR Article 33 requires it, within 72 hours.
Responsible Disclosure
Report vulnerabilities to [email protected]. The contact is also published in /.well-known/security.txt in the RFC 9116 format. Please include reproduction steps and the potential impact.
Security Questionnaire Quick Reference
| Question | Answer |
|---|---|
| Data encrypted at rest? | Yes, at the infrastructure level (Railway) |
| Data encrypted in transit? | Yes, HTTPS with HSTS |
| MFA available? | Yes, TOTP on every account |
| SSO supported? | No |
| SOC 2 or ISO 27001 certified? | No |
| Where is data hosted? | Railway, United States, with SCCs for transfers |
| Audit log available? | Yes |
| DPA available? | Yes, see /legal/dpa |
| Breach notification? | Without undue delay; within 72 hours where GDPR Article 33 applies |
Requesting a Security Review
Email [email protected] with your questionnaire attached and we will fill it in. We only answer with what is on the security page and in our DPA, and we will tell you plainly when a control is not in place.