Request a Data Processing Agreement

A DPA is a written agreement that governs one party’s processing of personal data on behalf of another. Depending on the law and arrangement, it can document instructions, responsibilities, safeguards, assistance, and what happens to personal data when the service ends.

For example, GDPR Article 28 requires a binding controller–processor contract to describe the processing and include specified processor duties. See the official text of Regulation (EU) 2016/679, Article 28.

A DPA may be needed when a customer engages a provider to process personal data on the customer’s documented instructions. Whether it is required depends on the actual service, the parties’ roles, the data, the people concerned, processing locations, and applicable law.

Browsing this public website or sending an ordinary business enquiry does not by itself establish that ClarifyData is acting as the visitor’s processor. A proposed product trial, customer dataset workflow, or other service must be assessed separately before personal data is supplied.

A controller generally determines why and how personal data is processed. A processor generally handles personal data on behalf of a controller and under documented instructions. The same organization can have different roles for different activities.

The parties must determine and document their roles from the real service arrangement. This page does not declare ClarifyData a processor for every interaction and does not shift a customer’s responsibility for lawful collection, instructions, notices, rights handling, or high-impact decisions.

A usable DPA and its processing schedule should identify, at minimum:

• The subject matter and duration of processing.
• The nature and purpose of each processing activity.
• The categories of personal data, including whether sensitive or special-category data is involved.
• The categories of data subjects whose information will be processed.
• The customer’s documented instructions and each party’s rights and obligations.
• The approved processing and storage locations, retention periods, and deletion or return instructions.

These facts cannot be responsibly completed as generic website copy. They must be agreed for the customer and service before processing begins.

Depending on the law and arrangement, a DPA commonly addresses:

• Processing only on documented instructions and notification if an instruction appears unlawful.
• Confidentiality commitments for authorized personnel.
• Technical and organizational security measures appropriate to the agreed risk.
• Authorization, notice, and flow-down terms for subprocessors.
• Approved international-transfer locations and safeguards.
• Assistance with data-subject rights requests.
• Security-incident notification and support responsibilities.
• Assistance with impact assessments or regulator consultation where applicable.
• Deletion or return of personal data at the end of the service, subject to lawful retention.
• Information and audit arrangements needed to demonstrate compliance.

Security commitments should match the data, architecture, access model, providers, locations, and risks of the actual service. A DPA may attach a schedule describing access control, confidentiality, resilience, recovery, testing, incident response, deletion, and other measures where applicable.

This page does not promise particular encryption standards, certifications, audit reports, data residency, or zero-retention behavior because those facts are not established by the current public website code.

A customer-specific assessment should identify every relevant hosting, email, support, infrastructure, and processing provider; the service each performs; its processing location; and the mechanism used for any restricted transfer.

The current public forms use FormSubmit for email delivery, but a future customer service may use a different architecture. The final subprocessor list and transfer terms must reflect the service actually purchased and deployed.

Send a request to Usman@geniusmindzone.com before providing customer personal data. Include enough non-sensitive information to scope the discussion:

• Customer legal name, contact, and relevant jurisdiction.
• Proposed ClarifyData service, use case, and expected duration.
• Categories and approximate volume of personal data and data subjects.
• Whether health, biometric, children’s, financial, employment, or other sensitive data is involved.
• Required locations, retention or deletion instructions, security requirements, and vendor-review materials.

Do not send sample personal data, patient information, credentials, or confidential datasets in the initial request.

The registered ClarifyData entity, business address, governing law, signing authority, service architecture, security schedule, approved subprocessors, transfer terms, incident commitments, audit process, liability allocation, and final deletion or return terms all require owner, technical, customer, and legal confirmation.

Viewing, linking to, or submitting a request through this page does not execute a DPA, amend any contract, or authorize ClarifyData to process customer personal data. A DPA becomes effective only when the correct agreement is completed and accepted by authorized parties in the manner stated in that agreement.