Data Processing Addendum

Last updated 29 July 2026

0. Read this first — the honest scope of this DPA

Most vendor DPAs assume a SaaS posture: the vendor hosts the service, holds the customer's data, and is squarely a processor of it. That is not our situation, and drafting as if it were would misdescribe the arrangement.

KubeManta is self-hosted. It runs inside your cluster, on your infrastructure. Your cluster data — workloads, logs, metrics, configuration, secrets, and any personal data they contain — is never transmitted to us. We have no access to it, no copy of it, and no technical means of obtaining it.

Therefore:

For your cluster data, we are not a processor at all — because we do not process it. There is no controller-to-processor relationship over that data, because no data flows to us to process.

This DPA covers the narrow set of data we genuinely do process on your behalf: account, billing, licensing and support data.

Two consequences worth stating up front, because they are unusually favorable to you and a reviewer should not have to hunt for them:

The scope of any breach on our side is bounded by the account data listed in §3. A compromise of our infrastructure cannot expose your cluster's contents, because our infrastructure never held them.
Data residency for your cluster data is whatever you choose, because it never leaves the infrastructure you selected. No transfer mechanism is required for data that does not transfer.

The one route by which cluster-derived content can leave your cluster is an AI provider you configure yourself — addressed precisely in §9.

1. Parties and relationship

This DPA is between:

You ("Customer", "Controller") — the entity that agreed to the Terms of Service; and
Infrastratus, a sole proprietorship registered in the Republic of the Philippines (full registered address available on request and stated on invoices), registration number ("Provider", "Processor", "we").

It supplements the Terms of Service and applies where we process personal data on your behalf in the course of providing the Service, and where you are subject to GDPR, UK GDPR, or a comparable regime.

Where this DPA conflicts with the Terms of Service on data protection, this DPA governs.

2. Definitions

"Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in the GDPR. "Applicable Data Protection Law" means the GDPR, the UK GDPR, and any other data protection law applicable to a party.

Other capitalised terms are defined in Terms of Service §2.

3. Subject matter, scope and duration

3.1 What we process as your processor

Category	Data	Purpose
Account and contact	Name, email address of the person who signed up or is named on the subscription	Providing the Service, delivering license keys, support
Billing	Subscription status, billing period, amounts, and the name/email attached to the subscription	Managing the subscription and entitlements
Licensing	License key; Cluster Fingerprint (a random UUID); tier and validation status; optional node-count telemetry (size counts and timestamps only — itemised in Privacy Policy §3.3, disableable, never used to calculate a charge)	Issuing and validating entitlements; product telemetry
Marketing attribution	UTM source/medium/campaign, referrer, captured at signup	Understanding acquisition channels
Support correspondence	Whatever you include in a message to us	Responding to you

Categories of data subjects: your personnel who sign up for, purchase, or administer the Service, and anyone who contacts our support.

Nature and purpose: storage, transmission, and retrieval for the purposes above, and no others.

Duration: for the term of your Subscription plus the retention periods in Privacy Policy §7.

Payment card data: we never receive it. Paddle, as Merchant of Record, holds it as an independent controller.

3.2 What we expressly do NOT process

For the avoidance of doubt, we do not receive or process, and have no means of accessing:

❌ Cluster workload data, pod specifications, container images or configuration
❌ Application logs, Kubernetes events, metrics, or traces
❌ Kubernetes Secrets, ConfigMaps, or credentials
❌ Your audit log, activity feed, or security-scan findings
❌ Any personal data your applications process inside your cluster
❌ Your end users' or employees' data held in your cluster
❌ Cluster name, node names or labels, cloud provider or region

(The one size-related figure we do receive — an optional, disableable count of how many nodes the cluster runs, with no names and no workload information — is listed in §3.1 under Licensing and itemised in Privacy Policy §3.3. It is arguably not personal data at all; it is disclosed here so this list and the Privacy Policy can never disagree.)

All of the above remain in your cluster, under your sole control. Where they contain personal data, you are the controller and we are not a processor of it.

4. Roles and obligations

4.1 You (Controller)

You warrant that you have a lawful basis for the personal data you provide to us in §3.1, and that you have given any notices and obtained any consents required.

For data inside your cluster you are the controller, and you are responsible for its lawful processing, its security, its retention, and for responding to data subjects about it. We cannot assist with the substance of such a request because we have no access to the data — but the Software gives you the tools to do so (see §6.2).

4.2 Us (Processor)

For the data in §3.1 we will:

Process it only on your documented instructions — the Terms of Service, this DPA, and your use of the Service constitute those instructions — unless required by law, in which case we will tell you first unless legally prohibited.
Ensure people authorized to process it are bound by confidentiality.
Implement appropriate technical and organisational measures (§6).
Respect the conditions in §5 for engaging subprocessors.
Assist you, so far as we reasonably can given the limited data we hold, with data-subject requests (§7), security, breach notification (§8), and impact assessments.
Delete or return the data at the end of the relationship (§10).
Make available the information reasonably necessary to demonstrate compliance with Article 28, and allow for audits (§11).
Tell you if we consider an instruction infringes Applicable Data Protection Law.

5. Subprocessors

You give general written authorization for us to engage subprocessors.

Our current subprocessors are listed in the Subprocessor List — a single canonical page, referenced rather than duplicated here so the two can never drift apart.

We will:

Impose data-protection obligations on each subprocessor no less protective than those in this DPA;
Remain liable to you for each subprocessor's performance of the data-protection obligations imposed on it under this DPA, to the same extent, and subject to the same exclusions and limitations, as apply to our own performance under §13;
Give you 30 days notice before adding or replacing a subprocessor that processes personal data (subscribe via [email protected]);
Consider in good faith any reasonable objection you raise. If we cannot resolve it, you may terminate the affected Service and receive a pro-rata refund of prepaid fees for the unused remainder — an exception to the no-pro-rata rule in the Refund & Cancellation Policy.

AI providers you configure are not our subprocessors — see §9.

6. Security measures

6.1 Measures protecting the data we hold

Encryption in transit (TLS) for all services
Encryption at rest for credential material
Encrypted off-site backups, GPG-encrypted before upload, with the decryption key held offline — our backup provider stores ciphertext it cannot read
Access control limiting access to those who need it
Payment card data never enters our systems (Paddle holds it)
Network isolation and edge protection for public endpoints

6.2 Measures in the Software, protecting the data we do NOT hold

The Software you run provides the controls you need to be a good controller of your own cluster data. These are your tools, not our obligations, but they are what makes the self-hosted posture practical:

Control	What it gives you
Data never leaves your cluster	The strongest available control — no vendor access by construction
SSO (SAML 2.0, OIDC, LDAP/AD)	Enterprise identity, JIT provisioning, group-to-role mapping
Role-based access control	Viewer/admin roles, enforced server-side on every privileged endpoint
Audit trail	Every privileged and destructive action recorded with actor, action and scrubbed detail
Encryption at rest (AES-256-GCM)	Credential-bearing settings encrypted in the Software's own database
Configurable retention	You set how long the audit log, activity feed and scan history are kept
Approval-gated writes	No autonomous changes; a human admin approves each write
Secret redaction	Credential-shaped content scrubbed from logs before they reach any AI prompt
Namespace scoping and IP access control	Restrict what the Software may read and who may reach it

Full technical detail: Security & Trust.

7. Data-subject requests

For the data in §3.1, we will assist you with access, rectification, erasure, restriction, portability and objection requests. Because that data is small and well-structured, we can usually satisfy such a request quickly. Email [email protected].

For data inside your cluster, we cannot assist with the substance — we have no access. You handle it directly using your own tooling and the controls in §6.2. This is a consequence of the architecture, not a limitation of our willingness.

8. Personal data breach

If we become aware of a personal data breach affecting personal data we process for you, we will notify you without undue delay and in any event within 72 hours of becoming aware, with the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken, and a contact point.

We will not notify a supervisory authority or data subjects on your behalf unless you ask us to or the law requires it of us directly.

A breach inside your cluster is yours to detect and report — we have no visibility into it. The Software's audit trail and alerting are designed to help you do so.

9. AI providers — controller/processor analysis

This section exists because a reviewer will ask, and the answer is not the usual one.

Default state. Out of the box no AI provider is configured and no cluster data goes anywhere.

If your administrator configures a third-party AI provider, prompt content — which may include cluster context such as namespace and pod names, Kubernetes events, resource specifications and redacted log excerpts — is transmitted from your cluster directly to that provider, under your API key and your contract.

The correct analysis:

Role	Party
Controller of that transfer	You
Processor of that data	The AI provider you chose
Our role	None. Not a controller, not a processor, not a subprocessor. The data does not pass through our infrastructure and we never see it.

You are responsible for assessing that provider's terms, for any transfer mechanism required, and for whether the transfer is lawful for your data.

Controls the Software gives you, which a reviewer should note are enforced mechanisms and not merely documented policy: local-only mode (point at a model in your own cluster — zero external egress), a deny-by-default outbound-domain allowlist, secret redaction before prompts are built, namespace scoping, an optional in-cluster prompt audit log, and a master kill switch that disables every AI entry point while leaving the rest of the product working.

Limits of redaction are stated honestly in Privacy Policy §5.4 — including that it is pattern-based, that it does not redact resource names or structure, and that an administrator in your organization can switch it off.

10. Deletion and return

On termination, we will delete or return the personal data in §3.1 within 90 days, except where retention is required by law (tax and accounting records in particular) or for establishing or defending legal claims. Retained data stays subject to this DPA.

Your cluster data needs no deletion step from us — we never held it. To remove it, uninstall the Helm release and delete the persistent volume. Nothing of yours sits on our side awaiting deletion.

11. Audits

We will make available the information reasonably necessary to demonstrate compliance with Article 28 — including this DPA, the Subprocessor List, and Security & Trust.

Where that information is not sufficient to demonstrate compliance with Article 28, you may request a further audit on the following terms. Such an audit may be requested no more than once in any twelve-month period (and additionally following a personal data breach affecting your data), on 30 days written notice, and will be:

conducted remotely, by you or by an independent auditor who is bound by confidentiality and is not a competitor of ours;
limited to the systems and records that process the personal data described in §3.1, and to information that does not compromise the confidentiality, security or data-protection obligations we owe to other customers;
conducted during business hours, without unreasonable disruption to our operations, and limited to one auditor-day per twelve-month period;
at your cost, unless the audit establishes our material non-compliance with this DPA, in which case we bear the reasonable cost.

On-site access will be granted only where a competent supervisory authority requires it in writing, and then only to the extent and for the period so required.

We do not currently hold a SOC 2 report or an equivalent third-party attestation, and we have not commissioned an independent penetration test. That is stated truthfully in Security & Trust §8, and nothing in this DPA should be read as implying otherwise.

12. International transfers

Two points that materially narrow the problem:

The data in scope is limited to §3.1 — account, billing, licensing and support data. Not cluster data.
Your cluster data does not transfer at all, so it needs no transfer mechanism. For many customers this is the entire reason the self-hosted model was chosen.

13. Liability

Liability under this DPA is subject to the limitations in Terms of Service §12, except to the extent Applicable Data Protection Law prohibits limiting liability for a given claim.

14. Term, order of precedence, governing law

This DPA takes effect when you accept the Terms of Service or sign this DPA, and continues while we process personal data for you.

Precedence: this DPA over the Terms of Service on data protection; a signed negotiated DPA over this template.

Governing law: as in Terms of Service §15 (the Republic of the Philippines), without prejudice to mandatory local data-protection law.

15. Signature

To request a DPA, email [email protected].

	Customer	Infrastratus
Signature
Name
Title
Date