Data Processing Agreement

01

The parties and what this is

This Data Processing Agreement ("DPA") forms part of the Terms of Service between AGA CRM ("Processor", "we") and the company that subscribes to AGA CRM ("Controller", "you"). It applies whenever we process personal data on your behalf, and it governs that processing in place of anything to the contrary in the Terms.

It is written to satisfy Article 28 of the UK GDPR and of Regulation (EU) 2016/679, and the equivalent obligations under the Nigeria Data Protection Act 2023 where your workspace or your customers sit there.

You do not need to sign anything to rely on it. Subscribing accepts it; if your procurement process needs a countersigned copy on your own paper, write to us and we will sign yours.

02

Who is the controller of what

The distinction decides who answers to whom, so it is worth being exact about it.

• Support data — the tickets, emails, chat messages, attachments, customer profiles, call records, notes and recordings your team handles in the CRM. You are the Controller. We are the Processor and act only on your instructions. Your customers are the data subjects, and we have no relationship with them.
• Account and billing data — your staff names and work email addresses, sign-in records, your subscription, seats and payments. We are the Controller of this, because we decide what is needed to run and bill the service. Our Privacy Policy covers it, and this DPA does not.
• Where you connect your own mailbox, telephony number or chat channel, the provider you chose remains your contract. We process what comes through it; we do not become responsible for the provider.

03

Subject matter, duration, nature and purpose

Required by Article 28(3), and in substance the description of the product.

• Subject matter: providing the AGA CRM customer-support platform.
• Duration: for as long as your subscription or trial is live, and then for the deletion window in clause 10.
• Nature and purpose: receiving support enquiries from the channels you connect, turning them into tickets, routing and escalating them, storing the conversation and the customer record, placing and recording calls where you enable it, generating reports and audit records, and — only if you switch it on — drafting summaries and suggested replies.
• Types of personal data: names, email addresses, phone numbers, postal and country data, account and order identifiers, wallet addresses, the content of messages and attachments your customers send, call audio and transcripts where enabled, and the staff account data needed to attribute actions.
• Categories of data subject: your customers and prospects, and your own staff who use the workspace.
• Special category data: we do not ask for it and the product has no field for it. Support conversations are free text, so you may end up sending it anyway. If that is foreseeable for your business, that is a reason to shorten retention in clause 10 and to say so in your own notices — not something this DPA can fix for you.

04

We process only on your instructions

We process support data only to provide the service, only as described in this DPA and the Terms, and otherwise only on your documented instruction. Using the product is itself an instruction: connecting a mailbox instructs us to read it, enabling the AI assistant instructs us to send conversations to the model named in the annex, and switching either off withdraws that instruction.

We do not sell support data, do not share it with anyone outside the annex, do not use it to advertise, and do not use it to train any model — ours or anyone else’s.

If an instruction you give us appears to breach data protection law, we will tell you rather than quietly carry it out, and we may pause that processing until it is resolved. If the law compels us to process something beyond your instructions, we will tell you before doing so unless the law forbids us from saying.

05

Confidentiality and our people

Everyone we allow near support data is bound by a written confidentiality obligation that survives their leaving, is told what they may and may not do with it, and is given access only to what their job needs. Access is removed when the role changes or ends.

06

Security measures

These are the measures in place under Article 32. They are the current state of the product, not an aspiration, and we may improve them — we will not reduce them below this.

• Encryption in transit: TLS on every connection, browser to app, app to mailbox, app to provider.
• Encryption at rest for secrets: OAuth tokens, mailbox credentials, two-factor seeds and payment keys are stored under AES-256-GCM.
• Passwords are stored only as salted bcrypt hashes. We cannot read them and cannot send one back to you.
• Per-workspace isolation: every query is scoped to your workspace, so one customer cannot reach another’s data.
• Role-based permissions, with a per-role matrix an administrator controls, and two-factor authentication available on every account.
• Sessions expire on inactivity, refresh tokens rotate on every use and a reused token is treated as theft and revoked.
• An append-only audit log of every mutating action, with sign-ins, permission changes and customer-contact views kept on a floor that workspace settings cannot shorten.
• Encrypted database backups: AES-256, taken nightly and before every deployment, with the plaintext never written to disk. Each one is verified by decrypting it in full and reading the archive back, so a backup that could not be restored is treated as a failed backup rather than discovered during an incident.
• Deletion that reaches the disk: erasing a customer or a ticket removes the attachment files from the server, not only the database rows.

07

Subprocessors

You give us general authorisation to engage the subprocessors listed in the annex below. Each of those is bound by written terms no weaker than this DPA, and we remain liable to you for what they do with your data as if we had done it ourselves.

Not everyone in that annex is a subprocessor, and the annex says which is which, because the difference decides who answers to you. A subprocessor acts on our instructions and nothing else. A payment provider also acts on its own account — it decides how to screen a transaction for fraud, what anti-money-laundering checks to run and what its regulators oblige it to keep — and it is an independent controller for that part, which no instruction from us reaches and which its own privacy notice governs. A mailbox or chat channel you connect is your provider under your own agreement; we pass data through it on your instruction and do not become responsible for it.

We would rather state that plainly than let one word cover all three. Calling every third party a subprocessor would imply we control things we do not, and the first time it mattered would be the first time you found out otherwise.

Before a new subprocessor starts processing support data we will update the annex and notify workspace administrators by email, giving you at least 30 days. If you object on reasonable data-protection grounds within that period, we will work to offer you a way of using the service without that subprocessor; if there is none, you may terminate the affected part of the subscription and we will refund the unused balance of any fees paid in advance.

Most of the annex never activates. The ones marked as switched on by you process nothing at all until an administrator connects that feature, and the payment processors never see support data in any configuration.

08

International transfers

Your workspace is hosted in Manchester, United Kingdom, so support data sits in the United Kingdom by default. The United Kingdom is covered by an EU adequacy decision, which is the basis for data reaching us from the EEA.

Some subprocessors in the annex process outside the UK and the EEA — the United States and, for one payment route, Nigeria. For those transfers we rely on the European Commission’s Standard Contractual Clauses together with the UK International Data Transfer Addendum, or on an adequacy decision where one covers the destination, and we carry out a transfer risk assessment for each.

The IDTA and the SCCs we rely on are available on request, and we will complete your own copy if your assessment needs it.

09

Our representative in the Union

We are established outside the European Union, so Article 27 requires us to designate a representative inside it, and we have not yet done so. Saying so in the agreement is the honest place for it: you are entitled to know before you rely on this DPA, not after your own regulator asks.

In the meantime supervisory authorities and data subjects reach us directly at info@agadigitaltech.com, and every time limit in this agreement — one month for a rights request, 72 hours for a breach — applies unchanged. The gap is in who can be served locally, not in what we owe.

No UK representative is required, because the United Kingdom is where we are established.

10

Helping you answer a data subject

When one of your customers exercises a right, the request is yours to answer — we hold the data, you decide. What we give you is the means to act on it without waiting for us.

• Access and portability: one button on the customer page downloads everything held about that person as a JSON file — the profile, every ticket, every message in full, the internal notes, call records and orders, with the attachment files embedded. It is the whole record, not a summary of it, and it is the format Article 20 asks for.
• Rectification: every customer field is editable by your staff.
• Erasure: an administrator can erase a customer from the customer page — their profile, every ticket, every message, the internal notes, the call records and the attachment files on the server. It is immediate and irreversible, and it writes an audit record of what was removed so you can evidence that you complied.
• Restriction and objection: you can close or hold a record, and disable the AI assistant for the whole workspace.
• If a request reaches us directly from one of your customers, we will not act on it. We will tell them to contact you, and tell you that they tried.

11

Retention, return and deletion

You set the retention. Workspace settings carry a retention period for finished tickets: once set, resolved and closed tickets older than it are deleted nightly along with their messages, notes and attachment files. It is off by default, so nothing disappears until you choose a period, and it has a 30-day floor so nothing can vanish while it is still being discussed.

When your subscription ends you keep access to export for 30 days. After that we delete the workspace and its support data. Encrypted backups are kept on a 30-day rolling window, so the last copy of a deleted workspace leaves the backup set within 30 days of the deletion and within 60 days of your subscription ending. That window is enforced by the backup job itself, not by anyone remembering to prune — it used to be an indefinite pile of files beside a promise of 60 days, which is the kind of gap worth stating now it is closed. We will delete sooner on written instruction, and confirm in writing when it is done.

We keep the audit record of an erasure after the erasure: the action, who did it, when, and the counts of what was removed. It holds none of the data that was erased, and keeping it is how either of us can later prove the request was honoured.

12

Personal data breaches

If we become aware of a breach affecting your support data we will notify you without undue delay and in any event within 72 hours of becoming aware, at the administrator addresses on your workspace.

The notification will say what happened, when, which categories and roughly how many records and data subjects are affected, what the likely consequences are, what we have done to contain it and what we recommend you do. Where we cannot establish all of that at once we will send what we have and follow up rather than wait.

Notifying your supervisory authority and your data subjects is your decision as Controller. We will give you what you need to make it and to make it on time.

13

Information and audits

We will give you the information you reasonably need to show that this DPA is being complied with, and will assist with your data protection impact assessments and any prior consultation with a supervisory authority.

You may audit our processing, once a year or after a breach affecting your data, on 30 days’ notice. We will answer a written assessment at no charge. An on-site or in-depth audit is at your cost, must be scoped so it cannot expose another customer’s data, and may be satisfied by a third-party report where one covers the question.

We are a small operation and say so plainly: there is no SOC 2 or ISO 27001 report to hand you today. The measures in clause 6 are real and verifiable in the product, and we would rather you test them than take a certificate on trust.

14

Liability, term and law

This DPA lasts as long as we process support data for you, and the clauses that have to outlive it — deletion, confidentiality, transfers — do.

It is governed by the law of England and Wales, whose courts have exclusive jurisdiction, except that nothing in it limits a data subject’s rights or a supervisory authority’s powers under applicable data protection law. Where the EU GDPR applies to a transfer, the SCCs’ own governing law and forum clauses prevail over this one.

The liability cap in the Terms of Service applies to this DPA, with the exception that it does not limit either party’s liability for a claim by a data subject or a fine imposed by a supervisory authority to the extent caused by that party’s own breach.

Questions, countersignature requests, transfer paperwork and deletion instructions all go to info@agadigitaltech.com.

15

Annex: authorised subprocessors

The complete list, generated from the same source as the one published on our security page so the two cannot disagree. “When it applies” is the condition that has to be true before the party receives anything at all, and “Role” is what it is in law for the data it gets.

Of these, 7 can touch support data and so fall within this DPA; 3 are subprocessors in the strict sense, bound by the flow-down in clause 6. The payment providers are listed for completeness and are independent controllers for part of what they do: they receive the billing contact and the amount, and never a ticket, a customer record or an attachment.