How EspoCRM supports GDPR data subject requests
A team running customer data in a self-hosted EspoCRM has to answer access, erasure and portability requests within the GDPR's timelines, and the platform can support three of the relevant obligations: the copy of personal data under Article 15(3), erasure under Article 17(1) and the structured, machine-readable export under Article 20(1). The documented features help most with the mechanics: administrators mark personal data fields in the Entity Manager, and users with the Data Privacy permission can view and erase personal data on Accounts, Contacts, Leads and Person-type custom entities, as described in the EspoCRM data privacy docs. Whether those steps satisfy an obligation depends on configuration and process you own: which fields are marked, who holds the Data Privacy permission, how identity is verified before anyone acts, and whether the response reaches the requester in an acceptable form. The platform does not decide when erasure is lawful. Article 17(1) lists six grounds, and a legal obligation to keep certain records can override an erasure request, so the team needs a documented decision for each request. DeployOpen plans and configures these controls and prepares the evidence an assessor will ask for. It does not issue certifications or audit reports, and the GDPR requires none, so independent auditors and certification bodies remain responsible for any attestation.
The sections below set out the data mapping, the access and erasure workflow, and the parts of the stack outside the CRM. Start by listing every entity that holds personal data, including custom Person-type entities, attachments, email and the activity stream, because a request is only answered completely if each of those locations is covered. Decide in advance who receives requests, who may approve erasure and how the answer is delivered. Confirm with your legal team which retention duties apply to each record type before the first request arrives, since the platform will carry out an erase instruction exactly as configured.
Plan the boundaries of the request as well. Backups, logs and upgrade copies can hold personal data after a record is erased in the live instance, and the GDPR's obligations still apply to them. Article 32 names resilience, restoration and regular testing as security measures, so the backup and restore procedure should be tested with erasure in mind. Ask DeployOpen or your own engineers to document how long each copy persists, who can reach it and how a restored backup is re-checked against erased records. Finally, confirm the regulatory position of your hosting location with counsel, since EDPB Guidelines 05/2021 treat remote access from a third country as a transfer under Chapter V.
Mapping GDPR request rights to EspoCRM features and configuration
This table maps each GDPR request right to the EspoCRM capability that supports it and the decision that remains with the controller. Read it as a checklist of what the platform can do, what must be configured in advance, and where a lawyer or privacy lead has to decide the outcome.
| Right or condition | What EspoCRM provides | What the controller decides or confirms |
|---|---|---|
| Access copy (Article 15(3)) | Personal data on Accounts, Contacts, Leads and Person-type entities can be viewed and exported through the interface, CSV export and the REST API, subject to user permissions | Confirm which other entities, attachments, emails and logs hold the person's data, and assemble the copy from all of them in a commonly used electronic form |
| Erasure grounds (Article 17(1)) | Marked personal data fields can be erased with the erase action for users holding the Data Privacy permission | Whether one of the six grounds applies, and whether an exception such as a legal obligation to keep records applies, is a legal judgment, not a platform setting |
| Personal data field marking | Administrators flag personal data fields in the Entity Manager so the View Personal Data and erase actions know which fields to act on | Which fields count as personal data for each entity, including custom fields and free-text notes that may contain personal data |
| Data Privacy role permission | Only roles granted the Data Privacy permission can view and erase personal data, so handling can be restricted to a privacy team | Who holds the role, and whether it is separated from general administrator accounts |
| Portability (Article 20(1)) | CSV export and the REST API return structured, machine-readable records for the data subject | Portability only applies where processing is based on consent or contract and carried out by automated means, so confirm the lawful basis for each dataset first |
| Erasure coverage limits | Erase acts on the records and marked fields in EspoCRM only, not on copies elsewhere | Backups, logs, mail archives, file storage and exports held outside the live database need their own retention and deletion decisions |
Handling access, erasure and portability requests step by step
An access request asks what personal data you hold about the requester and for a copy of it. Article 15(3) of the GDPR requires the controller to provide a copy of the personal data undergoing processing, and where the request is electronic, the answer should be in a commonly used electronic form unless the person asks otherwise. In EspoCRM, locate the requester's Contact, Account, Lead or Person-type custom record, then use the View Personal Data action, which requires the Data Privacy permission on the user's role. Note that the action covers the entity types listed in the data privacy documentation, so check related records such as emails, notes and attachments by hand.
- Find all records: search by email address, name and other identifiers, including duplicates and related Accounts.
- Use the View Personal Data action: run it only from a user whose role carries the Data Privacy permission.
- Check outside EspoCRM: mailboxes, exports, shared drives and backups may hold copies that the action does not show.
- Record the request: log the receipt date, identity verification, records reviewed and the date the copy was sent.
- Decide manually: whether any exemption applies and what must be withheld to protect other people's data.
Confirm the response deadline and any extension rules with your counsel, and confirm the current EspoCRM Data Privacy permission levels in your version before you write the procedure.
An erasure request asks you to delete personal data. Article 17(1) of the GDPR lists six grounds on which erasure must happen without undue delay, including withdrawn consent, a successful objection and unlawful processing. Erasure is not automatic: you must first confirm which ground applies and whether a legal obligation, such as a tax or financial record duty, requires you to keep part of the data. In EspoCRM, the erase action is also available through the Data Privacy permission and applies to the supported entity types, so use it only after the legal decision is recorded.
- Confirm the ground: check which of the six Article 17(1) grounds applies before deleting anything.
- Check retention duties: identify records you must keep, and consider restricting them rather than erasing.
- Run the erase action: use it only from a role with the Data Privacy permission, after the decision is logged.
- Handle linked records: check whether related Accounts, opportunities or activity still reference the person.
- Log the outcome: record the grounds, the date, the records erased and any data you kept, with the reason.
Confirm with counsel how erasure interacts with your retention schedule, and test the erase action in a non-production instance before you rely on it.
A portability request asks for personal data in a structured, commonly used and machine-readable format, and for the right to transmit it to another controller. Article 20(1) of the GDPR applies only where processing is based on consent or contract and is carried out by automated means. Those conditions are a legal decision, so record which basis applies before you export anything. EspoCRM's CSV import and export functions can produce files for the relevant records, but the export scope, field selection and format must be checked against the request.
- Confirm eligibility: verify the lawful basis is consent or contract and the processing is automated.
- Select the records: export the Contact, Account and custom Person records the requester is entitled to receive.
- Check the format: confirm the file is structured and machine-readable, and includes only the requester's own data.
- Protect the transfer: send the file through a controlled channel and confirm the recipient's identity.
- Record the transfer: log what was exported, the format, the recipient and the date.
Confirm with your privacy team how to handle a direct transmission to another controller and whether the export fields you choose are complete for that purpose.
A request log is the evidence that you handled each request consistently. Keep one entry per request, linked to the data subject, with the request type, dates, identity checks, the decisions taken and who made them. The GDPR's accountability principle means you should be able to show what you did, so the log should cover the decisions that EspoCRM cannot make for you. Use an EspoCRM record or a separate register, but avoid storing excess personal data in the log itself.
- Log each request: capture the type, receipt date, identity verification and the responsible person.
- Record actions: note each EspoCRM action taken, such as the View Personal Data action or the erase action.
- Record the decision: state the legal basis, any exemption applied and the reason for any refusal.
- Set a review step: require a second person to approve erasure and refusals.
- Keep the log itself under control: decide how long log entries are kept, and align that with your retention policy.
Confirm with counsel which fields your regulator expects in the log and how long the log must be kept.
Several decisions sit outside any software. EspoCRM can show and delete records, but it cannot tell you whether a request is valid, whether an exemption applies, whether a record is needed for a legal claim or whether a backup copy must be altered. The data privacy documentation covers only the entity types it lists, so other systems that hold the same person's data need their own process. Treat the EspoCRM actions as steps inside a manual procedure owned by your privacy and legal team.
- Validity and identity: the decision to accept a request and verify identity is a human judgment.
- Exemptions and legal claims: decide case by case whether any exemption or retained evidence applies.
- Other systems: map where else the person's data sits, including email, support tools and reporting databases.
- Backups and logs: agree a documented position on how backups and audit logs are handled.
- Deadlines: set internal targets and confirm the statutory period with counsel.
Before relying on the procedure, walk through one test request end to end with your privacy lead and document the result.
What EspoCRM evidence you can keep for a data request
A data subject request is only defensible if you can show what you received, what you searched, what you changed and when. In a self-hosted EspoCRM, that evidence is spread across configuration, permissions, consent records, exports and your own request log, so each piece needs an owner and a retention plan.
Marked field configuration
Export or screenshot the Entity Manager settings that show which fields are flagged as personal data on Accounts, Contacts, Leads and any Person-type custom entities. Keep a dated copy each time the field list changes, because an erasure can only be shown to be complete against the fields that were marked at the time. Ask the administrator to confirm that custom fields added later were reviewed as well.
Role permission snapshots
Record which roles hold the Data Privacy permission and who is assigned to them. Only users with that permission can view and erase personal data, so a dated export of role assignments answers the question of who was able to act on a request. Store the export outside the CRM so an administrator cannot quietly edit the record of their own access.
Double opt-in consent records
For leads captured through forms, keep the confirmation trail that shows consent was given, including the timestamp and the confirmation step. When a data subject asks what you hold about their consent, or withdraws it, this record ties the lead to the lawful basis you relied on. Confirm with your team exactly which fields store this evidence and whether they are included in exports.
Export files as response copies
Store each export produced for an access or portability request with its file name, generation date and the record IDs it covers. Article 15(3) expects a copy in a commonly used electronic form, and Article 20 expects a structured, machine-readable format for portability. Check that the export contains the related activity and attachments you hold, not only the core record.
Request log with a fixed owner
Keep a request register that records the requester identity check, the request date, the actions taken, the person who acted and the date each action was completed. Hold it in a separate system or a write-once store rather than in EspoCRM, since the CRM records being changed are the subject of the request. Link each entry to the audit and auth log exports for the same period.
Immutable storage and actor linkage
Tie every action to a named user account and a timestamp by using individual admin accounts, not shared logins, and by copying evidence to storage that users with CRM access cannot overwrite. Hash exported files and record the hash in the request log. Confirm your backup retention before relying on any copy, because backups and logs may still hold personal data after an erasure in the live system.
What backups, logs and mailboxes still hold after an erasure
Erasing a person's data in the live EspoCRM instance does not remove every copy. The erase action clears the personal data fields on the record, but database backups, upgrade backups, the audit log, the auth log, attachments, notifications and any mail archive kept outside EspoCRM can still hold the same values. Under Article 17 the controller must erase without undue delay, so the erasure process has to cover these stores too, or the team has to document why it cannot and what limits access to them in the meantime.
Start by listing every place the person's data may sit: the database and its scheduled backups, the upgrade backups that EspoCRM keeps when you upgrade, the stream and Audit Log entries, the auth log, uploaded attachments and their file storage, notifications, and the mailboxes that carry the email history. For each store, decide whether to purge the data, restrict access, or accept retention with a stated reason. Then compare those decisions against the cleanup periods for deleted records, attachments, notifications, logs and upgrade backups in your instance, and confirm each value in your own environment, because the defaults may delete evidence sooner or later than your policy expects.
Backups need a written rule. Restoring an old backup can bring erased records back into the live instance, so the procedure should say how a restore is followed by a re-run of the erasure for requests logged after the backup date. Confirm with your backup administrator how long backups are kept, whether individual records can be removed from them, and who approves a restore. Record the outcome in the request file so that an auditor or supervisory authority can see what was erased, what remained, and why.
What EspoCRM does not cover for GDPR compliance
EspoCRM can mark personal data, show and erase it, and export records, but it does not make the legal decisions behind a request. The cards below cover what stays with your organization, your processes and your infrastructure, and what to settle before the first request arrives.
Lawful basis and erasure grounds
EspoCRM does not decide whether processing has a lawful basis or which Article 17(1) ground applies to a request. Someone in your organization must record the basis for each data category and decide whether an erasure request is valid, partly valid or must be refused. The erase action only executes that decision. Check that consent records, contracts and legal holds are documented outside the system before anyone clicks erase.
Identity verification of requesters
The platform does not verify who is asking for access, portability or erasure. A request arriving by email may come from someone impersonating the data subject, and a wrong erase or export can cause harm of its own. Define how you confirm identity, what you ask for, and how you record that check. Agree this procedure with your legal and privacy team before go-live.
Request deadlines and case handling
EspoCRM has no built-in request queue with response deadlines, acknowledgments or extension tracking. You need a register of incoming requests, an owner for each, and a way to show when the response was sent. Decide whether that lives in a ticketing tool, a spreadsheet or a separate system, and confirm that the register itself is protected and retained appropriately.
Erasure in backups and logs
Erasing a record in the live CRM does not remove copies in backups, upgrade backups, attachments in file storage or audit history. Document which of these hold personal data, how long each is kept, and whether restoring an old backup could reintroduce erased records. Your backup policy and retention settings must match what you tell data subjects and what you can actually delete.
Processing outside the CRM
Personal data often also sits in mailboxes, spreadsheets, marketing tools, helpdesk systems and exports downloaded to laptops. An erasure inside EspoCRM will not reach those copies. Map every system that receives CRM data, including integrations and webhooks, and include them in your request procedure so each copy is found, exported or erased.
Transfer assessment for hosting and support
Self-hosting keeps data in your chosen infrastructure, but it does not settle transfer questions. Storage in a cloud region outside the EEA, or remote support sessions where a third-country engineer views data on screen, can count as transfers under EDPB Guidelines 05/2021. Assess where the servers, backups and support access sit, and which Chapter V mechanism covers each one.
Custom entities without Person type
The data privacy tools apply to Accounts, Contacts, Leads and Person-type custom entities. A custom entity that holds personal data but is not created as Person type will not show the View Personal Data or erase actions in the same way. Review every custom entity and field in the Entity Manager, mark personal data fields, and test a request against each entity before you rely on the process.
Configuring EspoCRM for request handling
This sequence sets up a self-hosted EspoCRM so that access, erasure and portability requests can be answered from a known set of personal data fields, a narrowly assigned role and a documented runbook. It ends with evidence that each step works on a non-production copy before anyone handles a live request.
Inventory personal data fields across entities
Start by listing every place your instance holds personal data: Accounts, Contacts, Leads, any Person-type custom entities, and the custom fields your teams added for phone numbers, addresses, dates of birth or identifiers. Record each field, the entity it sits on, the purpose it serves and whether it is needed at all. Assign an owner who signs off the list. The output is a written inventory that the admin team can check against the Entity Manager, and any field with no clear purpose is flagged for removal before you configure anything else.
Mark personal data fields in Entity Manager
In the Entity Manager, mark each inventoried field as personal data so that the View Personal Data and erase actions can find it. Work entity by entity, starting with Contacts and Leads, since these hold most requests. Check the marking on a sample record by opening the record and confirming the marked fields appear in the personal data view. Keep a change log of which fields you marked, by whom and on what date. The check is complete when every field on your inventory is marked or explicitly recorded as not personal data, and the sign-off is stored with the runbook.
Create and assign the Data Privacy role narrowly
Create a role that carries the Data Privacy permission and assign it only to the small group of staff who handle data subject requests, such as a privacy lead and one backup. Do not add it to general sales or support roles, and do not grant it to admin accounts used for daily work. Confirm in your own version how the permission scopes to each entity, since the documentation names Accounts, Contacts, Leads and Person-type custom entities. Test with a standard user account to confirm they cannot see or erase personal data. The output is a role assignment list that matches the access approval record.
Enable and verify double opt-in on lead capture
Turn on double opt-in for the lead capture forms that collect consent, then submit a test lead and confirm that the confirmation step runs and that the consent state is recorded on the lead before any marketing email goes out. Keep the test record and the confirmation message as evidence of how the form behaves. Confirm the exact configuration steps and where consent timestamps are stored in the version you run, because the feature detail may vary by release. The check is complete when a test submission shows the consent state change in the record and the evidence is saved.
Set export and audit procedures
Define how a portability or access response is produced: which role runs the export, which format is used for the copy, where the file is stored while it is reviewed, and how it is sent to the requester securely. Decide how each access and erase action is logged, and confirm which audit and action history records your version keeps and for how long. Do not assume default cleanup periods preserve evidence; check them against your retention policy. The output is a written procedure with each step assigned to a named role.
Test access and erase on a non-production copy
Restore a copy of the production instance to a separate environment and run a complete access and erase cycle on a test record that you created. Export the data, confirm the export contains the fields you expect, run the erase action, and check that marked fields are removed while records needed for legal or accounting reasons are handled as your policy directs. Then check whether the data remains in the backups and logs described in your runbook. Record each result. The check is complete when the test outcomes match the expected results in your procedure, and any gaps are fixed or documented.
Document the request handling runbook
Write a runbook that brings together the field inventory, the role list, the double opt-in evidence, the export and audit procedure and the test results. Include what the runbook says about backups, logs and copies that still hold personal data after an erase, and who decides how to answer requests in those cases. Ask your privacy counsel and your EspoCRM vendor or implementation partner to confirm each Data Privacy behavior against the version you run before the runbook is approved. The output is an approved runbook with a review date and a named owner.
Questions buyers ask before handling GDPR requests in EspoCRM
Is the open-source EspoCRM edition free to self-host?
Yes, the open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page. The software is licensed under AGPL-3.0, according to the license metadata of the espocrm/espocrm repository. The cost you carry is your own: servers or cloud accounts, the database, backups, TLS, staff time for configuration, and any partner work. The EspoCRM Cloud plans are a different product. Their published prices are 15 US dollars per user per month on Basic (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included, according to the same pricing page. Confirm the current terms before budgeting, because the licensing and hosting model determines who controls the data and the backups.
What drives the effort of configuring GDPR request handling in EspoCRM?
The effort depends on how many entities hold personal data, how many fields are personal, and how many teams need access to the privacy tools. The main configuration steps are marking personal data fields in the Entity Manager, assigning the Data Privacy permission through roles, and testing the view and erase actions on each supported entity type. Effort rises when you use custom Person-type entities, when personal data sits in attachments, notes, email or related tables, or when you need a documented procedure for each request type. Effort falls when the data model is already clean and the privacy roles are narrow. Ask any partner to split the estimate into field mapping, role design, testing, and written procedures, so each part can be checked.
Can our own team handle GDPR requests in EspoCRM without a partner?
Often yes, if you have an administrator who can work in the Entity Manager and roles, and a privacy owner who understands the request types. The EspoCRM documentation describes the built-in tools, so your team can start from the official data privacy guide. A partner is more useful when the data model is complex, when integrations copy personal data into other systems, or when you need the setup tested and documented for an audit. Decide early who signs off on each request type, because the technical steps are the smaller part of the work. Check whether your administrators also have the skills to review logs, backups and access controls.
What do staff and legal need to provide for GDPR requests?
Staff need a clear intake route, identity verification steps, and a named owner for each request. Legal or the data protection officer should confirm the lawful basis for keeping each category of data, the exceptions that can apply to erasure, and the deadlines that Article 12 sets for responding. Under Article 17(1), erasure is required without undue delay in six listed situations, including when consent is withdrawn or data is no longer necessary. Under Article 15(3), a copy of the data must be provided, and electronic requests should normally be answered electronically unless the person asks otherwise. Under Article 20(1), portability covers data provided by the person where processing is based on consent or contract and is automated. Legal should also confirm how the team records each decision as evidence.
How should backups be handled when someone asks for erasure?
Erasing a record in the live EspoCRM instance does not remove it from existing backups, snapshots, replicas or exports. Ask your team to document how long backups are kept, who can restore them, and what happens if a restore brings back an erased record. Your procedure should say whether the record is re-erased after a restore, and how that step is logged. Also check the database logs, file storage and any attachments outside the database. Article 32 names resilience, timely restoration and regular testing as example security measures, so the restore process itself belongs in the design. Confirm the retention periods with your legal team before you configure them.
What does a partner need to scope a fixed-price GDPR setup?
A fixed-price engagement needs a written scope before work starts. Prepare an inventory of entities and fields that hold personal data, the list of integrations and where they copy records, and the hosting setup, including backup and log locations. Provide the request types you must support, the staff roles that will handle them, and the evidence your auditors expect. You should also state the EspoCRM version in use, the authentication method, and whether you need the Advanced Pack. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing. DeployOpen does not publish a price list, so a quote follows from that written scope.
Does configuring EspoCRM make us compliant with the GDPR?
No. The GDPR requires no audit, attestation or certificate, and configuration alone does not establish compliance. EspoCRM can provide tools such as marking personal data fields and the View Personal Data and erase actions, but the controller remains responsible for the overall process. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Independent auditors and certification bodies do that work. Use the configuration as one part of a documented privacy program, and confirm the scope of the tools with the EspoCRM data privacy documentation before you rely on them.
How DeployOpen scopes and delivers GDPR request handling in EspoCRM
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM and data subject requests, we start from your written data inventory and request procedure, configure the CRM to match, and hand over the evidence your team needs to run access, erasure and portability requests on its own.
How we scope
- Engagements are fixed-scope, with the systems, entities and request types agreed in writing before work starts.
- The written scope lists which entities and custom Person-type records hold personal data and need field marking.
- We confirm which backups, logs and exports fall within the request procedure and which need documented handling rules.
- Quotes follow from the written scope, so ask for each item to be listed separately.
How we build
- We mark personal data fields in the Entity Manager and check View Personal Data and erase behavior on each in-scope entity.
- We design a Data Privacy role permission model so only named staff can view or erase personal data.
- We configure double opt-in evidence and export steps, then test each request type against sample records in a non-production instance.
- We document the test results and the open items for your privacy and security teams to review.
How we hand over
- You receive a runbook covering intake, identity checks, search, access copies, erasure and portability exports in EspoCRM.
- The handover documents what backups, audit logs and auth logs still hold after an erasure, and who decides on retention.
- Your team runs a supervised walkthrough of one access request and one erasure request from start to finish.
- Ownership of permissions, field markings and cleanup settings is recorded so changes stay under your control.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-checking field markings when your entities or custom fields change.
- Support can include reviewing EspoCRM upgrades for effects on personal data handling before they reach production.
- Your compliance advisers and auditors remain responsible for legal interpretation and any assessment outcome.
