The agreement that governs what we do with your data
Free to download, no form in front of it. It covers GDPR Article 28, the DPDP Act, the UK GDPR and the Standard Contractual Clauses, and it is incorporated into your agreement whether you signed an MSA or subscribed online.
Version 1.1 · Effective 2026-09-16
The AI question
B-52 runs on language models. Here is exactly what that means for your data.
It is the first question any security team asks about an autonomous platform, and it deserves a straight answer instead of a paragraph of reassurance. Four controls apply to every engagement, in every delivery model, and each is auditable on request.
| Control | What it means in practice |
|---|---|
| Anonymised and tokenised before it leaves | Before engagement material reaches a third-party model provider, the anonymisation layer swaps domains, application names, internal keywords, account identifiers and personal data for randomised or tokenised values. The model works on an abstracted version of your environment, and B-52 maps its answer back. §3.10(a). |
| Identifiable material stays with us | Where processing needs engagement material in identifiable form, it runs on models we operate on our own infrastructure. No third party receives it. §3.10(b). |
| Providers do not train on it | The providers named in Annex C do not use commercial API inputs or outputs to train their models, and are bound to that by their own published terms. §3.10(c). |
| You can opt out of platform improvement | We use anonymised engagement material to improve detection. You can exclude yours at any time in writing: no charge, no change to fees, no effect on the service. §3.10(d) and §3.11. |
Anonymised and tokenised before it leaves
- What it means in practice
- Before engagement material reaches a third-party model provider, the anonymisation layer swaps domains, application names, internal keywords, account identifiers and personal data for randomised or tokenised values. The model works on an abstracted version of your environment, and B-52 maps its answer back. §3.10(a).
Identifiable material stays with us
- What it means in practice
- Where processing needs engagement material in identifiable form, it runs on models we operate on our own infrastructure. No third party receives it. §3.10(b).
Providers do not train on it
- What it means in practice
- The providers named in Annex C do not use commercial API inputs or outputs to train their models, and are bound to that by their own published terms. §3.10(c).
You can opt out of platform improvement
- What it means in practice
- We use anonymised engagement material to improve detection. You can exclude yours at any time in writing: no charge, no change to fees, no effect on the service. §3.10(d) and §3.11.
Model hosting
Four ways to run the models, and the agreement covers each
Standard hosting puts the anonymisation layer in front of leading third-party models. Where your policy rules out shared model infrastructure, the models run on hardware dedicated to you or inside your own environment, or you bring your own. The option you choose is written into your agreement at §3.12, and the platform around it does not change.
| Hosting option | Where inference runs | Who receives your material |
|---|---|---|
| Standard | Supported third-party models, with our own models for anything that needs identifiable material. | The providers in Annex C, after the anonymisation layer has tokenised it. They do not train on it. §3.12(a). |
| Dedicated hardware | Compute that we own and operate, allocated to you alone. | No third-party model provider. §3.12(b). |
| Inside your environment | Supported models hosted inside your own infrastructure. | No third-party model provider. Inference stays inside your security boundary. §3.12(c). |
| Your own model | Your enterprise model, through your own provider agreement or hosted privately, once it is validated against the supported set. | Your provider, under your terms. It is your vendor, not our sub-processor. §3.12(d). |
Standard
- Where inference runs
- Supported third-party models, with our own models for anything that needs identifiable material.
- Who receives your material
- The providers in Annex C, after the anonymisation layer has tokenised it. They do not train on it. §3.12(a).
Dedicated hardware
- Where inference runs
- Compute that we own and operate, allocated to you alone.
- Who receives your material
- No third-party model provider. §3.12(b).
Inside your environment
- Where inference runs
- Supported models hosted inside your own infrastructure.
- Who receives your material
- No third-party model provider. Inference stays inside your security boundary. §3.12(c).
Your own model
- Where inference runs
- Your enterprise model, through your own provider agreement or hosted privately, once it is validated against the supported set.
- Who receives your material
- Your provider, under your terms. It is your vendor, not our sub-processor. §3.12(d).
How we handle your data walks through what the anonymisation layer replaces and where each option suits.
The default that does the work
In the ordinary case there is nothing of your customers' for us to hold
An authorisation defect is proved by reaching one record that belongs to somebody else. Enumerating the rest proves nothing further, so it is a separate act behind a separate written approval from you. That gate is in the agreement at §2.1, not only in the product. The report names every finding for which you granted it.
It is why the categories in Annex A describe your systems, not your customers: the scope you authorised, what the targets disclosed about themselves, and the request and response that evidence each finding.
Retention
Every period stated as a number
An unstated retention period reads as indefinite, which is worse than a long one. You can also ask us to delete engagement material earlier, and we act on that within thirty days.
| Material | Retention |
|---|---|
| Source code, where a review is in scope | Deleted after thirty days of engagement inactivity. Where the review runs inside your own pipeline it never leaves it. |
| Scope, evidence, target-disclosed information, reports | The engagement, then twelve months, then deleted. |
| Credentials you issued for testing | Not retained beyond the engagement. Yours to revoke, and worth revoking. |
| On termination | Thirty days for live systems, ninety for backups, and only statutory retention beyond that. |
Source code, where a review is in scope
- Retention
- Deleted after thirty days of engagement inactivity. Where the review runs inside your own pipeline it never leaves it.
Scope, evidence, target-disclosed information, reports
- Retention
- The engagement, then twelve months, then deleted.
Credentials you issued for testing
- Retention
- Not retained beyond the engagement. Yours to revoke, and worth revoking.
On termination
- Retention
- Thirty days for live systems, ninety for backups, and only statutory retention beyond that.
Residency
You choose the region. We tell you where that stops.
India, the European Union, the United States, or Singapore and Asia-Pacific. Your election governs where engagement material is stored and processed at rest, including the 180 days of rolling ICT logs that CERT-In Directions No. 20(3)/2022-CERT-In require to sit within Indian jurisdiction.
Where model inference happens is set by your hosting option instead. On standard hosting our own models run in our environment, and the third-party providers in Annex C may run inference outside your region, including in the United States, on tokenised material they do not train on. Where inference has to stay inside a boundary you define, run the models inside your own environment or bring your own. §5.5 sets out all four.
Need redlines, or have your own DPA?
We negotiate redlines and accept customer-provided DPAs. Email [email protected] with your draft or your changes, or to request a countersigned copy. We respond within two business days. Send your diligence questionnaire before the commercial conversation; the answers are the same either way.