Data Processing Addendum

This Data Processing Addendum (DPA) is between two parties. The first party is the customer that the applicable PayloadRelay account, order, or agreement identifies (Customer). The second party is Mikheit AB, organisation number 559548-6225 (PayloadRelay). This DPA is part of the PayloadRelay Terms of Service, or of another agreement that governs the use of the Service by Customer (the Agreement). It takes effect when Customer accepts the Agreement, or when Customer otherwise uses the Service to process personal data.

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

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

Customer is controller and PayloadRelay is processor of Customer Personal Data. If Customer acts as a processor for another controller, PayloadRelay is the subprocessor of Customer. Customer is responsible for its legal basis, its notices, its instructions, its configured destinations, and its compliance with Data Protection Law.

PayloadRelay will process Customer Personal Data only on Customer's documented instructions. These instructions include the Agreement, this DPA, the configuration and the use of the Service by Customer, the support requests, and other written instructions that PayloadRelay accepts. Under these instructions, PayloadRelay receives, validates, transforms, queues transiently, retries, and delivers data to the destinations that Customer selects. PayloadRelay also makes the transfers that such a delivery needs.

If EU law or Member State law requires other processing, PayloadRelay will tell Customer before it processes the data. PayloadRelay will not give that notice when the law prohibits it. If PayloadRelay finds that an instruction infringes Data Protection Law, PayloadRelay will tell Customer immediately. PayloadRelay can then pause the affected processing while the parties resolve the issue.

PayloadRelay gives access to Customer Personal Data only to the personnel and the contractors who need it. They need it to supply, secure, maintain, or support the Service. A confidentiality obligation or an appropriate statutory duty must bind each person who has the authority to process Customer Personal Data. Each such person must also receive the relevant data-protection guidance and security guidance.

PayloadRelay will keep appropriate technical measures and organisational measures under Article 32 GDPR. PayloadRelay considers the state of the art, the implementation cost, and the nature, the scope, the context, the purposes, and the risks of the processing. Annex 2 describes the current measures. PayloadRelay can update the measures as the technology and the risks develop, but an update must not materially reduce the overall protection.

Customer gives PayloadRelay a general written authorisation to use the subprocessors in Annex 3. PayloadRelay will put data-protection obligations on each subprocessor. These obligations give substantially equivalent protection for the relevant processing. PayloadRelay stays responsible for how each subprocessor meets those obligations, to the extent that Data Protection Law requires.

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

A webhook, an email recipient, a collaboration service, a spreadsheet, an incident-management service, or another destination that Customer selects is a customer-directed recipient. A delivery of data to such a destination does not alone make it a PayloadRelay subprocessor. Customer authorises that disclosure, and Customer is responsible for it.

PayloadRelay will give reasonable assistance to Customer with appropriate technical measures and organisational measures. PayloadRelay considers the nature of the processing and the information available to it. This assistance covers the response to a data-subject request. It also covers the obligations of Customer under Articles 32 to 36 GDPR, which include security, breach assessment, data-protection impact assessments, and prior consultation.

If PayloadRelay receives a request about Customer Personal Data, PayloadRelay will not answer it for Customer. PayloadRelay answers only when Customer authorises this, or when the law requires it. Where PayloadRelay can reasonably identify Customer, PayloadRelay will send the requester to Customer and will notify Customer. Assistance beyond the standard functionality of the Service can carry a reasonable fee that matches the necessary work. No fee applies when the assistance is necessary because PayloadRelay breached this DPA.

PayloadRelay will notify Customer without undue delay after it becomes aware of a personal data breach that affects Customer Personal Data. The notice will include the information that is reasonably available. That information describes the nature of the breach, the affected data and data subjects, the likely consequences, the measures that PayloadRelay took or proposes, and a contact point. PayloadRelay can give the information in phases as the investigation continues.

PayloadRelay will take reasonable steps to contain, investigate, mitigate, and remediate the breach. PayloadRelay will cooperate with the assessment and the notifications that the law requires from Customer. A notice is not an admission of fault. Customer stays responsible for the notifications to the supervisory authorities and to the data subjects. Customer can expressly authorise PayloadRelay to act for it instead.

PayloadRelay will supply the information that is reasonably necessary to show compliance with Article 28 GDPR. Customer first uses the current documentation, the questionnaires, the summaries, and the independent reports that PayloadRelay supplies. If these are not sufficient, Customer can make one audit in any 12-month period. That audit needs at least 30 days' written notice, and it occurs during normal business hours. The audit must not access the data of another customer, and it must not disrupt the operations unreasonably.

An auditor must be independent, appropriately qualified, and non-competitive. Confidentiality must also bind the auditor. Customer pays its audit costs and the reasonable assistance costs of PayloadRelay. The limits on the frequency, the notice, and the cost do not apply in two cases. The first case is an audit that a competent supervisory authority requires. The second case is an additional audit that credible evidence of a material breach makes reasonably necessary.

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

PayloadRelay does not store a relay request body or a message body outside the process memory and the trusted transport queues. If a delivery fails permanently, the message stays in a dead-letter queue for a maximum of 7 days, for diagnosis or a new delivery. The broker then discards the message. The database backups rotate after 35 days, and they are isolated from the normal use. If a restoration is necessary, PayloadRelay applies the completed deletion outcomes again. Limited controller records for billing, security, legal compliance, and deletion integrity are outside this DPA, and the Privacy Notice governs them.

PayloadRelay transfers Customer Personal Data outside the EEA only on the documented instruction of Customer, or with a transfer mechanism that Data Protection Law permits. Where this is necessary, the parties incorporate the then-current Standard Contractual Clauses of the European Commission. These clauses apply to a controller-to-processor transfer or a processor-to-processor transfer. This DPA supplies the relevant description annexes and security annexes. Swedish law governs an optional choice of governing law, and the clauses select the courts that the Agreement identifies where the clauses permit this. After a transfer assessment, PayloadRelay applies supplementary measures where these are reasonably necessary.

Where a term of the Agreement conflicts with this DPA about the processing of Customer Personal Data, this DPA controls. The liability provisions of the Agreement apply to this DPA, to the maximum extent that Data Protection Law permits. They do not limit the rights of a data subject or the powers of a supervisory authority. The governing-law provisions and the dispute provisions in the Agreement apply. The exception is where mandatory Data Protection Law or an incorporated transfer clause requires something different.

Send a data-protection notice or a data-protection request to [email protected].

Subject matter and duration

The processing that PayloadRelay needs to supply and support the Service during the term of the Agreement. Deletion or return under Section 9 then applies, together with the retention periods below.

Nature and purpose

PayloadRelay receives, validates, authenticates, parses, filters, transforms, queues transiently, routes, retries, fails over, and delivers the events. PayloadRelay stores the endpoints, the templates, the credentials, and the destinations that Customer configures. PayloadRelay records the activity that holds metadata only, and the outcomes. PayloadRelay enforces the security controls and the plan controls. PayloadRelay supplies support on the instruction of Customer.

Data subjects

The personnel, the users, the customers, the prospects, the suppliers, the contractors, the correspondents, and the end users of Customer. Also any other individual whose data Customer includes in an event, a configuration, a message, or an instruction.

Types of personal data

Identifiers, names, contact details, account references and customer references, IP information and device information, communications and message content, event attributes, and transaction information and operational information. Also any other personal data that Customer submits, or that Customer derives through a configured transformation. PayloadRelay does not determine or classify the contents of the events of Customer by itself.

Frequency

Continuous or intermittent, according to the configuration of Customer and the event traffic.

Operational retention

PayloadRelay holds a relay body only for the delivery. The body stays in the process memory and in the transport queues while PayloadRelay delivers the event. If the delivery fails permanently, the message stays in a dead-letter queue for a maximum of 7 days, for diagnosis or a new delivery. PayloadRelay keeps the activity metadata and the delivery outcomes for 30 days.

The stored configuration stays until Customer deletes it, or until the permanent deletion of the organization. Ordinary account deletion has a recoverable grace period of 30 days. The encrypted backups rotate after 35 days. Limited non-reversible deletion safeguards can stay for 45 days. An erasure request that PayloadRelay completes after an identity check can skip the ordinary grace period, subject to the legal retention that the law requires.

• Data minimisation: PayloadRelay excludes a relay body from the databases, the activity logs, the object storage, the application logs, the traces, the metrics, the caches, and the backups. A relay body stays only in the process memory and in the trusted transport queues that deliver it. A broker-enforced 7-day message expiry bounds the retention of a message that failed permanently.
• Transport: the public web traffic uses encrypted transport. PayloadRelay applies the internal transport protections and the destination transport protections where the configuration and the support allow this.
• Access: authenticated accounts, roles in an organization, tenant checks, least-privilege operational access, and controlled secrets protect the customer environments.
• Credentials: PayloadRelay hashes the passwords. PayloadRelay protects the sensitive destination credentials and secrets at rest, and it excludes them from the user-facing reads and the logs.
• Application security: PayloadRelay uses input validation, CSRF protections and session protections, rate limits, destination restrictions, dependency checks, and security-focused tests where these apply.
• Reliability: the message expiry bounds the queues for delivery, retry, and dead letters. Publisher confirmation, health monitoring, backup procedures, and recovery controls support the availability and the integrity.
• Logging and retention: the design of the logs and the telemetry excludes the relay bodies and the secrets. The metadata retention jobs and the deletion jobs are bounded and monitored.
• Personnel and incidents: confidentiality, restricted production access, incident handling, vulnerability remediation, and deletion procedures apply to the authorised personnel.
• Backups: the encrypted database backups use restricted credentials. They exclude the relay bodies by design, they rotate after 35 days, and they stay isolated from the ordinary application use.

Stripe and the optional OAuth providers process the account data or the billing data under their applicable terms and roles. This table does not list them only as Customer Data subprocessors.