Every vendor. Named. Bounded. Auditable.
GDPR Article 28(3) compliant
Every sub-processor signs a Data Processing Agreement. It restricts them to instructed purposes and GDPR-grade safeguards. If they can't prove compliance, we can terminate.
Hashes over plaintext, by default
Where the vendor can do its job with a hash prefix — the dark-web breach lookup, the password-check service — we send a hash prefix. The vendor never sees the full identifier.
Transfer mechanism declared per vendor
Where data leaves the EU, we identify the legal mechanism — adequacy decision, EU Standard Contractual Clauses (2021/914), UK IDTA, or Indian-export consent. We do not hand-wave international transfers.
In short: every third party we send data to is named below, with its legal entity, jurisdiction, exactly what we send, and the DPA that binds it. Where a hash works instead of the raw identifier, we send the hash. The vendors we deliberately refuse to use are listed too.
How to read this page
A sub-processor is any third party we instruct to process personal data on our behalf. Under GDPR Article 28(3), we must disclose them, bind them to written terms, and stay liable for their performance. Under DPDPA §8(7), we must give notice to the Data Principal. Under CCPA, processors are “service providers,” restricted from using data for their own purposes.
For each vendor we list:
- Legal entity — the actual contracting party.
- Jurisdiction — where the contracting entity sits and where processing happens.
- Purpose — exactly what we use them for.
- What we send — the data categories that leave our systems.
- Plaintext or hash — whether the vendor sees the raw identifier or only a hashed/prefixed form.
- Transfer mechanism — the legal basis for international transfers, where relevant.
- DPA reference — the contract that governs the relationship.
If a category is not listed for a vendor, we do not send it. This is our current set of sub-processors, updated as they change.
Infrastructure and analytics
Cloudflare, Inc.
| Jurisdiction | US-incorporated; EU traffic terminates at Frankfurt and Amsterdam edges |
| Purpose | CDN, DDoS protection, TLS termination for knytx.com |
| Data shared | Request metadata only (IP, user-agent, URL) — no account data |
| Plaintext / hash | Plaintext request metadata |
| Transfer mechanism | EU SCCs (Module 2, 2021/914) + supplementary measures |
| DPA | Cloudflare DPA (publicly published) |
Umami Cloud
| Jurisdiction | Umami Software, Inc.; processing in the EU |
| Purpose | Cookieless website analytics for knytx.com |
| Data shared | Hashed visit signals (page, referrer, anonymised country, device class) — no cookies, no persistent identifiers |
| Plaintext / hash | Hashed; raw IP is not stored |
| Transfer mechanism | Processing in the EU; no cross-border transfer |
| DPA | Signed processor DPA; Umami privacy notice linked for reference |
Email-forwarding provider
| Jurisdiction | EU-based; vendor selection in progress — entry will be updated before launch |
| Purpose | Receive and forward inbound email to *@knytx.com role addresses |
| Data shared | Contents of inbound email correspondence you send to us |
| Plaintext / hash | Plaintext; encrypted in transit (SMTP/TLS) and at rest |
| Transfer mechanism | EU SCCs if any non-EU touchpoint; otherwise intra-EU |
| DPA | Standard processor DPA |
Dark-web and breach-intelligence vendors (Pro tier and above)
We invoke these vendors when a Pro, Family, Team, or Executive user runs a scan with dark-web exposure checks. We do not invoke them for Basic or Free users.
These data feeds power KnytX Vigil’s dark-web credential monitoring.
SpyCloud, Inc.
| Jurisdiction | US (Texas) |
| Purpose | Detect user identifiers in stealer-log malware exports (Redline, Raccoon, Vidar, etc.) |
| Data shared | Email address only — no password, phone, or address |
| Plaintext / hash | Plaintext (SpyCloud catalog requires it); minimised to enabled identifiers only |
| Transfer mechanism | EU SCCs (Module 1, controller-to-processor) + enhanced-protection addendum |
| DPA | Signed processor agreement — forbids training, profile-building, or onward sale |
Hudson Rock Ltd. (Cavalier)
| Jurisdiction | Israel |
| Purpose | Stealer-log detection; redundancy check alongside SpyCloud (non-overlapping coverage) |
| Data shared | Email address only |
| Plaintext / hash | Plaintext |
| Transfer mechanism | Israel partial EU adequacy decision; SCCs for data outside adequacy scope |
| DPA | Signed processor agreement; same scope and restrictions as SpyCloud |
Flare Systems (Flare.io)
| Jurisdiction | Canada (Quebec) |
| Purpose | Dark-web forum, marketplace, and paste-site monitoring for user identifiers |
| Data shared | Email and, where enabled, phone number or username |
| Plaintext / hash | Plaintext (forum mentions are text-matched, not hash-indexed) |
| Transfer mechanism | Canada PIPEDA adequacy covers most exports; SCC fallback otherwise |
| DPA | Signed processor agreement; use restricted to query response |
DarkOwl, LLC
| Jurisdiction | US (Colorado) |
| Purpose | Secondary dark-web index; coverage redundancy alongside Flare |
| Data shared | Email, phone, username where enabled |
| Plaintext / hash | Plaintext |
| Transfer mechanism | EU SCCs |
| DPA | Signed processor agreement |
PimEyes sp. z o.o.
| Jurisdiction | Poland (EU) |
| Purpose | Reverse-image search for facial impersonation detection (Executive tier only, after explicit biometric consent) |
| Data shared | Single reference photo per query; “do not store” flag set where supported |
| Plaintext / hash | Image bytes (API requires it) |
| Transfer mechanism | Intra-EU; no third-country transfer |
| DPA | Signed processor agreement restricted to impersonation-defense purpose; see legal-framework matrix for joint-controller analysis |
Payments and billing
Stripe Payments Europe, Ltd.
| Jurisdiction | Ireland (EU customers); Stripe, Inc. (US); Stripe India Pvt. Ltd. (INR billing) |
| Purpose | Subscription billing and payment processing |
| Data shared | Customer email, billing country, and payment request — KnytX never sees or stores card numbers |
| Plaintext / hash | Plaintext for billing-required fields |
| Transfer mechanism | EU SCCs for EU-to-US transfers; Stripe operates EU-data residency for EEA customers |
| DPA | Stripe DPA (publicly published) |
What we deliberately do not use
- Google Analytics, Mixpanel, Amplitude, Segment, or any product-analytics SDK that builds behavioural profiles.
- Advertising networks (Google Ads, Meta, TikTok). KnytX does not advertise and does not run pixels.
- Customer-data platforms (Salesforce Marketing Cloud, HubSpot CRM). We use a single transactional-email vendor for service notifications and no CRM-style customer-data aggregation.
- Generative-AI vendors for processing user content. We do not pass user identifiers or scan content to OpenAI, Anthropic, Google, or any third-party model API. Internal AI models run on our own infrastructure.
Do you see a network call from knytx.com or the KnytX product to a vendor not listed here? Please report it to security@knytx.com. We want to know.
Adding, changing, or removing a sub-processor
When we add a new sub-processor we:
- Complete a written vendor-due-diligence review (security, privacy posture, data-residency, breach history).
- Sign a Data Processing Agreement before any data flows.
- Update this page within 5 business days.
- Give 30 days’ advance notice to enterprise customers, and to any individual customer who asked for sub-processor change notifications.
- Record the change in the next annual transparency report.
Customers may object to a new sub-processor. If we cannot reasonably accommodate the objection, you may cancel the affected service without penalty during the notice window.
DPA on request
Need the customer-facing DPA? It is the agreement between you and NCRYPTO Labs, and it names these sub-processors and their transfer mechanisms. Email legal@knytx.com with subject line “DPA request”.