GDPR Access Governance for Enterprises: Architecture, Implementation, and Hardening

Overview

GDPR access governance is the set of policies, identity controls, approval workflows, and audit mechanisms used to ensure personal data is accessed only by authorized users for legitimate purposes. Its core purpose is to enforce least privilege, separation of duties, accountability, and traceability across systems that store or process EU personal data.

Enterprises use GDPR access governance to reduce unauthorized access, support data subject rights, and demonstrate compliance during audits. In practice, this means linking identities to business roles, classifying personal data, enforcing conditional access, logging all access events, and reviewing entitlements regularly.

Architecture

A typical enterprise architecture includes:

• Identity provider such as Microsoft Entra ID or Okta for authentication and group-based authorization
• IGA layer such as SailPoint or Saviynt for joiner-mover-leaver workflows and access reviews
• PAM controls for privileged access to databases, cloud consoles, and admin interfaces
• Data classification and discovery to tag GDPR-relevant datasets
• SIEM and immutable logging for audit evidence and anomaly detection
• Policy decision points using conditional access, device trust, and location risk

Deployment models

• Cloud-first: Entra ID, Microsoft Purview, Azure SQL, Sentinel
• Hybrid: AD DS plus Entra ID sync, on-prem databases, cloud SIEM
• Multi-cloud: Central identity with AWS, Azure, and GCP policy enforcement

Data flow

1. HR system creates or updates worker status.
2. IGA provisions role-based access through identity groups.
3. Sensitive data stores map groups to scoped roles.
4. Access events stream to SIEM.
5. Quarterly reviews validate that access remains necessary and proportionate.

Implementation Guide

The example below uses Microsoft Entra ID, Azure SQL, Microsoft Purview, and Azure Monitor.

1. Create a security group for GDPR data readers

az ad group create --display-name "gdpr-data-readers" --mail-nickname "gdpr-data-readers"

1. Assign least-privilege database access

az sql server ad-admin create --resource-group rg-prod-data --server sql-gdpr-prod --display-name "SQL Admin Group" --object-id 11111111-2222-3333-4444-555555555555
az sql db show-connection-string --server sql-gdpr-prod --name customerdb --client sqlcmd
sqlcmd -S tcp:sql-gdpr-prod.database.windows.net,1433 -d customerdb -G -Q "CREATE USER [gdpr-data-readers] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [gdpr-data-readers]; DENY SELECT ON OBJECT::dbo.payment_cards TO [gdpr-data-readers];"

1. Enable diagnostic logging for auditability

az monitor diagnostic-settings create --name sql-audit --resource "/subscriptions/12345678-aaaa-bbbb-cccc-1234567890ab/resourceGroups/rg-prod-data/providers/Microsoft.Sql/servers/sql-gdpr-prod/databases/customerdb" --workspace "/subscriptions/12345678-aaaa-bbbb-cccc-1234567890ab/resourceGroups/rg-sec-ops/providers/Microsoft.OperationalInsights/workspaces/law-central" --logs '[{"category":"SQLSecurityAuditEvents","enabled":true},{"category":"AutomaticTuning","enabled":false}]'

1. Apply a conditional access policy baseline

• Require MFA for all interactive access to systems containing personal data
• Block legacy authentication
• Restrict admin access to compliant devices and named locations

1. Classify and label personal data

• Use Microsoft Purview scans for SQL, storage, and M365
• Map labels such as PersonalData, SpecialCategoryData, and RetentionRestricted

1. Schedule access reviews

• Review membership of gdpr-data-readers every 90 days
• Require manager and data owner attestation
• Auto-remove unreviewed access

Code Examples

1. Azure Policy-style tagging baseline

{
  "properties": {
    "displayName": "Require GDPR data classification tag",
    "policyType": "Custom",
    "mode": "Indexed",
    "policyRule": {
      "if": {
        "allOf": [
          {"field": "type", "equals": "Microsoft.Storage/storageAccounts"},
          {"field": "tags.data-classification", "exists": "false"}
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

2. Access review configuration

accessReview:
  name: gdpr-data-readers-quarterly
  scope: group
  groupName: gdpr-data-readers
  reviewers:
    - role: manager
    - role: data-owner
  recurrence: quarterly
  autoApplyDecisions: true
  defaultDecision: deny

3. Python audit query for suspicious access

from azure.monitor.query import LogsQueryClient
from azure.identity import DefaultAzureCredential

client = LogsQueryClient(DefaultAzureCredential())
query = "AzureDiagnostics | where Category == 'SQLSecurityAuditEvents' | where statement_s contains 'SELECT' | where database_principal_name_s == 'gdpr-data-readers' | summarize count() by client_ip_s, bin(TimeGenerated, 1h)"
result = client.query_workspace("law-workspace-id", query, timespan=None)
for table in result.tables:
    for row in table.rows:
        print(row)

Security Hardening

• Enforce MFA and phishing-resistant methods for all privileged and sensitive data access
• Use PIM/JIT for admin roles instead of standing privileges
• Encrypt data at rest with platform-managed or customer-managed keys and enforce TLS 1.2+
• Segment workloads so analytics, support, and operations teams have separate roles
• Mask or tokenize highly sensitive fields where full values are not required
• Forward logs to a centralized SIEM with retention aligned to legal and policy requirements
• Use break-glass accounts sparingly, monitor continuously, and exclude them only from controls that would prevent emergency access

Comparison

Troubleshooting

Error 1: Group not resolved in Azure SQL

Log sample:

Msg 33134, Level 16, State 1, Line 1
Principal 'gdpr-data-readers' could not be created. Only connections established with Active Directory accounts can create other Active Directory users.

Fix: Connect with sqlcmd -G using an Entra-authenticated admin and verify the SQL server has an Entra admin configured.

Error 2: Conditional access blocks automation

Log sample:

SigninLogs: Status=Failure, ResultDescription=Access has been blocked due to Conditional Access policies. Client app=Other clients, Grant Controls=Require multifactor authentication

Fix: Move automation to managed identities or service principals with certificate auth, then scope conditional access separately for workload identities.

Error 3: Missing audit events in Log Analytics

Log sample:

AzureDiagnostics | where Category == "SQLSecurityAuditEvents"
No results found from the last 24 hours.

Fix: Confirm diagnostic settings target the correct workspace, verify the database resource ID, and wait for ingestion latency before testing again.

Best Practices

Do

• Map access to business purpose such as customer support, fraud investigation, or payroll processing
• Use attribute-based controls for geography, department, and employment status
• Review high-risk access more frequently than standard access
• Keep evidence of approvals, revocations, and review decisions in the SIEM or IGA platform

Don't

• Do not grant broad db_owner or subscription-level roles for convenience
• Do not rely only on annual reviews for sensitive personal data access
• Do not mix human admin accounts with automation identities
• Do not store audit logs only on the same system being audited

A concrete example is to grant support analysts read-only access to pseudonymized customer records, while a separate approved workflow reveals direct identifiers only for regulated cases with full audit logging.