Skip to content

Data Processing Agreement

Version 2026-09-27 · Effective 27 September 2026

This Data Processing Agreement (“DPA”) is part of the Terms of Service between the Customer and SKE. It applies when SKE processes personal data on the Customer’s behalf through SKE. Where this DPA and the Terms of Service differ on data protection, this DPA wins. Where the SCCs or the UK Addendum apply (section 6), they win over both.

1. Scope and roles

  • Customer means the person or entity an organization in SKE belongs to: the company or other entity its Owners use it for, or an Owner who uses it for themselves. Other members act for the Customer.
  • Customer Personal Data means personal data that SKE processes for the Customer through SKE, as described in Annex I. Examples: emails and SMS caught by the mail and SMS catchers, Amazon SES delivery events, environment variables, and console commands and tinker input.
  • For Customer Personal Data, the Customer is the controller (or a processor acting for its own customer) and SKE is its processor (or sub-processor).
  • The account data SKE collects about the people who use SKE, such as their email address and sign-in records, isn’t covered here. SKE is its controller, and the Privacy Policy applies to it.
  • “GDPR” means the EU General Data Protection Regulation and, where it applies, the UK GDPR and the UK Data Protection Act 2018. “Data Protection Laws” means the GDPR and any other data protection law that applies to the processing.

2. Instructions

  • SKE processes Customer Personal Data only on the Customer’s documented instructions, including about transfers to other countries (section 6). The Terms of Service, this DPA, and the Customer’s own settings and actions in SKE (such as connecting a catcher, choosing its retention, or deploying) are those instructions.
  • SKE may also process it where the law of the European Union, an EU Member State or the United Kingdom that applies to SKE requires it. If so, SKE will tell the Customer first, unless that law forbids this on important grounds of public interest.
  • SKE will tell the Customer immediately if it believes an instruction breaks Data Protection Laws, or if it can’t follow an instruction.
  • The Customer also allows SKE to turn Customer Personal Data into aggregated data that can’t identify anyone, and to use it as section 5 of the Terms of Service describes.
  • Where the California Consumer Privacy Act applies to the Customer, SKE is its service provider. SKE won’t sell or share Customer Personal Data, won’t keep, use or disclose it for any purpose other than providing SKE, or outside its direct business relationship with the Customer, won’t combine it with personal data from elsewhere except as that law allows, will tell the Customer if it can no longer meet that law, and will let the Customer take reasonable steps to stop and fix any use that breaks it.
  • The Customer is responsible for having a lawful basis for the data it sends through SKE and for telling its own users about it.

3. Confidentiality

SKE makes sure that everyone it allows to process Customer Personal Data is bound by a duty of confidentiality.

4. Security

SKE applies the technical and organizational measures in Annex II and keeps them appropriate to the risk. SKE may change them, as long as the overall level of protection doesn’t go down.

5. Sub-processors

  • The Customer gives SKE general authorization to use sub-processors. The current list is at ske.io/subprocessors, where the last column marks the ones that process Customer Personal Data.
  • SKE will email the Owners of the Customer’s organizations, and update that list, at least 30 days before a new sub-processor starts processing Customer Personal Data. The email names the sub-processor, what it will do and where.
  • The Customer may object through SKE’s contact form within those 30 days. The parties will then try in good faith to resolve the concern. If they can’t, the Customer may stop using the affected part of SKE or close its account, without penalty.
  • SKE puts each sub-processor under a written contract that gives it, in substance, the same data protection obligations as this DPA, and that meets Clause 9 of the SCCs where they apply. SKE stays fully liable to the Customer for its sub-processors’ performance of those obligations.

6. International transfers

  • SKE runs the SKE API, and keeps caught-email attachments, background jobs and logs, in the EU (Frankfurt, Germany). Sub-processors process Customer Personal Data where the list at ske.io/subprocessors says.
  • Where Customer Personal Data is transferred from the European Economic Area to a country without an adequacy decision, the parties agree to the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 (“SCCs”), which form part of this DPA:
    • Module Two (controller to processor) where the Customer is a controller, and Module Three (processor to processor) where the Customer is a processor;
    • where SKE is established in the European Economic Area and the Customer isn’t, Module Four (processor to controller) applies to the Customer Personal Data SKE sends to the Customer;
    • Clause 7 (docking) applies;
    • under Clause 9, option 2 (general written authorization) applies, with the 30-day notice in section 5;
    • the optional wording in Clause 11 doesn’t apply;
    • under Clause 13, the competent supervisory authority is the one Annex I.C names;
    • under Clause 17 (option 2), the SCCs are governed by the law of the EU Member State where the Customer is established, and under Clause 18 disputes go to the courts of that Member State;
    • Annexes I, II and III of this DPA complete the SCCs’ annexes.
  • For transfers from the United Kingdom to a country without UK adequacy regulations, the parties agree to the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses (version B1.0), issued by the Information Commissioner under section 119A of the Data Protection Act 2018 (“UK Addendum”), which forms part of this DPA. Table 1 is completed by Annex I.A, Table 2 by the choices above, and Table 3 by Annexes I to III. Under Table 4, either party may end the UK Addendum as its Section 19 allows.
  • Where SKE or a sub-processor is certified under the EU-US Data Privacy Framework, or its UK Extension, transfers to it may rely on that certification instead of the SCCs. If the certification or the Framework stops applying, the SCCs apply.
  • When the Customer has SKE send Customer Personal Data to a destination it chooses, such as its own cloud account, an alert destination or an MCP client, that destination isn’t SKE’s sub-processor, and the Customer is responsible for any transfer safeguards it needs.

7. Helping with requests from individuals

SKE lets the Customer handle requests from its users itself where it can. For example, the Customer can delete caught messages or shorten their retention. Console commands and tinker input stay in the audit log until they expire after 12 months, and the Customer can’t delete them there. If SKE receives a request about Customer Personal Data, it will promptly pass it to the Customer without answering it, unless the Customer asks SKE to. SKE will otherwise help the Customer, as far as it reasonably can, to meet its obligations under Chapter III of the GDPR.

8. Personal data breaches

  • SKE will tell the Customer without undue delay, and where it can within 48 hours, after it becomes aware of a personal data breach affecting Customer Personal Data. The notice goes by email to the Owners of the Customer’s organizations.
  • The notice will give a contact point for more information and describe, as far as SKE knows at the time, the nature of the breach, the categories and rough number of people and records affected, the likely consequences, and what SKE has done or proposes to do, including to limit any harm. SKE will send more information without undue delay as it learns it.
  • SKE will take reasonable steps to contain the breach and limit its effects.
  • Telling the Customer about a breach isn’t an admission of fault.

9. Other help

SKE will give the Customer reasonable help, with the information SKE has, with data protection impact assessments, consultations with supervisory authorities, and security obligations under Articles 32 to 36 of the GDPR. SKE will also give the Customer the information it reasonably needs to assess the laws of the countries its data goes to, as Clause 14 of the SCCs requires.

10. When the service ends

  • Until an organization is deleted, the Customer can read and copy its Customer Personal Data in the dashboard and through the SKE API. That is how SKE returns it. SKE doesn’t offer a separate export.
  • When an organization is deleted, or the Terms of Service end, SKE keeps the organization’s data for 30 days and stops collecting new data for it. If an Owner asks through SKE’s contact form within those 30 days, SKE restores the organization so the Customer can take what it needs.
  • After those 30 days, SKE deletes all Customer Personal Data the organization holds, unless the law of the European Union, an EU Member State or the United Kingdom requires SKE to keep some of it. If the Customer asks, SKE confirms the deletion in writing.
  • Some Customer Personal Data is deleted sooner, as Annex I says. For example, caught emails and SMS go after the retention period set for their environment.
  • Resources in the Customer’s own cloud account aren’t affected. They stay there until the Customer deletes them.

11. Information and audits

  • SKE will make available all the information needed to show that it meets this DPA and Article 28 of the GDPR.
  • The Customer may audit SKE’s compliance, itself or through an independent auditor bound by confidentiality, on at least 30 days’ written notice through SKE’s contact form, no more than once a year, and in a way that doesn’t disrupt SKE or put other customers’ data at risk. These limits don’t apply to an audit a supervisory authority requires, one that follows a personal data breach at SKE, or one where there are signs that SKE isn’t meeting this DPA. Each party bears its own costs.

12. Liability

Each party’s liability under this DPA is subject to the limitations in the Terms of Service, as far as Data Protection Laws allow. Those limitations don’t apply to liability under the SCCs or the UK Addendum. Nothing in this DPA limits the rights that individuals have under Data Protection Laws.

13. How long this DPA lasts, and changes

  • This DPA applies for as long as SKE processes Customer Personal Data, including after the Terms of Service end.
  • SKE changes this DPA as section 13 of the Terms of Service describes. A change can’t lower the protection of Customer Personal Data unless the law requires it.
  • Adding or replacing a sub-processor as section 5 describes, and updating the list at ske.io/subprocessors, isn’t a change to the Terms of Service under their section 13.

Annex I: Details of the processing

A. The parties

  • Data exporter: the Customer: the person or entity that accepted the Terms of Service for its organizations in SKE. Contact: the Owners of those organizations, at the email addresses on their SKE accounts. A Customer that wants its legal name and address in this Annex can send them through SKE’s contact form. Activities: using SKE, as described in B. Role: controller, or processor acting for its own customer.
  • Data importer: SKE. Contact: SKE’s contact form. Data protection officer: none appointed. Activities: providing SKE, as described in B. Role: processor, or sub-processor.
  • Signature and date: by accepting the Terms of Service, which include this DPA, the Customer and SKE are treated as having signed this DPA, the SCCs and the UK Addendum. The date is the day the Customer accepts them, which is also the UK Addendum’s start date.

B. Description of the processing

  • Subject matter: providing SKE to the Customer under the Terms of Service: deploying and running its applications, and the mail and SMS catchers, Amazon SES delivery events, alerts, the console and application logs.
  • Duration: for as long as the Customer uses SKE, and then until the data is deleted as section 10 describes.
  • Categories of people: the Customer’s end users and anyone else whose personal data the Customer’s applications send, receive, record or print, such as the senders and recipients of emails and SMS; and the Customer’s own staff and contacts whose details it enters in SKE, such as alert recipients and the contact named in an Amazon SES production-access request.
  • Categories of personal data:
    • names, email addresses and phone numbers;
    • the content of caught emails and SMS, including subjects, bodies, headers and attachments;
    • email delivery events: the sender, recipients, subject and headers of each email and, when the Customer turns on open or click tracking, recipients’ IP addresses and browsers;
    • alert destinations (email addresses, chat webhook URLs and bot tokens) and the contact details in an Amazon SES production-access request;
    • deploy and job output, including what the Customer’s deploy hooks print and error text from its cloud account;
    • any personal data the Customer puts in environment variables or console commands;
    • passing through SKE without being stored: application log lines and console command output.
  • Special categories of data: none are intended. The Customer should keep them out of catchers, environment variables and console commands. If they are present, the measures in Annex II apply to them too.
  • Frequency: continuous, while the Customer uses the relevant features.
  • Nature and purpose: receiving, storing, displaying, sending and deleting Customer Personal Data so SKE can deploy and run the Customer’s applications, show the Customer what its applications sent, logged and printed, record the Amazon SES delivery, bounce, complaint, open and click events the Customer chooses to track, and send the Customer’s alerts.
  • Retention:
Data Kept for
Caught emails and SMS, with attachments The environment’s settings: 7 days and the newest 1,000 messages by default, 30 days and 5,000 messages at most. All go when the catcher is detached or the environment is deleted
Amazon SES delivery events 90 days, or until the Customer deletes the SMTP provider
Environment variables Until the environment is deleted
Console commands and tinker input, in the audit log 12 months
Deploy and job output Until the environment or organization is deleted
Alert destinations Until the Customer deletes the channel
Contact details in an Amazon SES production-access request Until the Customer deletes the SMTP provider
Metrics from the Customer’s cloud account Up to 90 days. They are numbers only, with no personal data
Copies in SKE’s own systems: failed background jobs, which can hold alert text, and SKE’s application logs, which can hold error text Failed jobs: 7 days. Logs: 14 days
Application logs, console output and secrets Not stored. Logs and console output pass through to the Customer, and secrets go straight to the Customer’s own secret store
  • Transfers to sub-processors: as listed at ske.io/subprocessors, for the purposes stated there, for as long as the Customer uses SKE.

C. Competent supervisory authority

  • If the Customer is established in an EU Member State: the supervisory authority responsible for the Customer’s compliance with the GDPR for the transfer.
  • If the Customer isn’t established in the EU, but the GDPR applies to it under Article 3(2) and it has appointed a representative: the supervisory authority of the Member State where that representative is established.
  • If the Customer isn’t established in the EU and doesn’t need a representative: the supervisory authority of a Member State where the people whose data is transferred are located.
  • For transfers from the United Kingdom: the Information Commissioner.

Annex II: Security measures

These are the measures SKE has today.

  • Encryption in transit: the website, the dashboard and the SKE API are served over HTTPS, and the adapter sends caught emails and SMS to the SKE API over HTTPS.
  • Encryption at rest: connected cloud credentials, catcher tokens and SES webhook secrets are encrypted by the application. AWS also encrypts the attachments in Amazon S3 and the logs in Amazon CloudWatch at rest.
  • Sign-in: passwordless sign-in with single-use links that expire after 10 minutes, access tokens that expire after 15 minutes, and refresh and API tokens stored as hashes.
  • Access control: each organization’s data is kept apart in a shared database. Every request from a person, API token or MCP client reaches only the organizations that person or token belongs to, and is checked against the roles granted in that organization, workspace, project or environment. An API token belongs to one organization and carries only the permissions chosen for it. Deploying to, or deleting, a protected environment needs an extra permission. Only people with the audit log permission, Owners and Admins by default, can see the audit log.
  • Machine access: each catcher sends data with its own token, and SES events are accepted only at a secret address for each SMTP provider and with a valid Amazon SNS signature.
  • Audit log: changes and operations are recorded with who did them and when, in an append-only log kept for 12 months.
  • Access to the Customer’s cloud: SKE uses only the role or service account the Customer grants, with the permissions SKE’s docs list, and the Customer can revoke it at any time. AWS roles are assumed with an external ID.
  • Abuse protection: rate limits on sign-in, the contact form, cookie choices, the SES webhook and failed API-token attempts, and a Cloudflare Turnstile bot check on dashboard sign-in and registration and on the contact form.
  • Data minimization: catchers keep messages for a limited time and number, application logs and console output from the Customer’s cloud are shown but not stored, and secrets set with ske secret set or in the dashboard go to the Customer’s own secret store, not SKE’s database. Environment variables are stored, so credentials belong in secrets instead, as section 3 of the Terms of Service says.
  • Physical security: SKE’s servers and storage run in its providers’ data centers, under their physical security.
  • Helping with requests: the Customer can read and delete caught messages, change their retention, and change environment variables with a deploy, without asking SKE.
  • Incident response: breaches are handled and reported as section 8 describes.

Annex III: Sub-processors

The list at ske.io/subprocessors forms part of this DPA.

Versions