European Regulations: GDPR, NIS2, and Cyber Resilience Act
The European Union has built the world's most advanced regulatory framework for data protection and cybersecurity. For developers, these regulations are not abstract legal documents, but concrete technical requirements that directly impact software architecture, design, and implementation.
In this article, we will explore GDPR from the developer's perspective, the new NIS2 directive for critical infrastructure security, and the Cyber Resilience Act that introduces mandatory security requirements for all digital products sold in the EU.
What You'll Learn
- GDPR for developers: technical principles and implementation
- Privacy by Design and Privacy by Default
- Data minimization, encryption, and retention
- NIS2: requirements for critical infrastructure
- Cyber Resilience Act: digital product security
- Technical implementation of regulatory requirements
GDPR for Developers
The GDPR (General Data Protection Regulation) is not just a regulation for lawyers. Its principles translate directly into technical decisions that every developer must know and apply.
Privacy by Design
Article 25 of the GDPR requires that data protection be integrated into system design, not added as an afterthought. For developers, this means:
- Data minimization: collect and store only strictly necessary data
- Purpose limitation: data collected for one purpose cannot be used for other purposes
- Storage limitation: define and implement retention policies for each data type
- Pseudonymization: separate identifying data from usage data
Technical GDPR Implementation
GDPR Requirements and Technical Implementation
| GDPR Requirement | Technical Implementation |
|---|---|
| Encryption at rest (Art. 32) | AES-256 for databases, storage, and backups |
| Encryption in transit (Art. 32) | TLS 1.3 for all communications |
| Right to erasure (Art. 17) | Soft delete + purge job, cascade delete |
| Right to portability (Art. 20) | Export API in standard JSON/CSV format |
| Data minimization (Art. 5) | Minimal DB schema, no unnecessary optional fields |
| Pseudonymization (Art. 4) | UUID for references, PII data separation |
| Breach notification (Art. 33) | Monitoring, alerting, automated incident response |
| Consent management (Art. 7) | Consent management system with audit trail |
Data Retention Policy
# data-retention-policy.yaml
retention_policies:
user_accounts:
active: "indefinite (while account is active)"
after_deletion: "30 days soft delete, then hard purge"
backup_retention: "90 days after purge"
access_logs:
retention: "12 months"
anonymization: "after 3 months, anonymize IP addresses"
archival: "cold storage after 6 months"
analytics_data:
retention: "24 months"
anonymization: "immediate (no PII in analytics)"
granularity: "aggregate after 3 months"
payment_records:
retention: "7 years (legal requirement)"
encryption: "AES-256, separate key per customer"
access: "restricted to billing team"
support_tickets:
retention: "36 months"
anonymization: "after resolution + 12 months"
pii_handling: "redact before long-term storage"
DPIA: Data Protection Impact Assessment
Article 35 of GDPR requires a DPIA (Data Protection Impact Assessment) when data processing presents high risks to the rights of data subjects. For developers, this applies when implementing systems with:
- Automated profiling that produces legal effects
- Large-scale processing of sensitive data
- Systematic monitoring of publicly accessible areas
- New technologies with unknown risks (AI, biometrics)
NIS2 Directive
NIS2 (Network and Information Security Directive 2) is the European directive that establishes cybersecurity requirements for organizations operating in essential and important sectors. Unlike GDPR which focuses on data protection, NIS2 concentrates on the security of digital infrastructure and services.
Sectors Covered by NIS2
- Essential sectors: energy, transport, banking, healthcare, water, digital infrastructure, public administration
- Important sectors: postal services, waste management, food production, chemicals, manufacturing, digital services, research
NIS2 Technical Requirements
NIS2 Requirements for DevSecOps
| NIS2 Requirement | DevSecOps Implementation |
|---|---|
| Risk analysis | Threat modeling, periodic vulnerability assessment |
| Incident handling | Automated incident response, notification within 24h |
| Supply chain security | SBOM, SCA, artifact signing |
| Vulnerability management | SAST, DAST, container scanning, patch management |
| Encryption | E2E encryption, key management, TLS everywhere |
| Access control | RBAC, MFA, zero trust, least privilege |
| Business continuity | DR plan, automated backups, defined RTO/RPO |
Cyber Resilience Act (CRA)
The Cyber Resilience Act is the European regulation that introduces mandatory security requirements for all digital products (hardware and software) sold in the European Union. It's the most significant change for developers because it requires:
- Security by design: software must be designed with security as a fundamental requirement
- Vulnerability handling: documented process for vulnerability management throughout the product lifecycle
- Mandatory SBOM: every product must provide a Software Bill of Materials
- Free security updates: for at least 5 years from sale
- Vulnerability notification: mandatory notification to authorities within 24 hours of discovering an actively exploited vulnerability
CRA Impact on Developers
- Every release must be accompanied by an updated SBOM
- The vulnerability disclosure process must be documented and accessible
- Security testing (SAST, DAST, SCA) must be part of the development process
- Technical documentation must include implemented security measures
- Penalties can reach 15 million euros or 2.5% of global turnover
Practical Implementation: Developer Checklist
# eu-compliance-checklist.yaml
gdpr:
data_protection:
- encryption_at_rest: "AES-256 for all personal data"
- encryption_in_transit: "TLS 1.3 mandatory"
- pseudonymization: "UUID for cross-system references"
- retention_policy: "Implemented and automated"
rights_implementation:
- right_to_access: "User data export API"
- right_to_erasure: "Complete deletion process"
- right_to_portability: "Standard JSON/CSV export"
- consent_management: "System with audit trail"
nis2:
security_measures:
- vulnerability_management: "SAST + DAST + SCA in CI/CD"
- incident_response: "Documented process, 24h notification"
- access_control: "RBAC + MFA + least privilege"
- supply_chain: "SBOM + artifact signing"
- monitoring: "Runtime security with Falco"
- backup: "Automated, tested monthly"
cra:
product_security:
- sbom: "Generated on every release"
- security_updates: "Security patch process"
- vulnerability_disclosure: "Public disclosure page"
- documentation: "Documented security measures"
- testing: "SAST, DAST, SCA, penetration testing"
EU Compliance Best Practices
- Privacy by Design: integrate data protection into architectural design
- SBOM for every release: automated generation and distribution of SBOM
- Vulnerability disclosure program: public process for reporting vulnerabilities
- Data mapping: document where personal data resides and how it flows
- Tested incident response: periodic exercises to meet notification deadlines
- Continuous training: stay updated on regulatory developments
Conclusions
European regulations are significantly raising the bar for software security. For developers, this is not a burden but an opportunity: organizations that implement mature DevSecOps are already largely compliant. GDPR, NIS2, and the Cyber Resilience Act all converge toward the same principles: security by design, vulnerability management, and transparency.
In the next and final article of the series, we'll present an end-to-end case study: the complete implementation of a DevSecOps pipeline in a real startup, with metrics, timeline, and lessons learned.