Drupal for GDPR consent and data subject requests

Only after the copy has been sanitized, and the safer default is that developers never receive a raw production dump at all. Article 25(1) asks the controller to apply data protection principles such as data minimisation and pseudonymisation when deciding how processing is done and while it runs, taking into account the state of the art and the cost of implementation. A development environment is still processing, so a copy that contains real names, emails, addresses or form submissions is personal data sitting in a less controlled place. Treat the sanitized copy as the only dev data that leaves production, and document that decision as part of your processing records.

Mask any field that identifies a person directly or allows indirect identification when combined with other data. In a typical Drupal site this covers the users_field_data mail and name columns, user profile fields, addresses, phone numbers, IP and session records in sessions and watchdog, comment authors, and any custom entity holding personal details. Replace values with consistent pseudonyms so relationships still work for testing, and reset every password hash. Ask your team to inventory fields with a data classification pass before the first dump, because contributed modules and custom fields are where most missed personal data is found.

Webform submission tables usually hold the most sensitive free text on a site, so they should be truncated or excluded from the dev dump rather than masked field by field. If developers need realistic submission volumes, generate synthetic rows with the same structure. For user emails, rewrite every address to a non-routable or internal domain such as an address you control, and disable outbound mail in the dev environment so queued messages never reach a real recipient. Check that mail, Webform handler settings and integrations pointing to a CRM or email service do not still hold live credentials or endpoints.

Raw production dumps should stay in the production trust boundary, meaning the storage, backup and access controls your organization already uses for live data. They must never be placed on developer laptops, shared drives, public CI artifacts, chat attachments or object storage buckets without matching access controls. If a dump or a sanitized copy is ever moved to a cloud or provider outside the EEA, it becomes a transfer under Chapter V, and EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer. Write these rules into the runbook, and confirm with your legal team where your dev hosting actually sits.

Verification should be a scripted check that runs after sanitization and blocks release if it fails. Typical checks include searching all text columns for email patterns, phone patterns and known production domains, confirming that no user row retains an original password hash, and confirming that the Webform and watchdog tables are empty or truncated as designed. Compare row counts against the production schema so referential integrity is preserved, and record the result with the dump's identifier. Have a second person review the sanitization rules when they change, and keep the report as evidence that the control operated.

The main cost is the time to inventory personal data, write and test sanitization rules, and build the verification job. Most of that is one-time, while rule maintenance recurs whenever content types, fields or modules change. Cost rises with the number of custom entities, the number of integrations that store personal data, and the number of environments that receive dumps. DeployOpen can scope this work as part of a fixed-scope engagement, with the deliverables and timeline agreed in writing before work starts. When you request a quote, ask for the field inventory, the rule set, the verification checks and the handover runbook as separate line items.

Yes, if your team has Drupal and database skills, a current data inventory and time to maintain the rules. The work is a sequence of steps: classify the data, write rules per table and field, run the export through those rules, verify the output and restrict access to the result. The points teams most often miss are contributed module tables, revision and log tables, cached data, and backups that still hold raw data. Ask whether the people maintaining the rules will still be there after the first release, because the rules must follow every schema change. A partner is useful when the internal team lacks time or Drupal depth for the field inventory and verification.

No. Sanitization reduces risk and supports the data minimisation principle, but a copy that still contains any personal data remains subject to the GDPR, and a copy that could be re-identified from remaining fields is still personal data. Access to dev environments still needs authentication, logging and a retention limit, and Article 32 security of processing applies to them. Confirm with your data protection officer or legal counsel how your sanitized copies are classified. Sanitization also does not replace the rights handling in production, such as access and erasure requests, which must still be applied to the live system.

The main drivers are the size of your data map, the number of places personal data enters and leaves the site, and how much custom code the work touches. A site with a few content types, one login and no third-party embeds is a small job. A site with many webforms, CRM and email integrations, several languages or multiple sites in one estate has more fields to inventory, more consent flows to build and more export and erasure paths to test. Fixed-scope quotes list each of these as a line item, so ask for the inventory, the integrations in scope and the environments covered. Effort is one-time for the initial build and recurs only when new forms, embeds or data stores are added.

Duration follows scope, so the honest answer is that it depends on the data map, the integrations and how quickly your data owners can answer questions. Work usually runs in stages: data inventory, consent design, build and configuration, export and erasure testing, and handover. Delays most often come from waiting on decisions about lawful basis and retention, not from the Drupal build itself. Ask for a timeline with each stage tied to a client input, and confirm which dates depend on access to a staging environment.

Three inputs matter most. Data owners need to describe what personal data each form, content type and integration holds and how long it is kept. Legal or privacy staff need to confirm the lawful basis for each processing purpose and the wording of consent and cookie notices. Engineers need staging access with a copy of the production configuration and representative content, so export and erasure can be tested safely. Ask each partner to list these inputs in the written scope so that delays are visible early.

Yes, many teams do the Drupal configuration themselves if they have a developer who knows Drupal well and a privacy lead who owns the decisions. The parts that tend to need outside help are the data map, consistent handling of export and erasure across every store, and testing that consent records hold up under review. Be honest about capacity: this work competes with routine maintenance, and it has to be repeated when the site changes. A partner can take the build while your team keeps decision ownership.

No. A module can provide tools for data export, erasure requests and consent storage, but compliance depends on what the site collects, why, how long it keeps it, who receives it and whether the consent flow meets the regulation. The GDPR requires controllers to demonstrate consent and to make withdrawal as easy as giving it, and modules cannot decide your lawful basis or write your notices. Infrastructure location, processor contracts and third-country transfers also sit outside any module. Treat modules as components inside a documented design.

No. DeployOpen plans, builds and documents the Drupal controls, and prepares evidence such as consent records, export and erasure test results and configuration exports. It does not issue audit reports, attestations or certifications. The GDPR itself requires no certificate, and any voluntary certification under Article 42 is issued by accredited bodies or supervisory authorities. Responsibility for compliance stays with your organization, so you should confirm the remaining legal questions with your own counsel.

Most engagements are fixed-scope, so the quote follows a written scope agreed before work starts. It should name the sites, forms, integrations and environments in scope, the deliverables such as consent configuration and tested export and erasure paths, the client inputs, and the timeline. Ask what is excluded, such as legal review, hosting changes or transfer assessments. Ongoing support and testing are offered as separate retainers, so ask which items recur after handover.