Exhibit C v1.2 (archive)
Exhibit C – Information Security and Data Processing Policy
Technical and organizational measures (SOC 2 Type II); details of processing (Annex 1)
Version 1.2. Last update: 09/11/2026
This Exhibit C forms part of, and is incorporated by reference into, the Software as a Service Agreement (the "SSA") between Maestra.io LLC ("Provider") and the Customer identified in the Order Form. This Exhibit describes the technical and organizational measures implemented by Provider to ensure the security of Customer Data and End Customer Data Processed through the Services. Capitalized terms not defined in this Exhibit have the meanings given in the SSA. Annex 1 to this Exhibit describes the Processing of PII through the Services: the data subjects, the categories and sources of PII, the data collected by Provider’s Tracking Technologies, and how the scope of Processing is determined.
1. Security Programme
1.1. Provider maintains a comprehensive information security programme designed to protect Customer Data and End Customer Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure or access. The programme is risk-based and is reviewed and updated periodically to reflect changes in the threat environment, technology, and applicable legal requirements.
1.2. Provider’s information security programme is certified to the SOC 2 Type II standard, with annual independent audits performed by qualified external auditors. The scope of the SOC 2 Type II audit covers the Trust Services Criteria for Security, Availability, and Confidentiality. Provider shall make a current SOC 2 Type II report available to the Customer on reasonable written request, subject to execution of a customary non-disclosure agreement.
1.3. Provider conducts annual information security risk analyses, annual inventories of information assets, and periodic external information security audits, in each case as part of its SOC 2 compliance programme.
2. Governance and Personnel
2.1 Policies and Procedures
Provider maintains a documented set of information security policies covering, at a minimum: access control, acceptable use, confidentiality, password management, risk management, asset management, incident response, business continuity, secure development, cryptography, supplier management, and physical security. Information-security responsibilities are formally assigned and reviewed at least annually.
2.2 Personnel Security
Provider personnel are subject to the following controls:
- Signed non-disclosure obligations as a condition of employment or engagement;
- Mandatory information security awareness training upon onboarding, and refreshed at least annually;
- Role-based access provisioning: each employee receives only the access necessary for their role (least-privilege principle);
- A formal list of positions authorized to Process PII;
- Documented onboarding and off-boarding checklists, including timely revocation of access on termination or role change;
- A maintained register of employee acknowledgement of personal-data Processing rules.
3. Access Control
3.1. Provider implements role-based access control (RBAC) across all production systems containing Customer Data. Access to PII is restricted to personnel with a legitimate need-to-know, and is logged centrally.
3.2. Authentication controls include:
- Two-factor authentication for all production-system access by Provider personnel;
- Protection against brute-force attacks: account lockout after five (5) consecutive failed login attempts;
- Use of enterprise password-management tools;
- Session tokens for application sessions; signed-link authentication for certain restricted flows;
- Configurable password expiration policies in the Customer’s account, set by the Customer.
3.3. The Customer can differentiate access rights among its own Authorized Users, including by hiding PII from certain Authorized Users through the Customer’s administrative interface. The Customer can also mask PII from Provider support employees, and can review actions taken by Provider support employees in the action log.
4. Network and System Security
Provider implements the following network and system security controls:
- Network segmentation with VLAN-level Access Control Lists between segments;
- Enterprise-grade firewalls at the perimeter, with rules to filter incoming traffic and to block all unused ports;
- Regular external web application vulnerability scanning;
- Testing of new versions of information systems in an isolated environment prior to production deployment;
- Endpoint protection (Microsoft Defender or equivalent) installed on all employee workstations;
- Master data management tools for configuration and asset tracking;
- A maintained registry and annual inventory of information assets.
5. Encryption
5.1. Data in transit: All connections to the Services from the Customer and from End Customers use industry-standard transport-layer encryption (TLS 1.2 or higher).
5.2. Data at rest: All Customer Data and End Customer Data stored at rest is encrypted. The Customer can select the encryption type from the options offered in the Customer’s account configuration.
5.3. Recommended data-transfer channels for the Customer’s integration with the Services are described in the Provider’s Documentation.
6. Logging and Monitoring
Provider maintains the following logging and monitoring controls:
- Centralised collection and analysis of security logs;
- Logging of user and administrator activity through built-in operating system and application controls;
- Logging of administrator logins and exits;
- Logging of access grants and revocations;
- Audit logs available to the Customer for actions taken in the Customer’s account, including by Provider support employees acting on the Customer’s behalf.
7. Data Lifecycle Management
7.1. Data masking. PII may be masked for Provider employees by default. The Customer can configure additional masking rules for its own Authorized Users.
7.2. Retention. The Customer can set retention periods for PII through the Customer’s account configuration. PII is deleted in accordance with the applicable retention period.
7.3. Backup. Provider performs daily backups of production data, with backup storage maintained at a separate location from the primary data centre. Backups of deleted data are retained for six (6) months, after which they are permanently deleted. This backup capability is operational and does not constitute a service-level commitment in the absence of a separately-signed Service Level Agreement.
7.4. Disposal. Decommissioned hardware and storage media are securely wiped or destroyed prior to disposal, using methods that prevent recovery of PII.
7.5. Details of Processing. The data subjects, categories and sources of PII Processed through the Services, and the data collected by Provider’s Tracking Technologies, are described in Annex 1 to this Exhibit.
8. Physical Security
Production data is hosted in third-party data centres located in the United States and operated by the hosting providers identified in Provider's sub-processor list, published at https://maestra.io/legal/subprocessors and incorporated into this Exhibit by reference. Each hosting provider maintains its own enterprise-grade physical security controls (including 24/7 staffed monitoring, biometric or badge access controls, environmental controls, and CCTV surveillance) and holds appropriate independent certifications. During the transition of Provider's hosting arrangements, certain workloads and ancillary data may also be processed in data centres in the European Union operated by the providers identified in the sub-processor list. Changes to hosting providers are made through updates to the sub-processor list and are notified in accordance with the Agreement and, where applicable, the applicable data processing terms.
In Provider’s own offices, the following physical security controls are implemented:
- CCTV at office entrances;
- Equipment sited as recommended by respective manufacturers and security regulations;
- Clean desk policy, clean screen policy, and lock screen policy;
- Mobile device management combined with anti-virus software and enforced updates.
9. Incident Response
9.1. Provider maintains a documented information security incident response plan. The plan defines roles, communication channels, escalation procedures, evidence-preservation requirements, and timelines for containment, eradication, recovery, and post-incident review.
9.2. Provider maintains a log of information security incidents and conducts post-incident reviews to identify systemic improvements.
9.3. In the event of a security incident involving PII concerning PII Processed by Provider as a processor on behalf of the Customer, Provider shall comply with the notification obligations set forth in Section 7 of the SSA and applicable U.S. federal and state security incident notification Laws (including U.S. state breach-notification statutes).
10. Supplier and Sub-processor Management
10.1. Information security obligations are incorporated into contracts with counterparties, including suppliers, sub-processors, and service providers with access to Provider’s information assets.
10.2. Provider conducts due diligence on prospective sub-processors prior to engagement, and reviews existing sub-processors periodically as part of its supplier-management programme.
10.3. The current list of sub-processors authorized to Process PII on behalf of the Customer is published at https://maestra.io/legal/subprocessors and is incorporated into this Exhibit by reference. Provider updates the list when sub-processors are added, replaced, or removed. For Customers whose data processing terms provide sub-processor notice or objection rights, changes to the list are notified in accordance with those terms; for all other Customers, the list as published from time to time applies in accordance with Section 12 of this Exhibit and the Agreement.
11. Customer Controls
In addition to the controls implemented by Provider, the Customer can configure the following security features through its Customer account:
- Two-factor authentication enforcement for the Customer’s Authorized Users;
- Password expiration policies;
- Differentiation of access rights among Authorized Users;
- Masking of PII from selected Authorized Users;
- Masking of PII from Provider support employees;
- Selection of the encryption type for data at rest;
- Retention periods for stored PII;
- Audit log review of actions taken in the Customer’s account.
The Customer is responsible for configuring these features in line with its own risk profile and applicable legal requirements, and for the security of any credentials, API keys, or tokens issued for use with the Customer’s account.
12. Updates
12.1. Provider may update the technical and organizational measures described in this Exhibit C from time to time to reflect changes in technology, applicable Law, and security best practices, provided that any such update shall not materially diminish the overall level of security.
12.2. Provider shall publish updated versions of this Exhibit C on its website, and the version then in force shall apply to the Processing of PII under the SSA. The Customer can request a current copy of this Exhibit at any time through the Means of Communication.
12.3. Changes to Default Collection. Notwithstanding Section 2.5 of the SSA, Provider gives Customer at least thirty (30) days’ notice before adding a category of data to the Default Collection described in Section G of Annex 1 or changing the consent behavior described there. Notice is given by publishing an updated version of this Exhibit and by written notice in accordance with Section 16.4(a) of the SSA. A change required for security, to comply with applicable Law, or by a third-party platform on which a Tracking Technology operates may take effect earlier, with notice as soon as practicable. Changes within the categories described in Section G — including new or changed data elements, events, attributes or identifiers of the same kind — removals, and changes of the domains to which Tracking Technologies send data are described in the Documentation as released and do not require notice under this Section.
Annex 1 — Details of Processing
Version 1.0, published with Exhibit C version 1.2. This Annex forms part of Exhibit C. Capitalized terms have the meanings given in the SSA and in Exhibit C.
A. Definitions
A.1. “Data Types” means the record types in which the Services organize Customer Data — Area, Customer, Customer action, Discount card, Order, Order external IDs, Order line, Product, Product list item, Promotion and Touchpoint — each as described in the Documentation, together with the custom attributes Customer adds to them.
A.2. “Tracking Technologies” means the software Provider makes available for installation on Customer’s websites, online stores and mobile applications to collect End Customer Data for the Services: the Maestra web tracker (a JavaScript library, whether installed directly or through the Maestra app for Shopify), the Web Pixel and other storefront and checkout components of the Maestra app for Shopify, and the Maestra mobile SDKs (iOS and Android, including their Flutter, React Native and Expo wrappers), together with any successor software of the same function described in the Documentation.
A.3. “Default Collection” means the data a Tracking Technology collects, and the identifiers it sets, without configuration by Customer, as described in Section G.
B. Roles and purpose
B.1. Customer is the “business” (or controller) and Provider the “service provider” (or processor), as set out in Section 7.4 of the SSA. Provider Processes PII solely to provide the Services under the Agreement and on Customer’s instructions, as described in the SSA (including Sections 3.5, 3.7 and 10.1), this Exhibit and the Documentation. Provider does not “sell” or “share” PII (Section 7.4(d) of the SSA).
C. Data subjects
C.1. End Customers: Customer’s customers, subscribers and prospects, and visitors to Customer’s websites, online stores and mobile applications.
C.2. Authorized Users: in respect of account, access and audit data.
D. Categories of PII, by Data Type
The categories below use the vocabulary of the California Consumer Privacy Act (Cal. Civ. Code § 1798.140(v)). Which of them the Services Process for a given Customer depends on the data Customer provides and configures (Section F).
D.1. Customer — identifiers (name, email address, telephone number, postal address, customer and external identifiers, device and cookie identifiers, hashed identifiers); customer records; consent and subscription status by channel; custom attributes configured by Customer. Characteristics of protected classifications (for example date of birth or gender) only where Customer configures the Services to collect them.
D.2. Customer action and Touchpoint — internet or other electronic network activity information: interactions with Customer’s websites, stores and applications (page and product views, cart and checkout events, searches, form and quiz submissions), interactions with communications sent through the Services (deliveries, opens, clicks, unsubscribes), campaign and referral attribution; device and browser information; and, where a feature Customer configures uses it (Section G), approximate location derived from the IP address.
D.3. Order, Order line, Order external IDs and Product list item — commercial information: orders and subscriptions, products purchased or placed in carts and lists, quantities and amounts, discounts applied, order status, external order identifiers.
D.4. Discount card and Promotion — commercial information: promotional codes and loyalty or discount cards issued to, or used by, an End Customer.
D.5. Area — the geographic area (for example postal code, city or region) associated with an End Customer or an order.
D.6. Product — business data about Customer’s catalogue; not personal information in itself; linked to an End Customer only through the Data Types above.
D.7. Inferences — segments, scores, predictions and recommendations generated by the Services from the data above (Section 3.7 of the SSA).
D.8. Sensitive personal information is not required by the Services and is not part of Default Collection. Where Customer configures the Services to collect it, Customer is responsible under Sections 7.2 and 7.3 of the SSA for establishing the lawful basis and for providing the notices and obtaining the consents applicable Law requires.
E. Sources
E.1. Customer and its Authorized Users: uploads, the Services’ API, the integrations Customer connects (for example Shopify and other platforms), and the forms, quizzes and other content Customer publishes through the Services.
E.2. Tracking Technologies installed on Customer’s properties: Default Collection (Section G) and the events Customer configures.
E.3. End Customers’ interactions with communications sent through the Services.
E.4. Provider Personnel acting on Customer’s written instructions (Section 3.3(d) of the SSA).
F. Scope determined by Customer
F.1. Customer determines the scope of PII Processed through the Services — including by installing and configuring Tracking Technologies, connecting integrations, publishing forms and quizzes, creating custom attributes on the Data Types, and instructing Provider Personnel. The number of custom attributes is not limited. Provider does not review the content Customer configures the Services to collect.
F.2. Customer is solely responsible, as set out in Sections 2.3(b), 7.2 and 7.3 of the SSA, for the lawfulness, accuracy and appropriateness of the data it configures the Services to collect, for the privacy notices it provides to End Customers, and for obtaining and recording any consents applicable Law requires.
F.3. Customer can review the attributes, forms, quizzes, integrations and audiences configured in its account through the Customer’s account, and can review actions taken in its account in the audit log (Section 6 of this Exhibit).
G. Default Collection by Tracking Technologies
G.1. This Section states the categories of data each Tracking Technology collects by default. The data elements, the identifiers set and their lifetimes, and the domains to which data is sent are described in the Documentation (developers.maestra.io and help.maestra.io), as updated from time to time. On Customer’s reasonable request, Provider discloses what its Tracking Technologies collect on Customer’s properties (Section 7.4(f) of the SSA).
G.2. Web tracker: page and referrer URLs, including campaign parameters; browser and device characteristics; a device identifier stored in the visitor’s browser; and the connection data Provider’s servers receive with each request. The website visit is the only event sent by default; customer identification, product, category, cart, order and custom events are sent only when Customer’s website calls the tracker with that data. Optional modules (web push notifications, bot protection) run only when enabled for Customer’s account.
G.3. Forms and quizzes published by Customer through the Services: the data a visitor enters, the traffic-source data attached to a submission, display and interaction events, performance measurements and, only for forms Customer targets by location, approximate location derived from the IP address.
G.4. Web Pixel for Shopify: the storefront events Shopify exposes (browsing, cart, checkout and purchase events) with product and checkout identifiers and, where the visitor is signed in or enters them at checkout, contact details, marketing opt-in choices and shipping location.
G.5. Mobile SDK: a device identifier for the installation, the push notification token and permission state, application and SDK version information and, where Customer configures it, an anonymous customer record. Application events are sent only when the application calls the SDK.
G.6. Consent behavior. Where a Shopify store exposes Shopify’s Customer Privacy API, Tracking Technologies installed through the Maestra app for Shopify start collecting only when that API indicates that analytics processing is allowed for the visitor, and the Web Pixel is loaded by Shopify subject to the store’s customer privacy settings. A web tracker installed by Customer directly collects data from the moment it is initialized, and Customer controls when it is initialized. The mobile SDK collects data from the moment the application initializes it; Provider recommends initializing it after the application has obtained any tracking authorization the platform or applicable Law requires. The configuration of Customer’s consent management platform, store privacy settings and application permissions is Customer’s responsibility.
G.7. Changes to Default Collection are governed by Section 12.3 of this Exhibit.
H. Retention, deletion, location, sub-processors, security
H.1. Retention and deletion: Section 7 of this Exhibit and Section 15.3 of the SSA. Location of Processing: Section 8 of this Exhibit. Sub-processors: Section 10.3 of this Exhibit. Security measures: Sections 1 to 9 of this Exhibit.
Archived versions: