Customer data in integration logs: what may be kept

A log containing names and addresses is a processing of personal data like any other. The same principles apply as for the customer account in the shop, and two of them hit integration logs directly. Personal data must be adequate, relevant and limited to what is necessary in relation to the purposes, which is data minimization (Art. 5(1)(c) GDPR). And it may be kept in a form that permits identification only as long as necessary for those purposes, which is storage limitation (Art. 5(1)(e) GDPR).

For an interface log, this means the purpose is debugging and proof that a message was delivered. Whatever does not serve that purpose does not belong in it, and whatever has served it is deleted. The GDPR also requires that, by default, only data necessary for each specific purpose is processed, and it explicitly names the amount of data collected, the extent of processing, the period of storage and accessibility (Art. 25(2) GDPR). Logging that writes the full payload by default misses this standard in its basic configuration.

Accountability comes on top: the controller must be able to demonstrate compliance with the principles (Art. 5(2) GDPR). Breaches of the Art. 5 principles fall under the upper fine bracket of up to EUR 20 million (Art. 83(5) GDPR) or, for an undertaking, up to 4 percent (Art. 83(5) GDPR) of total worldwide annual turnover of the preceding financial year, whichever is higher. That is the ceiling, not a forecast for an individual case. In day-to-day work, what counts more is that your logging can be explained and evidenced in a few sentences when a complaint or audit comes in.

Information security reaches the same result from the other side. The BSI IT-Grundschutz requires logging to comply with data protection rules and requires log data to be deleted according to a defined process (BSI IT-Grundschutz OPS.1.1.5). The same module explicitly lists misconfigured logging as a threat, where personal data is logged and stored without authorization.

For every field that should not go into the log in plain text, there are several options. They differ in whether the value can still be attributed later and who can do it. The GDPR explicitly names pseudonymization and encryption as examples of measures for the security of processing (Art. 32(1)(a) GDPR).

Pseudonymization deserves a closer look at the term. The GDPR defines it as processing after which the data can no longer be attributed to a specific person without the use of additional information, provided that information is kept separately and protected (Art. 4(5) GDPR). Pseudonymized data therefore remains personal data. The European Data Protection Board makes this clear in its guidelines on pseudonymization and gives an example that fits logs directly: if it is known that the transformation is merely a SHA-256 hash of a name, anyone with a list of names can compute the same hashes and find matches (EDPB Guidelines 01/2025).

For integration logs this leads to a simple rule. If you need a stable token, for instance to spot recurring errors for the same customer account, use a method with a secret key, such as an HMAC, and keep the key outside the logging system. The EDPB describes exactly this approach for security logs: identifiers such as IP addresses, access tokens and login credentials are transformed by a keyed cryptographic one-way function, provided they contain sufficient entropy, and removed otherwise (EDPB Guidelines 01/2025). Values with little entropy, such as postal codes or dates of birth, are therefore better dropped entirely.

The second line answers the same questions as the first: which order, when, which error, which field. Whoever needs the address for resolution opens the order in the shop or the entry in the dead-letter queue. Technically, it makes sense to implement this in one place, the logging module of the middleware, instead of in every connector separately. An allowlist per message type, a shared filter for known field names and an automated test that sends an order full of sample data and checks that none of the values appear in the log keep the rule stable through later format changes. The sample data belongs in a separate environment, as described in the article on test environments for ERP interfaces.

A single retention date for all logs is convenient and rarely fits. A success log is needed until the reconciliation between shop and ERP has confirmed that the message arrived. An error log is needed until the case is resolved, plus a follow-up period for queries. The dead-letter queue needs the payload only until the decision. The Standard Data Protection Model requires retention and deletion to be defined for log data and, as a rule, weighs at least two deletion periods (SDM module 43) against each other: the one derived from the business purpose and the one arising for functional reasons at the respective logging level. The business-based period is decisive.

The table deliberately gives no day counts. How long a follow-up period makes sense depends on how quickly queries from customer service and accounting typically arrive and how often reconciliation runs. Set the value per store, justify it in one sentence and let the system calculate the end from the event. How such a deletion concept is built across shop, ERP and accounting is described in the article on the deletion concept across system boundaries.

The verbose level deserves a rule of its own because it is the most common way full payloads slip into daily operations. Enable it only for a limited time and only for one interface, with automatic reset and a record of who activated it and when. The CWE weakness list maintained by MITRE lists writing sensitive information to log files as a weakness of its own and recommends, among other things, adjusting configurations when software moves from a debug state to production and protecting log files against unauthorized reading (MITRE CWE-532).

An objection often comes from accounting: the handover to the ERP must remain verifiable. That is true, but the proof does not need customer data. Whether a handover log counts among the other documents relevant for taxation under German tax law (Section 147(1) AO) is something to clarify with your tax advisor. Even then, document number, time, status and checksum are usually sufficient; the customer data sits in the document itself, which is kept in the ERP anyway. The GoBD process documentation then describes how this proof is produced.

When a customer wants to know which data is stored about her, the integration logs are part of the answer if they contain her data. The information includes, among other things, the envisaged storage period or, if that is not possible, the criteria used to determine it (Art. 15(1)(d) GDPR). It must be provided without undue delay and in any event within one month (Art. 12(3) GDPR) of receipt of the request; an extension is only intended in justified cases. The Standard Data Protection Model requires the logging concept to state whether and how access requests can actually be answered from the log data (SDM module 43). If you have customer data in your logs, you must be able to search them by person, not just by order number.

Erasure works the same way. If a person requests erasure of their data and one of the statutory grounds applies, the data must be erased without undue delay (Art. 17(1) GDPR). A deletion path that reaches the shop, the ERP and the CRM but skips the dead-letter queue and the central logging system is incomplete. With plain references to the order number, this effort shrinks, because the content is handled at the source and the logs only hold identifiers with short retention.

That leaves data breaches. A logging system bundles data from many applications and can itself be a target of attacks. OWASP points out that logs contain users' personal data and that attackers gather it to release it or use it as a stepping stone for further attacks (OWASP Logging Cheat Sheet). If a log with customer data leaks, that is a personal data breach which the controller notifies to the supervisory authority without undue delay and, where feasible, within 72 hours (Art. 33(1) GDPR), unless it is unlikely to result in a risk to the people concerned. A log with order numbers and error codes makes this assessment much easier than one with addresses and bank details.

The last step is easily forgotten. A new filter only protects the lines written from today onward. Whatever accumulated with full payloads in past months stays put until someone actively removes it. Schedule a separate date for this, and afterwards search for typical patterns such as IBAN formats or email addresses to check whether the data has really been cleaned up. If you are planning changes to the order handover anyway, for instance for order changes after the ERP export, switch the logging over at the same time. For your own connectors and interfaces we support you as part of API development, and when connecting your ERP and inventory system the logging rule belongs in the plan from the start.