GDPR stands for General Data Protection Regulation.
The General Data Protection Regulation is a regulation in European (EU) law on data protection and privacy for all individuals within the European Union (EU) and the European Economic Area (EEA). It also addresses the export of personal data outside the EU and EEA areas. The GDPR primarily aims to give control to individuals over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU.
The GDPR was adopted on 14th April 2016 and became enforceable beginning 25th May 2018. As the GDPR is a regulation, not a directive, it does not require national governments to pass any enabling legislation and is directly binding and applicable.
As the customer interacts with Magento’s front-end and submits his personal details, Magento front-end must also comply with GDPR. So, here are some suggestions:
Providing Privacy Settings To Customers:
The customer should have some Privacy Settings under his account to manage his personal information. Basic settings can be the following:
Personal Data:
The customer must always know and be aware of the information used by the system. He should be able to see that personal data in his account. If possible, then provide an option to the customer to download the entire data used by the system.
Anonymising Personal Data:
The customer should be able to anonymize his personal details anytime after completion of all of his orders as he might never want the system to manage his personal after a specific period.
Revoking his Privacy Policy Consent:
The customer should be able to revoke his consent anytime to feel comfortable while he would using the entire front end. If he sees any issue, he can revoke his consent anytime.
Deleting Account:
The system should allow the customer to request deleting his account from the system.
Taking Magento 2 Database Backup with GDPR compliance
With Magento 2 database, a database dump is generally created that has the entire database’s structure and data. This dump usually includes tables with customers’ personal data such as names, addresses, invoices, orders, emails, numbers, etc. Generally, when exporting a customer’s data is not needed, it is considered bad practice as the data might get stolen, lost or available to unwanted people.
To overcome this issue, N98-magerun2 provides Database Dump Tool to manage the database dump in Magento 2 through the command line.
To achieve this tool, N98-magerun2 should be installed and it can be installed through either Phar file or Composer.
Installing Phar File:
shasum -a256 n98-magerun2.phar
Installing With Composer:
composer update
Output: n98-magerun2 version 1.3.2 by netz98 GmbH
The db:dumpcommand is used to dump the project database,. It uses mysqdump:
php n98-magerun2.phar db:dump
The above command will create a file having the structure and data of the entire database.
-strip argument can be used to exclude specific tables from the dump. It can be used as:
php n98-magerun2.phar db:dump [–strip]
Tables can also be stripped directly by adding them with space. Wildcards like * and ? Can be used to strip multiple tables. That is:
php n98-magerun2.phar db:dump –strip=”customer_address* sales_invoice_*”
Pre-defined Table Groups can also be specified to strip the tables. Table groups start with @ sign and it can be used as:
php n98-magerun2.phar db:dump –strip=”@stripped”
The table groups are predefined in the config.yaml file either in the vendor/n98/magerun2/ folder or in the n98-magerun2.phar package.
@customers – Customer data (and company data from the B2B extension)
customer_address* customer_entity* customer_grid_flat customer_log customer_visitor newsletter_subscriber product_alert* vault_payment_token* wishlist*
@development – Removes logs, sessions, trade data and admin users so developers do not have to work with real customer data or admin user accounts
@admin @trade @stripped @search
@log – Log Tables
log_url log_url_info log_visitor log_visitor_info log_visitor_online report_event report_compared_product_index report_viewed_*
@search
catalogsearch_*
@sessions – Database Session Tables
core_session
@quotes – Cart (Quote) Data
quotequote_*
@sales – Sales data (orders, invoices, creditmemos etc.)
sales_order sales_order_address sales_order_aggregated_created sales_order_aggregated_updated sales_order_grid sales_order_item sales_order_payment sales_order_status_history sales_order_tax sales_order_tax_item sales_invoice sales_invoice_* sales_invoiced_* sales_shipment sales_shipment_* sales_shipping_* sales_creditmemo sales_creditmemo_* sales_recurring_* sales_refunded_* sales_payment_* enterprise_sales_* enterprise_customer_sales_* sales_bestsellers_* paypal_billing_agreement* paypal_payment_transaction paypal_settlement_report*
@admin
admin* authorization*
@trade – Current trade data (customers, orders and quotes). You usually do not want those in developer systems.
@customers @sales @quotes
@stripped
@log @sessions
Custom Table Groups:
Along with pre-defined table groups, custom table groups can also be defined. A custom table group can be defined by creating an n98-magento2.yml file inside the Magento2 project app/etc/ folder. The file should contain the following lines:
# app/etc/n98-magerun2.yaml # ... commands: N98\Magento\Command\Database\DumpCommand: table-groups: - id: table_group_name description: table group description tables: space separated list of tables # ...
So, @table_group_name can be used in -strip argument to exclude the data specified inside that particular group.
So, above is the best way to strip all of the data that’s not needed to include in the dump to make sure that the database dump is GDPR compliant.