Data Processing Addendum
Last updated: 27 September 2026
This Data Processing Addendum ("DPA") forms part of the Terms of Service or other agreement ("Agreement") between Techmek LLC ("we", "Processor") and the customer ("Customer", "you"). It applies when we process Customer Personal Data on your behalf in providing the Hosted Service. Capitalised terms not defined here have the meanings in the Agreement.
1. Definitions
- Data Protection Laws: all laws on the processing of personal data that apply to a party's processing under the Agreement, including the EU GDPR, the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, and US state privacy laws including the California Consumer Privacy Act as amended by the CPRA ("CCPA").
- Customer Personal Data: personal data in Customer Data that we process on your behalf.
- Security Incident: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
- SCCs: the Standard Contractual Clauses approved by European Commission Implementing Decision (EU) 2021/914.
- UK Addendum: the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner.
- "Controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings in the GDPR; "business", "service provider", "sell" and "share" have the meanings in the CCPA.
2. Scope and roles
2.1 You are the controller (or a processor acting for your own controller) and we are your processor for Customer Personal Data.
2.2 What is out of scope. The Gateway and any Self-Hosted or air-gapped Console run on your infrastructure. Prompts, code, files and the sensitive values the Gateway protects are processed there and are not sent to us, so we do not process them. Your AI providers receive requests directly from your Gateways; they are not our subprocessors.
2.3 We act as a controller only for our own business records (for example billing contacts, contract records, and security logs of our own operator staff), as described in our Privacy Policy.
3. Processor obligations (GDPR Article 28(3))
We will:
- process Customer Personal Data only on your documented instructions, which are the Agreement, this DPA and your configuration of the Hosted Service, unless law requires otherwise (in which case we will tell you first unless the law prohibits it). We will tell you if we believe an instruction infringes Data Protection Laws;
- ensure that people authorised to process Customer Personal Data are bound by confidentiality;
- implement the measures in Annex 2 (Article 32);
- engage subprocessors only under section 5;
- help you, taking into account the nature of processing, to respond to data subject requests (section 6);
- help you meet your obligations under Articles 32 to 36 (security, breach notification, data protection impact assessments and prior consultation), using the information available to us;
- delete or return Customer Personal Data at the end of the services (section 9); and
- make available the information needed to demonstrate compliance with this section and allow for audits (section 8).
4. Your obligations
You are responsible for the lawfulness of the Customer Personal Data you provide and of your instructions, and for giving any notices and obtaining any consents required. You will not submit special-category data, protected health information, payment card data or the values the Gateway protects to the Hosted Service (including in device labels or other free-text fields).
5. Subprocessors
5.1 You give general authorisation for us to engage subprocessors. Our current subprocessors are listed on the Subprocessors page, which forms part of this DPA.
5.2 We will give at least 30 days' notice of a new subprocessor. You may object in writing within that period on reasonable data-protection grounds. We will discuss the objection in good faith; if we cannot resolve it, you may terminate the affected part of the Service and receive a pro rata refund of prepaid fees for the unused remainder of the term.
5.3 We will impose data protection terms on each subprocessor that are no less protective than this DPA, and we remain liable for their performance.
6. Data subject requests
Most requests can be handled by you directly in the Console (view, correct or remove users; delete the organisation). If we receive a request directly, we will pass it to you without undue delay and will not respond ourselves except to redirect the requester, unless law requires otherwise.
7. Security Incidents
7.1 We will notify you without undue delay, and in any case within 48 hours, after becoming aware of a Security Incident affecting your Customer Personal Data.
7.2 The notice will describe, as far as then known: the nature of the incident, the categories and approximate number of data subjects and records affected, likely consequences, and the measures taken or proposed. We will provide further information as it becomes available and take reasonable steps to contain and remedy the incident.
7.3 Notice will be sent to your account owners and to any security contact you have set in the Console. Notice is not an admission of fault.
8. Audits
8.1 On request (no more than once a year, unless required by a supervisory authority or following a Security Incident), we will provide documentation reasonably needed to demonstrate compliance, including: our Security Overview; the Trust page and data inventory generated from the database schema; results of the release isolation tests; completed security questionnaires; and, when available, third-party audit reports or penetration test summaries. We do not currently hold a SOC 2 report or ISO 27001 certification; we will say so rather than imply otherwise.
8.2 Using the Console and Gateway you can produce evidence packs (vguard evidence export), proof reports (vguard prove) and the exact telemetry payload (vguard org telemetry).
8.3 If the information above is not enough to demonstrate compliance with Article 28, you (or an independent auditor bound by confidentiality, not our competitor) may conduct an audit on at least 30 days' notice, during business hours, in a way that does not compromise other customers' data or our security. You bear your own costs, and our reasonable costs if the audit takes more than two business days.
9. Deletion and return
9.1 During the term you can export Customer Data through the Console. After the Agreement ends, you may export for 30 days. We then delete Customer Personal Data from the live Hosted Service within 30 days of termination. On your written request we will delete sooner.
9.2 Encrypted database backups are kept with a 30-day write-protection lock and expire and are deleted within 90 days of creation, so Customer Personal Data in backups is gone no later than 90 days after deletion from the live service. Until then backups remain encrypted, isolated and used only for disaster recovery.
9.3 We may retain Customer Personal Data where law requires it, and will keep it confidential and process it only for that purpose.
10. International transfers
10.1 The Hosted Service and its backups are located in the United States. Where Customer Personal Data subject to the EU GDPR is transferred to a country without an adequacy decision, the SCCs are incorporated into this DPA by reference as follows:
- Module 2 (controller to processor) applies where you are a controller; Module 3 (processor to processor) applies where you are a processor.
- Clause 7 (docking clause) applies.
- Clause 9: Option 2 (general authorisation), with the notice period in section 5.2.
- Clause 11: the optional redress language does not apply.
- Clause 13: the supervisory authority of the EU Member State in which you are established or, if not established in the EU, where your EU representative is located.
- Clauses 17 and 18: the law and courts of Ireland.
- Annexes I and II are completed by Annexes 1 and 2 of this DPA; Annex III by the Subprocessors page.
10.2 For transfers subject to the UK GDPR, the UK Addendum is incorporated by reference. Table 1 is completed with the parties' details in the Agreement; Table 2 by the SCCs as set out in section 10.1; Table 3 by Annexes 1 and 2 and the Subprocessors page; and in Table 4 either party may end the UK Addendum as allowed by its Section 19.
10.3 For transfers subject to Swiss law, the SCCs apply with references to the GDPR read as references to the Swiss FADP, the competent authority being the Swiss FDPIC, and "Member State" not interpreted to exclude data subjects in Switzerland from bringing claims in their place of habitual residence.
10.4 If the SCCs conflict with this DPA, the SCCs prevail.
11. CCPA service-provider terms
For Customer Personal Data subject to the CCPA, we act as your service provider. We will not: (a) sell or share it; (b) retain, use or disclose it for any purpose other than the business purposes in the Agreement (providing, securing and supporting the Hosted Service), or outside the direct business relationship with you; (c) combine it with personal information we receive from other sources, except as the CCPA permits for service providers. We will comply with the CCPA, provide the same level of privacy protection it requires, and notify you if we can no longer meet our obligations. You may take reasonable and appropriate steps to stop and remediate unauthorised use. We certify that we understand these restrictions.
12. Liability and precedence
Each party's liability under this DPA is subject to the limitations in the Agreement, except where Data Protection Laws or the SCCs do not allow it. If this DPA conflicts with the Agreement on the processing of personal data, this DPA prevails.
Annex 1: Details of processing
| Item | Details |
|---|---|
| Data exporter | Customer (details in the Agreement or Order). Role: controller (Module 2) or processor (Module 3). |
| Data importer | Techmek LLC, postal address available on request from devopsplus11@gmail.com. Contact: devopsplus11@gmail.com. Role: processor. |
| Subject matter and nature | Hosting and operating a management console for the customer's Vaultless Guard gateways: storage, display, aggregation and deletion. |
| Purpose | To provide, secure and support the Hosted Service under the Agreement. |
| Categories of data subjects | Customer's console users (administrators, approvers, viewers); customer's personnel who use enrolled gateways (as named by device or user labels). |
| Categories of personal data | Console user account data: name, email address, roles, password digest (scrypt), MFA seed (encrypted), session records, sign-in events with a short tag derived from IP address; SSO/SCIM identifiers from the customer's identity provider; device identifiers and labels, and the user label a gateway enrolled with; audit trail of console actions. Content-free operational data linked to devices: counts per data category and outcome, token counts, model names, latency, versions, health, self-test results, audit-chain head hashes. Organisation settings and rules (sensitive-term rules stored only as salted digests). |
| Not processed | Prompts, responses, code, files, file paths, the values the gateway protects, MCP server names, the organisation's salt, and the plaintext of sensitive-term rules. |
| Special categories | None intended. Customer must not submit any (section 4). |
| Frequency | Continuous while the customer uses the Hosted Service (gateway heartbeats about every 15 minutes; daily count rollups). |
| Retention | During the term, subject to built-in limits (unless an Order Form sets custom retention): console audit trail and daily rollups 13 months; audit anchors all for 7 days, then one per gateway per day for 13 months; webhook deliveries and device commands 30 days; sessions deleted 1 day after expiry. Deletion after termination and backup expiry per section 9. |
| Subprocessors | See the Subprocessors page. |
Annex 2: Technical and organisational measures
Data minimisation by design - The gateway replaces sensitive values with tokens locally; the Hosted Service never receives content or protected values. The telemetry schema has no free-text field; gateways validate each batch before sending and the console validates it again and rejects anything else. - Sensitive-term rules are stored only as salted, keyed digests; plaintext terms are refused. Organisations can sign rule sets with their own key, which gateways verify, so the console cannot change what gateways enforce. - Customers can self-host the console or run air-gapped instead of using the Hosted Service.
Encryption - TLS for all connections to the Hosted Service. - Secrets the service must reuse (MFA seeds, webhook signing secrets, SSO client secrets) are encrypted at rest with AES-256-GCM under a key held outside the database. Passwords and tokens are stored only as one-way digests. - Backups are encrypted to our offline key (X25519 + ChaCha20-Poly1305) before leaving the server.
Tenant isolation - PostgreSQL row-level security, forced on every tenant table; the tenant application role cannot bypass it, and an unbound query returns nothing. Isolation is tested against the live service on every release. - Customer-facing and operator applications are separate, with separate hostnames, credentials and database roles. The operator application is restricted by source address.
Access control - Customer access: role-based access control, MFA (TOTP) enforceable by role, single sign-on with the customer's own OpenID Connect provider, SCIM provisioning, session limits, IP allow lists. - Vendor staff access: least privilege by role; every operator view of or action on a customer organisation is written to that customer's audit trail and webhooks; customers control whether operators may view usage detail or restore a locked-out administrator. - Two-person control: privileged and rule changes require approval by a second person; the proposer cannot approve.
Integrity and logging - Tamper-evident, hash-chained audit logs on gateways, anchored at the console by heartbeats. - Console audit trail of user and operator actions, exportable and streamable to customer webhooks.
Availability and recovery - Two application replicas; health checks; database outage handling that fails fast. - Database backups every 6 hours, each restore-tested automatically before being kept, encrypted, and copied to Amazon S3 (us-east-1) with a 30-day object lock and 90-day expiry. Upload credentials can only write, not read or delete. Alerts on stale or failed backups. A documented restore procedure. - Gateways protect data locally even when the console is unavailable.
Network - Default-deny network policies inside the cluster; only the application, migration, backup and test jobs can reach the database, and the database can reach nothing. - Rate limiting at the edge and per address in the application. Application access logs are disabled.
Development and change - Signed releases and signed offline bundles; pinned, hash-checked dependencies; network isolation tested on every release. - Documented vulnerability disclosure at /.well-known/security.txt and devopsplus11@gmail.com.
Current limits, stated plainly - The Hosted Service runs on a single Kubernetes node in one data centre. - No SOC 2 report, ISO 27001 certification or third-party penetration test yet.