GDPR-Compliant Customer Portal Architecture: 7 Technical Principles

GDPR compliance is not a label; it is the sum of every technical choice and architectural decision. When building a customer self-service portal, compliance cannot be achieved only through a "privacy notice." This article explains 7 concrete technical principles that must be applied at the portal's architectural level, and the implementation criteria for each.

"Every organization processing personal data under GDPR is obligated to ensure data security. This obligation is not only legal compliance but also a promise of trust made to the customer."

Principle 1 — Data Minimization

One of the core principles of GDPR Article 5 is the obligation to collect data that is "adequate, relevant and limited to what is necessary" for the processing purpose. In portal architecture, this is implemented as:

Implementation criteria

• Non-mandatory fields are made optional and explicitly marked
• The processing purpose of each collected data field is documented
• Queries for data not required for the operation are prohibited (e.g. national ID not requested for delivery)
• The database schema only contains actively-used columns

Example at the code level

"Optional" fields in the customer registration table are defined at the database level as NULLABLE. In the application layer, these fields are excluded from the form and requested only on demand.

Principle 2 — Layered Encryption

Personal data must be encrypted at every stage: when stored, in transit, and during processing. Single-layer encryption is insufficient.

Three layers

1. Transit encryption: TLS 1.3, HTTPS mandatory (via HSTS header)
2. Storage encryption: Database encryption (MySQL InnoDB encryption or application-layer AES-256)
3. Field-level encryption: Critical fields like national ID, IBAN, are separately encrypted at application layer

Critical field examples

The following fields are always stored with application-layer encryption:

• National ID number
• Passport / foreign ID number
• IBAN / card number (should be tokenized, not stored)
• Health data (diagnosis, treatment, prescription)
• Biometric data

Principle 3 — Role-Based Access Control (RBAC)

Every employee or system user must be able to access only data within their job scope. A "let every staff see everything" approach is a GDPR non-compliance.

Minimum role set

• Customer: Accesses only their own data; cannot view other customers' data under any circumstance
• Operations (ops): Processes customer data but has no deletion authority
• Manager: Has exceptional deletion and modification authority; every action is logged
• Data Controller: Full access, views all logs

Role assignment always follows the principle "opens when access is requested, closes when task is done." Persistent super-user privileges are kept limited.

Principle 4 — Comprehensive Logging and Traceability

Every access and action on personal data is logged in an immutable manner. Logs enable the data controller to answer "who, when, which data did you access" with proof.

Log record set

Log files are stored on a separate server or log service, not on the same place as the application server. This prevents log tampering in case of malicious access.

Principle 5 — Automated Retention Periods

GDPR requires personal data to be deleted when the processing purpose ends. Manual deletion processes are inadequate because they are forgotten and inconsistent.

Automation rules

• A retention period (TTL) is defined for each table and data type
• A daily background job (cron) deletes or anonymizes records whose TTL has expired
• Deletion must be irreversible (soft delete is not considered "deletion" under GDPR)
• Deletion information of erased records is logged (which record, when, under which policy)

Typical retention periods

• Contact form submission: 1 year
• Active customer account: as long as active + 10 years (per tax law)
• Invoice records: 10 years (tax law)
• Log records: 2 years
• Analytics data: 6 months (anonymized)

Principle 6 — Self-Service Tools for User Rights

User rights under GDPR Article 11 (right to information, right to erasure, data portability) must be provided self-service via the portal. Manual processing of each request creates non-compliance.

Tools offered within the portal

• Data View: User can see all their data on a single page
• Data Download: User can download their data in JSON or PDF (data portability)
• Correction: User can correct incorrect records from their own panel
• Erasure Request: User submits account deletion via form, receives response within 7 days
• Objection: Open channel to object to automated decision-making systems

Principle 7 — Disaster Recovery and Business Continuity

GDPR includes the data controller's obligation to protect not just security, but also the integrity and accessibility of data. A portal without a disaster recovery plan is considered non-compliant.

Core practices

• Backup: Daily encrypted backup; 3-2-1 rule (3 copies, 2 media, 1 off-site)
• Backup restoration test: Monthly, a random backup is restored in a test environment
• RTO (Recovery Time Objective): Maximum hours until service starts after disaster (typical: 4 hours)
• RPO (Recovery Point Objective): Maximum data loss window (typical: 24 hours)
• GDPR breach notification plan: Notify the authority within 72 hours of breach detection

Conclusion

GDPR compliance is not a single application or text; it is a discipline that must permeate every layer of portal architecture. When these 7 principles are applied at project inception, they eliminate a recovery cost that would be enormous if addressed later.

How many of these principles does your current portal architecture satisfy? If you request an audit, a compliance map of the current structure and an improvement roadmap are presented within a 30-minute free discovery call.