Legal

Data Protection Policy

last updated: 2026-07-02 · operated by sk21.tech

This policy describes the technical and organizational measures behind the privacy claims on our landing page. It applies to all verification data processed by PrivateKYCBot (operated by SK21.TECH) and is reflected in the data processing agreement (DPA) we sign with every Customer.

1. Roles

The company requesting a verification is the data controller; PrivateKYCBot is the data processor and acts only on the controller's documented instructions. data-controller: you · processor: privatekycbot

2. Data we process

• Identity documents (photos/scans) and the data extracted from them.
• Selfies and liveness-check media.
• Proof-of-address documents, where the flow requires them.
• Chat metadata needed to run the flow (platform user ID, timestamps, flow state).

We collect the minimum the configured flow requires — nothing else (data minimization).

3. Core guarantees

• Purpose limitation: verification data is used solely to complete the verification the end user was informed about.
• No training, no resale, no profiling: data is never used to train models, never sold, and never aggregated across tenants. cross-tenant access: none
• Tenant isolation: each Customer runs in strict isolation; one tenant's flows, media, and results are technically inaccessible to another's.

4. Retention & deletion

Retention is configured per flow by the controller:retention: 0d | 30d | 90d → auto-purge. Zero-day means media passes through to the controller's pipeline and is purged as soon as delivery is confirmed. When any window closes, media and PII are deleted automatically. Data-subject deletion and export are first-class operations (DELETE /api/subjects/:id → purged + receipt) and we assist controllers with data-subject requests without undue delay.

5. Security measures

• TLS for all data in transit; encryption at rest during the retention window.
• Access on a need-to-know basis, scoped per tenant, logged.
• Tamper-evident audit trail of every verification (what was checked, when, by which rule) that does not retain the raw documents.
• Secrets and credentials are never stored in client-side code or images; infrastructure follows least-privilege.

6. Sub-processors

We use a small set of infrastructure sub-processors: Google Cloud (hosting), Cloudflare (CDN/DNS), and the messaging platforms chosen by the end user (Telegram,WhatsApp/Meta) for message delivery. Controllers are notified before we add or replace sub-processors that touch verification data.

7. International transfers

Where verification data crosses borders, transfers rely on appropriate safeguards (such as the EU Standard Contractual Clauses) as set out in the Customer's DPA.

8. Breach notification

We notify affected controllers of a personal data breach without undue delay after becoming aware of it, with the information needed for their own regulatory notifications (for GDPR controllers, supporting their 72-hour obligation).

9. Contact

Data protection contact:[email protected]. A signed DPA, the current sub-processor list, and security documentation are available to Customers on request.