Data processing agreement
Last updated 24 October 2026
Draft, not in force. Words in square brackets are still to be filled in. A lawyer will read this page before paid plans open.
1. Who and what
This agreement is part of the terms of service between your organization ("you", the controller) and Mário Henrique Toste Sousa, tax number (NIF) 273284207 ("Gildyard", the processor). It covers the personal data that Gildyard processes on your behalf when it reads your cloud subscriptions: your cloud data. Annex 1 sets out the details. Data about the people who use Gildyard is covered by the privacy page.
Where this agreement and the terms differ about personal data, this agreement wins.
2. Your instructions
We process your cloud data only to run Gildyard for you, as the terms and your settings in Gildyard describe, and on your other written instructions. If we believe an instruction breaks data protection law, we'll tell you. If the law ever requires us to process your data otherwise, we'll tell you first unless the law forbids it.
3. Our people
Only people who need it for the service can reach your cloud data, and each of them is bound to confidentiality.
4. Security
We keep the measures in Annex 2 in place, and improve them as the service grows. We won't make them weaker.
5. Sub-processors
You allow us to use the sub-processors in Annex 3. We'll tell you at least 30 days before adding or replacing one; if you object for a good reason and we can't resolve it, you may stop using Gildyard and we'll delete your data. Each sub-processor is bound to data protection terms that protect your data at least as well as this agreement, and we remain responsible to you for its work.
6. Helping you
- If someone asks us to exercise their rights over your cloud data, we pass the request to you and help you answer it.
- We give you what you reasonably need for your own security, impact assessments and consultations with an authority, as far as it concerns Gildyard.
7. Personal data breaches
If we become aware of a breach that affects your cloud data, we tell you without undue delay, with what we know: what happened, which data and roughly how many people are affected, the likely consequences, and what we are doing about it. We add the rest as we learn it.
8. Deletion
Disconnecting a subscription deletes everything Gildyard holds about it, at once, and no deleted copies are kept. The exception is the activity log's lines recording who connected and disconnected it, with its name and id, which follow the activity log's retention. When the service ends for you, we delete the rest of your cloud data within 30 days. Service logs, which can contain subscription ids, age out after 30 days.
9. Showing that we comply
We give you the information you need to see that we keep to this agreement. You, or an auditor bound to confidentiality, may audit us once a year, at your cost, with 30 days' notice, in a way that doesn't put other customers' data at risk.
10. Where the data goes
Your cloud data is processed and stored in the European Union, in Azure's Spain Central region. If it ever has to leave the European Economic Area, it will only do so with safeguards the GDPR accepts, such as an adequacy decision or the European Commission's standard contractual clauses.
11. Liability and duration
Liability under this agreement follows the terms of service. This agreement lasts as long as we process your cloud data.
Annex 1. The processing
| Subject and purpose | Drawing your cloud subscriptions as a yard for the people you allow to see it, with what is failing, idle or costing money, and alerting them |
|---|---|
| Nature | Reading through Azure's read-only interfaces, storing the latest picture, showing it in the app and on TV links you create |
| Data | Subscription ids and names; resource ids, names, types, resource groups, regions, kinds and sizes or tiers; their state; activity, errors and load over the last hour; activity over the last 30 days, to tell how long a resource has been idle; this month's cost per resource; the scope of Gildyard's role assignment, which can name a management group. Personal data appears only where your people put it, for example a person's name in a resource name. The data inside your resources is never read, and tags are dropped as they arrive, never stored. |
| People concerned | Anyone whose personal data appears in those names, usually your staff and contractors |
| Special categories | None intended; please don't put them in resource names |
| How long | The picture is replaced every minute and keeps the last 300 events. A small working state (when each resource was last active, its costs) and the connection (who connected it, the scope of the grant) are kept until you disconnect. Disconnecting deletes all of it, except the activity log's lines about the subscription |
Annex 2. Security measures
- Read-only, with one exception you choose. Gildyard holds only Reader and Cost Management Reader, granted by you at the subscription or above it and labelled for your organization. It checks every 15 minutes that the grant is still there and stops when it isn't. It never changes your resources. The one exception is Do it for me, if you use it: with your own Azure sign-in, at that moment, Gildyard creates exactly those two role assignments on the subscriptions you pick, and your token is deleted within minutes.
- No client secrets. The service signs in to Azure with a managed identity trusted as a federated credential; no client secret exists in any deployed environment. Storage keys are switched off.
- Your data in one place. One private storage container in Azure's Spain Central region, reachable by the service's own identity and, for support, by the operator's own Azure account, encrypted at rest by Azure, and reached over TLS.
- Who sees what. Each yard belongs to one organization. Owners and admins decide who sees it, with four roles; membership is checked on every request, and decided by Microsoft's tenant and object ids, never by an email address. Every change lands in the organization's activity log.
- Links and sessions. TV links are random, stored only as a hash, revocable, and tied to the connection they were made for. Sessions are kept on the server under a hash of the cookie, last eight hours, and start fresh at every sign-in; the cookie is secure, HTTP-only and same-site.
- The web app. A token and an origin check on every change, a content security policy that blocks scripts from other sites, no scripts from other companies, and no framing by other sites.
- Less data. Tags and the data inside resources are never stored. For each subscription Gildyard keeps the latest picture, the last 300 events and a small working state. Logs hold no passwords, session cookies or TV link tokens, and are kept 30 days.
- Deletion. Disconnecting deletes everything about a subscription at once, with no deleted copies, except the activity log's lines about it.
- How it is built. Changes go through automated tests, a code scan and a dependency audit before they are merged, and an automated security review when they touch access, tokens or sign-in. Alerts fire when collection stops or errors rise. [Production runs in its own Azure subscription with its own app registration, apart from development; the development app registration, which also accepts a certificate on the operator's computer for local work, never reads customers' subscriptions.]
Annex 3. Sub-processors
| Sub-processor | What for | Where |
|---|---|---|
| Microsoft Ireland Operations Limited (Microsoft Azure) | Hosting the service, its storage and its logs | Spain Central region, EU |