Data Processing Addendum

This Data Processing Addendum (DPA) is between the customer identified in the applicable PayloadRelay account, order, or agreement ( Customer) and [LEGAL ENTITY NAME], organisation number [SWEDISH ORGANISATION NUMBER] (PayloadRelay). It forms part of the PayloadRelay Terms of Service or other agreement governing Customer's use of the Service (the Agreement) and takes effect when Customer accepts the Agreement or otherwise uses the Service to process personal data.

This DPA applies only to personal data that PayloadRelay processes on Customer's behalf as a processor in connection with the Service (Customer Personal Data). It does not govern personal data for which PayloadRelay acts as an independent controller, as described in the Privacy Notice.

“Data Protection Law” means the GDPR, applicable Swedish data-protection law, and other data-protection law applicable to the processing. “GDPR,” “controller,” “processor,” “data subject,” “personal data,” “processing,” “personal data breach,” and “supervisory authority” have the meanings given in the GDPR.

Customer is controller and PayloadRelay is processor of Customer Personal Data, except where Customer acts as a processor for another controller, in which case PayloadRelay is Customer's subprocessor. Customer is responsible for its legal basis, notices, instructions, configured destinations, and compliance with Data Protection Law.

PayloadRelay will process Customer Personal Data only on Customer's documented instructions, including the Agreement, this DPA, Customer's configuration and use of the Service, support requests, and other written instructions accepted by PayloadRelay. These instructions include receiving, validating, transforming, transiently queuing, retrying, and delivering data to destinations selected by Customer and making transfers required for that delivery.

If EU or Member State law requires other processing, PayloadRelay will inform Customer before processing unless the law prohibits notice. PayloadRelay will promptly tell Customer if, in its opinion, an instruction infringes Data Protection Law and can pause the affected processing while the parties address it.

PayloadRelay will limit access to Customer Personal Data to personnel and contractors who need it to provide, secure, maintain, or support the Service. Anyone authorised to process Customer Personal Data must be bound by confidentiality obligations or an appropriate statutory duty and receive relevant data-protection and security guidance.

Taking account of the state of the art, implementation cost, and the nature, scope, context, purposes, and risks of the processing, PayloadRelay will maintain appropriate technical and organisational measures under Article 32 GDPR. The current measures are described in Annex 2. PayloadRelay can update them as technology and risks evolve, provided the overall protection is not materially reduced.

Customer gives PayloadRelay general written authorisation to use the subprocessors in Annex 3. PayloadRelay will impose data-protection obligations that provide substantially equivalent protection for the relevant processing and remains responsible for each subprocessor's performance of those obligations to the extent required by Data Protection Law.

PayloadRelay will provide at least 30 days' notice by email or through the Service before adding or replacing a subprocessor that processes Customer Personal Data. Customer can object within 15 days on reasonable, documented data-protection grounds. The parties will work in good faith on a reasonable solution. If none is available, Customer can stop using and terminate the affected feature or Service before the change takes effect and receive a pro-rata refund of prepaid fees for the terminated, unused period.

A webhook, email recipient, collaboration service, spreadsheet, incident-management service, or other destination selected by Customer is a customer-directed recipient, not a PayloadRelay subprocessor merely because the Service delivers data to it. Customer authorises and is responsible for that disclosure.

Taking account of the nature of processing and information available to it, PayloadRelay will reasonably assist Customer with appropriate technical and organisational measures for responding to data-subject requests and with Customer's obligations under Articles 32–36 GDPR, including security, breach assessment, data-protection impact assessments, and prior consultation.

If PayloadRelay receives a request concerning Customer Personal Data, it will not respond on Customer's behalf unless authorised or legally required. Where reasonably identifiable, PayloadRelay will direct the requester to Customer and notify Customer. Assistance beyond standard Service functionality can be subject to reasonable fees based on the work required, unless the assistance is necessary because PayloadRelay breached this DPA.

PayloadRelay will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data. Notice will include the information reasonably available to describe the nature of the breach, affected data and data subjects, likely consequences, measures taken or proposed, and a contact point. Information can be supplied in phases as the investigation proceeds.

PayloadRelay will take reasonable steps to contain, investigate, mitigate, and remediate the breach and will cooperate with Customer's legally required assessment and notifications. Notice is not an admission of fault. Customer remains responsible for notifications to supervisory authorities and data subjects unless it expressly authorises PayloadRelay to act on its behalf.

PayloadRelay will make available information reasonably necessary to demonstrate compliance with Article 28 GDPR. Customer should first use current documentation, questionnaires, summaries, and independent reports that PayloadRelay makes available. If those are insufficient, Customer can conduct one audit in any 12-month period with at least 30 days' written notice, during normal business hours, without accessing another customer's data or unreasonably disrupting operations.

An auditor must be independent, appropriately qualified, non-competitive, and bound by confidentiality. Customer bears its audit costs and PayloadRelay's reasonable assistance costs. The frequency, notice, and cost limits do not apply where a competent supervisory authority requires an audit or where credible evidence of a material breach makes an additional audit reasonably necessary.

During the Agreement, Customer can delete configuration using available Service controls and can request reasonable assistance to retrieve Customer Personal Data that is available for export. When the relevant processing ends, Customer can instruct PayloadRelay to return or delete remaining Customer Personal Data. If Customer gives no instruction, the account-deletion and retention settings in Annex 1 apply. PayloadRelay will delete remaining copies unless EU or Member State law requires retention.

Relay request and message bodies are not persisted outside process memory and trusted transport queues, where a permanently failed message is retained for up to 7 days pending diagnosis or redelivery before the broker discards it. Database backups rotate after 35 days and are isolated from normal use; completed deletion outcomes are reapplied if restoration is necessary. Limited controller records for billing, security, legal compliance, and deletion integrity are outside this DPA and follow the Privacy Notice.

PayloadRelay will not transfer Customer Personal Data outside the EEA except on Customer's documented instruction or using a transfer mechanism permitted by Data Protection Law. Where required, the parties incorporate the then-current European Commission Standard Contractual Clauses applicable to controller-to-processor or processor-to-processor transfers. This DPA supplies the relevant description and security annexes, Swedish law governs optional governing-law choices, and the courts identified in the Agreement are selected where the clauses permit. PayloadRelay will apply supplementary measures where reasonably necessary after a transfer assessment.

This DPA controls over conflicting Agreement terms concerning processing of Customer Personal Data. The Agreement's liability provisions apply to this DPA to the maximum extent permitted by Data Protection Law, without limiting data-subject rights or a supervisory authority's powers. The governing-law and dispute provisions in the Agreement apply except where mandatory Data Protection Law or incorporated transfer clauses require otherwise.

Data-protection notices and requests can be sent to [email protected].

Subject matter and duration

Processing needed to provide and support PayloadRelay for the Agreement term, followed by deletion or return under Section 9 and the retention periods below.

Nature and purpose

Receiving, validating, authenticating, parsing, filtering, transforming, transiently queuing, routing, retrying, failing over, and delivering events; storing Customer-configured endpoints, templates, credentials, and destinations; recording metadata-only activity and outcomes; enforcing security and plan controls; and providing support on Customer's instruction.

Data subjects

Customer's personnel, users, customers, prospects, suppliers, contractors, correspondents, end users, and any other individuals whose data Customer chooses to include in events, configurations, messages, or instructions.

Types of personal data

Identifiers, names, contact details, account and customer references, IP and device information, communications and message content, event attributes, transaction and operational information, and any other personal data Customer chooses to submit or derive through configured transformations. PayloadRelay does not independently determine or classify the contents of Customer's events.

Frequency

Continuous or intermittent according to Customer's configuration and event traffic.

Operational retention

Relay bodies are held only for delivery: in process memory and transport queues while an event is being delivered, and for up to 7 days in a dead-letter queue where delivery failed permanently and the message awaits diagnosis or redelivery. Activity metadata and delivery outcomes are retained for 30 days. Stored configuration remains until Customer deletes it or the workspace is permanently deleted. Ordinary account deletion has a 30-day recoverable grace period; encrypted backups rotate after 35 days; limited non-reversible deletion safeguards can remain for 45 days. A verified erasure request can bypass the ordinary grace period, subject to required legal retention.

• Data minimisation: relay bodies are excluded from databases, activity logs, object storage, application logs, traces, metrics, caches, and backups. They are held only in process memory and in the trusted transport queues used to deliver them, where a broker-enforced 7-day message expiry bounds retention of permanently failed messages.
• Transport: public web traffic uses encrypted transport; internal and destination transport protections are applied where configured and supported.
• Access: authenticated accounts, workspace roles, tenant checks, least-privilege operational access, and controlled secrets protect customer environments.
• Credentials: passwords are hashed; sensitive destination credentials and secrets are protected at rest and excluded from user-facing reads and logs.
• Application security: input validation, CSRF and session protections, rate limits, destination restrictions, dependency checks, and security-focused tests are used where applicable.
• Reliability: delivery, retry, and dead-letter queues bounded by message expiry, publisher confirmation, health monitoring, backup procedures, and recovery controls support availability and integrity.
• Logging and retention: logs and telemetry are designed to exclude relay bodies and secrets; metadata retention and deletion jobs are bounded and monitored.
• Personnel and incidents: confidentiality, restricted production access, incident handling, vulnerability remediation, and deletion procedures apply to authorised personnel.
• Backups: encrypted database backups use restricted credentials, exclude relay bodies by design, rotate after 35 days, and remain isolated from ordinary application use.

Stripe and optional OAuth providers process account or billing data under their applicable terms and roles and are not listed here solely as Customer Data subprocessors.