GDPR — A practical guide for businesses and developers 🔒

The GDPR is not the developer’s enemy. It is the rulebook that nobody properly explained to you the first time.

What it is and why it matters 🔍

Regulation (EU) 2016/679 — known as the GDPR (General Data Protection Regulation) — is the European reference text for personal data protection. It has been directly applicable in all Member States since 25 May 2018, with no need for national transposition.

It is not an Italian law. It is not a directive that someone must transpose. It is a regulation: it applies uniformly across the entire European Union, and it applies to anyone who processes personal data of persons located in the European Economic Area.

Who does it apply to? Any organization — large or small, public or private, established in the EU or not — that processes personal data of people in the EEA. If you have an app that collects emails, a CRM with customer names, a database of employees, or even just a contact form, the GDPR applies to you.

Legal bases for processing

Every processing of personal data must have a legal basis. You cannot collect data “because it might be useful.” You must have one of these six foundations (Art. 6):

Legitimate interest is the most used and most abused legal basis. It requires a documented balancing test: if you cannot demonstrate that your interest overrides the data subject’s rights, you cannot use it.

The fundamental principles 📋

The GDPR rests on seven principles (Art. 5). They are not suggestions: they are requirements. Every processing must be able to satisfy them, and the controller must be able to demonstrate it (accountability).

1. Lawfulness, fairness, and transparency

Data must be processed lawfully (with a valid legal basis), fairly (not misleading), and transparently (the data subject must understand what happens to their data).

Practical impact: the privacy notice must be written in simple language, not in 47-page legalese. If a user cannot understand what you do with their data, you are not being transparent.

2. Purpose limitation

Collect data for a specific, explicit, and legitimate purpose. You cannot collect it “just in case.” If the purpose changes, you need a new legal basis or demonstrable compatibility.

3. Data minimization

Collect only what you need. If an email suffices for a newsletter, do not ask for first name, last name, date of birth, and tax ID.

4. Accuracy

Data must be accurate and up to date. If a customer changes their address and you keep shipping to the old one, you violate this principle. You must provide simple ways to update data.

5. Storage limitation

You cannot keep data forever “just in case.” You must define a retention period proportional to the purpose. Once expired, data must be deleted or anonymized.

Examples of retention periods:

6. Integrity and confidentiality

Data must be protected with adequate technical and organizational measures. This is not just encryption: it also includes access control, staff training, backup procedures, and disaster recovery.

7. Accountability

This is the principle that changes everything. It is not enough to comply: you must demonstrate compliance. Documentation, records, internal policies, impact assessments — everything must be traceable.

Data subject rights 🧑‍⚖️

The GDPR recognizes a series of rights for data subjects (the people whose data is processed) that organizations are obligated to guarantee. Ignoring them is not an option.

Right of access (Art. 15)

The data subject can request confirmation that you are processing their data and obtain a copy of all data you hold about them, along with: purposes, categories of data, recipients, retention period, data origin, any automated decisions.

Response time: 1 month, extendable by 2 months for complexity (with justification).

Cost: free for the first copy. You may charge a reasonable fee for subsequent copies or manifestly unfounded/excessive requests.

Right to rectification (Art. 16)

If data is inaccurate or incomplete, the data subject can request rectification. You must communicate it to all recipients to whom you have disclosed the data (Art. 19), unless impossible or requiring disproportionate effort.

Right to erasure — “right to be forgotten” (Art. 17)

The data subject can request deletion of their data when:

• Data is no longer necessary for the purpose for which it was collected
• They withdraw consent and there is no other legal basis
• They object to processing and there are no compelling legitimate grounds
• Data has been unlawfully processed
• There is a legal obligation to erase
• Data was collected in the context of information society services offered to minors

Exceptions (you do not have to delete): freedom of expression, legal obligations, public health, scientific research, establishment or defense of legal claims.

Right to restriction (Art. 18)

In four specific cases (accuracy dispute, unlawful processing with erasure objection, data needed for a legal claim, objection pending verification), the data subject can request to restrict processing: data is retained but not used.

Right to data portability (Art. 20)

When processing is based on consent or contract and is automated, the data subject can obtain data in a structured, commonly used, machine-readable format and transfer it to another controller.

Example: a user can request to export all their data from Spotify and import it into another platform. As a developer, you must provide this functionality if you offer a similar service.

Right to object (Art. 21)

For direct marketing (including related profiling), the data subject can object at any time: immediate stop, no justification needed.

For legitimate interest, objection requires reasons connected to the data subject’s particular situation, unless you demonstrate compelling legitimate grounds that override.

Automated decisions (Art. 22)

The data subject has the right not to be subject to a decision based solely on automated processing (including profiling) that produces legal effects or similarly significantly affects them.

Exceptions: decisions necessary for a contract, authorized by law, or based on explicit consent. In any case, you must ensure human intervention, the ability to express an opinion, and the possibility of contestation.

Business obligations 🏢

Privacy notice (Art. 13-14)

Every time you collect personal data, you must provide a notice that includes:

• Identity and contact details of the controller and DPO (if designated)
• Purpose and legal basis of processing
• Legitimate interest, if that is the legal basis (specify which)
• Recipients or categories of recipients
• Transfers outside the EEA and safeguards adopted
• Retention period or criteria for determining it
• Data subject rights
• Right to withdraw consent
• Right to lodge a complaint with a supervisory authority
• Whether communication of data is a contractual/legal obligation and what the consequences of non-communication are
• Existence of automated decisions including profiling

Notice for data not collected directly from the data subject (Art. 14) must also include the source of the data and must be provided within one month of obtaining it or at the time of first communication.

Records of processing activities (Art. 30)

Anyone processing data must maintain a record documenting:

• Purpose of processing
• Categories of data subjects and personal data
• Categories of recipients
• Transfers outside the EEA
• Planned deletion timelines
• General description of technical and organizational security measures

Exemption: companies with fewer than 250 employees, unless processing is not occasional, involves special categories of data, or data relating to criminal convictions.

Best practice is to keep the records anyway. In case of an inspection, it is the first document the supervisory authority asks to see.

Data Protection Impact Assessment — DPIA (Art. 35)

Before a high-risk processing, you must conduct a Data Protection Impact Assessment (DPIA). It is mandatory when processing involves:

• Systematic and comprehensive evaluation of personal aspects based on automated processing (including profiling)
• Large-scale processing of special categories of data
• Systematic monitoring of a publicly accessible area on a large scale

Minimum content of the DPIA:

1. Systematic description of processing operations and purposes
2. Assessment of necessity and proportionality
3. Assessment of risks to the rights and freedoms of data subjects
4. Measures to address risks, including safeguards, security mechanisms, and procedures

If the DPIA indicates residual high risk that cannot be mitigated, you must consult the supervisory authority in advance (Art. 36).

Data Protection Officer — DPO (Art. 37-39)

Designating a DPO is mandatory when:

• Processing is carried out by a public authority or public body
• The controller’s core activities consist of processing that requires regular and systematic monitoring of data subjects on a large scale
• The controller’s core activities consist of large-scale processing of special categories of data or data relating to criminal convictions

DPO position:

• Involved in a timely manner in all data protection matters
• Provided with adequate resources to carry out tasks and maintain expertise
• Not given instructions regarding task execution
• Not dismissed or penalized for performing tasks
• Reports directly to top management

Tasks: inform and advise, monitor GDPR compliance, cooperate with the supervisory authority, serve as contact point for the authority.

Security of processing (Art. 32)

Technical and organizational measures must be adequate to the risk. The GDPR does not prescribe specific technologies, but requires:

• Pseudonymization and encryption of personal data
• Ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems
• Ability to restore data availability promptly after an incident
• Regular processes for testing, assessing, and measuring the effectiveness of measures

Breach notification (Art. 33-34)

In case of a personal data breach (unauthorized access, loss, destruction, modification), you must:

1. Notify the supervisory authority within 72 hours of becoming aware (if the risk to rights and freedoms is high)
2. Communicate to the data subject without undue delay if the risk is high

The notification must include: nature of the breach, categories and approximate number of subjects, DPO contact details, likely consequences, measures taken or proposed.

Important: even if you do not notify (because the risk is not high), you must still internally document every breach.

Impact on developers 💻

The GDPR is not just a legal issue: it concretely changes how you design and write software.

Privacy by design and by default (Art. 25)

This is the principle that most impacts development. It means data protection must be built in from the design phase, not added as an overlay later.

In practice:

• Pseudonymization of data wherever possible (Art. 25.1)
• Minimization as the default setting: only strictly necessary data (Art. 25.2)
• No exposure to an indefinite number of persons without human intervention or control (Art. 25.2)
• Secure configurations as default: encryption active, minimal access, logging enabled

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Example: user pseudonymization in a Go system
type User struct {
    InternalID    string // pseudonymous identifier (UUID)
    EmailHash     string // email hash, not plaintext email
    ConsentFlags  ConsentFlags
    CreatedAt     time.Time
}

// Plaintext email is in a separate system with restricted access
type UserPII struct {
    InternalID string
    Email      string // encrypted at-rest
    // only the account management module accesses this store
}

Consent management

If you use consent as a legal basis, you must:

• Record its acquisition (when, how, which specific purposes)
• Make withdrawal as easy as giving consent
• Not mix consent for different purposes in a single checkbox
• Not condition services on consent for non-essential purposes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Example: consent management in a registration form
const consentOptions = {
  necessary: { required: true, label: 'Account creation' },
  analytics: { required: false, label: 'Anonymous usage analytics' },
  marketing: { required: false, label: 'Product updates via email' },
};

// Each consent is recorded separately with a timestamp
function recordConsent(userId, purpose, granted, timestamp) {
  // Save to consent database
  // This record is proof that consent was given or withdrawn
}

Security in systems

The GDPR requires “adequate” measures relative to risk (Art. 32). For a developer, this means:

• Encryption of sensitive data at rest and in transit
• Access control based on least privilege principles
• Logging of access to personal data (without logging the data itself)
• Encrypted backups with tested disaster recovery procedures
• Regular patch management
• Periodic penetration testing

API integration

If your system exposes APIs that process personal data, you must:

• Validate that every endpoint has a documented legal basis
• Implement mechanisms for data subject rights (portability, erasure, rectification)
• Rate limiting and access logging
• Not expose personal data in detailed error messages

Sanctions 💰

GDPR sanctions are among the most severe in the world. Art. 83 provides three levels:

Criteria for determining the amount include: nature and severity of the violation, degree of responsibility, mitigating measures adopted, prior violations, degree of cooperation, categories of data involved, manner of discovery.

In case of multiple violations linked to the same processing, the total does not exceed the sanction for the most serious violation.

Beyond financial sanctions, the authority can: order restriction or cessation of processing, prohibit data transfers, order rectification/deletion. And the data subject can claim compensation for material and immaterial damages (Art. 82), with joint liability between controller and processor.

Transfers outside the EEA 🌍

Transferring personal data outside the EEA is only possible if the destination country ensures an adequate level of protection, or if specific safeguards are in place.

Adequacy decisions (Art. 45)

The European Commission assesses whether a country ensures adequate protection. If so, transfers are free. Current adequacy decisions cover: Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, Uruguay, United Kingdom.

Standard Contractual Clauses — SCC (Art. 46)

In the absence of an adequacy decision, the European Commission’s Standard Contractual Clauses (SCC) are the most commonly used tool. They are standard clauses that the transferor and recipient insert into their contract.

Binding Corporate Rules — BCR (Art. 47)

For intra-group transfers, BCRs are approved by the supervisory authority. They are more complex than SCCs but offer an organic framework for the group.

Derogations (Art. 49)

In exceptional, non-recurring cases, transfer may be based on: explicit consent (after informing of risks), contract performance, public interest, establishment or defense of legal claims, vital interests.

Compliance checklist ✅

This checklist summarizes the main obligations to verify:

Organization

• Controller and processor identified for each processing activity
• DPO designated (if mandatory or voluntary)
• Data protection policies defined
• Staff trained on privacy and data security

Documentation

• Records of processing activities (Art. 30)
• Updated privacy notice for every channel (website, app, newsletter, etc.)
• Consent forms with specific purposes and withdrawal
• DPIA for high-risk processing
• Documentation of breaches (even if not notified)

Security

• Encryption of sensitive data at rest and in transit
• Access control based on least privilege
• Encrypted backups with tested disaster recovery
• Regular patch management and vulnerability assessment
• Access logs for personal data

Data subject rights

• Mechanism to respond to access requests within 1 month
• Rectification and data deletion functionality
• Portability functionality (export in structured format)
• Direct marketing objection mechanism
• Consent withdrawal management

Transfers outside the EEA

• Mapping of all transfers outside the EEA (including cloud providers)
• SCCs or other adequate safeguards in place for each transfer
• Assessment of the protection level of the destination country

Monitoring

• Breach notification process (72 hours)
• Periodic updates of risk assessments
• Annual review of policies and notices

Useful links 🔗

• Full text of the GDPR — EUR-Lex
• Garante per la protezione dei dati personali — Italian supervisory authority
• EDPB — European Data Protection Board — European Data Protection Board
• DPIA Practical Guide — Garante
• Standard Contractual Clauses (SCC) — European Commission
• Records of processing activities — Template — Garante

See also 📖

• NIS 2 — Cybersecurity — The complement to GDPR for network and information systems security
• AI Act — The EU regulation on artificial intelligence, with strong privacy implications
• Data Act — Equitable access and data portability: where GDPR meets the market