Privacy Architecture

Version 1.0

Last Updated: July 19, 2026

Purpose

This document describes the architectural principles that guide how SetRoasFlow processes and protects data.

Unlike the Privacy Policy, which explains legal obligations, this document explains how privacy is implemented within the platform's technical architecture.

Privacy is treated as a core engineering principle throughout the design, development and operation of the Services.

Privacy by Design

Privacy considerations are incorporated throughout the software development lifecycle rather than being introduced after implementation.

When designing new functionality, SetRoasFlow evaluates:

• whether Personal Data is actually required;
• whether less data can achieve the same objective;
• whether processing can occur earlier in the pipeline;
• whether identifiers can be transformed before transmission;
• whether processing can be avoided entirely.

The objective is to minimize unnecessary exposure of Personal Data while preserving platform functionality.

Data Minimization

SetRoasFlow is designed to process only the information required to provide the Services requested by the Merchant.

Examples include:

• avoiding unnecessary collection of attributes;
• minimizing persistent storage;
• limiting operational logging;
• restricting access to only required systems;
• avoiding duplicate storage where reasonably possible.

Merchants remain responsible for ensuring that data sent to SetRoasFlow is appropriate for their intended purposes.

Edge-first Processing

Whenever supported by the configured Collection Method, processing begins at the network edge.

Early processing enables:

• lower latency;
• faster consent evaluation;
• earlier filtering;
• reduced unnecessary data transmission;
• improved scalability.

Processing data closer to its point of collection also reduces unnecessary movement through downstream systems.

Consent-aware Architecture

Consent is evaluated as early as reasonably possible within the processing pipeline.

Depending on Merchant configuration and applicable regional requirements, processing decisions may include:

• allowing processing;
• suppressing identifiers;
• disabling routing;
• limiting destination delivery;
• applying destination-specific privacy controls.

Consent evaluation is intended to influence processing before downstream integrations receive data.

Geo-aware Enforcement

Where regional privacy requirements differ, SetRoasFlow supports geo-aware processing decisions.

Depending on Merchant configuration, routing logic may apply different processing behaviors for visitors located in different jurisdictions.

Examples include:

• regional consent requirements;
• destination-specific restrictions;
• jurisdiction-specific privacy controls.

The Merchant remains responsible for determining which legal requirements apply to their Connected Properties.

Hash-first Processing

Where supported by configured Destinations, identifiers may be transformed using SHA-256 before transmission.

Examples may include:

• email addresses;
• telephone numbers;
• other supported identifiers.

Hashing reduces exposure of raw identifiers while maintaining compatibility with supported advertising platforms.

Hashing is not considered anonymization and hashed identifiers continue to receive appropriate privacy protections.

Not every Destination category receives the same form of data:

Clear-text transmission to marketing and CRM platforms exists because those platforms operate on the Merchant's own customer relationships and cannot function on hashed values. It never occurs where consent is absent, and never where a United States opt-out signal (including Global Privacy Control) applies.

Identity Resolution

Multiple interactions associated with the same individual may be linked to create a unified Customer Profile.

Identity Resolution is performed only using information provided through supported Collection Methods.

The objective is to improve event continuity while avoiding unnecessary duplication of customer records.

Identity Resolution does not attempt to infer identities from unrelated third-party datasets.

Customer Profiles

Customer Profiles aggregate information collected on behalf of a Merchant.

Depending on Merchant configuration, profiles may include:

• identifiers;
• events;
• transaction history;
• audience membership;
• calculated attributes.

Profiles remain under the Merchant's control.

SetRoasFlow does not use Customer Profiles for unrelated commercial purposes.

Merchant-controlled Destinations

SetRoasFlow does not independently determine where Merchant Customer Data is transmitted.

Destinations are selected and configured exclusively by the Merchant.

The platform acts only according to Merchant instructions when routing information to supported Destinations.

This architecture ensures that Merchants retain control over downstream data sharing.

Warehouse export

Where enabled, warehouse export delivers raw event records to data infrastructure operated by the Merchant — a data warehouse, an object storage bucket, or an HTTP endpoint under the Merchant's control.

Two safeguards apply in addition to the consent decision already made at collection:

1. personal data is excluded by default; exporting clear-text email addresses or telephone numbers requires the Merchant to enable that option explicitly;
2. the consent decision for each event is written as a field of the exported record, so it remains visible and enforceable downstream.

Network identifiers (IP address and user agent) are not included in exported records.

Because the destination is infrastructure the Merchant selects and contracts for, the Merchant determines its location, its retention, and the safeguards applying to any international transfer.

Least Privilege

Every system component is designed to receive only the permissions necessary to perform its specific function.

Examples include:

• restricted service permissions;
• isolated runtime environments;
• controlled administrative access;
• limited operational privileges.

Reducing unnecessary permissions limits the potential impact of security incidents.

Infrastructure Isolation

Different platform components perform separate responsibilities.

Examples include:

• event collection;
• identity resolution;
• profile storage;
• dashboard services;
• authentication;
• destination routing.

Separating responsibilities reduces operational risk and limits unnecessary data exposure between components.

Operational Logging

Logging is designed primarily for operational reliability and security.

Logs are intended to contain the minimum amount of information necessary for:

• diagnosing failures;
• monitoring platform health;
• investigating incidents;
• improving service reliability.

Where practical, sensitive information is minimized or excluded.

Retention-aware Design

Storage is intended to support business functionality rather than indefinite retention.

Retention periods are determined according to:

• operational requirements;
• Merchant instructions where applicable;
• legal obligations;
• security requirements.

Information that is no longer required is deleted or anonymized according to applicable retention policies.

Secure Defaults

Default platform behavior is designed to prioritize security and privacy.

Examples include:

• authenticated dashboard access;
• encrypted communications;
• restricted administrative permissions;
• controlled processing workflows;
• infrastructure security controls.

Additional privacy functionality may be configured by Merchants according to their own compliance requirements.

Fail-Closed Processing

Where privacy-related decisions cannot be confidently evaluated, SetRoasFlow is designed to favor conservative processing outcomes whenever reasonably practical.

Depending on the processing context, this may include:

• withholding destination delivery;
• suppressing identifiers;
• delaying processing until required information is available.

This approach reduces the likelihood of unintended disclosures resulting from incomplete privacy information.

Continuous Evolution

Privacy architecture evolves continuously alongside:

• product capabilities;
• security practices;
• infrastructure improvements;
• regulatory developments;
• customer requirements.

Architectural improvements are evaluated with the objective of maintaining or improving privacy protections while preserving platform performance.

Relationship with Other Documents

This document should be read together with:

• Privacy Policy
• Terms of Service
• Data Processing Addendum
• Security Overview
• Data Retention Policy
• Subprocessors List

Contact

Questions regarding this document may be directed to:

Operator

Matteo De Giuseppe

Italy

Email

[email protected]

Version History

End of Privacy Architecture