How ERPNext handles GDPR data subject requests
When a controller running self-hosted ERPNext receives an access, portability or erasure request, the controller stays responsible for the request and the response. ERPNext helps with two specific tools: the Personal Data Download tool, which lets a logged-in user request their personal data, and the Personal Data Deletion tool, which randomizes personally identifiable data in user accounts, contacts, addresses, communications, leads and opportunities. Each request is recorded in its own DocType, the Personal Data Download Request or Personal Data Deletion Request, which gives you a starting point for the audit trail. Neither tool covers every DocType in your instance, so you must check which custom fields, attachments, print formats and linked records hold personal data outside those categories. DeployOpen can configure the tools, map where personal data sits in your installation and prepare evidence, but DeployOpen does not certify compliance and independent assessors judge the outcome.
The platform supports parts of three GDPR articles. Article 15(3) requires a copy of the personal data undergoing processing, and the Personal Data Download tool produces that copy as a JSON file emailed to the requester. Article 17(1) requires erasure without undue delay on defined grounds, and the Personal Data Deletion tool implements erasure by randomizing data rather than removing records. Article 20(1) gives a right to receive data in a structured, machine-readable format, and the JSON export is a candidate, but you must confirm whether it covers only data the person provided, and whether the processing is based on consent or contract and carried out by automated means. Decide in advance whether a JSON export meets that test for each data set.
The controller must still decide whether a request is valid, verify the requester's identity, decide which legal grounds apply, handle exceptions for records kept for legal reasons, and respond within the time limits. Your procedure should also cover backups, which the tools do not reach, and third-party processors that received the data. The EDPB's 2025 coordinated enforcement action on erasure, announced on 18 February 2026, identified ineffective anonymisation used in place of deletion and deletion of personal data in backups as recurring challenges, so the EDPB's findings on the right to erasure are a useful check on your process. Confirm the exact behavior of each tool against the version you run before writing it into your procedure.
Mapping GDPR request requirements to ERPNext capabilities
This table pairs each GDPR request requirement with the ERPNext tool or configuration that addresses it, and notes what the tool does not settle on its own. Read it as a checklist: a tool covers only part of a requirement, and the exception and backup rows show where your own process must fill the gap. Confirm each configuration against your ERPNext version and your legal retention rules before relying on it.
| Requirement | ERPNext capability | What you still need to confirm or decide |
|---|---|---|
| Article 15(3): copy of personal data undergoing processing | Personal Data Download tool. A logged-in user requests their data, which is emailed as a JSON file and logged in the Personal Data Download Request DocType. | Confirm the request reaches all systems holding the person's data, since the tool covers only the ERPNext records it reads. Decide how identity is verified before the email goes out. |
| Article 15(3): further copies and electronic form | Output is delivered electronically as JSON by email, which matches the commonly used electronic form the article describes. | Any fee for further copies is a policy decision for your organization, not a tool setting. Record how additional copies were handled. |
| Article 20(1): portability in a structured, machine-readable format | Personal Data Download produces JSON, a structured and machine-readable format. | The article covers only data the person provided, processed on consent or contract by automated means. The download is not scoped to that subset, so confirm what is included before sending it. |
| Article 17(1): erasure grounds | Personal Data Deletion tool randomizes personal data in user accounts, contacts, addresses, communications, leads and opportunities. | The tool does not decide whether a ground applies. Your process must record the ground, such as consent withdrawn or an successful objection, before the request is actioned. |
| Article 17 exceptions: data required by law to be kept | The deletion tool excludes data the law requires to be kept. | Identify which records your jurisdiction and accounting rules require you to keep, such as invoices and ledger entries, and confirm the tool treats them as excluded in your configuration. |
| Erasure via randomization rather than removal | Personal data is randomized, not deleted outright, in the listed DocTypes. | The EDPB's 2025 coordinated enforcement action identified ineffective anonymisation used instead of deletion as a recurring problem. Assess whether randomized values still allow re-identification in your data. |
| Erasure in backups | The tool acts on the live database, not on existing backups. | The EDPB action flagged deletion of personal data in backups as a recurring challenge. Define backup retention and restore-time erasure steps in your own procedure. |
| Request records and accountability | Personal Data Download Request and Personal Data Deletion Request DocTypes log each request. | Set who may view and act on these records, and keep evidence of the response date and the decision taken, using your own retention schedule. |
What the deletion tool anonymizes and what it leaves in place
The Personal Data Deletion tool does not erase records outright. It randomizes personally identifiable data held in user accounts, contacts, addresses, communications, leads and opportunities, and it skips data that the law requires you to keep. Every request is logged in the Personal Data Deletion Request DocType, so the log itself becomes evidence of what was processed and when. Before you run the tool, confirm with your data protection lead which fields in your instance the tool covers, because customizations, custom fields and custom DocTypes are outside its default list and keep their original values unless you handle them separately.
Randomizing identifiers is not the same as erasure in the EDPB's view. The EDPB's February 2026 report on the right to erasure names ineffective anonymisation used in place of deletion as one of its recurring findings, and the EDPB news item on the right to erasure is the natural starting point for the regulator's position. The practical risk is linkage. A randomized contact name still sits on a sales order, a purchase invoice, a delivery note or a payment entry that carries the person's address, tax ID, bank details or order history. Anyone with access to those records can often rebuild the identity, so the person may still be identifiable after the tool has run.
Plan a review of everything the tool does not touch. Check the documents that link back to the data subject, including transactions, print formats saved as PDFs, email attachments, scanned contracts, uploaded files in the File DocType and notes or comments attached to records. Decide per case whether the record must be kept for a legal obligation, such as a tax or accounting retention period, and document that decision in the request file. Confirm your retention periods with your legal and finance teams rather than assuming the tool's exclusions match them, and record the reviewer, the date and the outcome for each request.
Evidence the request log and tools produce for auditors
Each GDPR request handled through ERPNext leaves a trail in its own DocTypes, but the tool output is only part of what a supervisory authority or auditor will ask for. The cards below cover the request records, the download file, and the surrounding decisions you need to document and keep.
Personal Data Download Request record
Each download request is stored as a *Personal Data Download Request* document, which shows who asked, when, and whether the JSON file was produced and emailed. Keep this record as the proof that access was handled. Check that the requester identity matches the account the data came from, and confirm the record is not editable by the data subject or by ordinary users. Confirm exactly which fields your version stores before you rely on them as evidence.
Personal Data Deletion Request record
Each erasure is logged as a *Personal Data Deletion Request* document. For audit purposes this record should show the request date, the scope applied, and the reason for any data kept under a legal obligation. Do not treat the deletion log as a place to copy the personal data itself. Check that the log holds only what is needed to prove the action.
The emailed JSON file
The download is sent as a JSON file to the requester. Article 15(3) expects a copy in a commonly used electronic form, and Article 20 covers machine-readable portability where the basis is consent or contract. Record the file name, the send time, and the address it went to. Confirm that the email goes to a verified address and that you keep a record of the file content as it was sent, since the live data may change afterward.
Identity verification evidence
Before releasing or erasing data, record how you confirmed the requester was the data subject. Note the method used, the date, and the person who approved it. Store the evidence in a restricted location, such as a case file in your records system, and reference it from the request record rather than attaching identity documents to the ERPNext request itself. Confirm your own verification standard with your data protection lead.
Retention exceptions and reasons
When the deletion tool leaves records because the law requires them, document which records were kept, which legal obligation applies, and who decided. Tax, accounting and employment records are common examples, and your finance and legal teams should agree the list. Keep this decision note with the request so an auditor can see why a name remained in a ledger. Confirm the exceptions in writing with your legal counsel.
Backup and log handling
Erasure in the live system does not remove personal data from older backups or logs. Record how backups are handled for each request, such as the restore-time rule that re-applies erasure, or the expiry date after which copies are overwritten. The EDPB's 2026 enforcement findings name deletion in backups as a recurring problem. Document the approach and test it, and confirm the retention cycle of your backup platform.
Legal retention, backups and processor copies
The Personal Data Deletion tool does not erase everything. It randomizes personally identifiable fields on user accounts, contacts, addresses, communications, leads and opportunities, and it excludes data that a law requires you to keep. In practice, accounting ledgers, general ledger entries and tax documents such as sales and purchase invoices usually stay intact, because retention rules for financial and tax records apply to them. Your team must decide, per document type and per jurisdiction, which fields remain readable and for how long, and record that decision. Replacing personal data with random values is not the same as anonymization, and the EDPB's 2025 coordinated action flagged ineffective anonymization used in place of deletion as a recurring problem.
- Map retention to document types: List the DocTypes that hold personal data and state which ones fall under a retention obligation, the statute or rule behind each, and the period.
- Check what the tool leaves readable: Review a test request on a non-production site to confirm which linked fields still show a name, address or tax identifier on retained invoices and ledger entries.
- Restrict access to retained records: Use role permissions so that retained records are visible only to users who need them for filing or audit.
- Record the exemption: Keep a note in the Personal Data Deletion Request record, or in your register, that explains why each retained item was not erased.
- Set a review date: Retention periods end, so schedule a check that tells you when retained personal data must be erased or anonymized.
Confirm the retention periods and the legal basis for each record type with your legal or tax advisers, since they depend on your jurisdiction and sector.
Deleting a record in the live ERPNext database does not remove it from backups, database replicas, search indexes, log files or exports already sent to others. The EDPB's 2025 enforcement action on the right to erasure, announced on 18 February 2026, identified deletion of personal data in backups as one of seven recurring challenges across the 764 controllers reviewed. A workable position does not need to erase each backup on request. It needs a documented rule for how long backups persist, how restored data is treated, and how erasure is re-applied if a backup is restored.
- Document backup retention: State how long each backup set is kept, where it is stored and who can restore it.
- Plan re-erasure on restore: If a backup is restored, rerun the erasure requests logged since that backup was taken before users can access the data.
- Cover replicas and reporting copies: Include read replicas, analytics extracts and data warehouse loads, which often hold personal data outside the main database.
- Limit backup access: Restrict restore rights and encrypt backup media so that personal data in backups stays protected until it expires.
- Test the restore procedure: Run a restore on a separate environment and check that erased records do not reappear in the live site.
Ask your backup and database engineers to confirm the actual retention cycle and the restore steps, because these depend on your backup tooling and schedule.
Personal data in a self-hosted ERPNext often sits with more parties than the controller: cloud or data center operators, managed database services, email relays, backup vendors, support providers and any partner with remote access. Each of these may hold copies that your deletion tool never reaches. Under the GDPR, the controller remains responsible for ensuring that processors follow erasure instructions. Remote access from a third country, even just viewing data on a screen during support, counts as a transfer under EDPB Guidelines 05/2021, so the location of every party with access matters for both erasure and transfer compliance.
- List every processor and location: Record each hosting, backup, email and support provider, the data they hold and where it is stored or accessed from.
- Include erasure in processor contracts: Confirm that data processing agreements require the processor to erase or return data on instruction and to report completion.
- Set a deadline for propagation: Ask each processor to confirm how long it takes to apply an erasure instruction and how it handles its own backups.
- Assess transfer exposure: Where a provider is subject to third-country law, document the transfer assessment before engaging it, as the EDPB guidance recommends.
- Keep evidence of instructions: Store the instruction sent and the confirmation received for each processor against the original request.
Confirm these terms with each provider and with your privacy counsel, since the contractual wording and transfer analysis depend on the specific agreements in place.
Where ERPNext's tools stop and your process must start
The Personal Data Download and Deletion tools cover a defined set of ERPNext records, not every place personal data can sit in a self-hosted system. The cards below list the areas that fall outside that coverage, and for each one, what to confirm in your own environment before you tell a data subject their request is complete.
Custom fields and custom apps
Custom fields, custom DocTypes and third-party apps you have installed can store names, IDs, contact details or notes that the standard tools never visit. Export the schema of every custom DocType and list the fields that hold personal data, then decide whether each one needs its own anonymization step. Re-check this list after each app install or upgrade, because a new app can add personal data fields without any change to your core process.
Attachments and print outputs
Files attached to documents, scanned IDs, signed contracts and previously generated PDFs or print formats can keep personal data after the record fields are changed. Confirm where attachments are stored, whether they are removed or left in place during a deletion, and whether old print outputs or exports saved outside ERPNext still show the original values. Treat these copies as separate locations in your request procedure.
Email and communications
Emails sent from ERPNext, incoming mail linked to documents and the mailbox the system reads from can all hold personal data. Check whether your email account retains messages outside ERPNext, how long the mail server keeps them, and whether the communications records in ERPNext are the only linked copy. Your process should state which mailboxes are in scope for each request type.
Integrations with other systems
Payment gateways, bank feeds, ecommerce connectors, CRM sync and HR tools may have received or sent personal data. ERPNext can only anonymize its own records, so each connected system needs its own request handling. Build a register of every integration, its data flows and its own deletion or export method, and confirm with each vendor how they handle requests and what they retain.
Logs, error records and search indexes
Error logs, activity and access records, scheduled job output, and the search index that ERPNext builds for documents can all contain names or addresses in plain text. Confirm which log tables and files exist on your servers, how long each is kept, and whether the search index is rebuilt after an anonymization. Application logs written by the web server or reverse proxy may sit outside ERPNext entirely and need their own retention settings.
Exported files and backups
Spreadsheets, JSON downloads and reports that staff exported earlier remain on laptops, shared drives and email after a deletion in ERPNext. Backups also keep the original data until they expire. Record who exports data from ERPNext, where those files go, and how long your backups are kept, so you can explain to the data subject what remains and for how long.
Configuring the request process in self-hosted ERPNext
This sequence turns the Personal Data Download and Deletion tools into a controlled process with defined roles, tested behavior, documented legal-retention exceptions and a recorded sign-off. The result is a process a reviewer can follow and an auditor can trace from request to outcome.
Inventory personal data across DocTypes and apps
The privacy lead and an ERPNext administrator list every DocType that holds personal data, including standard DocTypes such as User, Contact, Address, Communication, Lead and Opportunity, plus any custom fields, child tables, print formats and custom apps that store names, contact details or identifiers. Record which fields the standard deletion tool covers and which fields it does not, because the tool only randomizes the categories it is built for. The step is complete when the inventory is signed off and every gap has an owner and a decision: extend the process, handle the field manually, or document why it is outside scope.
Confirm roles and request permissions
The administrator reviews who can open, view, approve and process the Personal Data Download and Personal Data Deletion Request records, and separates the person who submits a request from the person who approves its outcome where the organization requires it. Check that users without a privacy role cannot see other people's requests, and that the roles used for the tools do not grant broad access to the underlying customer or employee records. Test each role with a sample user account and keep the results. The step is complete when each role's access has been checked against the written access matrix.
Test the download and deletion tools on a copy
Restore a recent production backup to a non-production site and run a download request and a deletion request against test data that represents each category in the inventory. Open the resulting JSON file and confirm that it contains the expected records, and check the anonymized records afterward for leftover identifiers in fields the tool does not touch, such as free-text notes, attachments and linked documents. Record the test date, the ERPNext version and the results. The step is complete when the test log shows what was exported, what was randomized and what remained, and each gap has been resolved or accepted.
Define legal-retention exceptions
The privacy lead and finance or legal staff agree which records must be kept even after an erasure request, such as tax invoices, ledger entries and payroll records that the organization's own legal obligations require it to retain. The tool excludes data required by law to be kept, so this list must match what the deletion tool actually skips. Document each retention rule with the legal basis, the retention owner and the point at which the record can be erased. The step is complete when the written retention schedule has been approved and matches the test results from the previous step.
Decide on Server Scripts for custom handling
If the process needs custom logic, such as routing requests to a particular approver, blocking deletion while an open dispute exists, or adding a field to the export, decide whether to use Server Scripts. From version 15, Server Scripts are disabled by default and must be enabled deliberately through the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so confirm where the system runs before designing around them. Where scripts are used, store them in a version-controlled custom app with change review, and record who approved enabling them. The step is complete when the decision is written down and any enabled script has a reviewed, versioned source.
Set up the request review and sign-off
The privacy lead defines the review steps for each request: identity verification, confirmation of the request scope, check of retention exceptions, execution of the tool, review of the output and final sign-off with the date and approver recorded. Configure the workflow in ERPNext where possible, and keep a written checklist for steps that happen outside the system, such as identity checks by email. Confirm that every request record links to the outcome and to the approver. The step is complete when a dry-run request has passed through every stage and the sign-off trail is visible in the request records.
Document backup and restore handling
The operations lead records how backups are taken, where they are stored, how long they are kept and how a restore would interact with erasure outcomes. Erased personal data may still exist in backups, and the EDPB's 2025 coordinated enforcement action identified deletion in backups as a recurring challenge, so the organization needs a documented position on how to handle it. Confirm with the privacy lead whether a restore must re-apply completed erasures and how that is logged. The step is complete when the backup and restore procedure is approved and cross-referenced in the request process document.
Document the process and schedule a review
The privacy lead assembles the inventory, role matrix, test log, retention schedule, script decision, sign-off checklist and backup procedure into one controlled document with an owner and version number. Schedule a review after each ERPNext upgrade, after changes to custom apps, and when the data inventory changes, because the deletion tool's coverage may shift between releases. The step is complete when the document is approved, stored in a location the privacy team controls, and the review triggers are recorded.
Questions buyers ask before handling GDPR requests in ERPNext
Do the ERPNext personal data tools alone satisfy GDPR?
No. The Personal Data Download and Personal Data Deletion tools handle part of the work, but GDPR compliance also depends on your data inventory, lawful bases, retention rules, processor terms, and how you handle backups, logs, emails and files outside ERPNext. The deletion tool randomizes personal data in user accounts, contacts, addresses, communications, leads and opportunities, and it keeps data that the law requires you to retain. Each request is recorded in the Personal Data Deletion Request DocType. Your legal or privacy team must decide what each record type is for, how long it is kept, and what the response to a data subject looks like. Confirm these decisions in writing before you rely on the tools.
What does a GDPR implementation partner do, and what drives the cost?
A partner typically maps where personal data sits in your ERPNext sites, configures the download and deletion tools, documents the request process, tests both tools against a copy of production data, and sets up the records needed to show how requests were handled. Cost depends on the number of sites and apps in use, how many DocTypes and custom fields hold personal data, the state of existing customizations, how many integrations copy data to other systems, and how backups are restored. Most engagements are fixed-scope, so the quote follows a written scope that lists deliverables and timelines. Ask for the scope, the assumptions behind it, and what is excluded, including any ongoing support.
How long does configuration and testing take?
Duration depends mainly on your data inventory and customizations. A single site with standard ERPNext records and few custom fields needs much less work than a multi-company group with custom apps, scripts and connected systems that hold copies of customer records. Plan time for the inventory itself, for deciding retention rules with legal counsel, for testing download and deletion on realistic data, and for restoring a backup to confirm that a deleted record does not come back. Ask any provider for a timeline tied to the written scope, and confirm which steps depend on your own staff's availability.
What must our team provide before an engagement starts?
Your team needs to provide access to the ERPNext environments and the systems that receive copies of personal data, a list of the business processes that collect personal data, and named decision-makers from legal, privacy and IT. You also need the current retention schedule, the lawful basis for each processing activity if it exists, copies of your data processing agreements, and details of any third-country transfers. Provide a test environment with a recent backup so the team can verify deletion without touching live records. Missing inputs usually extend the timeline, so confirm the list with the provider during scoping.
Can our own staff run GDPR request handling in ERPNext internally?
Yes, many organizations do, provided they have ERPNext administrators who understand DocTypes, permissions and background jobs, and a privacy owner who makes the legal decisions. Internal teams usually handle the daily flow: verifying the requester, running the download tool, reviewing the Personal Data Download Request record, and approving deletions. The harder parts are the one-time inventory, custom app changes, backup handling and testing after upgrades. Decide who owns each step, document it, and check that the people involved can perform it without relying on a single person.
Can a GDPR implementation earn certification?
No, GDPR has no certificate that a vendor or implementer can issue, and DeployOpen does not issue audit reports, attestations or certifications. Article 42 certification is voluntary and is issued by accredited certification bodies or supervisory authorities for a limited period. What DeployOpen can do is prepare systems, configuration, procedures and evidence so that your own assessors or the relevant authority can review them. Your organization remains responsible for compliance regardless of any certification.
What should we check about backups and deleted data?
Check how long backups retain personal data and how you will handle a restore. Deleting a record in the live site does not remove it from older backups, so you need a documented position on backup retention and on what happens if a backup is restored and a deleted record reappears. The European Data Protection Board's 2025 coordinated enforcement action identified deletion of personal data in backups as one of the recurring challenges. Ask your provider how the restore procedure will re-apply deletions, and confirm the answer with your privacy team.
Why hosting location changes the request obligations
Self-hosting ERPNext in your own cloud accounts, data centers or air-gapped network keeps the personal data under your direct control, and that control is what makes the download and deletion tools practical to run. It does not, by itself, settle where the data may lawfully sit. Under the EDPB's *Guidelines 05/2021*, remote access from a third country counts as a transfer even when the person only views data on a screen for support or administration, and so does storing a cloud backup outside the EEA. A vendor engineer who troubleshoots a deletion failure from another continent can therefore create a transfer that no one logged. Map who can reach the ERPNext database, the file store and the backup targets from outside the EEA before you promise a data subject a response time.
Chapter V conditions also follow the data onward. Every transfer to a third country, including onward transfers from a processor or a backup provider, must meet a Chapter V transfer mechanism, and infringements of Articles 44 to 49 sit in the higher fine tier under Article 83(5)(c). Confirm with your counsel which mechanism covers each flow, including any support contract that gives an overseas partner access. Keep the answer in your records of processing so that an access or erasure request can be traced to every copy, not only to the primary site.
Some background is worth checking with counsel rather than assuming. The Court of Justice's 16 July 2020 judgment in *Schrems II* invalidated the Privacy Shield decision while upholding standard contractual clauses, and the EU-US Data Privacy Framework adequacy decision depends on whether the US recipient appears on the Data Privacy Framework List and on a pending appeal. Ask your counsel to confirm the current status of each transfer basis and whether any hosting provider is subject to third-country access laws that the EDPB treats as a risk.
How DeployOpen scopes and delivers GDPR request configuration
DeployOpen plans, implements, customizes, documents and supports self-hosted ERPNext inside your own infrastructure, including the personal data download and deletion tools. Each engagement starts from a written scope that maps your personal data, retention obligations and backup position before any configuration changes are made.
How we scope
- Inventory which DocTypes hold personal data across your ERPNext sites, custom apps and integrations.
- Agree in writing which records the deletion tool will randomize and which legal retention rules apply.
- Define who in your organization receives, approves and closes data subject requests and within what process.
How we build
- Configure the Personal Data Download and Personal Data Deletion tools with roles limited to the staff who handle requests.
- Test deletion against copies of your data, checking related contacts, addresses, leads and communications for remaining identifiers.
- Document how backups, logs and exported files are handled, and where your procedure needs a manual step.
How we hand over
- Deliver a written runbook covering intake, identity verification, export, deletion, exceptions and recordkeeping.
- Walk your privacy, IT and finance staff through the Personal Data Deletion Request and Download Request records.
- Provide a test log showing the scenarios run, the results observed and the open items your team must confirm.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, ERPNext upgrades and retesting after custom app changes are available as a retainer.
- Ask your legal and privacy advisers to confirm retention and transfer positions, since DeployOpen does not issue audit reports or certifications.
