Register

Please register below to gain access to exclusive insights, case studies, reports and more.

Country*

FAQs Regarding Aleph’s Data Processing Agreement (DPA)

FAQs Regarding Aleph’s Data Processing Agreement (DPA)

FAQs Regarding Aleph’s Data Processing Agreement (DPA)


To help you better understand our Data Processing Agreement (DPA) and how we handle data protection, we've compiled this list of Frequently Asked Questions (FAQs). 

These FAQs address common inquiries regarding our DPA terms, data processing practices, and how we ensure compliance with relevant data protection regulations, including GDPR where applicable. We've structured these answers to be clear, transparent, and informative, reflecting our commitment to building a strong foundation of trust and collaboration with our clients. 

We encourage you to review these FAQs, and if you have any further questions, please do not hesitate to reach out to us.

Question: Can we send Aleph our DPA template for review?

Answer: We appreciate you offering to share your Data Processing Agreement (DPA) template with us. We understand that you want to ensure the agreement aligns with your specific requirements.

To streamline the process and ensure efficiency for both of our legal teams, we generally recommend that your legal team review our standard DPA first. Our DPA is carefully tailored to address the unique aspects of our services and data processing activities, helping us to comply with all relevant data protection regulations.

This approach has proven to be a smooth and efficient starting point for most of our clients, as it allows us to quickly identify any areas where adjustments might be needed.

However, we are open to discussing your specific needs and concerns. After your team has had a chance to review our standard DPA, we can certainly address any questions or proposed modifications you may have.

We value your partnership and want to work collaboratively to establish a mutually agreeable and compliant DPA.

Question: Why do we need a DPA? The data protection clauses in the advertising agreement contradict the DPA terms.

Answer: We understand your concern about the potential conflict between the data protection clauses in our Advertising Agreement and the terms of the Data Processing Agreement (DPA). Let's clarify how they work together.

Essentially, we have two different types of data processing relationships with you, and they each require different agreements:

1. C2C (Controller to Controller) mutual obligations - Advertising Agreement

The Advertising Agreement states that each Party is a Controller for processing personal data of the other Party's representatives for a number of purposes. For example, Aleph may process personal data of Client's representatives to provide customer support to Client, respond to Client’s questions about the agreement, manage invoicing and payments, and resolve any disputes that may arise between the Parties. Aleph determines the purposes and means of the processing, as does the Client for the same or equivalent processing activities. 

2. C2P (Controller to Processor) DPA

In order to be able to effectively render our services under the Advertising Agreement, Aleph processes certain Client end user information (individuals who ultimately use or intended to ultimately use Clients' products and/or services). We only process this personal data on your behalf and in accordance with your instructions, as agreed and documented in the C2P DPA. As a result, we are considered Client's Processor (or Sub-processor, depending on the precise data flows) for this processing. Please refer to Annex A (ii) of our DPA for the details of the processing.

Why the Separate Agreements?

  • The Advertising Agreement covers the general business relationship, while the DPA addresses the specific legal requirements for processing end-user personal data.

  • These are distinct legal concepts and require different agreements, as they are used for different data processing activities.

  • By separating the two, we make sure that each data processing activity is covered by the appropriate legal framework.


Question: We won't be conducting Lead Gen campaigns / We won't be sharing any personal data with Aleph. Why do we have to sign a DPA?


Answer: Aleph Group has conducted a comprehensive assessment of our service offerings across all platforms to identify instances where we act as a Data Processor. Please refer to Annex A (ii) of our Data Processing Agreement (DPA) for detailed information on our processing activities and the conditions under which we may access end-user personal data.

Even if you are not currently sharing personal data with us, a Controller to Processor (C2P) DPA is required for services involving TikTok, Meta, Snapchat, Reddit, Amazon, or X. This is because:

  • Potential for Future Data Processing: Business needs and operations can evolve rapidly. There's a possibility you might grant us access to your accounts or share with us databases with end-user personal data, enabling us to process end-user personal data in the future.

  • Proactive Global Compliance: Aleph Group prioritizes global data protection compliance. Requiring a DPA upfront ensures we are prepared for any potential processing activities, avoiding any periods without necessary legal safeguards.

  • Triggered by Actual Processing: The terms of the DPA will only apply if and when actual processing of personal data commences.

This approach ensures both parties are protected and compliant with applicable data protection regulations, including GDPR where relevant, across all our operating markets.

Question: Why is Aleph a Processor when providing Meta, TikTok, X, Snapchat, Reddit, Amazon services?

Answer: We understand it's important to clarify our role as a Data Processor when we provide services related to platforms like Meta, TikTok, X, Snapchat, Reddit, and Amazon. While we might not always directly access your or your clients' end-users' personal data, there are specific situations where we do, and it's essential to understand when and how this occurs.

Specifically, we may access personal data when you or your clients run lead generation campaigns, or when you choose to share end-user data with our teams. However, this access is always subject to certain conditions and criteria, which we'll explain in detail for each Advertising Platform below.

This explanation aims to provide transparency and ensure you understand how we handle data in these specific scenarios.

  1. Why is Aleph a Processor when providing Meta services?

I.  Advertiser creates a lead generation form on Meta ("instant form"). In that case, the end user does not visit the customer's page but rather fills out the form on Meta. The information provided by the end user is then visible and downloadable inside the ad account and on the ad level of the campaign that was set up for this goal. This information remains available for 90 days. After that period, Meta by default restricts access to said data. 

Ii.  Our customer shares their Meta page with us. Only admins of the page can access the information mentioned under i. Since Aleph only owns clients’ ad accounts, here, by default, we do not have admin rights and will only be able to access any personal data following customer's action (Meta page sharing with Aleph ) and point iii. 

iii. Aleph team members assign an admin role to themselves for the Meta page. Only then we can access the information gathered within the instant form. 

  1. Why is Aleph a Processor when providing Tiktok services?

For the conduction of Lead Generation campaigns, we create a Lead Generation form on Tiktok (“instant form”) and in this process, our customer discloses Personal Data to TikTok.

Additionally, we download and forward to our Customer the information from the Lead Generation campaigns since they do not have that option to proceed to those activities themselves, due to not having full admin rights to Aleph.

  1. Why is Aleph a Processor when providing Snapchat services?

The Customer discloses Personal Data to us when conducting in-app Lead Campaigns, by granting us access to their Ads Manager.

Alternatively, the Customer discloses Personal Data to us when conducting Lead Campaigns, by requesting us to launch the campaign using our Ads Manager.

  1. Why is Aleph a Processor when providing X services?

Our Customer discloses Customer Personal Data to X by creating a new targeted audience list and uploading it directly to the platform, to which we are granted access rights.

Alternatively, there is the option for us to create a new audience list on behalf of our client, with the latter providing us information about it for direct upload and access.

  1. Why is Aleph a Processor when providing Amazon services?

Our Customer discloses Personal Data by creating a hashed data file (“File”) and sharing it with us to upload on the Platform. Since the Personal Data is encrypted and we do not have access to the encryption key, the data subjects and their information are non identifiable to us.  

  1. Why is Aleph a Processor when providing Reddit services?

Our Customer provides a list of new targeted audiences to Aleph for direct upload on Reddit. This process takes place on either pre-hashed emails and unhashed mobile advertising IDs (“MAIDS”) or unhashed emails and MAIDs.

Question: Are applicable platforms your subprocessors - do you have data processing agreements with Applicable Platforms?

Answer: The platforms we represent do not consider themselves to be sub-processors in relation to Aleph or vice versa, and therefore we do not have sub-processor agreements with the platforms.

For Managed Platforms, Aleph neither has access to nor inputs any of our clients' personal data into the platforms at all.

Meanwhile, the Self-Service Platforms are not engaged by Aleph to receive and resell their advertising services. Instead, the platforms engage Aleph as a sales partner to perform specific sales and support functions. Since the platform itself is the provider of the advertising services, and the Client/Agency interacts with the platform directly through the advertising accounts and self-service purchases, the Client/Agency also has a direct contractual relationship with the platform.

Therefore, with regard to personal data being processed by Self-Service Platforms, there are two sets of data processing relationships: that between the Client/Agency and Aleph and that between the Client/Agency and the platform.

If the platform processes personal data on the Client/Agency's behalf, the Client/Agency has a separate data processing relationship with the platform directly, even in cases where the Client assigns Aleph to access particular data on the platform. The legal aspects of personal data processing performed on the Client/Agency’s behalf on the Self-Service Platforms thus have to be arranged by the Client/Agency itself.

Please note that in this context, the Client/Agency has already accepted the platform’s terms and conditions, including data processing terms, both by accessing its accounts and by entering into the service agreement with Aleph.

In cases where Aleph makes use of sub-processors for international transfers, we make use of either an adequacy decision or apply Standard Contractual Clauses.

If end-user personal data is to be processed by Aleph on the Client/Agency’s behalf, we also propose concluding a Data Processing Agreement with us that outlines all the important aspects of any processing activities that may be performed by Aleph as a processor.

We are happy to share our latest Data Processing Agreement at your request.

Question: We are going to advertise on Advertising Platforms which are not listed in the DPA, such as Pinterest? Why are they missing from the DPA?

Answer: We understand your question about why certain advertising platforms, like Pinterest, are not explicitly included in our Data Processing Agreement (DPA).

To provide clarity, Aleph Group has conducted a detailed review of our data processing activities across all the platforms we support. This review has helped us determine the specific instances where we act as a Data Processor.

Here's a summary of our findings:

  • Platforms Requiring DPA (Processor Role): For services on platforms like Reddit, Snapchat, TikTok, Amazon, X, and Meta, we typically act as a Data Processor. This is because these platforms often require us to handle specific audience personal data to effectively manage your advertising campaigns.

  • Platforms Not Requiring DPA (Non-Processor Role): For other platforms (e.g., Pinterest), our services generally do not involve accessing or processing personal data of your ad viewers or target audiences in a way that necessitates a DPA. In these cases, our interaction with personal data is limited, or the platform itself handles the processing directly.

Therefore, including platforms where we don't act as a Processor in the DPA would create an inaccurate representation of our data processing responsibilities. The DPA is designed to cover the specific situations where we are handling personal data on your behalf.

We want to assure you that we still take data privacy seriously on all platforms. We adhere to industry best practices and applicable regulations to protect any data we may encounter, even if a formal DPA isn't required.

Question: We are an Agency and we do not process end user personal data. We are not a Controller. Why do we need to sign a DPA?

Answer: Even though your client is the Controller, and you, as the Agency, are the Processor of the end-user data, a DPA with Aleph as your Sub-processor is still essential for compliance. Here's why:

  • Agency's Role:

    • As our Agency client, you process certain end-user information on behalf of your client (the Controller) to effectively utilize Aleph's advertising services. This designates you as the Processor.

  • Aleph's Role:

    • Aleph, in turn, acts as your Sub-processor, handling data according to your instructions and as outlined in our DPA.

  • Legal Requirement:

    • GDPR mandates that both Processors and Sub-processors have a DPA in place. This ensures clear responsibilities and accountability for data protection.

    • Clause 2(b) of our DPA specifically addresses this, stating that when a Customer (you) acts as a Processor, Aleph becomes the Sub-processor, without altering either party's obligations.

  • Proactive Compliance:

    • Initiating data processing without a DPA creates a compliance risk. A "retroactivity clause" in a later DPA won't rectify this.

    • We're being proactive to ensure GDPR compliance from the outset.

  • Future-Proofing:

    • Signing the DPA now ensures that when end-user data processing begins, all data protection terms are already in place.

Question: Can we delete any platforms listed in Annex A that we won’t be advertising on?

Answer: We understand you might prefer to remove platforms you don't currently plan to use from Annex A of our Data Processing Agreement (DPA). However, it's important to keep all listed platforms to ensure the DPA remains comprehensive and adaptable to future advertising campaigns or agreements.

Here's why:

  • Future Flexibility: Annex A provides a complete overview of all potential data processing activities we might undertake. This approach allows the DPA to cover any platforms you might use in the future, even if they're not part of your immediate plans.

  • Avoiding Amendments: Removing platforms now would create inconsistencies and necessitate amendments to the DPA later on, which would be time-consuming and inefficient for both of us.

  • Clear Applicability: To avoid any confusion, we want to emphasize that the data processing information related to a specific platform applies only when that platform is actually included in a main agreement or campaign.

In essence, keeping all platforms listed in Annex A provides a convenient and proactive way to manage data processing activities. It ensures that the DPA is ready to cover any future advertising needs without requiring additional paperwork or delays.

Question: Why are X, TikTok, Meta, Snapchat, Reddit and Amazon (hereinafter also “Advertising Platforms”) not included in the Subprocessor list? 

Answer: We understand your question about why these Advertising Platforms aren't listed as Subprocessors in our Data Processing Agreement (DPA). Let's clarify the situation.

For services related to these Advertising Platforms, the account setup can vary. It might be created by you, by us, or by the platform's support. However, importantly, you remain the account holder throughout our contract and even after it ends. This means you have ultimate control over the account.

Because of this, we can't classify these platforms as our Subprocessors. Here's why:

  • Your Account Control: You own and control the accounts on these platforms at all times.

  • Service Independence: Our services on these platforms don't rely on us accessing end-user personal data in a way that would make them our subprocessors (as explained in section 1 of the DPA).

  • Your Access Decisions: You decide whether to grant us limited access for specific tasks, like creating new audience lists (often involving hashed data). This access is optional and doesn't impact our contract performance.

Essentially, we don't engage these Advertising Platforms as Subprocessors in the traditional sense. There's no direct Processor (Aleph) to Subprocessor (Platform) relationship in place that we can extend to you.

Instead, we strongly recommend that you establish a direct Controller-to-Processor relationship with each of these platforms. You can do this by contacting the platforms directly or, more likely, by accepting their DPAs, which are usually available on their websites.

This is crucial because, as the Controller and account holder, you are the one directly sharing any personal data with these platforms, without our involvement or access. This direct relationship ensures you have the proper protections in place.

Question: Why do breaches of the Data Processing Agreement (DPA) fall within the general liability cap of the Advertising Agreement?


Answer: Aleph's standard practice is to cap liability for DPA breaches at one time the total value of advertising purchased by the customer in the 12 months preceding the incident. This approach is based on several key considerations:


Market Standard: Our liability cap aligns with industry norms for data processing agreements.

Risk Proportionality: Higher liability caps are typically reserved for situations involving exceptionally sensitive data or complex processing. Our processing activities, as outlined in Annex A of our DPA, are generally limited in scope and often ancillary to the core advertising services.

Realistic Risk Assessment: The cap reflects a realistic assessment of the potential risks associated with our data processing activities. In many cases, our service delivery is not primarily dependent on processing end-user personal data, but rather on optional platform features (see Annex A for details).

Balanced Liability Triggers: The DPA's liability triggers are carefully balanced against the proposed cap.

Commercial Reasonableness: Imposing unlimited or significantly higher liability would create an unsustainable risk for Aleph, potentially exceeding our financial capacity and insurance coverage. This would result in a commercially unbalanced agreement.


Essentially, Aleph is not an insurance provider for all data protection risks. Our liability cap is designed to be fair, reasonable, and consistent with industry practices, while acknowledging the specific nature and scope of our data processing activities. Furthermore, it's important to recognize that the platforms through which we provide services are themselves acting as Data Processors for our clients. Therefore, we believe it's reasonable for our DPA terms to align with the industry standards you've already accepted when engaging with those platforms directly.


Question: What does limitation of liability include?

Answer: The limitation of liability is cumulative and not per incident. It includes any and all losses, such as any indirect, exemplary, special, consequential, incidental or punitive damages; any loss of profits, business, or anticipated savings; any loss of, or damage to data, reputation, revenue or goodwill; any regulatory fines and compensation to data subjects. 

Question: We want to exclude gross negligence, wilful misconduct and fraud from the limitation of liability. 

Answer: We understand your request to exclude gross negligence, willful misconduct, and fraud from our liability limitations under the Data Processing Agreement (DPA). We want to explain our position and find a solution that works for both of us.

The Controller-Processor relationship, as you know, is established by GDPR. This means the roles and responsibilities aren't entirely negotiable, and we need to adhere to the legal framework it sets.

Regarding liability, GDPR places certain responsibilities on Controllers. If we were to accept unlimited liability for all DPA breaches, even those involving gross negligence, willful misconduct, or fraud, we would essentially be taking on your liability under GDPR, which includes liability for the actions of your Processors.

We believe this would create an unbalanced situation where we, as your service provider, would bear the full legal burden that GDPR assigns to you as the Controller.

We also need to consider the specific nature of DPA breaches. Because these agreements are required by GDPR, they have a unique legal context that influences how liability is handled.

While we understand your concerns, we need to balance them with the legal requirements and the reality of our role as a Processor.

Question: Can you give an example of DPA violations, i.e. if there's a violation, which repercussions would follow? And also, how and what would Aleph do if such violation occurred?

Answer: It's important to understand how we approach data protection and what happens in the rare event of a Data Processing Agreement (DPA) violation.

The DPA outlines various responsibilities we have as a Data Processor. For instance, we're required to maintain detailed records of all processing activities we perform on your behalf. This ensures transparency and accountability.

Another key obligation is to assist you in responding to Data Subject Requests (DSRs) related to the data we process for you. If, in the unlikely event, we were to delay or fail to provide adequate assistance, it could potentially impact your ability to meet regulatory deadlines or respond thoroughly to a data subject.

While it's difficult to give precise consequences or remediation steps without knowing the specific circumstances of a potential violation, we can assure you that we take our DPA obligations very seriously.

Here's how we would approach a violation:

  • Immediate Investigation: We would conduct a thorough investigation to understand the cause and scope of the violation.

  • Prompt Communication: We would keep you informed throughout the process, providing timely updates and transparent communication.

  • Remediation and Mitigation: We would take immediate steps to rectify the issue and mitigate any potential harm. This might include implementing corrective measures, providing additional resources, or adjusting our processes.

  • Collaboration and Support: We would work closely with you to ensure a swift and satisfactory resolution.

  • Continuous Improvement: We would use the experience to improve our processes and prevent future occurrences.

Our goal is to build trust and ensure a strong partnership. We are committed to upholding the highest standards of data protection and will always work diligently to resolve any issues that may arise.

Question: We want to amend the definition of data breach in order to get notified for any security incident affecting our systems regardless of whether the incident is a data breach. Can we do so?

Answer: We understand your desire to be informed about any security incident affecting our systems, and we appreciate your proactive approach to data security. However, defining "data breach" so broadly that it includes every security incident presents some significant challenges, which we'd like to explain.

Here's why:

  • Focus on Impact to Personal Data: Data breach definitions, especially under regulations like GDPR, are specifically tied to incidents that compromise the security, confidentiality, integrity, or availability of personal data. This focus helps us prioritize the most critical incidents that pose a risk to individuals.

  • Efficient Incident Response: If we were obligated to report every security incident, even minor ones that don't involve personal data, it could divert our resources from effectively investigating and mitigating actual data breaches. This could, ironically, slow down our response to the incidents that truly matter most to protecting your audience's information.

  • Clear and Actionable Notifications: A flood of notifications about non-data breach incidents could overwhelm you and make it harder to quickly identify and respond to genuine data protection risks. We want to ensure that when we notify you of a data breach, it's a clear and actionable signal requiring your prompt attention.

That being said, we are committed to transparency and maintaining a strong security posture.

Here's what we do to keep you informed:

  • Robust Security Measures: We have robust security measures in place to protect our systems and your data.

  • Proactive Monitoring: We actively monitor our systems for security incidents.

  • Data Breach Notification: We will, of course, promptly notify you of any confirmed data breaches that meet the legal definition and may impact your audience's personal data, in accordance with our contractual obligations and applicable laws.

Question: We need you to share with us the Intragroup DPA.

Answer: We understand your request for a copy of our Intragroup Data Processing Agreement (DPA). This document outlines the data processing arrangements between Aleph's internal entities.

Unfortunately, due to the commercially sensitive and confidential nature of the Intragroup DPA, we are unable to share it with external parties.

However, we want to assure you that our internal data processing practices are fully compliant with relevant data protection regulations, including GDPR. We implement robust safeguards to ensure the security and privacy of personal data across our organization.

To provide you with further assurance, we are happy to share details about the specific data protection measures we have in place. Please let us know if you have any specific questions about our data processing practices, and we will do our best to address them within the boundaries of confidentiality.

Question: When do you process personal data outside the EU/EEA?

Answer: As Aleph Group operates in over 50 countries, with teams distributed globally, there are instances where personal data may be processed outside the EU/EEA. This typically occurs when delivering services under our Advertising Agreement that require the involvement of our international teams or subprocessors.

We understand the importance of data privacy and want to assure you that any transfer of personal data outside the EU/EEA is conducted in strict compliance with GDPR and other applicable data protection regulations.

To ensure transparency, we maintain a comprehensive list of our subprocessors, including their locations, in Annex A(iii) of our Data Processing Agreement (DPA). This document details the safeguards we have in place to protect your data during international transfers.

We also implement appropriate transfer mechanisms, such as Standard Contractual Clauses (SCCs) or other legally recognized safeguards, to ensure your data is protected to the same high standards as within the EU/EEA.

If you have any specific concerns or questions about our international data transfers, please don't hesitate to ask.

Question: Why are the SCCs included in the DPA? Is Aleph transferring personal data outside the EU? 

Answer: Aleph has global operations, meaning in certain instances there could be a transfer of personal data to a third country depending on team structure and internal operations. We do not use any vendors/sub-processors located in a third country when providing our Meta, TikTok, Snap, and X services. Although the implemented SCCs are not currently applicable, they cover processing in the event of an international transfer, but can be deleted if redundant.

Question: Can we amend the definition of Sub-processors to include only Sub-processors engaged by the Aleph entity signing the DPA?


Answer: We understand your request to limit the definition of Sub-processors to those directly engaged by the Aleph entity signing the Data Processing Agreement (DPA). However, we're unable to make that specific amendment.

Let us explain why: Aleph Group operates with a structure that often involves shared services and resources across our various entities. This means that a Sub-processor contracted by one Aleph entity might actually be handling personal data related to the services you're receiving, even if they aren't directly contracted by the specific Aleph entity you're working with under this DPA.

Our aim is to provide a complete and accurate picture of our data processing activities. Including all relevant Sub-processors, even those engaged by other Aleph entities, ensures transparency and reflects the reality of our shared services model.

We want to assure you that all Sub-processors, regardless of which Aleph entity contracted them, are subject to the same stringent data protection requirements and safeguards. We have robust contractual agreements in place to ensure compliance with GDPR and other applicable data protection laws.

We understand the importance of clear information about data handling. If you have any specific concerns about our Sub-processor arrangements, please don't hesitate to ask. We're happy to provide further details about our data protection practices and safeguards.

Question: Which national supervisory authority is in charge of the DPA and which national data protection laws are applicable? We want to include references to our local supervisory authority and laws. 

Answer: We understand your desire to include specific references to your local supervisory authority and data protection laws in our Data Processing Agreement (DPA). However, determining the precise applicable legal framework can be complex, as it involves several factors.

As Aleph Group operates globally, and our services may involve processing data related to individuals in various jurisdictions, the conduct and relationship of the parties could potentially fall under the jurisdiction of multiple supervisory authorities. This is further complicated by the fact that the Aleph entity signing the DPA might be located in a different country than your business or the individuals targeted by your advertising campaigns.

While we can't definitively specify one single supervisory authority or set of national data protection laws, we can assure you that we are committed to complying with all applicable data protection regulations, including GDPR, which sets a high standard for data protection across the European Economic Area (EEA).

We understand the importance of local compliance and are happy to discuss specific concerns or questions you have regarding your local data protection requirements. If you provide us with details about your location and the target audience of your campaigns, we can offer more tailored guidance on relevant data protection considerations.

We also recommend that you consult with your own legal counsel to ensure full compliance with your local data protection laws.

Question: Can Aleph share the DPAs it has with its sub-processors? 

Answer: We understand your interest in reviewing our Data Processing Agreements (DPAs) with sub-processors. We appreciate your diligence in ensuring data protection.

While we cannot share the full, unredacted sub-processor contracts, we want to explain why and what alternatives we can offer. Our sub-processor contracts contain sensitive commercial information, such as pricing and specific business terms, as well as detailed security provisions that are commercially confidential. Sharing this level of detail could put us at a competitive disadvantage.

However, we are committed to providing you with assurance about our sub-processor arrangements.

Here's how we can address your concerns:

  • Summary of Key Provisions: We are happy to provide a summary of the key data protection provisions included in our sub-processor agreements. This would cover essential elements like data security, confidentiality, and compliance with GDPR.

  • Audit Rights: Our DPA with you includes audit rights, which can be exercised under agreed-upon conditions. During an audit, you can review relevant aspects of our sub-processor arrangements to verify compliance.

  • Due Diligence Information: We can share information about our sub-processor selection process and the due diligence we conduct to ensure they meet our data protection standards. This might include certifications, security assessments, or other relevant documentation.

This approach balances the need to protect our confidential information with your need for transparency and assurance. It also aligns with common industry practice, where full sub-processor contracts are often reviewed during audits rather than as a standard pre-contractual step.

We are open to discussing your specific needs and concerns and finding a solution that provides you with the necessary confidence in our data protection practices.

Question: Can we amend Annex A (ii) of the DPA where the processing information for each platform is detailed?

Answer: We understand your interest in amending Annex A (ii) of the Data Processing Agreement (DPA), which outlines the specific data processing activities for each platform. We appreciate your attention to detail.

To explain why making changes to this section is generally not feasible, it's helpful to understand how Annex A (ii) is created.

Our internal teams have conducted a detailed data mapping exercise. This involves a thorough analysis of the data processing required to deliver our advertising services on platforms like Meta, Snapchat, TikTok, Amazon, Reddit, and X. This mapping is essential to accurately reflect how data is handled to provide those services.

The information in Annex A (ii) is closely tied to the functionalities and technical requirements of each platform. It's not simply a list of options, but a reflection of how the platforms themselves operate and how we must interact with them to deliver effective advertising campaigns.

Therefore, while we appreciate your request, directly modifying the personal data categories or processing activities as described in Annex A (ii) is typically not possible. These descriptions are based on the inherent nature of the platforms.

Our goal is to be transparent and collaborative, while also ensuring that the DPA accurately reflects the technical realities of providing advertising services on these platforms.

Question: Can we make changes to any IT security sections, such as Annex B?

Answer: We understand your interest in ensuring the IT security sections of the Data Processing Agreement (DPA), such as Annex B, fully align with your requirements. We appreciate your focus on data security.

To explain the process for reviewing changes to these sections, it's important to note that any proposed modifications to our technical and organizational measures require careful evaluation by our dedicated IT and Security teams. This ensures that any changes maintain the overall security and integrity of our systems.

We recognize that this review process can sometimes take time, as our IT department has a number of ongoing priorities. We are working to streamline this process to respond to your requests as efficiently as possible.

We also want to assure you that the measures outlined in Annex B represent Aleph Group's established internal security and compliance standards. These standards have been rigorously approved by our IT and Security teams and are designed to provide a strong foundation for data protection.

Furthermore, we're committed to demonstrating our dedication to data security. Several Aleph entities, including those in Spain, Slovenia, Singapore, and Argentina, have achieved ISO 27001 certification. We're actively pursuing certification for our remaining EU entities as well. This certification is a testament to our ongoing efforts to implement industry best practices and maintain the highest levels of data security.

We are open to discussing your specific security concerns and exploring how we can best address them. While direct amendments to Annex B may not always be feasible due to the need for thorough review and the importance of maintaining our core security standards, we are happy to provide detailed explanations of our measures and discuss alternative solutions or contractual clarifications where appropriate.


Question: Can we execute a signed version of the DPA?

Answer: Yes, we can execute a signed version of the DPA if there are specific legal requirements in your jurisdiction which require this. However, typically, signing the Information Table is considered as signing the DPA as well. This is because the DPA is incorporated by reference within our terms and conditions, which are available on our website and linked in the Information Table. By signing the Information Table, you agree to those terms and conditions, including the DPA.

Get in touch
If you're a digital media platform looking to expand internationally, an advertiser looking to reach over 3 billion consumers globally or anyone else seeking digital media solutions, contact us and we'll be in touch about how Aleph can help you grow your business and reach.