Data Processing Agreement
Last updated:
This DPA has 2 parts: (1) the Key Terms on this Cover Page and (2) the Common Paper DPA Standard Terms Version 1.1 ("DPA Standard Terms"), which is incorporated by reference. If there is any inconsistency between the parts of the DPA, the Cover Page will control over the DPA Standard Terms. Capitalized words defined on this Cover Page have the meanings given here. However, if the Cover Page omits or does not define such a word, the default meaning will be "none" or "not applicable" and the correlating clause, sentence, or section does not apply to this DPA. All other capitalized words have the meanings given in the DPA Standard Terms or the Agreement.
This DPA is part of the Agreement, so Customer enters into it by accepting the Agreement, and it applies from the Agreement's Effective Date. This DPA is accepted electronically with the Agreement; no separate signature is required.
Key Terms
- Agreement
- This DPA supplements the Strent Terms of Service between Provider and Customer.
- Approved Subprocessors
-
- Render Services, Inc.
Country of location: United States (Render's Virginia region).
Processing task: Hosting the Service: its application servers, database, database backups, and server logs. - Porkbun LLC
Country of location: United States.
Processing task: Receiving email sent to strent.dev addresses, such as Customer's requests about its end customers, and forwarding it to Provider's mailbox. - Google LLC
Country of location: United States.
Processing task: Hosting the mailbox that receives the email Porkbun forwards.
- Render Services, Inc.
- Provider Security Contact
- legal@strent.dev
- Security Policy
- Provider will use commercially reasonable efforts to secure the Service from unauthorized access, alteration, or use and other unlawful tampering. Annex II describes the measures the Service implements.
Restricted Transfers
- Governing Member State
- EEA Transfers: Spain.
UK Transfers: the laws of England and Wales.
Changes to the DPA Standard Terms
Audits. Section 5.2 (Security Reports) of the DPA Standard Terms does not apply: no independent auditor audits Provider, and there is no Report. Customer's audit rights under Section 5.1 (Audit Rights) are exercised through Section 5.3 (Security Due Diligence). Where Article 28(3)(h) of the GDPR or the EEA SCCs require it, Provider will also allow an audit by Customer or by an auditor Customer mandates, at Customer's cost, on reasonable notice, and at most once a year. The annual limit and the notice requirement yield as far as necessary when there are indications of non-compliance or the law requires otherwise, including under Clause 8.9(c) of Module Two of the EEA SCCs. An auditor Customer mandates must be bound by confidentiality and must not be a competitor of Provider.
Security Incident notice. Modifying Section 4.1(a) of the DPA Standard Terms, Provider will notify Customer of a Security Incident without undue delay after becoming aware of it; the 72-hour limit does not apply.
Records. The last sentence of Section 5.1 (Audit Rights) of the DPA Standard Terms, on keeping records of compliance for 3 years after the DPA ends, does not apply.
Subprocessor objections. Modifying Section 2.6(a) of the DPA Standard Terms, Customer may object to a change to the Approved Subprocessors on reasonable data-protection grounds within 10 business days after Provider's notice of it; otherwise Customer is deemed to accept the change. Customer and Provider will cooperate in good faith to resolve a timely objection before the new Subprocessor processes that Customer's Personal Data.
UK Addendum. Modifying the first sentence of Section 3.3(b) of the DPA Standard Terms, for Table 4 of the UK Addendum, Provider is selected as a party that may end the UK Addendum as set out in its Section 19.
Annex I(A): List of Parties
- Data Exporter
-
Name: Customer, as identified by its Strent account.
Contact: the main email address on Customer's account.
Activities relevant to transfer: see Annex I(B).
Role: Controller, or Processor where Customer processes the data on behalf of another Controller. - Data Importer
-
Name: Provider, Juan Manuel Copia Mateu, trading as Strent.
Address: Calle Mezquite 2, 28045 Madrid, Spain.
Contact person: Juan Manuel Copia Mateu, Provider, legal@strent.dev.
Activities relevant to transfer: see Annex I(B).
Role: Processor, or Subprocessor where Customer is a Processor.
Annex I(B): Description of Transfer and Processing Activities
- Service
- Strent.
- Categories of Data Subjects
- Customer's end customers: the people whose customer records are in the Stripe account Customer connects to a Strent project.
- Categories of Personal Data
-
- Stripe identifiers: Stripe customer IDs, and the IDs of their subscriptions, subscription items, and subscription schedules.
- Transactional information: each subscription's status, products and prices (IDs, names, lookup keys, nicknames, amounts, currencies, and billing intervals), quantities, and its start, billing-period, trial, cancellation, and end dates, and the phases of its subscription schedule.
- The content of the Stripe events Customer's Stripe account sends to Strent. For the events Strent requires, this includes the Stripe Customer object, such as name, email address, phone number, postal and shipping addresses, description, and metadata, and the subscription and subscription schedule objects. Any other event Customer sends is kept the same way.
- Request metadata: request URLs that contain Stripe customer IDs, recorded in server logs.
- Special Category Data
- No.
- Frequency of Transfer
- Continuous.
- Nature and Purpose of Processing
-
Provider will Process Customer Personal Data as instructed in Section 2.3 of the DPA Standard Terms, to keep a copy of each end customer's subscription state, answer Customer's access checks and billing reads, and let Customer inspect and repair that copy. The nature of processing includes:
- Receiving data, including retrieval from Stripe with Customer's restricted API key and recording the Stripe events Customer's account sends.
- Holding data, including storage, organization, and structuring.
- Using data, including consultation through the Strent API, SDK, and Admin console. Customer's application, not Strent, decides what each end customer may access.
- Updating data when Stripe reports a change.
- Protecting data, as described in Annex II.
- Sharing data, by making it available to Customer.
- Erasing data, including expiry and deletion.
- Duration of Processing
-
Provider will process Customer Personal Data as long as required (i) to conduct the Processing activities instructed in Section 2.2(a)-(d) of the Standard Terms; or (ii) by Applicable Laws.
Deleting a project deletes all of its Customer Personal Data from the active database. Copies in server logs and database backups remain until their retention periods end: up to 7 days for server logs and up to 7 days for database backups. To delete one end customer's data, Customer deletes that customer in Stripe, stops its application's calls to Strent for it, and asks by email from its account's address to legal@strent.dev. Provider will implement that instruction as soon as reasonably practicable and provide the assistance required for Customer to meet its obligations under Applicable Data Protection Laws.
Annex I(C)
- Competent Supervisory Authority
- The supervisory authority will be the supervisory authority of the data exporter, as determined in accordance with Clause 13 of the EEA SCCs or the relevant provision of the UK Addendum.
Annex II: Technical and Organizational Security Measures
- Encryption of credentials
- Customer's Stripe restricted API keys and webhook signing secrets are encrypted at rest with AES-256-GCM. Strent API keys are stored only as SHA-256 hashes and shown once, when created.
- User identification and authorization
- Admin console users sign in through Clerk, and every request about a project is checked against the project's owner. Each Strent API key belongs to one project, is verified with a keyed signature before it is looked up, and can be revoked. The operator console uses a separate sign-in and admits only Provider's operator account.
- Protection in transit
- The Service is served over HTTPS only, with plain HTTP redirected to it, and its websites and consoles send Strict-Transport-Security headers. Strent accepts a Stripe event only when its signature matches the project's webhook signing secret.
- Protection in storage
- The database accepts no connections from the internet; the Service reaches it over Render's private network. The API that answers Customer's access checks connects with a database role that can only read the tables it needs.
- Data minimization
- Strent reads Customer's Stripe account with a read-only restricted key limited to customers, products, subscriptions, the Stripe account, test clocks, and webhook endpoints. It never writes to Customer's Stripe account.
- Limited retention
- A daily job deletes Stripe events 30 days after Strent receives them, and finished refresh records 30 days after they end, except each customer's latest refresh and the refreshes its current data comes from.
- Erasure
- Deleting a project deletes all of its data, including its operator records that name one of its Stripe customers, in one database transaction.
- Events logging
- Server logs redact credentials, including authorization headers, cookies, API keys, and Stripe signatures. Each action the operator takes on a project through the operator console is recorded with who took it, what it was, and when.
- Availability
- The public API limits request rates per source and per project.
- Testing
- Automated tests, including tests of the authorization boundaries above, run on every change, and only a change that passes them is released.
Common Paper Data Processing Agreement (Version 1.1) free to use under CC BY 4.0.