Most EU compliance work ends up on a lawyer's or compliance officer's desk. But the technical obligations — the ones that require engineering decisions, product architecture choices, and infrastructure changes — are the CTO's problem. If your legal team signs off on a GDPR DPA but your product engineers haven't implemented privacy by design, you are non-compliant. This guide covers what technical and product leaders need to own.
GDPR: What CTOs Must Build
Privacy by Design (Article 25)
GDPR Article 25 requires data protection to be built into product and system design from the start — not bolted on as an afterthought.
What this means technically:
- Data minimisation: collect the minimum personal data needed for the product's function. Default to not collecting data that isn't necessary.
- Purpose limitation: do not reuse data for purposes other than what users were informed of
- Retention limits: build automatic deletion or anonymisation after retention periods, not manual processes
- Access controls: personal data must be accessible only to users and systems that need it for defined purposes
The practical failure mode: A legal team approves a privacy notice that says data is deleted after 12 months. Engineering has no deletion process. The promise is not met.
Consent Management
If your product or website uses non-essential cookies (analytics, tracking, advertising):
- Cookie consent must be implemented before non-essential cookies fire
- No cookies before consent; equal reject/accept options
- Consent must be recorded
Technical requirements: A consent management platform (CMP) that fires before analytics scripts; JavaScript implementation that blocks non-consented tags. This is an engineering task.
Data Subject Rights
GDPR requires responses to subject access requests (SARs) within 30 days. For this to be operational:
- Your system must be able to identify all personal data associated with a user across all storage locations
- You must be able to export it in a structured format (Article 20 portability)
- You must be able to delete it upon request (Article 17 right to erasure)
- Your product team must design for this — "find and delete user" must be a queryable, executable operation
The practical failure mode: An SAR arrives; the engineering team spends 40 hours manually searching through multiple databases to find all the data. This is avoidable with data architecture.
EU AI Act: What CTOs Must Build
Risk Classification
Before deploying AI features: conduct a technical risk assessment. The CTO or Head of AI should be able to answer:
- Which AI Act risk tier does this system fall into?
- If high-risk: what technical documentation is required?
- If it includes AI-generated content or chatbots: what transparency disclosure must be shown to users?
Technical Documentation (Annex IV — High-Risk AI)
For high-risk AI systems, Annex IV requires extensive technical documentation covering:
- System description and use case
- Development methodology and training data description
- Performance metrics and testing results
- Known limitations and failure modes
- Post-market monitoring architecture
This is a product engineering deliverable — not a legal document. The CTO team must write and maintain it.
Article 50 Transparency
If your product includes chatbots or AI that users might mistake for a human:
- Engineering must implement a disclosure that the user is interacting with AI
- Disclosure must be clear and given at the start of the interaction — not buried in terms of service
- Exception: "sincere question" rule — if a user genuinely wants to know if they're talking to AI, the system cannot be designed to deceive them
Logging Requirements (High-Risk AI Deployers)
If you deploy high-risk AI: GDPR-aligned logging of AI system use must be retained for at least 6 months (some categories: 3 years). Build logging infrastructure as part of the AI system, not retrospectively.
NIS2: What CTOs Must Implement
NIS2 Article 21 specifies security measures that are primarily technical. For in-scope companies:
MFA everywhere: Multi-factor authentication on all production systems, administrative access, and systems containing sensitive data. Non-negotiable; should be in place already.
Encryption: Data at rest and in transit with documented standards. This is an architecture decision — storage encryption, TLS configuration, key management.
Access control and privilege management: Role-based access control with least-privilege. Privileged access management (PAM) for administrative accounts. Periodic access reviews — must be a product/engineering process, not a manual exercise.
Vulnerability management: Automated scanning of production infrastructure and code dependencies. Patching SLAs with enforcement — not just a policy. Integration into CI/CD pipeline.
Incident detection: SIEM or equivalent log aggregation and alerting. The 24-hour NIS2 incident notification requirement means you must detect incidents quickly enough to report them — without detection infrastructure, you cannot meet the timeline.
DORA: What CTOs at Financial Services Companies Must Own
Register of Information: The ICT third-party risk register is a data asset that must be maintained. Engineering and procurement must feed it with accurate service information.
4-Hour Incident Notification: Meeting DORA's initial notification deadline requires detection, classification, and notification to happen in less than 4 hours. This requires:
- Real-time monitoring and alerting
- Automated incident classification triage
- On-call process with defined escalation
Resilience Testing: DORA requires regular testing of ICT systems' resilience. For significant entities: TLPT (threat-led penetration testing) with TIBER-EU methodology. For all entities: basic testing across all ICT systems.
Data Act: What CTOs Building IoT or Cloud Products Must Design For
Data access by default: If your product includes IoT or connected device components, users must be able to access their data through the device interface or app. This is a product design decision — build the data access interface into the architecture from the start.
Data export in standard formats: If you are a cloud provider, customers must be able to export all their data in a machine-readable, non-proprietary format. Build your export capability before it becomes a regulatory requirement.
Compliance Is a Product Quality Issue
The mindset shift for technical leaders: compliance is not someone else's job that you support on request. It is a product quality attribute — like performance, reliability, and security. A product that stores personal data without deletion capabilities is a broken product. An AI chatbot that doesn't disclose its AI nature is shipping a compliance defect.
Build compliance requirements into your engineering workflow: add privacy and security review to your sprint process; include data protection impact assessment in product launch gates; make compliance documentation part of feature delivery.