What is a Data Processing Agreement (DPA)?
A Data Processing Agreement is a legally binding contract between a data controller and a data processor. It governs how personal data is processed and ensures compliance with GDPR Article 28. In the Debitura ecosystem, your clients (creditors) act as the data controller, and Debitura acts as the data processor. This means creditors determine the purpose of data processing (collecting outstanding debts), while Debitura processes debtor personal data on their behalf and under their instructions.
For a detailed explanation of GDPR roles and responsibilities, see Data protection and DPA fundamentals.
Why this matters for referral partners
As a referral partner, you integrate with Debitura through dedicated APIs and may submit cases on behalf of your clients. With the Starter Integration, the collection request you send carries your client's and the debtor's details. With the Full Integration, your platform creates cases and reads case data through bearer tokens. Either way, personal data (debtor names, contact details, addresses, financial claim details, and supporting documents) flows through the platform. Understanding how this data is protected helps you inform your clients, maintain trust, and align with your own compliance obligations.
Your clients can request a DPA from Debitura at any time. It is not required before personal data can be processed. The DPA is not part of the API-driven referral onboarding flow. Instead, Debitura provides a self-service DPA wizard that creditors complete by logging into the Debitura platform directly. This wizard covers company data confirmation, authority attestation, digital signing, and adding a privacy policy snippet to the creditor's website as required by GDPR Article 13. There are no API endpoints for the DPA process.
GDPR roles in the referral model
The referral partner model involves several actors with distinct data responsibilities:
Creditor (your client): Data controller. Determines the purpose of processing. Responsible for putting GDPR Article 28 terms in place, which they can do by requesting a DPA from Debitura.
Debitura: Data processor. Processes debtor personal data on the creditor's instructions. Does not use debtor data for its own purposes.
Collection partner: Performs actual debt recovery work. Operates under the legal framework established by the contracts and signatures framework.
Referral partner (you): A business that brings clients to Debitura, usually a software platform connected through the Starter or Full Integration. With the Starter Integration, sends collection requests and reads their status. With the Full Integration, accesses case data through scoped, time-limited bearer tokens issued via the Referral Partner API.
How your clients sign the DPA
The DPA is not part of the API-driven referral onboarding flow. If your client requests a DPA, they complete it separately by logging into the Debitura platform. The DPA wizard is a five-step process available to creditor admin users:
Review and confirm company data (creates an immutable snapshot of company details at signing time)
Review the DPA document and attest to signing authority
Provide a digital signature
Add a GDPR Article 13 privacy policy snippet to their website
Final confirmation
The signed DPA is stored as a PDF with a SHA256 integrity hash. Every action in the DPA process is logged in an audit trail capturing event type, user identity, and timestamp.
Bearer token security and data access
When your integration accesses the Customer API on behalf of a client, it uses short-lived bearer tokens (JWT) with a 30-minute expiry. These tokens are scoped to a specific client and include audit metadata:
Tokens are signed using HMAC-SHA256 and transmitted over HTTPS only
Each token issuance is logged with IP address and user agent for anomaly detection
Tokens can be revoked in the event of a security incident
No refresh mechanism exists; a new token must be requested after expiry
For more on how your integration connects to Debitura, see API and integration overview.
Data retention and deletion
How long data is kept depends on the type of data:
Data type | Retention period |
Active account and case data | While the creditor's account is active |
Account data after closure | Personal data is scheduled for anonymization 30 days after the closure request; cleanup of stored files and linked external records runs separately and can take longer. Account closure starts scheduled anonymization and separate cleanup. Required financial and linked records can remain; there is no automatic process that permanently removes every account and financial record after seven years. Contact Debitura for the scope of a specific retention or erasure request. |
Audit logs | No fixed retention period. Audit records are kept until a specific process removes them; there is no automatic archival, pseudonymization or deletion after a set number of years. |
After a client requests account closure, access to the closing account is revoked immediately and anonymization of their personal data is scheduled for 30 days later - company and debtor names, contact details and addresses are anonymized, and cleanup of the account's stored files and linked external records starts. Some provider-held history may be retained under a documented exception, so closure is not a promise that every copy held by every service disappears. The account itself is not deleted at that point: collection partners keep the anonymized case history for billing purposes. Required financial and linked records can remain after that; there is no automatic process that permanently removes every account and financial record after seven years. Audit logs follow their own rule: no fixed retention period, and no automatic archival or pseudonymization after a set number of years.
GDPR rights and requests
Your clients, as data controllers, are responsible for responding to GDPR requests from debtors. Debitura supports these obligations:
Data Subject Access Requests (DSAR): Creditors can contact [email protected] to request an export of debtor data held by Debitura.
Erasure requests (GDPR Article 17): Creditors can contact [email protected]. Some records, such as audit logs and financial records, may be kept where the law requires it.
The controller normally must respond within one month. Any applicable extension or refusal must be communicated under the relevant rules; acknowledgement alone does not complete the response. See the European Data Protection Board (EDPB) guidance on respecting individuals' rights.
Audit trails
Debitura records defined events, including user-management and DPA-signing events. These records are not a complete log of every case view, document download or processing activity. Fields and retention vary by event; for example, password-login audit rows do not contain an IP address. Audit records have no fixed retention period.
The DPA audit log follows its own, separate rule and is not covered by the above: if the creditor party anonymizes, that DPA's audit-log rows are deleted outright; if a collection partner anonymizes, its DPA audit rows survive but have IP address, user agent, browser data and event payload cleared.
What to expect
Clients handle the DPA directly with Debitura. The DPA is completed through the Debitura platform (not via API). You do not need to facilitate the DPA signing, and a client who has not completed one can still have their cases processed.
Your API access is scoped and audited. With the Full Integration, bearer tokens limit access to a specific client's data for a short time window. Each token issuance is logged.
Data is not shared beyond the collection workflow. Debitura processes debtor data solely for debt collection on the creditor's instructions. Debitura does not use debtor data for its own purposes.
Future Partner-Debitura DPAs. The DPA architecture supports agreements between partners and Debitura. If formal referral partner DPA requirements are introduced, this article will be updated.
Related resources
Data protection and DPA fundamentals - GDPR roles and responsibilities explained
Referral program overview - What you earn, when, and what counts
Developer Docs: Developers: For technical details on bearer token authentication and API integration, see Developer Docs: Referral Partner API.