How Tracefox handles your data
When you put a monitoring tool on client sites, the first question your client's IT team asks is where does the data live. Here's the complete answer, every engineering and operational decision we've made around your data.
Read-only scanning
Tracefox never writes to your client's site. We load the page in a headless browser and capture what's already public, scripts, cookies, DOM, network requests. Zero plugin installs, zero database access, zero code injection.
EU-region storage
Scan snapshots and screenshots live in EU-region object storage (AWS S3, eu-west-1). Data at rest is AES-256 encrypted. No cross-region replication unless you explicitly request it.
Encrypted in transit
Every scan request leaves our infrastructure over TLS 1.2+. Dashboard and API traffic is TLS-only. HSTS enforced. No plaintext endpoints.
Credential hygiene
Passwords are hashed with bcrypt (cost factor 10+). API keys are salted + hashed in the database, we can't see your key after you create it. Session cookies are HttpOnly, Secure, and SameSite=Lax.
What we capture (and what we don't)
A scan captures only what a regular browser would receive when loading the page. We don't authenticate, don't fill forms on production, don't interact with private pages.
What we capture
- ✓Public HTML, DOM structure, and inline scripts
- ✓Third-party scripts and their domains
- ✓Cookies set by the page (name, domain, expiry, not user values)
- ✓Network requests fired by the page
- ✓Public policy/terms/privacy pages (if you opt in)
- ✓Rendered screenshot of the viewport
What we never capture
- ✗Personal data of your client's visitors (no PII harvesting)
- ✗Authenticated or private pages (no logins)
- ✗Form inputs on production sites
- ✗Email, financial, or session data
- ✗Keystrokes, mouse tracking, or behavior analytics
- ✗Data from pages outside the URLs you add
A note on checkout testing
Checkout tests are the one place where Tracefox does interact with a live site. By design, the tests run with your recorded inputs, test data, test card numbers, and stop at the point you define (typically the payment confirmation step). We recommend a dedicated test coupon that zeroes the order total, which most e-commerce platforms support.
We do not store payment card numbers. Test data you provide is encrypted at rest and only decrypted inside the isolated test-runner environment at execution time.
Compliance & certifications
GDPR compliant
EU data storage, DPA available on request, right-to-erasure honored within 30 days. We publish a full Privacy Policy describing data flows.
Cookie Consent Mode v2
Our own site uses Google Consent Mode v2 with analytics_storage denied by default. Marketing tags only fire after explicit opt-in.
SOC 2 Type I
Audit in progress. Target completion: Q3 2026. We're being deliberately transparent here rather than claiming a certification we don't yet hold, happy to share current-state control documentation under NDA for procurement reviews.
Subprocessor list
We rely on AWS (S3 storage, eu-west-1), Resend (transactional email), Stripe (payments), and PostHog (product analytics, self-hosted-eligible). Background jobs run on our own infrastructure (BullMQ + Redis on Railway). Full list + DPAs on request.
If something goes wrong
We commit to a 72-hour disclosure window for any confirmed data incident affecting customer data, per GDPR Article 33. Material incidents are posted to tracefox.co/status with a timeline, scope, and remediation plan, no vague "we're aware of an issue" language.
Security-sensitive reports (vulnerabilities, suspected account compromise) go to [email protected]. We respond within 1 business day.
Need a DPA, subprocessor list, or to run Tracefox through your vendor security review?
Contact security team