Run your CRM under GDPR without guessing who is responsible

GDPR splits responsibility between two roles. The controller determines the purposes and means of processing. The processor processes personal data on the controller's behalf and on its documented instructions. When you use a sales CRM, you are almost always the controller and the vendor is the processor. You decided to collect prospect names and business email addresses, you chose why, and you decided how long to keep them. The vendor supplies the system that stores them. This is not a technicality. It determines who a regulator writes to, who must respond to an access request, and who must be able to justify the processing at all.

Being the controller means several duties are yours and cannot be outsourced by contract. You choose and record a lawful basis. You provide the privacy notice at the point of collection. You decide retention and delete records when the purpose ends. You handle data subject requests, decide whether exemptions apply and respond within the deadline. You run a data protection impact assessment where the processing is high risk. A vendor can give you tools that make each of these easier, and a good vendor will, but the accountability sits with you under Article 5(2) and cannot be transferred to a supplier by agreement.

The processor has its own direct obligations, and they are enforceable against the processor. It must act only on your documented instructions, secure the data under Article 32, keep staff under confidentiality obligations, manage subprocessors properly, assist you with data subject requests and breach handling, and delete or return data at the end of the service. One point deserves attention during vendor evaluation. If a vendor uses your CRM data for its own purposes, such as building its own products or marketing lists, it may be acting as a controller for that activity. Ask the question directly, and check that the contract answers it.

Every processing activity needs a lawful basis under Article 6, and there are six: consent, contract, legal obligation, vital interests, public task and legitimate interests. In a B2B sales CRM, three come up repeatedly. Contract covers processing needed to deliver something the person has asked for or to take pre-contract steps at their request. Legitimate interests often covers business development and account management, provided the balancing test genuinely holds. Consent covers activities where the law or your own risk appetite requires an unambiguous opt-in, and it must be freely given, specific, informed and as easy to withdraw as it was to give.

Legitimate interests is the basis most sales teams rely on, and it is the one most often applied loosely. It requires a documented three part test: identify the interest, show the processing is necessary for it, and balance it against the rights and reasonable expectations of the individual. Write that assessment down before you start, not after a complaint arrives. Remember also that electronic marketing is governed separately by the ePrivacy rules as implemented in each member state, so a valid Article 6 basis for storing a contact record does not by itself authorise sending that contact a marketing email today.

Two practical habits reduce risk considerably. First, keep special category data out of the CRM. Article 9 sets a much higher bar for data revealing health, religion, trade union membership, political opinions and similar categories, and free-text notes fields are where this data usually enters a CRM by accident. Train your team on what not to type. Second, set retention rules per record type and then actually enforce them. Holding a cold prospect record indefinitely because nobody deleted it is a storage limitation problem under Article 5, and it is entirely within your control to fix without vendor help.

Article 28 requires a written contract between controller and processor, usually called a data processing agreement. It must set out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subject, and the controller's rights and obligations. It must then bind the processor to a specific list of commitments: process only on documented instructions including for transfers, ensure personnel are under confidentiality obligations, implement Article 32 security measures, respect the rules on engaging subprocessors, assist with data subject requests, assist with obligations under Articles 32 to 36, delete or return data at the end, and make information available for audits.

When reviewing any vendor DPA, read for the parts that are commonly weakened. Check that subprocessor changes come with advance notice and a real opportunity to object, rather than a clause saying the list may change at any time. Check the audit clause: many vendors satisfy it by providing an independent report such as SOC 2 rather than admitting on-site auditors, which is normal and workable, but the mechanism should be stated. Check the end of service terms, including how deletion is confirmed and how long backups persist. Check that assistance with data subject requests is an obligation, not a chargeable professional services engagement.

HelloGrowthCRM makes a DPA available, and you should request and read it from sales@hellogrowthcrm.com before you load EU or UK personal data into a workspace. Alongside it, ask for the SOC 2 Type II report, which Soor LLC completed for the February to June 2025 observation window and shares under NDA. Together those two documents answer most of what Article 28 asks you to verify: the contractual commitments in the DPA, and independent evidence of the security measures in the report. Reviewing them at the same time is faster than treating security and privacy as two separate procurement exercises.

Chapter V of the GDPR restricts transfers of personal data outside the EEA unless a safeguard applies. The common routes are an adequacy decision covering the destination country, or the European Commission's 2021 Standard Contractual Clauses, which come in modules for different controller and processor combinations. For UK data, the UK GDPR uses the ICO's International Data Transfer Agreement or the Addendum to the EU clauses. Since the Schrems II judgment, using the clauses is not enough on its own. You are expected to run a transfer impact assessment considering the destination country's laws and any supplementary technical measures, such as encryption, that reduce the risk.

Subprocessors are the vendors your vendor uses, and they matter because your data reaches them. Article 28 requires prior authorisation, either specific or general, and where authorisation is general the processor must notify you of intended changes and give you the chance to object. In practice most vendors operate a published list plus a notice mechanism. HelloGrowthCRM publishes its subprocessor list at /subprocessors. Review it before signing, and check it again at renewal. A vendor that will not tell you which providers touch your data cannot support you in a transfer assessment, because you cannot assess a destination you are not permitted to know about.

For HelloGrowthCRM, customer records live in Supabase-managed Postgres on AWS, with row-level security enforcing tenant isolation at the database layer. Data is encrypted in transit with TLS and encrypted at rest, which are exactly the kind of supplementary technical measures a transfer assessment looks for. The specific hosting region for your workspace is confirmed during onboarding, so raise data residency early if your own customer contracts or sector rules constrain where data may sit. Getting that answer in writing before implementation is far easier than discovering a constraint after your team has already migrated its pipeline into the system.

GDPR gives individuals rights of access, rectification, erasure, restriction, portability and objection, plus rights concerning solely automated decision making. Controllers generally must respond within one month, extendable by two further months for complex or numerous requests, with the individual informed of the extension. As controller you decide whether a request is valid, whether an exemption applies and what to disclose. Your processor's job is to make the underlying data reachable. Practically, that means you need to be able to search across records, export what you find, correct inaccuracies and delete a person from the system without leaving orphaned fragments behind anywhere.

HelloGrowthCRM supports this operationally. Workspace admins can export contacts, deals and activity data at any time, which serves both access and portability requests and gives you a route out of the product if you ever want one. Account deletion is honoured. Role-based access control inside each workspace lets you limit who can view or change records while a request is being handled. How data rights requests are handled is documented at /legal/data-rights. Data-handling practices align with India's DPDPA, and EU, UK and California customers have equivalent access, correction and erasure rights, so the same operational routes serve several regimes at once.

Article 32 requires security appropriate to the risk, and Articles 33 and 34 govern breaches. A controller must notify its supervisory authority without undue delay and where feasible within 72 hours of becoming aware, and must tell affected individuals where the risk to their rights is high. A processor must notify the controller without undue delay, which is why the vendor's incident process directly affects whether you can meet your own deadline. HelloGrowthCRM operates a documented incident-response workflow covering detect, contain, assess, remediate and notify, and runs automated backups with point-in-time recovery to support the restoration expectations in Article 32.