Data processing agreement

Why this page is public

A data processing agreement is usually behind a form. You ask, someone sends a document, and you read it after you have already spent an afternoon on the trial. We publish ours, including both annexes, because the questions it answers are the ones that decide whether we are usable by you at all, and the honest place for that is before you invest any time.

It also applies to free organisations. There is a common arrangement in this industry where the processing terms, the audit trail and the subject access tooling arrive three tiers up. We think an organisation that cannot afford a paid plan does not deserve worse evidence when something goes wrong, and the obligations that come with holding data about people do not scale with what you pay us.

1. Roles

For data your organisation puts into Consonas about its own contacts, customers, candidates, members or staff, you are the controller and we are the processor. For your account and billing data we are the controller, and our privacy notice covers that.

The distinction matters in practice rather than only on paper. As controller you decide what goes in, why, and for how long, and a request from an individual to see or delete their record comes to you. As processor we act on your instructions and do not decide anything about the purpose of the processing. Where somebody writes to us directly about a record held in your organisation, we will tell them to contact you and tell you that they did.

2. Subject matter, duration, nature and purpose

We process your data to provide Consonas as described on this website, for as long as your account exists plus the retention period in the terms. The nature of the processing is storage, organisation, retrieval, transmission and deletion at your instruction.

Annex 1 sets this out in the itemised form that a record of processing activities normally requires, so that you can copy it into your own documentation rather than reconstructing it from prose.

3. Categories of data and of people

You decide what goes in, so you decide the categories. In ordinary use they are names, contact details, organisation details, correspondence, notes, files, appointments and commercial information, about your customers, prospects, suppliers and staff.

Consonas is not designed for special category data such as health records, and the product does not ask for it. If you intend to hold any, tell us first so we can tell you honestly whether we are suitable. Several sector pages on this site say the same thing in the specific: the healthcare page says plainly that this is not a clinical system and that clinical records belong in one.

Free text fields will hold whatever someone types into them, which is a limitation every system of this kind shares. Nothing in the product prevents an employee writing something sensitive in a note, and no supplier can promise otherwise. What we can do is make it findable and deletable, and the subject access tooling searches free text as well as fields.

4. Our obligations

• We process your data only on your documented instructions.
• Everyone with access is under a duty of confidence, and access is limited to those who need it for a specific, recorded reason.
• We apply the technical and organisational measures described on our security page and set out in Annex 2, which forms part of this agreement.
• We assist you in responding to requests from individuals, and with your own data protection obligations, using the tooling built into the product.
• We delete or return your data at the end of the agreement, at your choice.
• We make available the information you need to demonstrate compliance, and allow audits as described in clause 10.
• We tell you if an instruction you give us appears to breach data protection law, instead of carrying it out silently.

5. What counts as an instruction

Your documented instructions are this agreement, the terms of service, the configuration choices you make inside the product, and anything else you ask us in writing. Using a feature is an instruction to process in the way that feature processes.

We will not process your data for any other purpose. That includes the purposes a supplier is most often tempted by: we do not use your data to train models, to build a benchmark, to derive statistics we publish, or to develop features by reading what customers have stored. Where we need to understand how the product is used, we use aggregate counts of product events that carry no customer content.

Where you ask us for support that requires someone here to look at a record, that is an instruction for that purpose and no other, it is limited to the people who need it, and it is recorded.

6. Sub processors

You give general authorisation for us to use the sub processors listed on our sub processors page. We will notify you by email before adding one, with enough time to object. If you object and we cannot resolve it, you may end the agreement and take a full export.

Each sub processor is bound by terms no less protective than these. The list is short and we intend to keep it short, because every name on it is someone else you have to trust on our recommendation.

7. Security measures

Set out in full on the security page and itemised in Annex 2. In summary: each organisation's data is held in its own separate database rather than a shared one; every request is authorised on the server against membership, role and permission; data is encrypted in transit and at rest; passwords are hashed with a slow algorithm and checked against breach lists; every change is recorded in an audit trail written in the same moment as the change; and point in time recovery covers the last thirty days.

The first of those is the one worth understanding, because it is the one that cannot be added later. Almost every system of this kind keeps every customer's records in one shared database and relies on each query carrying the right condition to separate them. It works, and it has one failure mode: a query written without that condition returns one customer's records to another, silently, with nothing about the request looking unusual while it happens. A database per organisation removes that failure mode rather than defending against it, and what that choice costs us is written out separately rather than left as a claim.

8. Assisting you with the rights of individuals

The product carries tooling for this on every plan, and the assistance we owe you under this agreement is largely delivered through it rather than through a request to us.

• Access. A subject access export gathers everything held about one person across records, notes, correspondence, files and the audit trail, in a form you can send on.
• Rectification. Editing is ordinary use, and the audit trail records what was changed, by whom and when, so a correction is evidenced.
• Erasure. Deletion removes the record and its associated content. The audit trail retains the fact that a deletion happened and who did it, without the deleted content, because a log you can erase is not a log.
• Objection and consent. Consent and objection are recorded against the relationship with a date and a source, and the product shows them wherever somebody might act.
• Portability. Complete export is available on every plan at any time without asking us.

Where you need something the tooling does not cover, ask us and we will help. We will not charge for assistance of this kind.

9. Breach notification

If we become aware of a personal data breach affecting your data, we will tell you without undue delay and in any event within twenty four hours of becoming aware. We will tell you what happened, what data was involved, what we are doing and what we suggest you do, and we will keep telling you as we learn more instead of waiting until we have a complete account.

Twenty four hours is shorter than the law requires of us and it is deliberate. Your own obligation to a regulator, which in the United Kingdom means the Information Commissioner's Office, runs from when you know, and a supplier who spends three days assembling a tidy narrative has spent three days of your reporting window. We would rather send you an incomplete account quickly and correct it than a complete one late.

We will also tell you about incidents that did not become breaches where they affected your service, because you will otherwise hear about them from your own users.

This clause is an undertaking rather than a description of software, and a deadline that lives only in an undertaking is one somebody has to remember at four in the morning. So there is a register behind it. Declaring an incident records what is known and which organisations are affected, stamps the moment, and counts both periods from that stamp: seventy two hours for a report to a supervisory authority where one is owed, twenty four for each of you. Telling you is recorded against the incident with who did it, when, and by what means, and any organisation still unnotified past its day appears as overdue. You will find the same record in your own audit trail, written when we tell you rather than when we declare, because an organisation reading about a breach in its audit log before anybody has written to it would be a worse failure than the one this clause is about.

Where the breach is yours rather than ours, a shared password or an export sent to a personal address, we are not the party who has to notify anyone and we will not pretend otherwise. What we will do is help you work out what was reached and when, from your own audit trail, at the speed of an incident rather than the speed of a support queue. That assistance sits under clause 8 and is not chargeable.

10. Audit

We will answer reasonable questions about our processing and provide the documentation we hold. Where an on site audit is genuinely required by law, we will cooperate, on reasonable notice, at your cost, and not more than once a year unless a regulator requires otherwise.

We do not hold SOC 2 or ISO 27001 and there is no published penetration test. We say so here as well as on the security page, because a procurement process that requires one of those is a process we do not currently pass, and finding that out at the end of an evaluation wastes more of your time than ours.

11. Transfers

Your data is held in the region you chose when creating your organisation, which is either the European Union or the United States and is fixed from that moment. Where any processing takes place outside the United Kingdom or European Economic Area, it is covered by the appropriate safeguards, which are the European Commission's standard contractual clauses and the addendum named on the sub processors page.

Organisations in the United Kingdom should choose the European Union. There is no United Kingdom region, and we would rather write that plainly than let somebody discover it after creating an organisation they cannot move.

12. Deletion and return

You can export everything at any time without asking us. On termination we delete your data in accordance with the terms of service, unless you ask us to return it first, in which case we will provide it in a machine readable form before deletion.

Because each organisation has a database of its own, deletion removes that database rather than marking rows inside a shared one. Backups age out on their own schedule, at most thirty days beyond the deletion, and we do not restore a deleted organisation from a backup afterwards.

13. Staff

Access to production systems is limited to the people who need it, is authenticated with two factors, and is recorded. Everyone with access is bound by confidentiality that survives their leaving.

We are a small company, which cuts both ways and we would rather say both halves. Fewer people have access to anything, which is a genuine security property. There are also fewer people to notice something, which is a genuine risk, and the security page treats it as one.

14. Liability and precedence

The liability provisions in the terms of service apply to this agreement. Where this agreement and the terms of service conflict on a matter of data protection, this agreement wins.

15. Changes

We will not change this agreement in a way that reduces your protection without telling account holders at least thirty days beforehand. If you do not accept a change, you may end the agreement and take a full export.

Annex 1: details of the processing

Written in the itemised form a record of processing activities normally requires, so you can lift it into your own documentation.

• Subject matter. Provision of the Consonas service to your organisation.
• Duration. The life of your account, plus thirty days retention and up to a further thirty days for backups to age out. A free organisation that nobody has signed into for twelve months is closed by us, after warnings at six, seven and eight months, and the same two clocks then run. A paying organisation is never closed for being quiet.
• Nature. Storage, organisation, structuring, retrieval, transmission, backup, restoration and deletion.
• Purpose. Providing, securing, supporting and maintaining the service on your instructions.
• Categories of individual. Determined by you. In ordinary use: your customers and prospects, their staff, your suppliers, your own staff, and anybody else you choose to record.
• Categories of data. Determined by you. In ordinary use: names, contact details, employment and organisation details, correspondence, notes, files, appointments, tasks, commercial terms, consent and objection records.
• Special category data. Not intended, not requested by the product, and not to be entered without telling us first.
• Frequency. Continuous for the duration of the agreement.
• Location. The region chosen at organisation creation: the European Union or the United States.

Annex 2: technical and organisational measures

The measures we apply. The security page describes them at greater length, including the two protections that are built and not yet enabled in production, which we name there instead of omitting.

• Separation. One database per organisation, created in the chosen region. Separation is architectural instead of a condition attached to each query.
• Authorisation. Every request authorised on the server against membership, role and permission. Nothing relies on the interface having hidden a control.
• Encryption. In transit throughout, and at rest for stored data and files.
• Credentials. Passwords hashed with a deliberately slow algorithm and checked against known breach lists at the point they are set. Two factor sign in available on every plan and requirable for a whole organisation.
• Sessions. Held server side, revocable, and visible to the account holder so an unexpected session can be ended.
• Audit trail. Written in the same transaction as the change it records, so a change cannot exist without its entry. Readable by you. No entry can be rewritten or removed by anyone, and the single exception is erasure, which blanks the values held in the entries about the erased person and leaves who acted, what they did and when standing, so that the trail cannot defeat the erasure it evidences.
• Recovery. Point in time recovery covering the last thirty days, per organisation, so a restore does not affect anybody else.
• Access control. Production access limited, authenticated with two factors, recorded, and reviewed when someone's role changes or they leave.
• Change control. Changes reviewed before release, with an automated test suite that runs on every build, including tests that exist specifically to prevent a previously found defect returning.
• Deletion. Removal of the organisation's database instead of a flag on rows, with backups ageing out on a fixed schedule.

Six words this agreement uses more narrowly than conversation does

Almost every disagreement about a document like this one turns out, on inspection, to be a disagreement about a word rather than about a position. These six are the ones that cause it here. The definitions below are the ones the clauses above are relying on, and where the ordinary sense of a word is wider or narrower, the difference is named rather than left to be discovered in an argument later.

Controller and processor are jobs, not sizes

Both words get read as descriptions of the two companies: the big one and the small one, or the one that owns the data and the one that merely holds it. Neither reading is right. The controller is whoever decides why personal data is processed and what happens to it. The processor is whoever does that processing on someone else's decision. A consultancy of one person is the controller of every record in its Consonas organisation, and we are its processor, and nothing about the relative size of the two companies alters either role. Nor does who typed the data in. If your customer filled in a form and the data arrived without a keystroke from you, you are still the controller of what arrived.

An instruction is usually a click, not a letter

Clause 5 says your documented instructions include the configuration choices you make inside the product. Read that carefully, because it means instructions rarely arrive as correspondence. Turning a feature on is one. Inviting a colleague is one. Asking us for help with a record is one, for that purpose and no other. The practical consequence is the one worth carrying away: you cannot instruct us by not knowing something, and we cannot claim an instruction from your silence.

Your data means the contents, not the account

Throughout the clauses above, your data means what your organisation has put into Consonas about other people. It does not mean your billing address, your sign in records or the email you send us asking a question. For those we are the controller and the privacy notice governs, not this agreement. The two sets are held apart on purpose, because they give different answers to every question that matters: who decides, where a request goes, how long it stays and what happens to it when you leave.

A personal data breach is wider than a hack

The legal meaning, which the Data Protection Act 2018 carries into United Kingdom law, covers accidental loss, unauthorised alteration, unauthorised disclosure and loss of access. A backup that turns out not to restore is a breach. A record sent to the wrong recipient is a breach. An organisation locked out of its own records is a breach. This matters more than a definitional point normally does, because a supplier using the narrow sense can tell you honestly that there has been no breach while an event of exactly the kind you would want to hear about has occurred. Clause 9 uses the wide sense.

Erasure is an outcome, deletion is an action

Deleting a record is something a person does in the product. Erasure is something you owe an individual, and satisfying it usually needs several deletions across several places plus one fact retained: that the erasure happened, when, and at whose hand. Clause 8 keeps that last fact deliberately. An organisation that cannot show it erased somebody has not finished erasing them, it has merely lost the evidence, and those are opposite positions in front of a regulator.

A sub processor is not every supplier we use

It means a supplier that processes your data on our behalf. Our accountant is a supplier and is not a sub processor, because your records never reach them. The distinction is what keeps the sub processors page short enough to be worth reading. A list naming every company we pay would be longer, would look more thorough, and would tell you less about who can see your records.

Where the line between controller and processor turns awkward

Clause 1 settles the split in a sentence, and in ordinary use the sentence is enough. A CRM produces a handful of situations it does not settle on its own. These are the ones that actually arise, with what we think the answer is and, where the answer is yours rather than ours, why we will not make it for you.

You hold records on behalf of your own client

An agency, a bookkeeper, a recruiter or a membership body often does. Then your client is the controller, you are the processor, and we are a sub processor to you. This agreement still works in that arrangement, but two things follow that are easy to miss. You owe your client processing terms of your own, and ours cannot serve as them, because they are between us and you. And the notice we give you before we add a sub processor is a notice you have to pass on. Your client's right to object runs through you, and it stops at you if you keep the email to yourself.

The same person is a customer and a member of staff

One human being, two reasons for holding data about them, and a record that has no opinion about the difference. You set the lawful basis and the retention for each purpose separately even though the information sits in one place. When the employment ends and the customer relationship continues, a request about the employment has to be answered about that part and not the other. We cannot make that separation for you. Purposes are a controller's property and we do not hold them.

A contact signs in to the customer portal

When someone outside your organisation signs in to see their own records, none of the roles change. They remain your data subject, you remain the controller, we remain the processor. What changes is that a person now has a route into a part of your data, which is why the security page treats the portal as a separate trust boundary rather than as another screen. Deciding who is given that route is a controller decision and the agreement leaves it entirely with you.

You imported a list you did not collect

This is the awkward one, and it is common enough to deserve saying plainly. From the moment an import finishes you are the controller of every record in it, including the records whose origin you cannot account for. Nothing in this agreement gives you cover for how they were collected, and no supplier's agreement can give you that, whatever it says on the front. What this agreement does give you is the assistance in clause 8, so that when someone in that list asks where you got their details, you can find everything you hold about them rather than guessing.

An employee leaves and their notes stay

Notes written by a colleague about your customers are your organisation's records, not theirs. Their departure is an access question rather than a data question, and clause 13 is about our staff, not yours. A departing employee who asks for their notes to be deleted is asking you, as controller, to erase your own records about other people, and that is a request you are entitled to refuse. What they can ask about is the personal data concerning themselves, which is a narrower thing than everything they typed.

Two organisations hold the same person

If your group runs more than one Consonas organisation, or if you and an unrelated customer both hold the same contact, the two records have nothing to do with each other. Each organisation has a database of its own, so deleting someone in one does nothing in the other, an erasure request has to be answered separately in each, and we cannot search across them for you because there is no across to search. That is the cost of the separation described in clause 7, and it is a cost we accept knowingly.

The individual writes to us instead of to you

Clause 1 says we point them at you. In practice that means we do not confirm whether we hold a record about them, we do not tell them which organisations use Consonas, and we tell you the same day that a request arrived. The alternative, answering them ourselves, would be us making a controller's decision using your data, which is the one thing a processor must not do however helpful it would look.

Seven clauses a processing agreement usually carries and this one does not

What a document leaves out is harder to notice than what it says, and in processing agreements the omissions are where the value sits. Each of the following appears routinely in agreements of this kind. Each is missing here on purpose, and the reason is worth more to you than the absence.

No permission to use your data in aggregated or anonymised form

The usual wording reserves a right to derive insights, benchmarks or statistics from customer data, and it is presented as harmless because the output names nobody. Our objection is not that it is dangerous. It is that it is processing for our purposes rather than yours, which clause 5 says we do not do. Where we need to understand how the product is used we count product events carrying no customer content. The cost of that position is real: we can never publish a figure about how organisations like yours actually work, and every such figure you see elsewhere came from someone's records.

No right to change the sub processor list without telling you

The common alternative is notice by publication: the list is updated on a page you are expected to check, and your right to object begins and expires without your knowing it existed. Clause 6 requires an email before the change. It costs us a mailing every time, and that cost is the entire point of the clause.

No charge for assisting with requests from individuals

Many agreements make this assistance chargeable at a professional rate, quoted in an annex, which turns a statutory right of somebody else's into a line on your invoice. Clause 8 says we will not charge. It is affordable because the tooling does most of the work, and if it were not affordable the honest answer would be to build the tooling rather than to bill you for our not having built it.

No confidentiality condition attached to a breach notification

There is no clause requiring you to keep a notification confidential, to agree wording with us, or to give us sight of what you send a regulator. Your duty is statutory and ours is contractual, and a contract does not get to sit on top of a statute. Suppliers who write such clauses know this. The clause is there to slow you down, not to bind you.

No separate liability cap for data protection

Clause 14 points at the terms of service and stops. A second, smaller cap applying only to data protection matters is common, and it is normally placed in an annex where it is least likely to be read alongside the first one. There is also no clause excluding our responsibility for the acts of a sub processor. We chose them, so they are ours.

No acceptance by silence

Clause 15 requires thirty days of notice before a change that reduces your protection. What is absent is the sentence that usually accompanies it, deeming a change agreed because you did not object within some period. Continuing to use the product is not agreement to terms you have not read, and we would rather lose a customer at a change than keep one on a technicality.

No certification we do not hold

Nothing in this document says we are aligned with, working towards, or consistent with a security standard. Clause 10 names what we do not have, and this paragraph exists because the phrase aligned with a standard carries no obligation whatever, cannot be checked, and reads to a procurement team almost exactly like the certification it is standing in for.

Four decisions this agreement deliberately leaves to you

A processing agreement reads as though everything has been settled between the parties. Four things have not been, and each is a controller's decision that we could guess at but would be wrong to default on your behalf. Two of them are difficult to revisit afterwards.

The region, which you do not get to revisit

Chosen when the organisation is created and fixed from that moment. The reason it cannot be changed later is the same reason it is worth anything at all: your organisation's database is created in that jurisdiction rather than tagged with its name. There is no move, and we would rather write that here than let you find it in a support conversation. If your organisation is in the United Kingdom, choose the European Union. If you have customers in both places, choose where your obligations are heaviest rather than where most of your customers are.

Whether special category data is going in at all

Clause 3 and Annex 1 both ask you to tell us before any goes in, and that is not a formality to be initialled. Deciding yes and telling us may get you an answer you do not want, which is that we are not suitable and you should buy something else. Deciding yes without telling us is worse than either outcome, because you will have taken on a heightened obligation with a supplier who never agreed to carry its half, and the first time anyone examines that will be the worst possible time.

How long a record about a person stays

This agreement fixes the duration of our processing, which is the life of your account plus the retention in the terms. It says nothing about how long any particular record should remain inside your organisation, and that silence is deliberate. A supplier that removed your records on a schedule of its own choosing would be deciding about purpose, and deciding about purpose is the definition of a controller. So the schedule is yours to set, and the uncomfortable part of that is that no one will remind you.

Who in your organisation can give us an instruction

Clause 5 makes configuration an instruction, which means anybody who can change a setting can instruct us on behalf of your organisation. Decide who those people are before you need to have decided. The consequence of leaving it is not dramatic and it is not nothing: a request from somebody you did not intend to speak for the organisation is still an instruction from the organisation, and your audit trail will tell you about it afterwards rather than beforehand.

Getting a clause changed to satisfy your own legal advice

Write to privacy@consonas.com. If you need something in this agreement changed to satisfy your own legal advice, ask. We would rather have the conversation than lose you at the end of a procurement process.