Configure Article 30 Records¶

Article 30 requires detailed records of processing activities. This guide walks you through configuring Dxtra to automatically capture and document these required elements.

What Must Article 30 Records Include?¶

GDPR Article 30 requires controllers and processors to maintain comprehensive records of all processing activities. These records demonstrate accountability—showing regulators, data subjects, and auditors exactly what personal data you handle, why you handle it, and how you safeguard it.

For Controllers¶

Controllers must document:

• Name and contact details of the controller and any joint controllers
• Processing purposes for each data category (e.g., customer service, marketing, fraud prevention)
• Categories of recipients who receive data (internal teams, processors, third parties, regulators)
• Transfers to third countries or international organizations and applicable safeguards (SCCs, BCRs, adequacy decisions)
• Retention periods for each data type or how you determine retention
• Description of technical and organizational measures for data security (encryption, access controls, audits)
• Categories of personal data being processed (names, email, transaction history, etc.)
• Categories of data subjects (customers, employees, prospects, etc.)

For Processors¶

Processors must document:

• Name and contact details of the processor and all sub-processors
• Categories of processing on behalf of controllers (e.g., data storage, analytics, backup)
• Name and contact of each controller that the processor works with
• Transfer mechanisms for data transfers outside the EU/EEA
• Categories of personal data and data subjects processed on controllers' behalf
• Retention periods or criteria for determining how long data is kept
• Description of technical and organizational measures protecting data

Step 1: Map Your Processing Activities¶

Before configuring logs, understand what you actually process. This mapping becomes the foundation for your Article 30 records.

Identify Data Sources¶

Start by cataloging every system that collects or processes personal data:

• Customer relationship management (CRM) systems
• Email and communication platforms
• Analytics and tracking tools
• Database systems storing customer or employee data
• File storage and backup systems
• Payment processors and billing systems
• Third-party integrations and APIs

For each source, document: what data enters it, where it comes from, and who maintains it. This inventory prevents processing activities from being accidentally omitted from your Article 30 records.

Map Processing Purposes¶

Align your systems with your documented purposes. Common purposes include:

• Contract fulfillment: Processing necessary to deliver a service you've contracted
• Legal obligation: Processing required by law (tax records, employment law)
• Legitimate interest: Processing for business operations where your interest outweighs data subject rights
• Consent: Processing where individuals have explicitly agreed
• Vital interests: Emergency processing to protect life or health
• Public task: Processing necessary for a public authority function

In Dxtra, map each data source to its primary purpose(s). This ensures your Article 30 records clearly justify every processing activity.

Define Data Categories¶

Document the specific personal data your systems process. Examples include:

• Identifiers (name, email, phone, ID number)
• Contact information (postal address, billing address)
• Financial data (payment method, transaction history, bank account)
• Behavioral data (browsing history, purchase history, preferences)
• Sensitive data (if applicable—health, ethnicity, political affiliation, biometrics)
• Technical data (IP address, device fingerprint, cookies, logs)

Classify data by sensitivity level and retention need. This classification drives your safeguards documentation.

Identify Recipients¶

List every party that receives personal data:

• Internal teams: Which departments or individuals access data (customer service, finance, product)
• Service providers: Processors handling data on your behalf (hosting, CRM, analytics vendors)
• Third parties: Other organizations you intentionally share data with (partners, advertisers, data brokers)
• Regulators: Government agencies that may request data during investigations
• Data subjects: Individuals' access to their own data

For each recipient, document the data categories they receive and the purpose. This becomes part of your Article 30 records.

Step 2: Configure Event Logging¶

Once you've mapped your processing, configure Dxtra to automatically capture processing events that demonstrate compliance.

Select Integration Method¶

Choose how Dxtra receives processing events. Options depend on your systems:

• Application logging: Your application sends events to Dxtra when processing occurs
• Database activity monitoring: Dxtra monitors database queries and logs access patterns
• API-based submission: Systems submit processing events via Dxtra's ingestion APIs
• Log aggregation: Dxtra ingests logs from your existing monitoring infrastructure

Start with your highest-risk systems (those processing sensitive data in large volumes). You can expand integrations over time.

Configure Event Types¶

Define what events to capture:

• Access events: When personal data is read or viewed (supports "audit trail" requirements)
• Modification events: When data is created, updated, or deleted
• Transfer events: When data is shared with recipients or transferred to third countries
• Retention events: When data is evaluated for deletion or retention
• Authorization events: When access controls are modified (who can access what data)

Focus on events that demonstrate lawful processing and adherence to retention policies. Low-value event logging (e.g., logging every cache read) adds overhead without compliance benefit.

Map Events to Purposes¶

Connect logged events to your documented processing purposes:

• When your e-commerce system logs a "process payment" event, associate it with your "contract fulfillment" purpose
• When your analytics system logs user behavior, associate it with your "legitimate interest in product improvement" purpose
• When your customer service system logs a data access, associate it with your "customer service" purpose

This mapping transforms raw events into Article 30-compliant records showing purpose-driven processing.

Step 3: Define Retention Periods¶

Clear retention policies demonstrate you don't keep personal data indefinitely. Document when and how data is deleted.

Establish Retention Rules¶

For each data category, define:

• Active retention period: How long data is kept while actively used (e.g., 2 years for customer data)
• Archival period: How long data is kept in archive before deletion (e.g., 3 additional years for regulatory retention)
• Trigger for deletion: What event triggers data deletion (account closure, contract end, retention period expiry)

Example retention policy:

• Customer transaction data: 2 years active retention, then delete
• Marketing preference data: 3 years, or until consent withdrawn
• Employee records: 3 years post-employment, then delete
• Tax records: 7 years (legal requirement), then delete

In Dxtra, document these policies so Article 30 records reflect a defined, justified retention approach rather than indefinite data storage.

Implement Deletion Schedules¶

Establish automated deletion to enforce retention policies:

• Schedule monthly or quarterly deletion jobs that remove expired data
• Document which systems perform deletion and when
• Log deletion events so your Article 30 records show you actively enforce retention
• Archive deletion logs for 1-2 years to demonstrate compliance during audits

Step 4: Document Safeguards¶

Article 30 requires you to describe the security measures protecting personal data. Document both technical and organizational safeguards.

Technical Measures¶

List the technical controls protecting your data systems:

• Encryption: Data encrypted in transit (TLS) and at rest (AES-256)
• Access controls: Role-based access, multi-factor authentication, principle of least privilege
• Monitoring: Intrusion detection, continuous security scanning, activity logging
• Data masking: Personally identifiable information masked or tokenized in non-production environments
• Backup and recovery: Regular backups, tested restoration procedures, encryption of backups
• Network security: Firewalls, network segmentation, DDoS protection

Organizational Measures¶

Describe how your organization manages data handling:

• Data protection training: Staff annual privacy and security training with documentation
• Access restriction: Policies limiting data access to those with business need
• Data processing agreements: DPAs with all processors defining security requirements
• Incident response: Procedures for detecting, responding to, and reporting breaches
• Vendor management: Security assessments of third parties, audits, regular review
• Privacy by design: Data minimization, pseudonymization where feasible
• Data subject rights: Processes to handle access requests, deletion, portability requests

Step 5: Generate Article 30 Records¶

With your processing mapped and events logged, generate your official Article 30 documentation.

Generating Controller Records¶

Controllers document their own processing:

1. Log into Dxtra and navigate to Processing Logs
2. Review the Processing Activities summary showing all sources, purposes, and recipients you've configured
3. Generate a controller record document (typically a PDF or Word file)
4. The record includes: purposes, data categories, recipients, transfers, retention, and safeguards
5. Review for completeness and accuracy
6. Store the record securely and update it when processing materially changes

Dxtra generates records that controllers can submit to regulators as compliance evidence.

Generating Processor Records¶

Processors generate records documenting processing on controllers' behalf:

1. Navigate to each controller relationship in Dxtra
2. Generate a processor record for that controller relationship
3. The record includes: categories of processing, sub-processors, transfers, and safeguards
4. Share the record with your controller so they can incorporate it into their own Article 30 documentation
5. Update the record when processing changes or new sub-processors are added

Step 6: Maintain and Update Records¶

Article 30 records aren't static. As your processing evolves, your records must evolve too.

Regular Review¶

Establish a review schedule:

• Quarterly reviews: Check that logged events still align with documented purposes
• Annual reviews: Comprehensive audit of all processing activities, purposes, and recipients
• Event-triggered reviews: When new systems are added, purposes change, or recipients expand

During review, verify: - Are all processing activities still necessary? - Have data categories or recipients changed? - Are retention policies still appropriate? - Are safeguards still adequate?

Audit Readiness¶

Prepare for regulatory requests by:

1. Maintaining complete records: Keep Article 30 documentation, processing logs, and safeguard descriptions accessible
2. Generating audit reports: Use Dxtra to generate compliance reports on demand
3. Documenting changes: When processing changes, log what changed, when, and why
4. Retaining evidence: Keep processing logs, deletion logs, and access logs for 1-2 years to demonstrate compliance

When a regulator asks "show me your processing records," you can produce a complete, timestamped audit trail proving lawful, accountable data handling.

Data Subject Audit Trails¶

Beyond overall Article 30 records, you can generate individual audit trails for specific data subjects on request.

Generating Individual Audit Trails¶

Data subjects have the right to know how their data is processed. Dxtra can generate:

• A timeline of all processing events (access, modification, deletion) on an individual's data
• Associated purposes for each processing activity
• Recipient information (who their data was shared with)
• Retention decisions (when their data will be deleted)

Use this capability when responding to Data Subject Rights Requests (DSRRs) or handling privacy inquiries. Individual audit trails prove transparency and strengthen trust.

Frequently Asked Questions¶

• How detailed must my Article 30 records be? Sufficient to demonstrate you've documented all required elements; overly granular logging isn't required. One record per processing activity type is typically adequate.
• Can I use a template? Yes, Dxtra provides Article 30 templates; customize them for your specific processing activities and purposes.
• How often should I update records? Whenever processing materially changes; at minimum conduct annual reviews to ensure records remain accurate.
• What if processing changed before I configured logging? Document the change, explain when logging began, and monitor going forward. Retroactive logging isn't required, but documenting the gap shows good faith.
• Do I need separate records per data source? No. One Article 30 record can document multiple purposes and data sources. Organize by purpose or recipient, not by system.
• How long should I keep Article 30 records? Keep current records indefinitely. Keep historical records (showing prior versions) for 2-3 years to demonstrate continuous compliance during audits.

Related Guidance¶

• Processing Activity Logs
• Automation Overview
• Processor Management

Ready to configure? Log into Dxtra, navigate to Processing Logs, and click "New Article 30 Record."