Privacy by Design: A Practical Guide for Software Development Teams

Privacy by Design is not a suggestion --- it is a legal requirement under GDPR Article 25. Organizations must implement "appropriate technical and organisational measures" to ensure data protection principles are integrated into the processing itself. Yet most development teams treat privacy as an afterthought, bolting on consent forms and cookie banners after the architecture is set.

This guide translates the seven foundational principles of Privacy by Design into actionable engineering practices, design patterns, and code-level implementations.

Key Takeaways

• Privacy by Design means embedding privacy into architecture decisions, not adding it as a feature later
• Data minimization at the schema level prevents over-collection from the start
• Pseudonymization and encryption provide defense in depth when breaches occur
• Privacy-preserving analytics can deliver business insights without exposing individual user data

---

The Seven Principles Applied to Software

1. Proactive Not Reactive

Build privacy controls before collecting data, not after a breach.

In practice:

• Include privacy requirements in user story acceptance criteria
• Run a privacy threat model during architecture reviews
• Create a privacy checklist for every pull request that touches user data

2. Privacy as the Default Setting

Users should not need to take action to protect their privacy.

In practice:

• New user accounts default to minimum data sharing
• Analytics tracking is opt-in, not opt-out
• Profile visibility defaults to private
• Data retention defaults to the minimum required period

// Default privacy settings for new users
const DEFAULT_PRIVACY_SETTINGS = {
  profileVisibility: 'private',       // Not 'public'
  analyticsTracking: false,           // Opt-in required
  marketingEmails: false,             // Opt-in required
  dataSharing: false,                 // Opt-in required
  activityLog: true,                  // Security feature, on by default
  twoFactorAuth: true,               // Security feature, on by default
};

3. Privacy Embedded into Design

Privacy is a core component of the system, not an add-on.

Database schema design:

-- Privacy-aware schema design
CREATE TABLE users (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    -- Separate PII from operational data
    email VARCHAR(255) NOT NULL,          -- PII
    email_hash VARCHAR(64) NOT NULL,      -- For lookups without exposing email
    name_encrypted BYTEA,                 -- Encrypted at rest
    -- Operational fields (non-PII)
    role VARCHAR(50) NOT NULL DEFAULT 'user',
    created_at TIMESTAMP DEFAULT NOW(),
    -- Privacy metadata
    consent_timestamp TIMESTAMP,
    consent_version VARCHAR(20),
    data_retention_until TIMESTAMP,
    deletion_requested_at TIMESTAMP
);

-- Separate sensitive data into its own table with stricter access
CREATE TABLE user_pii (
    user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
    phone_encrypted BYTEA,
    address_encrypted BYTEA,
    date_of_birth_encrypted BYTEA,
    -- Audit trail
    last_accessed_at TIMESTAMP,
    last_accessed_by UUID
);

4. Full Functionality (Positive-Sum)

Privacy should not come at the cost of functionality. Design systems that deliver both.

Example: Instead of choosing between personalization and privacy, use privacy-preserving personalization:

• Federated learning: ML models trained on local data, only aggregated results shared
• Differential privacy: Add noise to analytics to prevent individual identification
• On-device processing: Recommendations computed on the user's device, not the server

5. End-to-End Security

Protect data throughout its entire lifecycle.

6. Visibility and Transparency

Users must understand what happens to their data.

Implementation:

// Privacy dashboard API endpoint
@Controller('privacy')
export class PrivacyController {
  @Get('my-data')
  @ApiOperation({ summary: 'Get all personal data (GDPR Art. 15)' })
  async getMyData(@Req() req: AuthenticatedRequest) {
    return {
      profile: await this.userService.getProfile(req.user.sub),
      orders: await this.orderService.getUserOrders(req.user.sub),
      supportTickets: await this.supportService.getUserTickets(req.user.sub),
      loginHistory: await this.authService.getLoginHistory(req.user.sub),
      consentRecords: await this.consentService.getUserConsents(req.user.sub),
      dataProcessors: this.getDataProcessorList(),
    };
  }

  @Post('export')
  @ApiOperation({ summary: 'Export personal data (GDPR Art. 20)' })
  async exportMyData(@Req() req: AuthenticatedRequest) {
    // Generate machine-readable export (JSON)
    return this.privacyService.generateDataExport(req.user.sub);
  }

  @Post('delete')
  @ApiOperation({ summary: 'Request data deletion (GDPR Art. 17)' })
  async requestDeletion(@Req() req: AuthenticatedRequest) {
    return this.privacyService.initiateDataDeletion(req.user.sub);
  }
}

7. Respect for User Privacy

Keep the user at the center of every design decision.

---

Privacy-Preserving Architecture Patterns

Pattern 1: Data Separation

Separate personally identifiable information from operational data:

[Frontend] --> [API Gateway] --> [Application Service]
                                       |
                      +----------------+----------------+
                      |                                 |
              [Operational DB]                    [PII Vault]
              (Orders, products,                  (Names, emails,
               analytics - by ID)                  addresses - encrypted)

Pattern 2: Consent-Driven Processing

// Consent middleware
async function requireConsent(purpose: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const consent = await consentService.check(req.user.id, purpose);
    if (!consent.granted) {
      throw new ForbiddenException(
        `Processing for "${purpose}" requires user consent`
      );
    }
    next();
  };
}

// Usage
@Get('recommendations')
@UseGuards(requireConsent('personalization'))
async getRecommendations(@Req() req: AuthenticatedRequest) {
  return this.recommendationService.getForUser(req.user.sub);
}

Pattern 3: Automatic Data Expiry

// TTL-based data retention
const RETENTION_POLICIES = {
  supportTickets: { days: 1095, action: 'anonymize' },    // 3 years
  recruitmentData: { days: 730, action: 'delete' },        // 2 years
  analyticsEvents: { days: 365, action: 'aggregate' },     // 1 year
  sessionLogs: { days: 90, action: 'delete' },             // 90 days
  tempUploads: { days: 7, action: 'delete' },              // 7 days
};

---

Privacy in Third-Party Integrations

Every third-party integration is a potential privacy risk. When your application sends user data to an external service, you become responsible for how that service handles it.

Integration Privacy Assessment

Before integrating any third-party service that processes user data:

Common Integration Privacy Risks

Analytics: Google Analytics, Mixpanel, and similar services receive user behavioral data. Use server-side analytics or cookie-free alternatives (Plausible, Fathom) to minimize data exposure.

Payment processing: Stripe, PayPal, and similar services process financial data. Use their hosted payment forms (Stripe Elements) to avoid PCI-DSS scope expansion. Never log full credit card numbers.

Email services: SendGrid, Mailgun, and similar services process email addresses and message content. Ensure the email service provider has a signed DPA and does not use your recipient data for advertising.

Customer support: Zendesk, Intercom, and similar services store customer conversations that may contain PII. Configure data retention in the support platform and ensure the DPA covers all data types.

---

Developer Checklist

For Every Feature Touching User Data

• What personal data does this feature collect? (Document it)
• What is the legal basis for collection? (Consent, contract, legitimate interest)
• Is this the minimum data needed? (Data minimization)
• How long will we retain it? (Retention policy)
• Who has access? (Least privilege)
• Is it encrypted at rest and in transit? (Security)
• Can the user access, export, and delete their data? (Rights)
• Is it logged for audit purposes? (Accountability)
• Does it cross borders? (Transfer mechanisms)
• Has a DPIA been completed if high risk? (Assessment)

---

Frequently Asked Questions

Is Privacy by Design only for GDPR?

No. While GDPR makes it a legal requirement (Article 25), Privacy by Design is a recognized best practice globally. California's CPRA, Brazil's LGPD, and India's DPDP all include similar requirements for embedding privacy into system design. Implementing Privacy by Design for GDPR compliance automatically satisfies most other jurisdictions' requirements.

How do we retrofit privacy into an existing application?

Prioritize: (1) Audit what personal data you have and where it lives, (2) Implement data subject request workflows (access, delete, export), (3) Add encryption for sensitive data at rest, (4) Implement retention policies and automated deletion, (5) Add consent management where missing. This is not ideal but addresses the highest-risk gaps first.

Does Privacy by Design mean we cannot use analytics?

No. It means using analytics responsibly. Aggregate data rather than individual tracking. Use cookie-free analytics (Plausible, Fathom) for website metrics. For product analytics, collect events without PII or pseudonymize identifiers. For A/B testing, use server-side assignment without client-side tracking cookies. Privacy and analytics are compatible with thoughtful design.

How do we implement Privacy by Design in Odoo?

Odoo provides several built-in privacy features: user access groups (per-module access control), audit logging (chatter on records), and data archiving. Enhance these with: encrypted custom fields for sensitive data, automated retention rules using scheduled actions, GDPR data export functionality using custom reports, and consent tracking on contact records. ECOSIRE's Odoo customization services include privacy-by-design implementation.

---

What Comes Next

Privacy by Design is the engineering discipline. Pair it with data retention policies for lifecycle management, cookie consent implementation for web properties, and employee data privacy for internal systems.

Contact ECOSIRE for privacy-by-design consulting and software architecture review.

---

Published by ECOSIRE -- helping businesses build privacy into every line of code.