GDPR without myths: what to record, where, and on what basis

Acceptance of terms and conditions: proof required, separate table not required#

Acceptance of the terms and conditions is not GDPR consent for order fulfillment. Data necessary for the account, order, payment, security, and legal obligations are processed on the appropriate basis, e.g., contract performance, legal obligation, or legitimate interest. Do not force 'GDPR consent' which, if withdrawn, would prevent the fulfillment of the concluded contract.

The 'I accept the terms and conditions' checkbox is a contractual declaration. The law primarily requires that the terms and conditions be made available before the contract is concluded in a manner that allows them to be obtained, reproduced, and stored, and that the operator can demonstrate which content was in effect. No provision mandates the creation of a table with a specific name or a separate acceptance table for this reason.

However, the operator must have reliable proof that allows linking:

• who accepted;
• the date and exact time;
• the version of the terms and conditions and policy that the acceptance concerned;
• the exact text of the checkbox label;
• the context, e.g., seller registration or a specific order;
• an evidence identifier allowing the event to be reconstructed.

This can be implemented in several correct ways: in the existing account event log, order history, audit log, or a separate acceptance register. The choice of tables and names is a technical decision. The condition is that the document is versioned and immutable, and the account or order record clearly indicates this version.

Minimal variant for Artovni:

1. Each published version of the terms and conditions has an identifier, an effective date, and immutable content - e.g., a versioned PDF file or a locked revision in the CMS. A file hash can serve as additional proof.
2. An existing account creation event records the terms and conditions version identifier and the acceptance time. There is no need to copy the entire terms and conditions to each record.
3. If the checkbox text is part of an immutable version of the form or application release, it can be reconstructed from that version; it does not need to be duplicated in every record.
4. For an order, the versions of documents relevant to that transaction or a checkout snapshot are recorded. Acceptance of account terms and conditions does not substitute proof of information and conditions for a specific sale.

There is no need to record the IP address or user-agent 'just in case.' They can be added after a risk analysis and legal basis assessment, but the primary evidence is the consistent linking of the user or order, time, and immutable content version.

The mere fact that a button was disabled without checking the checkbox is not sufficient proof if the platform cannot reconstruct the event and document version. If the current data model allows this to be done reliably and immutably, it may be sufficient without a new table.

When consent is needed and how to prove it#

Consent is typical for optional marketing, non-essential cookies, and certain additional features. It must be voluntary, specific, informed, unambiguous, not pre-checked, and as easy to withdraw as to give.

Proof of consent should be available in a single controlled evidentiary source, not solely in a mailing tool without its own export and history. This can be an existing event log or a separate register; the law does not dictate the name or structure of the table. The proof should include:

• the person or account;
• the controller and the purpose;
• the channel: email, SMS, phone, push - separately if they differ in scope;
• the exact text and version of the clause;
• the time, source, and method of granting;
• the status and time of withdrawal;
• the systems to which consent was transferred.

Cookies and similar technologies#

• Technologies necessary for transmission or a service requested by the user can operate without consent.
• Analytics, advertising, personalization, and other optional technologies do not activate before consent.
• The first layer provides equally easy 'accept' and 'reject' options; the user can select categories.
• Withdrawal is constantly available and stops future operation.
• The platform records the decision identifier, the version of the panel/list of providers, categories, time, and the change in decision.
• A new provider or a new purpose requires updating the information and, if it goes beyond the granted scope, a new user decision.

Who is the data controller#

What to store and where - architecture description, not data model#

Minimization and seller access#

The seller receives only the data necessary for their own delivery, sales documentation, and after-sales service. They do not see the customer's full history, shopping carts with other sellers, operator's marketing consents, fraud scoring, or other sellers' documents.

The delivery address is not used for the seller's own marketing. After the relevant retention period ends, operational access is revoked, even if the operator retains the proof due to legal obligations or defense of claims.

Individual rights#

The platform has a single request channel and a process to identify which systems and roles the matter concerns. It generally responds within one month; for complex cases, it may extend the deadline by another two months, but it informs about this and the reasons within the first month.

Account deletion does not mean immediate erasure of all orders. The platform deletes or anonymizes data it no longer needs, and data subject to accounting, tax, DAC7, DSA, defense of claims, or incident response is blocked until the relevant deadline and not used for new purposes.

Data breaches#

The process involves detection, containment, risk assessment, evidence preservation, and decision on notification. If a breach is likely to result in a risk to the rights and freedoms of individuals, the controller notifies the President of the Personal Data Protection Office (UODO) without undue delay, where feasible within 72 hours of becoming aware of it. In case of high risk, it also informs the individuals, unless a statutory exception applies.

GDPR documents that must be practically functional#

• record of processing activities - a typical marketplace does not practically use the exemption for entities with fewer than 250 persons, as processing of accounts and orders is regular;
• privacy policy and layered clauses in specific locations;
• data processing agreements with processors and a register of processors and transfers;
• access matrix and authorizations;
• retention and deletion mechanisms;
• individual rights and breach procedures;
• risk assessment; DPIA when processing is likely to result in a high risk, e.g., extensive profiling or systematic monitoring;
• decision on whether a data protection officer is required - a marketplace does not automatically need one, but may meet statutory criteria depending on the scale and nature of monitoring.

Basis and sources: GDPR - Regulation (EU) 2016/679; Act on the Provision of Services by Electronic Means - Art. 8; UODO - Record of processing activities and exemption for entities with fewer than 250 persons; UODO - Data breaches; Electronic Communications Law - marketing and information in the terminal device.