GDPR extension - data retention

An extension for Store Builder and Multi-Vendor closes a GDPR compliance gap that is easy to forget. The built-in GDPR module in CS-Cart anonymizes data only for registered customers, while orders placed by guests, without creating an account, carry a full set of personal data: first name, last name, address, phone, and email. Our add-on takes over those orders, lets you anonymize them one by one or in groups, and above all introduces a retention policy that keeps watch on its own, so data older than the defined period disappears without any staff involvement. It does not stop there. Customer data rarely leaves a store through a break-in, and far more often through ordinary daily work: through the order list opened for a tracking number, through an export of the entire customer base into a spreadsheet, and through a copy of the store pulled onto a developer machine. The add-on masks personal data on the panel screens, records every reach for it in an access log, and prepares a safe database copy for work outside the server.

See how it works, in about a minute

Full walkthrough, 6 minutes

Key Features

- Guest order anonymization one by one or in groups from the list, with line items and amounts left intact for accounting.

- An automatic retention policy in a cron job, with a configurable period, status exclusions, and test mode enabled by default.

- Personal data masking on the panel screens, with full values revealed by one deliberate click and a trace left in the history.

- An access log that raises an alert when one person reads or exports an unusual amount of data, and when somebody switches the add-on off.

- An encrypted order archive in place of anonymization beyond recovery, so a sales document can still be restored for a tax office or a court.

- Database copy anonymization for development work, run from the console and protected by four independent gates.

- Clearing that reaches every place the store keeps customer data: the delivery address held in the order structure, text typed into a product option, files uploaded by the customer, gift certificates and shipment comments.

- Order reads through the REST interface recorded as well, so the data pulled by integrations is as visible as the data viewed in the panel.

Before we get to the screens, it helps to separate three things the add-on does independently of one another. The first cleans data inside the store and runs without human involvement. The second covers data on screen without touching the database. The third cleans a copy of the database away from the store, for development work. Their reaches do not overlap, and mixing them up causes the most common misunderstandings:

Diagram 1: the three mechanisms and the reach of each one

It all starts with a single setting. In the Data Retention tab you state how many years after a customer's last activity their data should be anonymized, and next to it you tick the order statuses excluded from that rule. On the screenshot the period is six years, which matches the usual requirement for keeping tax documentation, and three statuses are selected: open, awaiting delivery and awaiting a call. That second field matters more than it looks, because an order with an open return or an ongoing complaint keeps its full data for as long as the case stays unresolved, even when it has formally passed the retention period:

Screenshot 1: the retention period and the statuses excluded from automatic anonymization

The automatic cleanup is deliberately narrow. It covers orders placed without an account and customer accounts, and everything beyond those two areas stays untouched. An order qualifies only once it is older than the configured threshold and its status is absent from the exclusion list:

Diagram 2: reach of the automatic cleanup and the conditions an order must meet

The second tab governs what the staff sees every day. The Mask personal data switch turns on shortening of values across the panel screens, and the list below decides which fields it covers: the mail address, the phone, the surname, the address and the payment details. A separate field points out the administrator groups covered by masking, so the support desk can work under different rules than accounting. An empty selection means everyone here, so the default setting protects the data as widely as possible:

Screenshot 2: the scope of data masking and the administrator groups

The audit tab sets when the store should react to an unusual read. The alert threshold is given in records and the time window in minutes: on the screenshot that is two hundred records within fifteen minutes, clearly above a normal working day of the support desk. Exports have their own threshold counted in occurrences, because many small exports are the usual way around a threshold counted by volume. Below sit the log retention period and the address that notifications should go to:

Screenshot 3: alert thresholds, the time window and the notification recipient

Automation comes down to three switches. The first two decide whether the scheduled job covers guest orders, registered customer accounts, or both. The third is test mode, enabled by default: a run then finds the candidates, counts them and records them in the history, but changes not a single row in the database. The first encounter with retention therefore ends with a report rather than a surprise, and the decision to switch it on for real comes only after looking at the numbers:

Screenshot 4: the scope of automatic anonymization and test mode

Before you see a masked list, it is worth telling apart two situations that look almost identical on screen. Masking covers data in the view only, while the database keeps it intact and returns it the moment the setting goes off. Anonymization overwrites the values in the database, and no setting brings them back:

Diagram 3: masking in the admin panel compared with data anonymization

This is how the order list looks with masking on, and it is the screen that most people pass by during the day. The customer column holds a first name with the surname cut to an initial, and the phone column keeps the last three digits. Orders from 110 upwards look different, because they have already been through retention: substitute values stand where the data used to be. The order number, the status, the date and the amount stay untouched, so the staff still recognises an order and does their job, only without a full set of personal data on the screen:

Screenshot 5: the order list with masked personal data

The same masking covers the customer list. The surname is cut to an initial, the mail address to the first three characters before the at sign, and the phone number to its ending. The operational columns, that is the number of orders, their value and the account status, stay fully legible, because without them the list would stop being usable. It is also visible here that the protection does not depend on whether the customer ever bought anything:

Screenshot 6: the customer list with masked contact details

The curtain is not an absolute barrier, and it was never meant to be one. Staff sometimes need the full address, so the add-on provides a separate reveal request, and every use of it leaves an entry in the log. What the reveal returns depends on the state the data is in:

Diagram 4: revealing full data and the trace it leaves behind

When the full data is genuinely needed, an item in the row menu opens it in a separate window. Every field has its own button that copies the value to the clipboard, so the staff retypes nothing by hand. At the top of the window sits a note that the preview has been recorded in the operation history together with the administrator account and the time, and right below it an explanation that the values were restored from the encrypted archive, because this order has already been through retention. The store therefore shows the full data of a person whose personal details have left the order table, and it does not lose track of who reached for them:

Screenshot 7: revealing the full personal data under control

A single order is handled in the place you know best. In the order details action menu, next to the core printing and editing items, two new ones appear: Anonymize and Show personal data. The first shows up only where it makes sense, next to a guest order that has not been processed yet. An order of a registered customer goes to the core GDPR mechanism instead, so the two tools never get in each other's way:

Screenshot 8: the add-on items in the order action menu

You are about to see an order after the operation, so it helps to know that the add-on offers two roads for old data. The first overwrites it for good. The second moves it into an encrypted archive it can be restored from, for as long as the key file exists:

Diagram 5: anonymization and archive as two roads through the same cleanup

Once the operation is done, the same order looks completely different. In the customer section the first name and the surname have given way to asterisks, the mail address has taken a neutral form with a prefix, and the phone number has been zeroed. The line items, amounts and taxes on the left stay untouched, so the document still adds up in accounting and in the sales reports. This state cannot be undone, which is why the add-on guards it with three safeguards at once: test mode, excluded statuses and a confirmation prompt:

Screenshot 9: the order after anonymization, data replaced, amounts intact

When clearing up after years, single orders are not enough. Once rows are ticked on the list, the bar at the top shows how many are selected, and the Actions menu holds an Anonymize selected item next to the core export and delete operations. One command then covers the whole selected set, and the store asks for confirmation first, because the operation cannot be undone. The same possibility works on the customer list:

Screenshot 10: anonymizing many selected orders with a single command

The GDPR management screen opens with whatever calls for a human reaction. A highlighted alert section reports that an administrator exceeded the data read threshold within the time window, together with the date, the account and the number of records read. Below stand two counters of anonymization candidates, each with a button leading straight to the matching list, and under them a button that runs the whole pass by hand, without waiting for the server schedule:

Screenshot 11: the mass read alert and the retention statistics

Further down the same screen lies the operation history, the material for an inspection. Every row says when the operation took place, which record it concerned, what action it was and what triggered it. The add-on's whole repertoire is visible side by side: anonymizing an order, moving it to the archive, clearing the source columns, previewing the full data and the mass read alert. The order number is a link, so from the history you go straight to the document the entry is about:

Screenshot 12: the history of operations on personal data

The access log measures two different things with two different units, and that distinction is deliberate. Ordinary browsing is counted in records seen within a time window, while exports are counted in runs, because the store platform does not reveal how large an exported file was:

Diagram 6: the two alert threshold measures and the notification channels

The last section answers the question that comes up most often during an inspection: who had access to the data and when. The log notes every visit to the order list, the customer list and the order details, and records with each of them the number of records the administrator actually saw. The event column also shows reveals of masked values and data exports. The IP address sits next to the account, while the session identifier is not stored in the clear, because it is an authentication credential:

Screenshot 13: the personal data access log

At the end of the retention tab sits the setting that decides the fate of the data once the storage period is over. The first mode overwrites it beyond recovery and remains the default. The second moves it into the add-on's encrypted archive and only then clears the columns in the order table. Below you give the path of the key file, which has to live outside the store directory, and the store confirms its state with a message about readiness and available versions. Without the key the archive mode refuses to work, rather than quietly falling back to overwriting:

Screenshot 14: the retention mode and the state of the archive encryption key

The archive mode rests on a single key file kept outside the store directory. As long as the key exists, data comes back in full. Once it is lost, the archive stays unreadable forever, which makes the outcome equal to plain anonymization. The operation itself is protected by its order of steps, where an order is cleared only after its copy has been read back successfully:

Diagram 7: the role of the key file and the step order that protects the data

Finally, a tool you cannot launch from the admin panel. Cleaning a database copy supports development on realistic data turned into stand-ins, and it is the only part of the add-on that works in bulk. That is exactly why it demands four independent conditions at once, and a single missing one stops the operation:

Diagram 8: the four conditions required to clean a database copy

How each feature works

Anonymizing a single guest order. An Anonymize item appears in the order details action menu, shown only for an order placed without registration and not processed yet. One click replaces the first name, the last name, both addresses, the phone numbers and the mail address with substitute values built on the same schema CS-Cart itself uses. Line items, amounts and taxes stay untouched, so the document still adds up in accounting. An order of a registered customer goes where it always went, to the core GDPR mechanism.

Bulk operations. From the order list you can select many rows at once and anonymize them with a single command from the actions menu, without opening each one separately. The same works on the customer list. For a registered account the add-on reaches for the core anonymization classes, so it covers exactly the tables and fields the store itself would cover, including address profiles and consents. When the operation runs from the schedule, that is without a logged-in administrator, the add-on switches to its own write path, because the core mechanism requires an active panel session.

The automatic retention policy. A scheduled job finds guest orders and customer accounts that have passed the retention period and anonymizes them with no staff involvement. Guest orders are grouped by mail address, and the threshold counts from the NEWEST order of that address, so a customer who returns every two years never loses their data mid-relationship. A registered account qualifies when its last order is older than the threshold, or when the customer never ordered at all. The job runs from a server schedule command or from an address opened in the panel, and both variants are ready to copy straight from the settings. An account that has never placed an order is measured by its own history, that is by its registration date and its last login, so an account created recently and yet to buy anything is never touched. The first run in a store with years of history spreads across several passes, because the size of a single batch is limited and the remaining candidates return with the next run; a run also refuses to start while another one is still going, so clicking the button in the panel during the nightly job duplicates nothing.

The retention period and excluded statuses. The period is given in years and defaults to six, which matches the usual requirement for keeping tax documentation. Next to it sits a list of statuses excluded from the rule. An order with an open return or an ongoing complaint keeps its full data for as long as the case stays unresolved, even when it has formally passed the retention period. The exclusion works both ways, so such an order is left out of bulk operations as well.

Test mode. Enabled by default and designed so that the first encounter with retention ends with a report rather than a surprise. A run in this mode finds the candidates, counts them and records them in the history, but changes not a single row in the database. That makes it possible to check on production how many customers and how many orders the policy will touch, before the decision to switch it on.

Data masking in the panel. On the order list, in the order details and on the customer list, personal data appears in a shortened form: the mail address down to its first three characters, the phone number to its last three digits, the surname to an initial, the street and the postcode to their beginning. The city and the country stay visible, because without them the list stops being usable in daily work, while on their own they identify nobody. Masking works on the view layer and never touches the database, so a masked value cannot be saved anywhere. The set of fields and the administrator groups covered by masking are configured separately, so the support desk can work under different rules than accounting. There is also one adjustable exception: orders from the last few days can show their full data, so that the person packing parcels does not have to reveal each of them separately. The window counts from the order date, an order leaves it on its own once the configured number of days has passed, and the exception is off by default, because it deliberately weakens the protection. Payment data stays masked inside that window as well.

Revealing the full data under control. Masking must not block the work, because sometimes you need to call the customer or correct a shipping address. An item in the row menu therefore opens a window with the full values and buttons that copy each of them to the clipboard. The full data does not sit in the list page source; it is fetched only by a deliberate click, and the whole thing is protected by its own permission. Every reveal leaves an entry in the history together with the administrator account and the timestamp, so it is known who reached for a particular person's data and when.

The personal data access log. The add-on records every visit to the order list, the customer list and the order details, along with the number of records the administrator actually saw. Reveals of masked values and exports of orders or customers are recorded as well. An entry holds the account, the time, the IP address and the place in the panel, while the session identifier is stored only as a hash, because it is an authentication credential. The write is failure-tolerant: a database error interrupts neither the list nor the export.

Alerts about unusual access. When one administrator exceeds the configured threshold within a rolling time window, the add-on reports it through three channels at once: an entry in the operation history, an entry in the diagnostic log and an e-mail message, provided that sending has been enabled. Exports have their own threshold counted in occurrences, because many small exports are the usual way around a threshold counted by volume. At most one alert per window and per administrator is raised, so notifications do not turn into an avalanche. Switching the add-on off is a separate event: it is recorded while the add-on is still running and is not subject to the rate limit, because every occurrence of it matters.

The encrypted order archive. A retention mode setting decides what happens to the data once the retention period is over. By default it is overwritten beyond recovery. The second mode moves it first into an encrypted table of the add-on and only then clears the columns in the order table, so a database dump no longer carries personal material while the store keeps the ability to restore the original on an authorised person's request. The archive is protected by AES-256-GCM, and the key lives in a file outside the store directory, created by a separate command run deliberately. The source columns disappear only after the encrypted copy has been confirmed to exist, to be readable and to match character for character the values that are about to go. The data preview recognises an order held in the archive and shows the decrypted values, and when the archive is unreadable it says so plainly instead of returning something arbitrary.

Anonymizing a database copy for development. A copy of the store on a developer machine is the most often overlooked route of a leak: customer data then sits outside the server, outside the backups and outside any record of processing activities. A command line tool turns such a copy into technical material that can still be worked on, but that holds nobody's name, address or phone number. Thirty-five areas are covered, reaching past accounts and orders into reviews, discussion posts, newsletter subscriptions, gift certificates, shipment comments, company and supplier data. Mail server credentials, payment gateway parameters and payment transactions are cleared separately, so no test on the copy will send a message to a real customer or touch a real payment. Run without parameters the tool prints a report only, and actual cleaning requires an explicit confirmation carrying the database name and the installation address, guarded by four independent gates.

Personal data outside the order columns. An order in CS-Cart does not fit into a single table, and that is the most common source of a false sense of compliance. Alongside the visible fields the store keeps the delivery address as a shipping structure, the text a customer typed into a product option, that is an engraving dedication or the content of a print, the files uploaded into such an option, the sender and recipient data of a gift certificate, and shipment comments. None of these places is cleared by the built-in GDPR module for a guest order, so an order that looked anonymized in the panel could still carry the customer's full name and address. Our add-on covers all of them, on every path that clears data, and files uploaded by the customer are removed from the store's disk as well. Caution is built into the scope: values of options picked from a list stay untouched, because they carry the price modifier of the line item, a gift certificate that can still be redeemed stays untouched regardless of the age of the order, and the store's own address, held in the same structure as the customer's, goes on to the invoice and the waybill. Stores that anonymized data with earlier versions of the add-on have a command line mode that closes that backlog, and run without a confirmation it only reports its scale.

Reads through the programming interface. A store usually knows who holds a panel account, yet rarely remembers how many external systems pull its orders and since when. A key issued long ago to a courier company or a wholesaler grants access to the same data as the panel, only without a single click in the interface. The access log therefore records order reads through the REST interface as well, as a separate event type and with the company taken from the integration's authentication, so in the multi-vendor edition the entry reaches the right vendor. Only reads are recorded, and an order created the same way does not count as access to data. Events of this kind are the only ones exempt from the alert threshold, because an integration pulling data every few minutes exceeds any sensible threshold by definition, and an alert that goes off daily for no reason stops being read.

Verifying the result of an operation. Anonymizing a customer account can fail quietly, because the replacement values are generated at random and the store rejects the write when it hits an address already taken by another account. The add-on therefore verifies the result of every write before it treats an account as processed: the account row, every address profile it owns and the values of custom fields are all checked. An account that fails verification is left without the marker, recorded in the history with a note about what had already been overwritten, and picked up again on the next run. Anonymization is separately held back for an account whose orders did not reach the encrypted archive first, because an order holding full personal data next to an account that can no longer identify it is the worst possible outcome. A run in which anything failed ends with an error status, so the server schedule reports it instead of treating it as done.

Operation history and accountability. Every operation on personal data leaves an entry with the date, the entity type, the action taken and the trigger source, ready to present during an inspection. The mail address lands there only as a hash, never in plain text, because a register of operations on personal data must not become one more place that stores it. In the multi-vendor edition the history is separated between vendors: each of them sees the entries about their own orders and their own customers, while the complete picture stays with the platform operator. The company stored with an entry belongs to the record the entry is about, not to the panel the operation was performed in, so a preview performed by the operator stays visible to the vendor as well and accountability works both ways.

What you set up after the installation

The add-on arrives with settings chosen so that a fresh installation changes nothing in your data until you decide otherwise. Test mode is on, mail notifications are off, and the retention period is set to six years, which corresponds to the tax record keeping obligation in most European jurisdictions. The whole configuration lives in one place, in the add-on settings, and is divided into five sections.

Data retention. Here you set the number of years since the last activity of a customer, after which personal data is to be removed, and the list of order statuses that are never to be touched. Excluding the open and the processing statuses is the usual starting point, and stores handling returns add the statuses they use for complaints. A single excluded status protects an order for as long as it remains in it, which is exactly what you want when a case is still open. The same section holds the retention mode, that is the choice between overwriting the data beyond recovery and moving it first into the encrypted archive.

Data masking. The master switch decides whether the panel screens show shortened values at all. Below it you choose the groups of data to hide, and an empty selection means all of them, which is the safe default. The city, the state and the country stay visible on purpose, because without them the order list stops being usable for daily work, while on their own they identify nobody. The third field selects the administrator groups that masking applies to, and it is worth reading its direction carefully: you select the groups that are covered, not the ones that are exempt. An empty field therefore covers everyone.

Access audit. The audit records who reached for personal data and at what scale. The read threshold, five hundred records by default, is counted within a rolling time window of fifteen minutes, and the export threshold is counted separately in occurrences, three by default. The log keeps entries for ninety days and is trimmed by the same recurring run that handles retention. Mail delivery is the third notification channel and stays disabled until you enable it and point it at an address, so an update never surprises a store with a wave of messages.

Automation. Two switches decide whether the recurring run covers guest orders, customer accounts, or both. Above them sits test mode, enabled by default, in which the run finds the candidates and writes them to the log without changing a single row. The settings also print two ready to copy items: the command for the server scheduler and the link to paste into the browser of a logged in administrator, for installations where no scheduler is available.

Diagnostic log. Detailed logging of the add-on operations is useful during the deployment and during any investigation, and can be switched off afterwards to save space in the database. The operation history of personal data is a separate thing and is kept regardless of this setting.

The recommended order of enabling the automation is worth following, because it costs one extra run and removes the whole class of unpleasant surprises. Leave test mode on, configure the schedule, let the run finish, and read the list of candidates it produced. Only when that list matches what you expected do you switch test mode off and run it again, this time for real.

Typical situations the add-on was built for

A customer asks for their data to be deleted. Somebody who ordered as a guest two years ago writes in and invokes the right to be forgotten. The administrator finds the order by the mail address, confirms the identity of the person asking, and picks the anonymization item from the order action menu. The line items, the amounts and the taxes stay where they were, so the accounting records remain complete, while the name, the address, the phone number and the mail address are replaced. The operation lands in the history together with the date and the account that performed it, which is what you present if anyone later asks how the request was handled.

Years of accumulated old orders. A store that has been running for eight years holds tens of thousands of guest orders that nobody has any reason to keep. The administrator sets the retention period, excludes the statuses that are still in play, and leaves test mode on. The first run reports how many orders and accounts would qualify today, and that number is usually the moment when the scale of the problem becomes visible. After the list has been reviewed, test mode goes off and the recurring run keeps the store tidy on its own, night after night, processing only what has newly crossed the threshold.

Seasonal staff and the full customer base on screen. Several temporary people handle orders, and each of them sees the complete data of every customer, although the work mostly needs the order number, the city and the shipment status. Masking shortens the values on the panel screens for the selected groups, leaving the lists usable. When somebody has to call a customer or correct a shipping address, an authorised person reveals the full value with one deliberate click, and that reveal is recorded together with the account and the time.

A suspicion that the customer base walked out of the door. An employee resigns and moves to a competitor, and the owner has no way to confirm or rule out that the base was copied first. With the access log running, the answer exists in the panel: who opened the lists and when, how many records they saw, how many exports they ran and from what address. The threshold raises an alert on its own, at most once per window and per person, so an hour of intensive browsing produces a few messages rather than dozens.

A database copy for an external contractor. A contractor rebuilding the shipping module needs data of realistic structure and volume, and a production dump would hand them the complete customer base. The copy sanitizer replaces the data across thirty-five areas at once, from accounts and orders through newsletter sign ups and vendor conversations to the mail server credentials and the payment gateway parameters. It runs from the command line only, on a local installation, with a marker file naming the database and an explicit confirmation typed by hand, which is four independent conditions that all have to be met before a single row changes.

A tax inspection long after the retention period. Seven years after a transaction the authorities ask for the sales documentation together with the identification of the parties, and the anonymized orders hold asterisks where the surname used to be. This is the situation the archive mode exists for. Personal data is moved into an encrypted table and the source columns are cleared only after the copy has been written, read back and compared character for character with the values that are about to disappear. The store can demonstrate that in daily work and in every database copy the data simply is not there, and still answer the request when a lawful obligation requires it.

Frequently asked questions

Does the add-on require the built in GDPR module? No, it works on its own. When the core module is active, the add-on cooperates with it and reuses the core mechanisms for registered customers, which keeps the result consistent with what the platform does by itself.

Can anonymization be undone? No. The data is overwritten with placeholder values and the original is not kept anywhere, which is exactly the point of the operation. That is why test mode exists and why every manual anonymization asks for confirmation. The archive mode is the one exception, and only for orders: they keep an encrypted copy that can be read back as long as the store holds the key file.

What happens to the order history? It stays intact. The products, the prices, the dates and the taxes are untouched, because the add-on removes the personal data of the buyer and nothing else. The order remains visible in the system and remains usable for accounting.

Why six years by default? Because in most European jurisdictions tax documentation has to be kept for five years counted from the end of the tax year, which in practice means six. If your jurisdiction says otherwise, the period is a plain setting.

Why do I not see the anonymization item in an order? Three conditions have to hold at once: the order has to be a guest order, it must not have been anonymized already, and the administrator has to hold the add-on permission. Orders of registered customers are handled through the account, using the mechanism of the platform itself.

Does masking change anything in the database? No. It works on the values passed to the template, moments before the screen is rendered. Invoices, printouts, exports and integrations keep seeing complete data, and switching the setting off restores the full view immediately.

Why is the customer edit form not masked? Because saving such a form would write the mask into the database and destroy the data for good. For the same reason masking skips the invoice printout and the picker windows.

I selected the masked administrator groups, and after reinstalling the add-on all of them are selected again. The field deliberately says who is covered rather than who is exempt, and an empty selection means everyone. The platform restores the unchecked options of such fields when an add-on is reinstalled, so with this direction a return to the defaults widens the protection instead of quietly switching it off.

Will the alerts flood my mailbox? No. At most one alert is raised per administrator and per time window. An hour of intensive browsing with a fifteen minute window produces four messages, not forty.

Why does the export have a threshold of its own, counted in occurrences? Because the platform does not report how many records went into the file, so an export cannot be measured by volume. Ten small exports are also the usual way around a threshold counted by volume, so what counts here is the repetition itself.

What if somebody simply switches the add-on off to silence the audit? They leave a trace. At the moment of switching off, the add-on writes a security alert into the operation history together with the account and the time, and the entry is created before the platform stores the new status, so it survives its own shutdown. The alert is exempt from the limit that protects the mailbox, so every occurrence is recorded separately. It is worth knowing the other side of this too: uninstalling the add-on removes its tables, so with the default configuration it leaves no trace, and the permission to manage add-ons should be treated as the permission to switch the audit off.

How does the archive differ from anonymization? Anonymization overwrites the personal data in the order table and cannot be undone. The archive first stores an encrypted copy in a separate table and only then clears the source columns. In both cases a database dump no longer holds personal data, but in the archive mode the store can restore it, given the key file.

What happens if the key file is lost? The archived data is lost with it, because without the key it cannot be decrypted. The orders themselves stay complete, that is the number, the line items, the amounts and the status, and what disappears is the ability to establish who was party to the transaction. A backup of the key is therefore mandatory and has to be kept apart from the database backups, because kept together they recreate exactly the state the archive was meant to avoid.

How does key rotation work? Keys are versioned and the file holds all of them, one per line. Running the key command again appends a new version, which encrypts from that moment on, while the older ones stay in the file for reading what was written earlier. Every record remembers the version it was encrypted with, so the file must never be trimmed to the newest line, however tidy that may look.

Can the copy sanitizer be run on production by accident? Four independent safeguards would have to fail at the same moment. It runs from the command line only, it requires a marker file whose content matches the database name, it checks that the installation address is local, and it demands a confirmation containing the database name and the address. Run without that confirmation it prints a report and changes nothing.

What does a vendor see in Multi-Vendor? Only what concerns their own company, and this covers all three listings at once: the operation history, the security alerts and the access log. It works in both directions, which tends to surprise: if the platform operator revealed the data of an order belonging to a vendor, that entry shows up in the vendor's log as well. The retention policy itself stays in the operator's hands, so a vendor has insight rather than control.

The GDPR Extension closes the most often overlooked gap in a store's GDPR compliance, the personal data in guest orders, and along the way it puts order into what happens to that data inside the panel. Manual anonymization of single orders, bulk operations, and a fully automatic retention policy form its first layer, data masking, the access log, and the alerts form the second, and the encrypted archive forms the third, the one that lets a store reconcile the duty to erase personal data with the duty to keep sales documents. Test mode and status exclusions protect against accidental data loss, everything runs alongside the built-in GDPR module with no system file changes, and the full operation history gives you peace of mind in case of an inspection.

Feel free to contact us and purchase the add-on!