Data Processing Addendum

Last updated and effective: August 5, 2026.

This Data Processing Addendum (“DPA”)  forms part of and is incorporated into a Digital Advertising Services Agreement, a Master Services Agreement,  the StackAdapt Platform Terms of Use or any other written or electronic agreement (the “Agreement”) between StackAdapt Inc. or one of its affiliates (“StackAdapt”) and you, as the customer (“Client”, and collectively, the “Parties”) for the services made available through the StackAdapt platform (identified either as the “Services”, or the “Platform” herein, as the context requires). This DPA reflects the Parties’ agreement with regard to the Processing of Personal Data.

1. Definitions

Capitalized terms not otherwise defined herein shall have the meaning given to them in the Agreement. In this DPA, the following terms shall have the meanings set out below:

• “Client Personal Data” means Personal Data which is contained in any Client Data.  
• “Data Protection Laws” means any and all applicable data protection, security, or privacy-related laws, statutes, directives, or regulations in full force and effect to the extent they apply to the Personal Data Processed under the Agreement, including but not limited to: (a) the EU General Data Protection Regulation 2016/679 (“GDPR”) together with any amending or replacement legislation, and any EU Member State laws and regulations promulgated or incorporated thereunder; (b) the UK Data Protection Act 2018 and the GDPR as it forms part of the law of England and Wales, Scotland, and Northern Ireland by virtue of section 3 of the European Union (Withdrawal) Act 2018 (“UK GDPR”); (c) the Singapore Personal Data Protection Act, (d) the California Consumer Privacy Act of 2018, Cal. Civ. Code § 1798.100 et seq. (“CCPA”), together with any amending or replacement legislation, including the California Privacy Rights Act of 2020 and any regulations promulgated thereunder; (e) the Canada Personal Information Protection and Electronic Documents Act, S.C. 2000, c. 5 (“PIPEDA”) and any substantially similar provincial laws, as each may be amended, extended or re-enacted from time to time. For the avoidance of doubt, if a Party’s activities involving Personal Data are not within the scope of a given Data Protection Law, such law is not applicable for purposes of this DPA.
• “Data Privacy Framework” or “DPF” means the EU-U.S. Data Privacy Framework, the UK Extension to the EU-U.S Data Privacy Framework and the Swiss-US Data Privacy Framework operated by the U.S. Department of Commerce; as may be amended, superseded or replaced.
• “Data Privacy Framework Principles” means the Principles and Supplemental Principles contained in the relevant Data Privacy Framework available at: https://www.dataprivacyframework.gov/program-articles/Participation-Requirements-Data-Privacy-Framework-(DPF)-Principles; as may be amended, superseded or replaced.
• “Data Subject” means an identified or identifiable natural person whose Personal Data is being Processed. Where applicable, the term “Data Subject” shall refer to “Consumer” as that term is defined under Data Protection Laws.
• “Personal Data” means information that identifies, relates to, describes, is capable of being associated with, or can reasonably be linked, directly or indirectly, with a particular individual or household, or is otherwise defined as “personal data,” “personal information,” or “personally identifiable information” by applicable Data Protection Laws. 
• “Regulatory Authority” means the applicable public authority or government agency responsible for supervising compliance with Data Protection Laws, including but not limited to the UK Information Commissioner’s Office; EU Member State supervisory authorities; Singapore Personal Data Protection Commission; the California Privacy Protection Agency; U.S. state attorneys’ general; and the Canada Office of the Privacy Commissioner of Canada, including any relevant provincial data protection authority. 
• “Prohibited Data” means (i) any information revealing race or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership; (ii) an individual’s full date of birth; (iii) maiden name of an individual’s mother; (iv) an individual’s digitized or other electronic signature (v) genetic data; (vi) biometric data; (vii) data concerning health, which includes all individually identifiable health information that is subject to the Health Insurance Portability and Accountability Act; (viii) data concerning a natural person’s sex life or sexual orientation; (ix) any personal data regarding a minor under the age of 17, or if Applicable Laws of any jurisdiction otherwise define a child or a minor as another age, then personal data regarding a child as thereby defined by the Applicable Laws; (x) any financial account numbers, including financial institution or bank account number, credit or debit card number security or access code, password, expiration date, PIN associated with financial or customer account information, regardless of whether such information is combined with or stored separately from the financial information or any other information subject to the Payment Card Industry Data Security Standards, the Gramm-Leach-Bliley Act, or the Fair Credit Reporting Act;  (xi) a user name, email address or other unique electronic identifier or routing code, which is sent in combination with a personal identification code, password, or security question and answer that would permit access to an online account; (xii) insurance plan numbers that can be used to identify an individual; (xiii) any government-issued identifiers or identification; (xiv) with respect to Imported Data only, any information about individuals domiciled outside the United States, Canada, Australia or the United Kingdom; (xv) any data subject to the Family Educational Rights and Privacy Act; or (xvi) any other “Sensitive Personal Data”, “Special Categories of Data” or substantially similar categories of Personal Data, as defined under Data Protection Laws.
• “Standard Contractual Clauses” means (i) where the EU GDPR applies, the contractual clauses annexed to the European Commission’s Implementing Decision 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council (“EU SCCs”); and (ii) where the UK GDPR applies, the EU SCCs as amended by the UK Addendum.
• “Subprocessor” means, when StackAdapt is acting as a Processor, any third party appointed by StackAdapt to Process Personal Data in connection with the Agreement.
• The terms “Business,” “Business Purpose,” “Controller,” “Process,” “Processor,” “Sale,” “Service Provider,” “Share,” and “Third Party” shall have the same meaning as in the Data Protection Laws, and their cognate terms shall be construed accordingly.

2. Processing of Personal Data

1. Roles of the Parties. The Parties acknowledge and agree that the roles of the Parties with respect to specific Processing activities shall be determined by the nature and purpose of the Processing as described Appendix 1 to this DPA.
   • Where the Parties jointly determine the purposes and means of the Processing of Personal Data, in accordance with Data Protection Laws, the Parties shall be considered joint Controllers.
   • Where StackAdapt Processes Client Personal Data solely on Client’s behalf and in accordance with Client’s instructions, Client shall be the Controller and StackAdapt shall be a Processor. Where StackAdapt acts as a Processor, Section 4 of this DPA shall also apply.
   • Where StackAdapt shares Personal Data with Client, the Parties shall be considered independent Controllers.
2. Compliance with Data Protection Laws. Each Party shall use all efforts necessary to comply with the obligations imposed on it by applicable Data Protection Laws with regard to Personal Data Processed in connection with Services.  Each Party shall inform the other Party promptly if, in its opinion, any development or change of the Processing of such Personal Data breaches the Data Protection Laws. In the event of a material change to Data Protection Laws, such as any change that results in a different classification of a Party in relation to the Services, data localization, or if a transfer mechanism is deemed invalid, the Parties will negotiate a suitable resolution in good faith.
3. Notice and Choice. Client warrants that for the purposes of the Agreement and use of the Services: (i) it has notified Data Subjects through appropriate means reasonably designed to satisfy its obligations under Data Protection Laws about the Processing of Personal Data by Client and StackAdapt, including the use of Online Tracking Technologies; (ii) it is lawfully permitted to share Personal Data with StackAdapt in connection with its use of the Services; (iii) where required by Data Protection Laws it has implemented a mechanism to obtain consent or facilitate opt-outs from Data Subjects, including from any digital properties on which Client deploys Online Tracking Technologies to collect Personal Data and (iv) it will not disclose or make available to StackAdapt any Personal Data relating to Data Subjects that have not consented, or have opted-out of, or otherwise exercised other rights that bar the Processing performed in connection with the Services provided under the Agreement (as applicable) unless this is for the purpose of suppressing such Data Subjects from marketing. Where requested by StackAdapt, as may be required pursuant to Data Protection Laws, or by order, request or other instruction by a Regulatory Authority, Client agrees to promptly provide documentation evidencing that such consent has in fact been obtained from Data Subjects.
4. Prohibited Data. Client shall not provide Prohibited Data to StackAdapt.
5. California Personal Data Processing. To the extent the Parties Process Personal Data subject to the CCPA, the following terms shall also apply:
   • The receiving Party (acting as the “Third Party”) will provide the same level of privacy protection to the Personal Data as required of the disclosing Party (acting as the “Business”) by the CCPA.
   • The Personal Data is made available to the Third Party solely for the purposes specified in the Agreement and Appendix 1 of this DPA.
   • Subject to Section 6 of this DPA, the Business shall be permitted to take reasonable and appropriate steps to ensure the Third Party’s compliance with the CCPA and this DPA, including any reasonable steps to stop and remediate any unauthorized use of Personal Data.
   • The Third Party shall promptly notify the Business in writing if at any time the Third Party makes a determination that it can no longer meet its obligations under the CCPA.
   • With respect to Services for which StackAdapt acts as a Processor, the Parties agree that Client is acting as the Business and StackAdapt is acting solely as a Service Provider with respect to the Processing of Client Personal Data. When StackAdapt is a Processor, StackAdapt will not: (i) Sell or Share Client Personal Data; (ii) retain, use, or disclose Client Personal Data (a) except as necessary to perform the Business Purpose or (b) outside the direct business relationship between StackAdapt and Client; or (iii) combine Client Personal Data with Personal Data StackAdapt has received or receives from another party, or has collected or collects from its own interaction with a Data Subject, provided that StackAdapt may combine such information to perform any Business Purpose.
6. Data Partners. If Client directs StackAdapt to either: (i) disclose Personal Data to a Data Partner or (ii) Process Personal Data received from a Data Partner, Client represents and warrants that it has an executed agreement that contemplates such Personal Data disclosure, sharing and Processing (as may be applicable).

3. Rights of Data Subjects

1. Parties as Joint or Independent Controllers. To the extent the Parties are joint or independent Controllers, each Party will process its own requests for Data Subjects to exercise their rights. With respect to requests from, or on behalf of Data Subjects with regard to the Processing of their Personal Data that is shared between the Parties, including requests to opt-out from the Sale/Share of Personal Data pursuant to CCPA, the parties will collaborate to honor such objections or opt-out requests.
2. StackAdapt as Processor.  When StackAdapt is a Processor, if a Data Subject makes a lawful request directly to StackAdapt seeking to exercise any right available to it under Data Protection Laws that references Client, StackAdapt shall not respond to such communication directly without Client’s prior authorization, unless required by applicable law. To the extent Client does not have direct access to Client Personal Data through its use of the Services, and therefore does not have the ability to address such Data Subject request itself, StackAdapt shall, upon Client’s request, provide commercially reasonable cooperation to assist Client to address such request, to the extent required under Data Protection Law.

4. Processor Requirements

The following provisions shall apply when and to the extent that StackAdapt acts as a Processor with respect to Client Personal Data:

• Client Instructions. StackAdapt will Process the Client Personal Data in accordance with Client’s instructions in the Agreement, unless prohibited from doing so by law to which StackAdapt is subject; in such a case, StackAdapt shall inform Client of that legal requirement before Processing, unless that law prohibits such information on important grounds of public interest. 
• Confidentiality of Personal Data. StackAdapt shall ensure that its personnel engaged in the Processing of Client’s Personal Data are informed of the confidential nature of the Personal Data, and are under a duty of confidentiality.
• Limitation of Access. StackAdapt shall ensure that StackAdapt’s access to Client Personal Data is limited to those personnel performing Services in accordance with the Agreement.
• Cooperation. To the extent that the required information is reasonably available to StackAdapt, and Client does not otherwise have access to the required information, upon receipt of written request, StackAdapt will provide reasonable assistance to Client with any data protection impact assessments, and prior consultations with Regulatory Authorities to the extent required by applicable Data Protection Laws.
• Subprocessors. StackAdapt may entrust Subprocessors with Processing Client Personal Data under this DPA for the purposes of performing Services in accordance with the Agreement. StackAdapt may provide notification of any new Subprocessors before authorizing  them to Process Personal Data in connection with the provision of the Services and Client shall be responsible for receipt and review of such notification. Client may object to the Processing of Client Personal Data by such new Subprocessor, for reasonable and explained grounds, within ten (10) days of receiving the notification. The Parties will use good-faith efforts to resolve Client’s objection. In the absence of a resolution, StackAdapt will use commercially reasonable efforts to provide Client with the same level of service, without using the Subprocessor to Process Client Personal Data.

5. Security

1. Controls for the Protection of Personal Data.  In connection with the Processing of Personal Data, the Parties shall maintain appropriate technical and organizational measures designed to protect against a Security Incident.  Client shall monitor compliance with these measures in accordance with its internal information security program. StackAdapt shall monitor compliance with these measures in accordance with Appendix 2 of this DPA.
2. Security Incident Management and Notification. Each Party shall maintain security incident management policies and procedures designed to identify the Security Breach.  The Parties agree to apply the following procedures in the event of a Security Incident involving Personal Data shared between the Parties:
   • The Party responding to the Security Incident (the “Responding Party”) shall notify the other Party (the “Interested Party”) without undue delay after becoming aware of the  Security Incident.
   • The Responding Party shall use commercially reasonable efforts to identify the cause of the Security Incident and take steps required by any applicable Data Protection Laws and reasonably necessary  to remediate the Security Incident. 
   • The Responding Party shall cooperate in a reasonable manner with the Interested Party to allow the Interested Party to notify the relevant Regulatory Authority within forty-eight (48) hours (or any other timeframe required by Data Protection Laws) of the Responding Party becoming aware of the Security Incident (the “Notification to Regulatory Authority”).
   • The Interested Party shall consult with and provide the Responding Party the opportunity to comment on any Notification to Regulatory Authority.
   • Neither Party shall make any Security Incident public without the other Party’s prior written consent.
3. Nothing in this DPA shall be construed to require either Party to violate or delay compliance with any legal or contractual obligations it may have with respect to a Security Incident.

6. Audit

1. Provision of Information. To enable each Party to demonstrate compliance with its obligations pursuant to applicable Data Protection Laws, each Party shall provide the other Party with information regarding the (i) storage, (ii) country of origin and/or (iii) destination of Personal Data exchanged in connection with Client’s use of the Services.
2. Cooperation with Request for Audit.
   • Upon receipt of a written request from one Party (the “Auditing Party”) to the other Party (the “Audited Party”), the Parties shall reasonably cooperate in relation to any audit necessary or reasonably required in connection with the Processing of Personal Data by the other Party  related to Client’s use of the Services. 
   • Any audit shall be (x) at the Auditing Party’s expense, (y) subject to a mutually agreed upon scope, and (z) conducted either by the Auditing Party, in which case all information exchanged as part of the audit shall be subject to the confidentiality obligations set forth in the Agreement, or if conducted by a mutually agreed upon third party, such party must execute a satisfactory non-disclosure agreement with the Audited Party. 
   • The Auditing Party shall use reasonable endeavors to minimize any disruption to the Audited Party’s business activities over the course of an audit. 
   • Each Party may request an audit of the other Party once in any calendar year unless and to the extent that the Auditing Party (acting reasonably and in good faith) has reasonable grounds to suspect any material breach of this DPA. 

7. Cross-Border Data Transfers

1. Transfers of EEA, Swiss, or UK Personal Data. Where the Processing of Personal Data includes transfers from the European Economic Area (“EEA”), Switzerland, or the United Kingdom to countries which are deemed to provide inadequate levels of data protection (“Other Countries”), if required by Data Protection Laws, the Parties agree to: (i) execute the model clauses adopted by the relevant data protection authorities of the European Commission or the UK Secretary of State as set forth in this Section 7 (if applicable); or (ii) comply with any of the other mechanisms provided for under Data Protection Laws for transferring Personal Data to such Other Countries, including, but not limited to, the Data Privacy Framework. Additional information required by the Standard Contractual Clauses is set forth in Appendix 1 and 2 attached hereto.
2. Data Privacy Framework. StackAdapt participates in and certifies compliance with the Data Privacy Framework. As required by the Data Privacy Framework, StackAdapt (i) provides at least the same level of privacy protection as is required by the Data Privacy Framework Principles; (ii) will notify Client if StackAdapt makes a determination it can no longer meet its obligation to provide the same level of protection as is required by the Data Privacy Framework Principles, and (iii) will, upon written notice, take reasonable and appropriate steps to remediate any unauthorized Processing of Personal Data.
3. EU SCCs Modules. The Parties agree that for transfers of Personal Data from the EEA where the Data Privacy Framework does not apply, the Standard Contractual Clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council, as annexed to Commission Implementing Decision 2021/914 of 4 June 2021 (the “EU SCCs”), are hereby incorporated by reference into this DPA as follows:
   • Where  the disclosing Party is located in non-adequacy approved third countries, and the receiving Party is established in the EEA or is otherwise transferring the Personal Data of EEA Data Subjects (either directly or via onward transfer) (“Restricted Transfer”); where the Parties are  Controllers Module 1: Transfer controller to controller, Clauses 1 to 8, and 10 to 18 apply, and where StackAdapt is a Processor Module 2: transfer controller to processor, Clauses 1 to 18 shall apply.  Both modules with the following exceptions: (i) in Clause 7 (Docking Clause) – the Optional provision shall NOT apply; (ii) in Clause 11(a) (Redress) – the Optional provision shall NOT apply; (iii) in Clause 17 (Governing Law) – Option 1 shall apply, and the laws of Republic of Ireland shall govern; and (iv) in Clause 18 (Choice of forum and jurisdiction) – the courts of the Republic of Ireland shall have jurisdiction;
   • The EU SCCs shall come into effect under this Section 7(c) on the later of: (i) the data exporter becoming a Party to them; (ii) the data importer becoming a Party to them; and commencement of the relevant Restricted Transfer.
4. UK Model Clauses. The Parties agree that for transfers of Personal Data from the United Kingdom where the Data Privacy Framework does not apply, the International Data Transfer Addendum to the EU SCCs, issued by the UK ICO under S119A(1) Data Protection Act 2018 and in force March 21, 2022 (the “UK Addendum”), shall apply. The start date in Table 1 of the UK Addendum shall be the date that the Parties have executed Appendix 1. The selection of modules and optional clauses shall be as described in Sections 7(a) and 7(b) above, subject to any revisions or amendments required by the UK Addendum. All other information required by Tables 1-3 is set forth in Appendix 1 and 2. For the purposes of Table 4, the parties agree that both the importer and exporter may end the UK Addendum as set out in Section 19 of the UK Addendum.
5. Swiss Data Transfers. The Parties agree that for transfers of Personal Data from Switzerland where the Data Privacy Framework does not apply, the terms of the EU SCCs shall be amended and supplemented as specified by the relevant guidance of the Swiss Federal Data Protection and Information Commissioner, and the competent supervisory authority shall be the Swiss Federal Data Protection and Information Commissioner.
6. Canada Data Transfers. The Parties agree that any transfer of Personal Data outside of Canada must ensure a level of protection comparable to that required under applicable privacy laws. Such protection may be established through contractual safeguards or other legally recognized mechanisms. The Party responsible for the transfer must inform individuals, at the time of collection, that their personal information may be transferred outside of the jurisdiction, provide a designated contact for inquiries, and disclose any potential risks associated with access by foreign authorities.

8. Limitation of Liability

The “Limitation of Liability” terms under the Agreement shall apply to all claims, demands, suits, causes of action, awards, judgments and liabilities, including reasonable attorneys’ fees and costs, arising out of or alleged to have arisen out of either Party’s breach of its obligations under this DPA.

9. Prior Agreement

Unless a prior agreement precludes the Parties from entering into this DPA, this DPA and the Agreement shall supersede all prior discussions and agreements and constitutes the entire agreement and understanding between the Parties with respect to its subject matter. 

10. Modifications

If necessitated by amendments in Data Protection Laws or any other applicable laws or regulations or by developments in StackAdapt’s Services or Platform, StackAdapt may modify this DPA unilaterally to the extent it is reasonably necessary. 

11. Governing Law

Without prejudice to the relevant provisions of any applicable transfer mechanisms identified in Section 7 of this DPA, including the EU SCCs and UK Addendum, the Parties to this DPA hereby submit to the choice of jurisdiction stipulated in the Agreement with respect to any disputes or claims howsoever arising under this DPA, including disputes regarding its existence, validity or termination or the consequences of its nullity; and this DPA is governed by the laws of the country or territory stipulated for this purpose in the Agreement.

Appendix 1

Description of Processing

1. Controller (Client) To Controller (StackAdapt)

1. Parties:
   • Controller/Business (Data Exporter) is Client. 
   • Controller/Third Party (Data Importer) is StackAdapt
2. Categories of Data Subjects:
   • Clients or prospect of Client
   • Users and visitors to Client’s digital properties (websites, mobile applications)
   • Individuals responding to Client’s advertisements
   • Client’s employees and/or users of the Services
3. Nature and Purpose(s) of Processing:
   • Performance of Services as described in the Agreement, including marketing, cross-context behavioral/targeted advertising and measurement.
4. Categories of Personal Data:
   • ☒ Personal identifiers: online identifiers; IP address; cookie ID, device ID. At the request of the Client: Email address, first name, last name, phone number, postal address.
   • ☒ Internet or other electronic network activity information: e.g., referral URL; user agent; and information on a consumer’s interaction with a website, application, or advertisement.
5. Duration of Processing:
   • As agreed between the Parties in this DPA or the Agreement. Additional permitted purposes may include legal, regulatory, backup, archival, accounting, and/or audit purposes.

2. Controller (Client) To Processor (StackAdapt)

1. Parties:
   • Controller (Data Exporter) is Client
   • Processor (Data Importer) is StackAdapt
2. Instructions for Processing:
   • As described in the Agreement and relevant insertion order
3. Categories of Data Subjects:
   • Clients or prospects of Client
   • Users and visitors to Client’s digital properties (websites, mobile applications)
   •  Individuals responding to Client’s advertisements
4. Nature and Purpose(s) of Processing:
   • Sending email campaigns on behalf, for the benefit and under instructions of the Client.
   • Onboarding Client Personal Data for identity resolution.
5. Categories of Personal Data:
   • ☒ Personal identifiers: e.g., name; alias; postal address; online identifiers; IP address; email address; account name; or hashed identifiers.
6. Duration of Processing:
   • As agreed between the Parties in this DPA or the Agreement. Additional permitted purposes may include legal, regulatory, backup, archival, accounting, and/or audit purposes.

3. Controller (StackAdapt) To Controller (Client)

1. Parties:
   • Controller/Business (Data Exporter) is StackAdapt
   • Controller/Third Party (Data Importer) is Client
2. Categories of Data Subjects:
   • Individuals responding to Client’s advertisements
3. Nature and Purpose(s) of Processing:
   • Measurement and analytics of campaigns activated via the StackAdapt services.
4. Categories of Personal Data:
   • ☒ Personal identifiers: online identifiers; IP address; cookie ID, device ID.
5. Duration of Processing:
   •  As agreed between the Parties in this DPA or the Agreement. Additional permitted purposes may include legal, regulatory, backup, archival, accounting, and/or audit purposes.

Appendix 2

TECHNICAL AND ORGANIZATIONAL MEASURES TO PROTECT THE SECURITY OF THE PERSONAL DATA

Information Security Schedule

1. Purpose and Scope

• This Information Security Schedule (“Schedule”) forms part of and is incorporated into a Digital Advertising Services Agreement, a Master Services Agreement,  the StackAdapt Platform Terms of Use or any other written or electronic agreement (the “Agreement”) between StackAdapt and Client.  
• This Schedule describes the technical and organisational measures implemented and maintained by StackAdapt to protect the confidentiality, integrity, availability, and security of Client Data processed in connection with the Services provided under the Agreement.  All capitalised terms not otherwise defined in this Schedule shall have the meanings given to them in the Agreement. For convenience only, certain definitions from the Agreement may be reproduced in this Schedule and shall have the same meaning.  In the event of any conflict between the terms of the Agreement and this Schedule, this Schedule shall prevail solely with respect to security and data protection matters.

2. Governance and Risk Management

1. Information Security Program. StackAdapt maintains an information security program and control environment aligned with the principles of the ISO/IEC 27001:2022 standard and the NIST Cybersecurity Framework. The program includes written policies, plans, standards, and guidelines governing the implementation and operation of security controls across the organization. Policies are reviewed at least annually or upon a material change to infrastructure, organisational structure, or regulatory and compliance requirements.
2. Roles and Responsibilities. StackAdapt’s Information Security Team is responsible for the development, implementation, and ongoing management of the security program and is led by the Senior Director of Information Security, who reports to the Chief Technology Officer.
3. Security Governance. StackAdapt operates a cross-functional Security Committee that meets quarterly to oversee key security programmes, projects, and initiatives, and to ensure alignment with organisational goals and risk management priorities.
4. Risk Management. StackAdapt maintains an enterprise-wide risk management framework designed to identify, assess, and manage risks across key organizational domains, including legal and regulatory compliance, business strategy execution, vendor management, financial management, competitive environment, people, data privacy and security, technology strategy, platform performance and innovation, and global footprint.  Formal risk assessments are conducted semi-annually by key business stakeholders to evaluate the impact, likelihood, existing and planned mitigations, and residual risk for each identified risk within these domains. At least annually, a Risk Report is presented to the Executive Leadership Team, consolidating all known risks and highlighting leadership perspectives on priority risks across the organization. The overall process is coordinated and overseen by the Internal Audit function to ensure consistency, objectivity, and accountability.

The Information Security Team maintains a formally documented Information Security Risk Management Policy that defines how information security risks are identified, evaluated, treated, and monitored. The team also maintains an Information Security Risk Register that records all identified security risks, their assessed impact and likelihood, and the status of mitigation activities, and conducts formal risk reviews at least biannually to ensure appropriate mitigation and continuous improvement of StackAdapt’s security posture.

3. Asset and Configuration Management

• Asset Management. StackAdapt maintains processes and technologies to identify, classify, and manage its key assets, including physical assets, software assets, and information assets.
  • Physical and Endpoint Assets. StackAdapt uses centralized mobile device management (MDM) solutions to maintain real-time visibility into its corporate endpoint fleet, including hardware inventory, installed software, and compliance posture. All StackAdapt-issued user endpoints are protected by an endpoint detection and response (EDR) platform that provides continuous monitoring, threat detection, and endpoint visibility, including a comprehensive inventory of installed applications and real-time query capabilities for endpoint activity.
  • Software and Cloud Applications. StackAdapt employs automated discovery and inventory tools to identify and manage the use of cloud-based and software-as-a-service (SaaS) applications across the organization. These controls enable usage monitoring, compliance status, and license governance.
  • Cloud Infrastructure Assets.  StackAdapt leverages Amazon Web Services (AWS) as its public cloud infrastructure platform. Native AWS tools are used for asset discovery and resource tracking. In addition, StackAdapt uses a cloud security posture management tool that provides continuous cloud security assessment and monitoring, including real-time asset inventory and configuration evaluation to ensure visibility and control over StackAdapt’s cloud environment.
• Endpoint and Cloud Configuration Hardening. StackAdapt implements endpoint and cloud configuration hardening controls to protect corporate devices and cloud infrastructure from unauthorized access, misconfiguration, and exploitable vulnerabilities.
  •  User Endpoints. All StackAdapt-issued user endpoints are centrally administered through mobile device management capabilities that automatically apply secure baseline configurations. These baselines are aligned with the Center for Internet Security (CIS) Benchmarks and relevant vendor security guidance. Endpoints are required to remain compliant with enforced operating system and application update policies to ensure timely remediation of vulnerabilities.
  • AWS Environment. Within AWS, security configurations are implemented in alignment with the AWS CIS Foundations Benchmark. StackAdapt uses automated cloud security monitoring to continuously assess compliance with these configurations and to detect and alert on deviations from approved baselines (i.e., configuration drift).
• Data classification and Handling. StackAdapt has established a formal Data Classification Standard that defines how information across the organization is categorized and protected to ensure its confidentiality, integrity, and availability. All information created, stored, used, shared, archived, or destroyed by StackAdapt must be classified into one of the following categories:
  • Restricted: Information accessible strictly on a need-to-know basis, including business secrets, proprietary data, and employee HR data.
  • Confidential: Information of a highly sensitive nature where unauthorized disclosure, alteration, or loss could have a critical impact on StackAdapt or its Clients, suppliers, business partners, or employees.
  • Internal: Information of a sensitive nature where unauthorized disclosure, alteration, or loss could have a significant but not critical impact on StackAdapt or its Clients, suppliers, business partners, or employees.
  • Public: Information intended for public release or that would pose minimal risk to StackAdapt if disclosed, altered, or made unavailable.

StackAdapt has also implemented a formal Data Handling Guidelines policy that specifies how information must be managed throughout its lifecycle, based on its classification. These guidelines outline requirements for data access, storage, transmission, sharing, and destruction, ensuring that handling practices are consistent with the assigned classification level and comply with StackAdapt’s internal security and privacy requirements and applicable law.

4. Human Resource Security

• Background Checks. StackAdapt conducts background checks for all employees prior to the start of employment, in accordance with applicable laws and regulations. These checks are carried out globally where legally permissible and typically include:
  • Proof of identity;
  • Proof of legal right to work in the hiring jurisdiction;
  • Verification of employment history and references from the two most recent employers;
  • Criminal record check; and
  • Credit check for employees in Finance roles
• Confidentiality and Acceptable Use Agreements. New employees are required to attest that they have read and understood, at a minimum, the following documents:
  • Code of Conduct, which outlines expected standards of professional behaviour and workplace conduct; and
  • Employee Acceptable Use Policy, which defines acceptable use of StackAdapt computer equipment, systems, information, and internet resources.
    
    As part of the offer process, prospective employees are required to sign an employment agreement that includes provisions related to intellectual property ownership and confidential information protection. This agreement must be executed prior to onboarding or system access.
    
• Security and Privacy Awareness Training. StackAdapt maintains a formal Information Security Awareness Program designed to ensure that all employees understand their security responsibilities and can recognize and report potential Security Incidents. For purposes of this Schedule, “Security Incident” means a breach of security measures leading to accidental or unlawful destruction, loss, alteration, or unauthorized access to or disclosure of Client Data or StackAdapt Data. All new employees complete a mandatory information security training module as part of StackAdapt’s global onboarding program. This module includes an assessment that must be passed to demonstrate understanding of the content. StackAdapt conducts annual information security awareness training for all staff, supplemented by targeted awareness training for specific roles as needed. In addition, StackAdapt performs monthly simulated phishing exercises to strengthen employee awareness of social engineering and phishing threats. All employees are also required to complete data privacy training upon hire and on an annual basis thereafter.

5. Access Control

• User Onboarding and Offboarding StackAdapt has established and documented procedures for user onboarding, role changes, and offboarding designed to ensure appropriate access provisioning and timely access revocation.
  • Onboarding. User access requests are initiated via StackAdapt’s service management tool and require approval from designated approvers, such as the relevant application owner, before implementation by system administrators in accordance with documented access management procedures.
  • Role Changes (“Movers”/“Transfers”). When users transfer between departments or roles, access rights are reviewed and updated to ensure permissions are appropriate to their new responsibilities and that any access no longer required is revoked.
  • Offboarding. Offboarding requests are initiated by StackAdapt’s People Team via StackAdapt’s service management tool. System administrators revoke access on or before the user’s final day of employment. Access is typically removed within 24 hours, and in the case of involuntary offboarding, access is revoked immediately upon notification.
• Authentication and Authorisation. The StackAdapt Platform is the primary system used by Clients to manage and execute their digital advertising activities under the Agreement.
  • Authentication. Internal users authenticate to the StackAdapt Platform via SAML-based Single Sign-On (SSO) through StackAdapt’s identity provider. Each user is assigned a unique user ID to ensure individual accountability and traceability of access. Shared or generic accounts are not permitted. StackAdapt also offers federated SSO integration via Okta for clients. For clients, multi-factor authentication (MFA) is available. MFA uses a username and password in combination with a time-based one-time password (TOTP) generated by an authenticator application or received via SMS or other supported second factors. While MFA is not mandatory for clients, StackAdapt strongly recommends enabling this feature to enhance account security.
  • Authorisation. Access within the StackAdapt Platform is governed by role- and permission-based controls. Roles define available features and data access levels, ensuring users have access only to functions necessary for their responsibilities, consistent with the principle of least privilege.
    1. 1. Client Accounts. Client account administrators can grant or modify user access within their organisation.
    2. 2. Internal Users. StackAdapt managers assign or modify employee access based on job requirements. Employee access is restricted according to the principle of least privilege, ensuring that users only have access necessary to perform their duties.
• User Access Reviews. StackAdapt conducts user access recertification exercises on a periodic basis, typically monthly or quarterly, depending on the system or platform, to validate the continued appropriateness of access.
• Password Policies. StackAdapt maintains a Password Policy that defines requirements for the creation, protection, and management of passwords across the organization. The policy establishes standards for password construction, hygiene, and handling, including prohibiting password sharing and requiring prompt reporting of any suspected password compromise.

6. Cryptography and Data Protection

• Encryption Key Management. StackAdapt maintains a Cryptographic Controls and Key Management Policy that defines the requirements and procedures for the use of encryption and other cryptographic techniques. The policy governs the protection of sensitive data at rest and in transit, including the management and safeguarding of encryption keys. Encryption keys are rotated at least annually, and additionally in response to any suspected Security Incident or identified encryption-related vulnerability affecting cryptographic controls. At this time, StackAdapt does not support Client-managed encryption keys (CMEK).
• Encryption in Transit and at Rest. StackAdapt encrypts data at rest using AES-256 (or stronger) encryption and protects data in transit over untrusted networks using Transport Layer Security (TLS) 1.2 (or higher). Full-disk encryption is enforced on all StackAdapt-issued user endpoints through the organization’s MDM solution. Encryption is implemented using native operating system encryption technologies (e.g., FileVault and BitLocker) to ensure data at rest is protected.
• Data Loss Prevention (DLP). StackAdapt has implemented controls to restrict the transmission of sensitive data via email. This includes detecting and blocking messages containing financial information (e.g., IBANs, SWIFT codes, credit card numbers), sensitive personal data, regulated information, and health information, while also providing advanced email security protection. Additional DLP capabilities monitor and control user web traffic and continuously identify and remediate risks such as externally shared sensitive files, unused external access, and third-party applications with excessive permissions.

7. Operations and Network Security

• Data Centre Management and Hosting. StackAdapt maintains a formal Cloud Security Policy governing risk management, cloud service selection, data protection and privacy, minimum security requirements, the shared responsibility model, incident response, monitoring, and compliance. The Services are hosted in the Amazon Web Services (“AWS”) public cloud environment. StackAdapt relies on AWS’s independently assessed security and compliance certifications, including ISO 27001, ISO 27017, ISO 27018, ISO 22301, SOC 1 Type II, SOC 2 Type II, SOC 3, and CSA STAR (Levels 1, 2, and 3). A current list of AWS compliance certifications is available at AWS Compliance Programs.
  
  StackAdapt serves clients globally by leveraging AWS data centre regions across multiple geographic locations and primarily utilises the following AWS regions for data processing:
  • USA: Northern Virginia (us-east-1)
  • USA: Northern California (us-west-1)
  • Europe: Frankfurt, Germany (eu-central-1)
  • Asia: Singapore (ap-southeast-1)
    
    For security reasons, AWS does not disclose the precise physical location of its data centers.
    
• Network Security. StackAdapt is a remote-first, cloud-native organization with collaboration hubs in place, located in London, UK and Toronto, Canada.  Therefore, it does not manage a traditional local perimeter network. Instead, StackAdapt implements a Zero Trust Architecture that focuses access control on individual users, assets, and endpoints, using its identity provider (IdP) to standardize authentication for cloud application access and enable user-friendly single sign-on, combined with mobile device management (MDM) controls to enforce device trust.
  
  StackAdapt employs real-time risk-based monitoring that evaluates access requests based on signals such as user behaviour and login anomalies to detect and mitigate potential malicious activity. Within AWS, network and security configurations follow the AWS CIS Foundation Benchmarks and the security networking controls of StackAdapt’s cloud security monitoring platform, including:
  • Use of security groups to restrict public access and unnecessary ports.
  • Enforcement of least privilege on routing tables for VPC peering and network ACLs for subnet-level protection.
  • Continuous monitoring via AWS Shield Standard.
• Backup Management. StackAdapt shall maintain a documented Backup Policy defining requirements for data backup, restoration, and monitoring. StackAdapt operates a data backup program that ensures key data within its cloud-based infrastructure is continuously and securely backed up using native AWS backup capabilities.
• Vulnerability Management. StackAdapt maintains a formally documented Threat and Vulnerability Management Policy governing the identification, triage, prioritisation, and remediation of software vulnerabilities across corporate and cloud environments. Vulnerability management includes:
  • Continuous vulnerability scanning of user endpoints to identify and report endpoint vulnerabilities, configuration risks, indicators of compromise, and potential malicious activity.
  • Vulnerability scanning and monitoring across StackAdapt’s cloud infrastructure using a combination of agent-based and agentless technologies, including daily configuration and vulnerability snapshots. 
  • StackAdapt’s server infrastructure incorporates file integrity monitoring (FIM) capabilities to detect unauthorised or unexpected changes to critical system files and configurations.
• Patch Management. StackAdapt maintains a documented Endpoint Patch Management Standard that governs the deployment of software and operating system patches across the organization, including:
  • Patching schedules for operating systems, applications, and supporting software components;
  • Severity-based SLAs aligned with CVSS ratings; and
  • Emergency patching procedures for vulnerabilities with publicly available exploit code or evidence of active exploitation.
    
    Patch management processes are reviewed periodically to ensure continued alignment with organizational risk tolerance and industry best practices.
    
• Logging and Monitoring. StackAdapt maintains a centralized security information and event management (SIEM) solution that collects, correlates, and analyzes security logs from relevant systems (including cloud infrastructure, identity and access management, code repositories, email and productivity platforms, and endpoint-security tools) to support real-time detection, analysis, and response to potential Security Incidents. Detection rules combine standard content (for example, rules aligned with MITRE ATT&CK framework) with custom correlation and detection rules maintained by StackAdapt’s Information Security Team.
• Log Retention. StackAdapt retains StackAdapt Platform actions logs and SIEM logs for a period of at least twelve (12) months.

8. Application Security

• Software Development Lifecycle. StackAdapt maintains a formal Engineering Change Management Policy governing how software changes are managed throughout the Software Development Lifecycle (SDLC), supported by StackAdapt’s Secure Coding Principles and Secure System Architecture and Engineering Principles. 
  
  StackAdapt uses modern, secure open-source frameworks with built-in controls intended to mitigate exposure to common application-security risks identified in the OWASP Top 10, such as SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF).
  
  As part of the SDLC, StackAdapt performs Static Application Security Testing (SAST) using Brakeman and Software Composition Analysis (SCA) using Dependabot and Renovate. Application deployments are continuously scanned at build time and in production environments to detect dependency vulnerabilities, monitor network activity, and identify anomalous user behaviour or potential malicious activity.
  
  StackAdapt employs Infrastructure-as-Code (IaC) practices so that infrastructure changes are tested against StackAdapt’s security standards, peer-reviewed, and validated before deployment, reducing the risk of insecure configurations, inadvertent exposure of secrets, and unencrypted data storage.
• Environment Segregation. StackAdapt maintains segregated production and non-production (for example, testing or staging) environments. Access to each environment is restricted to authorized personnel and governed by the principle of least privilege through defined access-control mechanisms.
• Penetration Testing.  StackAdapt engages an independent third-party security firm to conduct annual penetration testing of the StackAdapt Platform, including external and internal testing, to identify and help remediate potential security vulnerabilities. Findings are tracked through remediation with severity-based timelines, and a high-level executive summary of such testing is available to Clients upon reasonable request and subject to appropriate confidentiality obligations (for example, an NDA).

9. Physical Security

• Physical Security. Physical Security controls for facilities hosting the Services are provided by StackAdapt’s cloud infrastructure provider, AWS.  StackAdapt does not own, operate, or manage physical data center facilities used to host the Services.   AWS is responsible for the implementation and operation of physical security controls designed to protect data centers against unauthorized physical access, damage, and interference.  Such controls include, as applicable:
  • Controlled physical access at the perimeter and building ingress points
  • Video surveillance
  • Intrusion detection systems 
  • Multi-factor authentication mechanisms to access data centre floors
  • Redundancy control
  • Fire detection and suppression
  • Redundant power supply
  • Climate and temperature controls
  • Environment management for electrical, mechanical and life support systems
  • Media management

StackAdapt relies on AWS’s independently assessed physical security controls and related certifications as part of its overall security posture.

10. Incident Response and Monitoring

• Security Incident Response. StackAdapt maintains a documented Security Incident Response Plan (“SIRP”) describing the procedures for detecting, analysing, containing, eradicating, and responding to Security Incidents, as well as conducting post-incident reviews (e.g., lessons learned). The SIRP defines the key individuals involved in incident response and specifies their respective roles and responsibilities. StackAdapt conducts annual incident response exercises involving members of the Engineering department and key business stakeholders (for example, IT Operations and Legal) to validate the plan’s effectiveness and update it as required.
• Security Incident Notification and Cooperation. If a Security Incident affects Client Data, StackAdapt applications that support the provision of Services (“Services”), or the Services, StackAdapt shall notify Client without undue delay after becoming aware of the Security Incident (typically within forty-eight (48) hours). Such notification shall include, to the extent known at the time:
  • The timeframe of the incident, including the time of compromise and discovery;
  • The nature and potential impact/consequences of the Security Incident;
  • The categories of Client Data and, where applicable, the approximate number of data records or data subjects affected;
  • The extent to which Client Data, Systems, or Services were impacted;
  • The measures taken or proposed by StackAdapt to contain, mitigate, and remediate the Security Incident;
  • The status of StackAdapt’s investigation; and
  • The contact point from which further information may be obtained.

StackAdapt shall provide timely updates as additional information becomes available and shall cooperate in good faith with the Client to support the Client’s own incident response, assessment, mitigation, and any legally required notifications to regulators or affected individuals.

11. Business Continuity and Disaster Recovery

• Business Continuity and Disaster Recovery. StackAdapt shall maintain a documented Disaster Recovery and Business Continuity Plan (“DRBCP”) addressing the resilience and recovery of key StackAdapt Platform services and IT systems. The DRBCP shall describe roles and responsibilities, critical assets, key risks, recovery procedures, service disruption and data loss recovery processes, and post-incident activities, and shall define Recovery Time Objectives (“RTOs”) and Recovery Point Objectives (“RPOs”) for key StackAdapt Platform services. For StackAdapt’s Tier 1 platform services, the RTO is one (1) hour and the RPO is four (4) hours. StackAdapt shall test the DRBCP at least annually with relevant members of the Engineering department and update it as appropriate based on test results or material operational changes. StackAdapt’s recovery strategy in AWS is designed to meet applicable RTO and RPO objectives using a combination of data backup and replication, high availability and failover mechanisms, documented disaster recovery procedures, and ongoing testing and monitoring.

12. Vendor Security Management

• Vendor Security. StackAdapt shall maintain a documented Vendor Security Policy describing how StackAdapt identifies, assesses, and manages information security risks associated with third-party vendors that Process or have access to Client Data or support the Services.
  
  As part of vendor onboarding, StackAdapt shall conduct risk assessments to determine the level of due diligence required, taking into account factors such as the sensitivity of data processed and the criticality of the services provided. Vendors may be asked to complete an information security questionnaire and provide supporting evidence, which StackAdapr evaluates and documents, including any identified risks and associated remediation or risk-acceptance decisions. For higher-risk or critical vendors, StackAdapt may require additional validation of security controls, including, where applicable, evidence of independent assurance such as current SOC 1, SOC 2, or ISO27001 certifications.
  
  Based on the vendor’s risk level and service scope, StackAdapt’s Information Security Team defines applicable security requirements for project teams to implement during system configuration and integration, covering control areas such as access management, data protection, auditing, change management, backup, and service management.  StackAdapt periodically reviews the security posture of key vendors to verify continued compliance with applicable security requirements.
• Sub-processors. Sub-processors engaged by StackAdapt in connection with the Processing of Client Data shall be listed on the Platform.

13. Compliance and Continuous Improvement

• Compliance. StackAdapt shall maintain a comprehensive information security and compliance program designed to protect the confidentiality, integrity, and availability of its systems and data. The effectiveness of this program is subject to regular independent assessment, including at least annual SOC 1 Type II and SOC 2 Type II examinations. StackAdapt is also subject to recurring annual audits of its internal controls over financial reporting, performed by an independent audit firm, which includes assessments of IT General Controls (for example, controls related to change management, access management and IT Operations) for key systems supporting financial reporting.
• Continuous Improvement. StackAdapt reviews key risk indicators (“KRIs”) and other security metrics quarterly to monitor control effectiveness and identify improvement opportunities. Identified improvements are implemented as part of its ongoing compliance and risk management activities.

14. Audit and Verification Rights (“Right to Audit”)

• Audit and Due Diligence Requests. Subject to this section, Clients may request to conduct a remote-only information security audit and/or due diligence review (for example, by submitting a security questionnaire) to verify StackAdapt’s security controls related to the processing of Client Data. StackAdapt shall cooperate in good faith with reasonable remote audit or due diligence requests and may provide relevant supporting documentation, which may include current SOC 1 Type II and SOC 2 Type II reports and/or high-level summaries of recent penetration testing results, subject to confidentiality obligations.
• Frequency and Notice. Unless otherwise required by applicable law or following a verified Security Incident impacting Client Data, Client may submit no more than one (1) Formal Audit Request in any rolling twelve (12)-month period and must provide at least thirty (30) days’ prior written notice. A “Formal Audit Request” means a written request to conduct a remote-only audit or due diligence review that identifies the audit’s purpose, scope, proposed timing, audit method, and auditor, and that is subject to Client’s compliance with StackAdapt’s confidentiality and audit-related requirements. 
• Scope and Confidentiality. The scope, duration, and method of any audit or due diligence activity shall be mutually agreed upon in advance and limited to systems, facilities and processes directly involved in the Processing or storage of Client Data in connection with the Services. All information obtained in the course of an audit or review shall be treated as confidential and subject to applicable non-disclosure obligations.
• Third-Party Auditors and Costs. If Client appoints a third party to conduct an audit or due diligence review, such third party must be independent, reputable, and bound by written confidentiality obligations as required by StackAdapt. Each party shall bear its own costs associated with audits or due diligence activities.

Annex 1

StackAdapt maintains the following list of information security policies, standards, plans, and guidelines (which StackAdapt may update from time to time to reflect organizational, technical, or regulatory changes):

Policies and Plans

• Access Management Policy  
• Backup Policy 
• Bring Your Own Device Policy 
• Change Management Policy (Engineering) 
• Cloud Security Policy 
• Cryptographic Controls and Key Management Policy 
• Clear Desk Policy 
• Disaster Recovery and Business Continuity Plan  
• Enterprise Asset Management Policy 
• Information Security Policy   
• Information Security Risk Management Policy 
• Information Transfer Policy 
• Password Policy 
• Physical and Environmental Security Policy 
• Secure System Architecture and Engineering Principles 
• Secure Coding Principles 
• Secure Configuration and Handling of User Endpoint Devices Policy 
• Security Awareness Training Management Policy 
• Security Incident Response Plan 
• Security Logging & Monitoring Policy 
• Software Asset Management Policy 
• StackAdapt Platform Access Management and Controls  
• Threat & Vulnerability Management Policy 
• Vendor Security Policy 

Standards 

• AWS Patch Management Standard 
• Chat GPT Enterprise – Secure Use Standard 
• Data Classification Standard 
• Endpoint Patch Management Standard 
• Identity and Access Management Standard 
• PCI Security Standard 
• Security Incident and Event Standard 

Guidelines

• Data Handling Guidelines 
• Password Construction Guidelines 
• Public Wi-Fi Security Guidelines 
• User Phishing Guidelines 
• Vulnerability and Patch Management Guidelines