Compliance and Privacy (GDPR & Data Protection): compliance is not about paperwork, but about customer trust

Data Processing Agreement (DPA): A Mandatory Document Often Overlooked

2.1. What is a DPA and Why Does It Exist

A Data Processing Agreement is a legally binding contract between a Controller and a Processor of personal data, as mandated by Article 28 of the GDPR. Its absence constitutes a standalone violation of the regulation, even if the actual data processing is carried out lawfully. A DPA defines: the subject matter, duration, nature, and purpose of the processing; categories of personal data and data subjects; rights and obligations of both parties; technical and organizational security measures; the procedure for engaging sub-processors; actions to be taken in the event of a data breach.

2.2. Controller vs Processor: The Crucial Difference

Understanding the distinction between these roles is fundamental to correctly structuring relationships and documentation.

2.3. Typical mistakes in outsourcing relationships

IT outsourcing is a high-risk environment from a GDPR perspective. A developer or service company that gains access to a client’s database containing personal data is a processor and must conclude a DPA with the client-controller.

The most common mistakes we observe in practice:

• The DPA is completely absent — the parties limit themselves to an NDA or a standard development agreement.
• A DPA exists but does not contain the mandatory elements of Article 28 GDPR — for example, there is no list of technical security measures or a procedure for handling a breach.
• Subprocessors are not declared — the developer engages third-party contractors (hosting, analytics) without notifying the controller and without concluding separate DPAs with them.
• The roles of controller and processor are confused — the company considers itself a processor but in fact independently determines the purpose of data processing.
• A DPA is concluded, but the data is actually transferred to countries without an adequacy decision without SCCs.

Privacy by Design: data protection from the first line of code

3.1. What it is and why it matters

Privacy by Design is a principle enshrined in Article 25 of the GDPR, according to which the protection of personal data must be embedded into the architecture of a product or system at the design stage, rather than added as a “layer” before launch or after regulatory review.

In practice, this principle is implemented through two requirements:

Data Protection by Design: technical and organisational security measures must be built into the system design from the outset (encryption, pseudonymisation, access control, data minimisation).

Data Protection by Default: by default, the system must process only the minimum amount of personal data necessary for a specific purpose. In other words, “maximum privacy” is the default state, not an option.

3.2. Practical implementation at each stage

Phase 1. Discovery and architecture design

Before development begins, a Data Protection Impact Assessment (DPIA) must be conducted. A DPIA is mandatory under Article 35 GDPR in cases of “systematic and large-scale” profiling, processing of sensitive data, or public monitoring. However, even where a DPIA is not formally required, conducting one is a sign of a mature compliance approach.

At this stage, it is necessary to define: what personal data is collected and for what purpose; the legal basis for processing (consent, contract, legitimate interest, etc.); who will have access to the data; how long the data will be stored; how data will be transferred to third parties.

Phase 2. Development

• Encryption: data at rest and in transit must be encrypted (AES-256, TLS 1.2+).
• Pseudonymisation: where possible, replace direct identifiers with pseudonyms or hashes.
• Data minimisation principle: do not collect fields that are not required for functionality. If only an email is needed for registration, do not request a phone number.
• Access control: implement role-based access control (RBAC) and the principle of least privilege.
• Logging: maintain detailed access logs for personal data for auditing purposes.
• Automated deletion: implement retention policies so that data is automatically deleted after the storage period expires.

Phase 3. Testing and QA

Test environments should not contain real personal data. Use synthetic or anonymised data for testing. Conduct penetration testing and vulnerability assessments before production release.

Phase 4. Release and ongoing maintenance

Maintain a Record of Processing Activities (Article 30 GDPR). Appoint a Data Protection Officer (DPO) if required by the scale or nature of processing. Establish a data breach response procedure: GDPR requires notification to the regulator within 72 hours from the moment the breach is identified.

Cookie Compliance: why an “OK” button is not compliance

4.1. Legal basis: GDPR + ePrivacy Directive

Cookie compliance is regulated not only by the GDPR, but also by the ePrivacy Directive (2002/58/EC, as amended by 2009/136/EC) — the so-called “Cookie Law”. These two frameworks apply simultaneously, and compliance with one does not replace compliance with the other.

Key requirement: most cookies that are not strictly necessary for the technical functioning of a website require prior, freely given, specific, informed, and unambiguous consent from the user before they are set. Not after. Not “if you continue browsing the site”. But before.

4.2. Three categories of cookies and their legal regime

4.3. What does NOT constitute valid consent: common violations

EU regulators (especially France’s CNIL, Ireland’s DPC, and the Netherlands’ AP) have imposed fines specifically for improper implementation of consent mechanisms. The following are clearly not valid consent:

• Pre-ticked boxes — pre-selected checkboxes for analytics or marketing cookies.
  “By continuing to browse the site, you agree” — continuing navigation does not constitute consent.
• A banner with only an “OK” or “Understood” button without an “Reject” or “Settings” option — this is a dark pattern.
• Refusal must be as easy as acceptance — an “Accept all” button next to “Settings” (where refusal is hidden deep in menus) is considered an unlawful dark pattern.
• Lack of granular consent — users must be able to separately accept or reject analytics and marketing cookies.
• No record of consent — you must be able to prove who consented, when, and to what (consent management records).

4.4. What is actually required: checklist

• Consent Management Platform (CMP): use a certified platform (OneTrust, Cookiebot, Axeptio, etc.) or a custom-built system that complies with IAB TCF 2.2 requirements.
• Cookie audit: conduct a full audit of all cookies set by your website, including those added by third-party providers.
• Cookie policy: a separate page describing each cookie, its purpose, duration, and provider.
• Opt-out mechanism: ability to withdraw consent at any time as easily as it was given.
• No cookies before consent: technically ensure that analytics and marketing cookies are not set before the user clicks “Accept”.
• Updates when providers change: every new tracking pixel or analytics tool requires updating the cookie policy and CMP configuration.

Recommendations for Businesses

5.1. Assessing GDPR applicability (first step)

Before developing a compliance program, determine whether GDPR actually applies to your business. Answer the following questions:

• Do you have users, clients, or contacts physically located in the EU?
• Is your product/website accessible to EU residents without restriction?
• Do you collect any information (email, IP, cookies) from individuals in the EU?
• Do you have a legal entity, partner, or subcontractor located in the EU?

If the answer to at least one question is “yes” — GDPR applies. The next step is a gap analysis: assessing the difference between your current practices and GDPR requirements.

5.2. Minimum compliance package for an IT company

• Privacy Policy: public, clear, and up to date. Must describe all data processing activities.
• Record of Processing (Article 30 RoPA): internal document listing all personal data processing activities.
• DPAs with all processors: hosting, CRM, email services, analytics, outsourcing teams.
• SCCs for data transfers outside the EU: if your servers or vendors are located outside the EU.
• Cookie banner and CMP: in line with ePrivacy and GDPR requirements.
• Data breach response procedure: who notifies the regulator, within what timeframe, and what the notification includes.
• Data subject request procedure: handling rights of access, rectification, deletion (right to be forgotten), and portability.

5.3. When a Data Protection Officer (DPO) is required

Appointment of a DPO is mandatory in three cases:
(1) public authority or public body;
(2) systematic and large-scale monitoring of data subjects;
(3) large-scale processing of special categories of data (health, biometrics, racial or ethnic data, etc.).

For most B2B IT companies, a DPO is not legally required, but having one is a significant advantage during audits and in relationships with EU enterprise clients.

5.4. Compliance as a competitive advantage

It is worth shifting perspective: GDPR compliance is not a cost but an investment. Enterprise clients in the EU and the US routinely conduct vendor due diligence, including security questionnaires and verification of DPAs, Privacy Policies, and internal procedures.

A company without basic compliance regularly loses tenders and negotiations, even when it offers a better product or price.

Conclusions

GDPR is not a one-time project but an ongoing process. Key takeaways:

• The geographic location of your office does not matter: if your users are in the EU, GDPR applies to you regardless of where your servers or legal entity are located.
• A DPA is a mandatory document in any controller–processor relationship. Its absence is a standalone violation that can result in fines.
• Privacy by Design means that data protection is engineered into the product from the start, not added just before release.
• A cookie banner with only an “OK” button and no rejection option is an unlawful dark pattern. Equal ability to refuse and granular consent are required.
• Compliance means client trust, the ability to contract with EU customers, and avoidance of fines of up to €20 million.
• The starting point is a gap analysis: understand your current state and build a roadmap toward full compliance.

Regulatory changes are ongoing: the upcoming ePrivacy Regulation is expected to replace the current Directive and impose even stricter rules on cookie practices. Companies that already have a mature compliance culture will adapt far more easily than those building processes from scratch under regulatory pressure.

Need help with GDPR compliance for your company?

Barbashyn Law Firm provides a full cycle of data protection compliance services: from gap analysis and DPA drafting to implementation of Privacy by Design and representation before EU regulators.

barbashyn.law • GDPR • Data Protection • IT Law • Privacy Compliance