Danish Data Protection Laws: A Developer's Practical Guide

GDPR in Denmark: What Developers Actually Need to Know

Most GDPR guides for developers are written for a generic EU audience and focus on theoretical principles. This guide is different. It is written specifically for developers building web applications and mobile apps for Danish businesses or Danish users, and it focuses on practical implementation -- what to actually build and how to build it.

Denmark enforces GDPR through the Danish Data Protection Act (Databeskyttelsesloven) and the Danish Data Protection Agency (Datatilsynet). While the core GDPR rules are the same across the EU, Denmark has specific interpretations and additional requirements that affect how you implement data protection in your applications.

The Legal Framework: GDPR + Danish Data Protection Act

As a developer, you need to understand three overlapping legal frameworks that govern data protection in Danish web applications:

For developers, the practical implication is: you need to think about data protection at three levels. What personal data are you collecting (GDPR)? Are there any Danish-specific rules for that data type (Databeskyttelsesloven)? Are you using cookies or device fingerprinting to track users (ePrivacy/Cookie law)?

Lawful Basis for Processing: A Practical Guide

Every piece of personal data you process needs a lawful basis. This is not bureaucracy -- it is the foundation of your data architecture. The lawful basis determines what consent flows you need, how long you can keep data, and what rights users have over that data. Choose the wrong basis and your entire data pipeline may be non-compliant.

Consent Patterns That Actually Work

When consent is the appropriate lawful basis, the GDPR (and Datatilsynet's guidance) sets a high bar for what counts as valid consent. It must be freely given, specific, informed, and unambiguous. Here is what that means in practice:

// Cookie consent state structure
interface CookieConsent {
  necessary: true       // Always true, no toggle
  functional: boolean   // Language preferences, UI settings
  analytics: boolean    // Usage statistics, heatmaps
  marketing: boolean    // Ad targeting, social media pixels
  consentDate: string   // ISO date of consent
  consentVersion: string // Version of privacy policy
}

// Store consent server-side (not just in a cookie)
async function saveConsent(consent: CookieConsent) {
  await db.consentRecord.create({
    data: {
      ...consent,
      ipHash: hashIP(request.ip), // Hash, don't store raw
      userAgent: request.headers['user-agent'],
      timestamp: new Date().toISOString()
    }
  })
}

Case Study: Cookieless Analytics (No Consent Required)

At Twin Current, we built our own privacy-first analytics system (tw.js) that tracks website usage without cookies and without requiring user consent. This is not a workaround -- it is compliant by design. Understanding how this works illustrates GDPR principles in action.

How tw.js Works

// Simplified fingerprint generation (client-side)
// No cookies, no localStorage, no sessionStorage
function generateSessionId() {
  const components = [
    navigator.language,
    screen.width + 'x' + screen.height,
    new Date().toDateString(), // Rotates daily
    // Additional entropy from browser features
  ]

  // Hash the components - one-way, not reversible
  return hashComponents(components)
}

// Server-side: the fingerprint hash is stored,
// never the raw components
// IP addresses are NOT stored - only used for
// geolocation lookup, then discarded

Privacy by Design Principles Applied

This approach is used across all Twin Current properties and client sites. It provides the analytics data we need (page views, sessions, referrers, Core Web Vitals, error tracking) without requiring a consent banner for analytics. The result: a cleaner user experience and full GDPR compliance.

Data Storage and Retention Requirements

GDPR's data minimization principle says you should not keep personal data longer than necessary. But Danish law also mandates minimum retention periods for certain data types, particularly financial records. Navigating these overlapping requirements is one of the trickiest parts of Danish data protection compliance.

Implementation: Automated Data Lifecycle

// Example: Automated data retention enforcement
// Run as a daily cron job

async function enforceDataRetention() {
  const now = new Date()

  // Delete server logs older than 90 days
  await db.serverLog.deleteMany({
    where: {
      createdAt: { lt: subDays(now, 90) }
    }
  })

  // Anonymize analytics data older than 26 months
  await db.analyticsEvent.updateMany({
    where: {
      createdAt: { lt: subMonths(now, 26) },
      anonymized: false
    },
    data: {
      sessionId: 'anonymized',
      fingerprint: 'anonymized',
      anonymized: true
    }
  })

  // Delete inactive user accounts after 30-day grace
  await db.user.deleteMany({
    where: {
      deletionRequestedAt: { lt: subDays(now, 30) },
      status: 'pending_deletion'
    }
  })

  // NOTE: Financial records are NEVER auto-deleted
  // They must be retained for 5 years per Danish law
}

Implementing Data Subject Rights

GDPR gives individuals specific rights over their data. As a developer, you need to build technical mechanisms that enable these rights. Datatilsynet expects you to respond to requests within 30 days. Here are the key rights and how to implement them:

Developer Compliance Checklist

Use this checklist when building or auditing a web application for the Danish market. It covers the most common compliance requirements we encounter in our work at Twin Current.

Data protection compliance is not a one-time implementation. It is an ongoing practice that needs to be maintained as your application evolves, new features are added, and regulations are updated. Build these checks into your development process -- not as an afterthought, but as a first-class requirement alongside security, testing, and performance.