Self-hosting does not make you compliant. What it does is shrink the number of parties involved, which makes the obligations you already have far easier to discharge. Here is the controller/processor distinction in plain language, and what access and erasure requests look like in practice.
With that stated plainly, there is still a real and often misunderstood point to make: where your CRM runs changes the shape of your compliance work, sometimes substantially. Most of the difficulty small businesses have with GDPR is not the principles, which are broadly sensible. It is the paperwork and the visibility problem created by having customer data spread across a dozen vendors.
Controller and processor, in plain language
GDPR splits responsibility between two roles. The controller decides what personal data gets collected and why. The processor handles that data on the controller's instructions, without deciding the purposes for itself.
If you run a business and keep a list of customers so you can sell to them and invoice them, you are the controller. That is the role with the substantive duties: having a lawful basis, telling people what you do with their data, keeping it accurate, not keeping it longer than necessary, securing it, and answering requests from the people it describes. Those duties are yours regardless of what software you use. No hosting arrangement transfers them and no vendor can absorb them.
A processor is anyone you hand that data to in order to do something with it on your behalf: a hosted CRM, an email-sending service, a support-desk tool, a cloud backup provider, an analytics platform that receives identifiable data. Each one is a separate relationship you are responsible for having set up correctly.
What each extra processor actually costs you
The obligations attached to using a processor are not onerous individually. They are onerous in aggregate, because they repeat per vendor:
- A written data processing agreement. Article 28 requires a contract with defined terms. Most vendors publish a standard DPA, so this usually means reading and retaining it rather than negotiating it — but you do have to actually do that, per vendor.
- A sub-processor chain to track. Your CRM vendor uses a hosting provider, probably a CDN, a monitoring service, maybe an email relay. Those are sub-processors, and they can change. Reputable vendors publish the list and notify you of changes, which means someone has to read those notifications.
- A transfer position. If personal data leaves the UK or EEA, you need a lawful transfer mechanism and, in many cases, an assessment of the destination.
- An entry in your record of processing, with categories of data, purposes, recipients and retention.
- A line in your privacy notice, because people are entitled to know the categories of recipient.
- A breach dependency. If the vendor is breached, your notification clock is driven by when they tell you.
Six items, times however many tools touch customer data. This is why compliance work in a small business tends to feel like admin rather than protection: most of the effort goes into documenting relationships rather than improving how data is actually handled.
How self-hosting collapses that surface
When the CRM is a plugin running inside your own WordPress install, writing to a database on your own server, the CRM vendor is not in the data path at all. There is no copy of your contacts on their infrastructure because there is no infrastructure of theirs involved in running it. You still have a processor — your web host — but you already had that one.
Concretely, Stillpoint CRM creates its own database on first load: by default a single SQLite file at wp-content/uploads/stillpoint-crm/crm.sqlite, inside a folder protected by a deny-all .htaccess rule and a blank index file. You can point it at your own MySQL or MariaDB database instead, and you can move the file outside your web root entirely by defining STILLPOINT_CRM_DATA_DIR. In every one of those configurations the data sits on hardware you already have a relationship with.
What that changes in practice: no new DPA, no sub-processor list to monitor, no transfer assessment for the CRM itself, no extra recipient category in your privacy notice, and no dependency on a vendor's breach-notification timeline for your CRM records. The licensing relationship is still a relationship — a vendor knows you are a customer and holds your billing details — but that is ordinary supplier data, not your customer database.
Data residency and why jurisdiction matters
Residency is about which country's legal system can reach your data. It matters for two distinct reasons that often get conflated.
The first is the transfer rules: moving personal data outside the UK or EEA needs a lawful basis for the transfer, and depending on the destination that can mean an adequacy decision, standard contractual clauses, or an assessment of local surveillance law. The second is quieter and arguably more practical: laws in the country where your data physically sits can create obligations for the company holding it, whatever your contract says.
Self-hosting makes both tractable in the same way — you choose the server, so you choose the jurisdiction, and you can put it in the same country as the customers whose data it holds. A German business can keep German customer records on a German host. That is not a legal argument so much as the removal of a question you would otherwise have to answer with documentation. It is also worth noting the flip side: because you chose the location, you own the consequences of choosing badly.
Access and erasure requests, mechanically
Individuals can ask what you hold about them, ask for a copy, ask you to correct it, and in many circumstances ask you to delete it. Whether the request is easy or miserable comes down to one question: do you know everywhere the data is?
Access requests
With a single self-hosted CRM the sequence is mechanical. Search the contact record. Confirm the requester's identity by a means proportionate to the sensitivity involved. Export the record and its related data — deals, notes, activity history, invoices, stored emails — as CSV or a document. Review before sending, because the copy you provide should not disclose personal data about other people, and a note reading "spoke to his colleague Sarah, she thinks the budget is fictional" is exactly the kind of thing that needs handling with care.
The part that trips people up is not the CRM. It is remembering the mailbox, the accounting system, the support inbox and the spreadsheet on somebody's laptop. Fewer systems means a shorter list to search, which is the real gain.
Erasure requests
Erasure is not unconditional. You can normally retain what you need for a legal obligation — invoices and tax records being the usual example — so a full erasure of a customer who has bought from you is often not the right answer. The practical pattern is: delete the marketing and relationship data, retain the minimum financial record you are required to keep, and record why.
Then the question everyone forgets: backups. If you delete a contact today and restore last week's database next month, you have undeleted them. There is no clever solution to this, only a defensible policy. State a backup retention period, keep it short enough to be honest, log erasure requests, and re-apply logged erasures after any restore. The important thing is that the process exists and is written down, rather than being discovered during an incident.
Retention discipline is the unglamorous half
Storage costs almost nothing now, which is precisely why data minimisation has become the principle people quietly ignore. GDPR says keep personal data no longer than necessary for the purpose. A CRM makes that easy to violate, because nothing forces you to clean up and everything encourages hoarding on the theory that a lead from 2019 might come back.
A workable approach, sized for a small business:
- Write down a retention period per category: active customers, lapsed customers, unconverted leads, and financial records. Different numbers, different reasons.
- Pick periods you will actually honour. A stated three years that you ignore is worse than a stated seven years that you enforce, because the first is a documented failure.
- Put a recurring reminder in the calendar to run the deletion. Nobody does this spontaneously.
- Prefer deleting to anonymising unless you genuinely need the aggregate, because half-anonymised records tend to remain identifiable when combined with the rest of the row.
- Collect less at the point of capture. The custom field nobody has filled in for two years is not a data asset.
None of that depends on where the CRM runs. It is just easier to execute when there is one database to run it against rather than five vendors with five different export and delete behaviours.
What this does and does not buy you
Self-hosting your CRM removes one processor from your chain, gives you a definite answer about where the data lives, puts backups and deletion under your direct control, and reduces the number of places you have to search when someone exercises a right. That is a genuine simplification of real work.
It does not give you a lawful basis, write your privacy notice, define your retention periods, secure your server, or handle a request on your behalf. Those remain yours because you are the controller, and that was true before you chose any software.
If you want the technical detail on where the database sits and how to harden it, that is on the data ownership page. What we do with data on this website — which is a separate question from what your CRM install does with yours — is set out in our privacy policy.