Data Processing Agreement

Name: the Customer signing this DPA

Activities relevant to transfer: See Annex I(B)

Role: Controller

Name: the Provider signing this DPA

Contact person: Sean Walsh, Cofounder

Address: 82 Wendell Ave, Ste 100, Pittsfield, Massachusetts 01201, United States of America

Activities relevant to transfer: See Annex I(B)

Role: Processor

• Customer's employees
• Individuals who may be named or pictured in Customer's Klaviyo content and image assets (for example, signatories, testimonial authors, or people in photos).

• Name
• Contact information such as email, phone number, or address
• User activity and analysis such as device information or IP address
• Images and image metadata (file names, folder paths) that may depict or identify individuals.

Provider will Process Customer Personal Data as instructed in Section 2.3 of the DPA Standard Terms. The nature of processing includes:

• Receiving data, including collection, accessing, retrieval, recording, and data entry
• Holding data, including storage, organization, and structuring
• Using data, including analysis, consultation, testing, automated decision making, and profiling
• Protecting data, including restricting, encrypting, and security testing
• Sharing data, including disclosure, dissemination, allowing access, or otherwise making available
• Erasing data, including destruction and deletion
• Organizing and importing images in Customer's Klaviyo account at Customer's direction.

Pseudonymization and encryption of personal data: Encryption at rest. Credentials we hold to access the services Customer connects, such as access tokens and API keys, are encrypted with industry-standard encryption (AES-256). The database stores only ciphertext. Encryption in transit. Customer data is transmitted over HTTPS. Server-side fetches of customer files from connected asset sources are restricted to HTTPS and to an allowlist of provider hosts. Credentials are never exposed to the browser extension or written to logs; the extension communicates only with our API.

User identification and authorization process and protection: Sign-in. Users sign in with a supported method, such as Google, an emailed one-time link, or email and password. Passwords are stored only as hashes, never in plaintext. Sessions expire, and authentication endpoints are rate limited. All state-changing requests are checked for origin and CSRF. Access control. Customer data is isolated by organization. Each request is checked server-side against the user's organization membership and role. Credential security. Third-party credentials we hold on the customer's behalf are encrypted at rest (see encryption above). They are never exposed to the browser extension or written to logs. Where a connected service provides its own file picker, access is limited to the files the user picks, and any access token it issues is held only on our servers. Staff access. Access by our staff requires both membership in an access-controlled group and an internal staff role bound to their email. Impersonation is time-limited, blocked from sensitive account actions, and audited.

Protecting Customer Personal Data during transmission (in transit): Customer data is transmitted between users' browsers, our extension, our servers, and connected services over HTTPS (TLS). Our servers fetch customer files from connected asset sources and upload them to Klaviyo only over HTTPS, and only to an allowlist of approved provider hosts. Files are streamed through to Klaviyo and are not stored. The browser extension communicates only with our API, and uses short-lived, single-use sign-in tickets that are never placed in a URL.

Protecting Customer Personal Data during storage (at rest): Credentials we hold for the services Customer connects are encrypted at rest with industry-standard encryption (AES-256), so the database stores only ciphertext. Customer data is logically separated by organization, and every request is checked server-side against the user's organization membership and role. Uploaded image files are streamed to Klaviyo and are not stored by us; we keep only metadata such as file names, sizes, and source locations. Staff access to customer data is restricted to an access-controlled group, limited in time, and audited. Our data is stored with managed infrastructure providers listed in our subprocessor list.

Events logging: We keep an audit log of security-relevant account events, such as connection, credential, role, and ownership changes, and actions by our staff (recording which user was impersonated). Application and request logs are kept in our hosting provider for operational and security troubleshooting. Application errors are sent to an error-tracking service configured not to collect IP addresses, cookies, headers, or request bodies. Background job records are pruned after a short retention period.

Systems configuration, including default configuration: Our infrastructure configuration is maintained as code in version control, and changes are deployed through automated CI. Development, staging, and production run as separate deployments. To test changes and troubleshoot issues, our staging and preview environments may use copies of production data, held with our database provider in the same region. These environments are restricted to authorized staff, and copies are refreshed or deleted when no longer needed. Credentials we hold for customers remain encrypted in these copies, and non-production environments do not have the keys to decrypt them. Staff and administrative tools are restricted behind an access-controlled gateway. The application ships with protective defaults, including origin and CSRF checks on all state-changing requests, clickjacking protection, rate limiting on authentication endpoints, and strict validation of outbound file fetches. We monitor the service using application error tracking and hosting-provider logs.

Ensuring data minimization: We limit what we collect and process to what is needed to provide the service. We request only the Klaviyo permissions the service uses, and we do not request subscriber, profile, list, segment, or event data from Customer’s Klaviyo account. Image files, whether uploaded from a user's computer or a connected source, are streamed to Klaviyo unchanged and are not stored; we keep only metadata such as file names, sizes, and source locations, and how Customer organizes images in BrandRetriever, such as folders and favorites. When reading Klaviyo content to show where images are used, we read it in transit and keep only the image references and related names and statuses, not the content itself. Access granted for a single pick is deleted within minutes rather than kept. When a connection is disconnected, we revoke or delete its stored credentials. Background job records are pruned after a short retention period.

The references to automated decision making and profiling in Nature and Purpose of Processing do not apply; Provider does not engage in either.

Updates to security measures. Provider may update the Technical and Organizational Security Measures in Annex II from time to time, provided that the updates do not materially decrease the overall protection of Customer Personal Data.

Account and usage data. Provider processes account, billing, authentication, and usage information about Customer's users (such as name, email address, role, and activity in the Product) as an independent controller for the purposes described in its Privacy Policy, including operating and securing accounts, product analytics, and service and marketing communications. This includes how Customer's users interact with the Product, which may include on-screen content captured in product analytics and session recordings, with account details masked, used to maintain and improve the Product. This DPA, including the Service Provider Relationship terms, applies to Personal Data that Provider processes on Customer's behalf, such as content in Customer's connected Klaviyo and asset-source accounts.

We maintain a current list of subprocessors at https://brandretriever.com/legal/subprocessors/. Customers may subscribe to receive notice of new subprocessors. Raleko will notify subscribers at least 10 business days before authorizing a new subprocessor. Customers may object to a change within 30 days of the notice. Customer is responsible for subscribing.