WARNING - It is not legal advice — have counsel confirm the specific wording and workflow match your data practices.
Privacy Impact Assessment (PIA)¶
Use of Stripe as a Third-Party Payment Processor¶
Prepared for: [Company Legal Name] Prepared by: [Privacy Officer name/title] Date: [Month DD, YYYY] Reviewed by legal counsel: [ ] Yes [ ] Pending
Note before using: This PIA is built to satisfy Law 25’s requirement (s. 3.3 and s. 17 of the Act) that a privacy impact assessment be conducted before acquiring, developing, or redesigning an information system or electronic service delivery project involving personal information, and specifically before any transfer of personal information outside Quebec. It’s grounded in Stripe’s current publicly documented practices (checked [today’s date]), but you must verify the specifics against your own Stripe account configuration, your actual Data Processing Agreement with Stripe, and confirm nothing has changed since this was drafted — Stripe’s subprocessor list and entity structure are updated periodically. Replace bracketed placeholders and have counsel sign off before relying on this.
1. Project description¶
Purpose of this assessment: To evaluate the privacy risks associated with using Stripe, Inc./Stripe, LLC (and affiliated entities) as our payment processing service provider, and to determine whether the transfer of personal information to Stripe — including outside Quebec — provides a level of protection equivalent to that required under the Act.
Description of the project: [Company Name] uses Stripe to [process customer payments / manage subscriptions / issue invoices / etc.]. This involves transmitting customer personal information to Stripe’s systems for processing.
Business purpose: [e.g., “To accept credit card payments securely without storing cardholder data on our own servers, and to reduce PCI DSS compliance scope.”]
2. Roles¶
| Party | Role |
|---|---|
| [Company Name] | Data Controller (in Stripe’s terminology: “Business User” / Controller for most flows) |
| Stripe, LLC (US) | Data Processor for most payment processing activities; independent Data Controller for certain purposes (e.g., fraud prevention, regulatory compliance, its own Radar fraud-detection network) |
| Stripe Technology Company Limited (STC) | Data Controller for Stripe’s EMEA/APAC regions, where applicable |
| Stripe subprocessors | Sub-processors engaged by Stripe (cloud hosting, identity verification, tax filing, customer support tooling, etc.) — see Section 5 |
This dual role — processor for some purposes, independent controller for others (e.g., fraud detection, legal compliance, aggregated risk scoring across Stripe’s network) — should be disclosed in our own privacy policy so customers understand Stripe may use their data for its own purposes in addition to acting on our instructions.
3. Personal information involved¶
| Category | Examples | Sensitivity |
|---|---|---|
| Identification | Name, email, billing address | Standard |
| Payment information | Card number (tokenized by Stripe), last 4 digits, expiry, payment method type | Sensitive (financial) |
| Transaction data | Amount, currency, date, order reference | Standard |
| Identity verification data (if applicable) | Government ID, date of birth [if using Stripe Identity / Connect] | Sensitive |
| Device/technical data | IP address, device fingerprint (used by Stripe Radar for fraud detection) | Standard |
Note: [Company Name] does not directly store full card numbers — Stripe’s tokenization means raw cardholder data is held by Stripe, reducing our own PCI DSS scope. Confirm this matches your actual integration (e.g., Stripe Elements/Checkout vs. a custom integration that touches raw card data).
4. Necessity and proportionality¶
- Is the information collected necessary for the purpose? Yes — processing payments inherently requires payment method and billing information; this is proportionate to a transactional relationship.
- Could the purpose be achieved with less information or a lower-risk method? [Assess — e.g., “No; industry-standard payment processing requires this level of data. Using a PCI DSS Level 1 processor with tokenization minimizes our own exposure compared to a custom in-house solution.”]
- Is a Level 1 PCI DSS-certified processor being used to minimize risk? Yes — Stripe holds PCI DSS Level 1 certification, the highest level of Payment Card Industry compliance, requiring annual validation by an independent Qualified Security Assessor.
5. Data flow and sub-processing¶
Stripe publishes a current list of sub-processors and affiliates it relies on to deliver its services (hosting, identity verification providers, tax filing partners, customer support tools, etc.), available at Stripe’s Service Providers, Sub-Processors & Affiliates page. Under Stripe’s DPA, [Company Name] has the right to object in writing to a new sub-processor within 30 days of a list update; if no objection is raised, the appointment is deemed accepted.
Action item: [Privacy Officer] should subscribe to updates on this page and review new sub-processors as part of the ongoing monitoring plan (Section 9), rather than treating this PIA as a one-time exercise.
6. Cross-border transfer analysis (Section 17 assessment)¶
This is the core analysis Law 25 requires before data leaves Quebec.
6.1 Where does the data go?¶
Stripe’s corporate structure involves transfers of personal information to the United States (Stripe, LLC — the entity Stripe, Inc. converted into, effective January 3, 2026) and potentially to other jurisdictions via Stripe’s global sub-processor network, depending on region and product.
6.2 What safeguards does Stripe have in place for these transfers?¶
- Contractual mechanism: Stripe’s Data Processing Agreement incorporates a Data Transfers Addendum, which applies the EU Standard Contractual Clauses (SCCs) and the UK Data Transfer Addendum where applicable, and specifies an order of precedence among transfer mechanisms so only one mechanism governs a given transfer.
- Certification-based mechanism: Stripe, LLC self-certifies under the EU-U.S. Data Privacy Framework (and its UK and Swiss extensions), which the U.S. and EU/UK/Swiss authorities recognize as providing adequate protection for personal data transferred from those jurisdictions to certified U.S. companies.
- Security certifications: Stripe maintains PCI DSS Level 1, SOC 1, SOC 2 Type II (with a public SOC 3 summary), and ISO 27001 certifications, and states its security policies are aligned with the NIST Cybersecurity Framework.
- Sub-processor flow-down: Stripe’s agreements with its own sub-processors require equivalent data protection commitments and restrict sub-processors from using the data for their own purposes.
6.3 Does this meet Law 25’s “equivalent protection” standard?¶
Quebec’s Act requires that, before a cross-border transfer, the organization assess whether the receiving jurisdiction’s protections are “equivalent” to Quebec’s — not identical, but providing comparable safeguards. Relevant factors:
| Factor | Assessment |
|---|---|
| Is there a binding data protection agreement? | Yes — Stripe’s DPA is a mandatory part of the Stripe Services Agreement |
| Are there recognized transfer mechanisms (SCCs, adequacy, certification)? | Yes — SCCs + Data Privacy Framework self-certification |
| Independent security certification? | Yes — PCI DSS Level 1, SOC 2 Type II, ISO 27001 |
| Breach notification commitment? | Yes — Stripe’s DPA commits to notifying [Company Name] without unreasonable delay following a data incident, and to cooperating on our own downstream notification obligations |
| Restrictions on onward transfer/use for unrelated purposes? | Yes — Stripe’s DPA restricts use of personal data to specified purposes and requires flow-down terms to sub-processors |
| Data subject rights support | Yes — Stripe commits to informing us of data subject requests it receives and directing individuals back to us as controller, rather than responding unilaterally |
Preliminary conclusion: [To be finalized by Privacy Officer/counsel] Based on the contractual (SCCs/DPA), certification-based (Data Privacy Framework), and independently audited security safeguards (PCI DSS Level 1, SOC 2, ISO 27001) Stripe has in place, the level of protection appears [equivalent / not equivalent — state conclusion] to that required under Quebec law. [State any residual concerns, e.g., “Note: Stripe is not FedRAMP-authorized; this is not a concern for our use case but would be relevant if serving U.S. federal government customers.”]
7. Risk assessment¶
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Unauthorized access to payment data via Stripe breach | Low | High | PCI DSS Level 1, SOC 2, ISO 27001 certifications; tokenization means we never hold raw card data |
| Sub-processor introduces new risk without our awareness | Medium | Medium | 30-day objection window on Stripe’s sub-processor updates; assign monitoring owner |
| Cross-border transfer lacks adequate protection | Low | High | SCCs + Data Privacy Framework certification + contractual DPA in place |
| Stripe uses data for its own independent-controller purposes beyond our instructions (e.g., network-wide fraud scoring) | Medium | Low-Medium | Disclosed in our privacy policy; limited to fraud/risk and legal compliance purposes per Stripe’s terms |
| Data subject exercises access/deletion rights we can’t fulfill through Stripe | Low | Medium | Confirm process for relaying and fulfilling access/deletion requests via Stripe’s dashboard/API |
| Retention beyond necessity | Low | Medium | Confirm Stripe’s data retention period post-account closure and align with our own retention policy |
8. Consultation¶
- [ ] IT/Security team reviewed integration method (Stripe Elements/Checkout vs. direct API touching raw card data)
- [ ] Legal counsel reviewed the Stripe Services Agreement and DPA currently in effect
- [ ] Privacy Officer reviewed Stripe’s current sub-processor list
- [ ] Confirmed our own Privacy Policy discloses Stripe as a processor/recipient (see Section 6 of our Privacy Policy template)
9. Ongoing monitoring plan¶
| Action | Frequency | Owner |
|---|---|---|
| Review Stripe’s sub-processor list for new entries | On notification / at least quarterly | [Privacy Officer] |
| Reconfirm Stripe’s certifications (PCI DSS, SOC 2, ISO 27001) are current | Annually | [Privacy Officer] |
| Re-verify Data Privacy Framework certification status | Annually | [Privacy Officer] |
| Review this PIA for continued accuracy | Annually or upon material change to the Stripe relationship | [Privacy Officer] |
| Confirm Stripe DPA/DTA terms haven’t materially changed | Upon Stripe contract update notice | [Legal] |
10. Decision and sign-off¶
Decision: [ ] Proceed with Stripe as configured [ ] Proceed with additional safeguards (specify) [ ] Do not proceed
Additional safeguards required (if any): [e.g., “Update Privacy Policy to explicitly name Stripe as processor and disclose cross-border transfer”]
| Role | Name | Signature | Date |
|---|---|---|---|
| Privacy Officer | |||
| Legal Counsel | |||
| [Executive Sponsor] |
Sources reviewed¶
- Stripe Data Processing Agreement — stripe.com/legal/dpa
- Stripe Data Transfers Addendum — stripe.com/legal/dta
- Stripe Data Processing Agreement FAQs — stripe.com/legal/dpa/faqs
- Stripe Service Providers, Sub-Processors & Affiliates — stripe.com/legal/service-providers
- Security at Stripe — docs.stripe.com/security
This PIA supports compliance with Quebec’s Act respecting the protection of personal information in the private sector (Law 25), including the privacy impact assessment requirements under sections 3.3 and 17. It is not legal advice — confirm current Stripe contract terms and have counsel review before relying on this assessment.