Data Processing Agreement

This agreement is between you, the customer (the Controller), and Community Den Ltd, registered in England and Wales under number 15654370, of 110 Market Street, Milnsbridge, Huddersfield, England, HD3 4HT (the Processor).

It forms part of the Terms of Service and takes effect when you create an account. We publish it rather than negotiating it one customer at a time, which is why it is already complete: a small supplier who answers a due-diligence questionnaire six weeks late has usually already lost the customer.

You decide what personal data goes into the service and why. We act only on your instructions. If you need this executed as a signed counterpart for your records, write to privacy@crmcity.app and we will sign one.

We process personal data only on your documented instructions, which consist of this agreement, the Terms of Service, and your use of the features of the service. Configuring a campaign, connecting a webhook or calling the API is an instruction.

We will not process the data for our own purposes. We do not sell it, we do not use it for advertising, and we do not use it to train AI models.

If we believe an instruction breaches data protection law we will tell you and may pause that processing. Where the law requires us to process data other than on your instruction, we will tell you first unless the law forbids it.

Access to personal data is limited to people who need it to run or support the service. They are bound by confidentiality obligations that survive the end of their engagement, and they receive access on the principle of least privilege.

We implement the technical and organisational measures in Annex 2, which meet Article 32. Those measures may change as the service develops, but we will not reduce the overall level of protection.

You give general authorisation for us to engage the sub-processors listed in Annex 3. Each is bound by written terms imposing obligations no less protective than these, and we remain fully liable to you for their performance.

We will give you at least 30 days’ notice before adding or replacing a sub-processor, by email to your account address. If you reasonably object on data protection grounds, tell us within those 30 days and we will try to offer an alternative; if we cannot, you may terminate the affected part of the service and we will refund any fees paid in advance for it.

If one of your contacts exercises a right, the request is yours to answer — but the service is built so that you can, without needing us:

• Access and portability — a full export of everything in an organisation, from settings or over the API, on every plan.
• Rectification — every field is editable.
• Erasure — a genuine hard delete of a contact and their associated records, guarded by a typed confirmation so it cannot happen by accident. The suppression entry for their email address deliberately survives, because deleting it is what would allow them to be emailed again.
• Objection to direct marketing — a preference centre each contact can reach by their own stable link, on any channel, plus one-click unsubscribe on every marketing email. What they choose there is enforced across the whole product, not just the channel they used.
• Consent records — an append-only consent log, so what was agreed and when is provable rather than merely stated.

Where a request still needs us, we will help you, and we will not charge for reasonable assistance. If a contact approaches us directly we will refer them to you rather than act on it ourselves.

We will notify you without undue delay, and in any event within 48 hours of becoming aware of a personal data breach affecting your data. The notification will describe what happened, the categories and approximate number of people and records affected, the likely consequences, and what we are doing about it — as far as we know it at the time, rather than waiting until we know everything.

Notifying the ICO and, where required, the affected individuals is your decision as controller. We will give you the information you need to make it, and assist with your obligations under Articles 32 to 36, including any data protection impact assessment or prior consultation.

Your CRM data is stored in the European Union (Frankfurt). Transfers from the UK to the EEA rely on UK adequacy regulations.

Where a sub-processor in Annex 3 processes personal data outside the UK or EEA, the transfer relies on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on the UK Extension to the EU-US Data Privacy Framework where that provider is certified. You instruct us to make those transfers on your behalf.

You can export everything, at any time, without asking us — which makes this clause much less frightening than it usually is.

When the agreement ends, we delete the personal data from live systems 30 days after account closure; it ages out of encrypted backups within a further 30 days. On request during those 30 days we will return an export or delete immediately. We keep only what the law requires us to keep — chiefly billing records — and the suppression list described in clause 6.

On reasonable written request, and no more than once a year unless a regulator or a breach requires otherwise, we will provide the information needed to demonstrate compliance with Article 28, including a written response to a security questionnaire. Where that is not enough, we will cooperate with an audit conducted by you or an auditor you appoint, at reasonable notice, during business hours, subject to confidentiality, and without giving access to other customers’ data.

The limitations of liability in the Terms of Service apply to this agreement. It lasts as long as we process personal data on your behalf, and the clauses that by their nature should survive do. It is governed by the law of England and Wales. Where it conflicts with the Terms of Service on data protection, this agreement wins.

Subject matter — providing the CRM City service to you.

Duration — the term of your agreement, plus the deletion periods in clause 9.

Nature and purpose — storing, organising, retrieving, analysing and transmitting personal data so you can manage relationships: keeping records, sending and receiving messages, scheduling, invoicing, and the automations you configure.

Categories of data subject — the people you choose to record. Typically your contacts, leads and customers, and depending on the modules you enable: members, donors, students, candidates, event attendees, support requesters, and the colleagues you invite as users.

Types of personal data — identity and contact details (name, email, phone, address, date of birth); professional details (employer, role); the content and metadata of communications you exchange through the service; engagement data (opens, clicks, bookings, purchases, attendance); commercial records (quotes, invoices, payments); files you attach; and anything else you choose to add through custom fields or notes.

Special category data — the service is not designed for it and we ask you not to enter it. If your use genuinely requires it (a pastoral or charitable context can), you remain responsible for the additional Article 9 conditions, and you should tell us so we can agree any further measures.

Separation of customers. Every table carries the organisation identifier and every access policy is enforced by row-level security in the database itself, keyed to a claim in the authenticated session. The database refuses to return another organisation’s rows regardless of what the application asks for, so a bug in application code cannot leak data across organisations. The few internal paths that bypass those policies re-check the organisation and the user’s role independently, so two separate layers must fail for data to cross.

Encryption. All traffic is over TLS. Data is encrypted at rest by the hosting provider.

Authentication and access control. Passwords are salted and hashed by our authentication provider and never stored by us in readable form. Two-factor authentication (TOTP) is available to every user and enforced through the whole application once enabled. Roles limit what each user can do, and field-level visibility rules can restrict who sees which data. Bot protection guards the sign-in and registration forms.

API and integration security. API keys are individual, revocable, displayed once and stored only as hashes. Every API route is rate limited. Inbound webhooks from providers are signature-verified with timing-safe comparison and rejected if unverified; outbound webhook deliveries are signed with your secret. Scheduled jobs refuse to run if their shared secret is absent, rather than running unauthenticated.

Accountability. Significant actions are recorded in an audit log with the acting user and timestamp. Consent records are append-only, because an editable consent record proves nothing.

Resilience and recovery. The database is managed by our hosting provider with automated encrypted backups and point-in-time recovery. Deletions in the interface are recoverable soft deletes; erasure for a data subject is a genuine hard delete, and is deliberately separate.

Development practice. Changes go through version control and an automated pipeline that must pass linting, type checking and tests before release. Database changes are reviewed against an automated security advisor. Errors in production are monitored.

Four of these engage only if you switch something on: Telegram if you connect a bot, Anthropic if you scan a business card, and the email and payment providers if you send mail or subscribe to a paid plan. The rest are needed to serve the application at all.

For sub-processor notices, questionnaires or a signed counterpart, write to privacy@crmcity.app. For anything else about your account or the service, write to support@crmcity.app.