§What PCI DSS requires
Source: Payment Card Industry Data Security Standard — maintained by the PCI Security Standards Council — accessed 2026-05-11.
Jurisdiction. Maintained by the PCI Security Standards Council, founded in 2006 by American Express, Discover, JCB International, MasterCard, and Visa. PCI DSS is not a government regulation — it is a contractual industry standard. The PCI SSC manages the standard itself; payment brands and acquirers enforce compliance through their own programmes.
Personal data definition. PCI DSS distinguishes cardholder data (CHD) from sensitive authentication data (SAD), and applies to "all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE)." This includes merchants, processors, acquirers, issuers, and service providers.
Key requirements relevant to mobile analytics. PCI DSS "defines security requirements to protect environments where payment account data is stored, processed, or transmitted." It "provides a baseline of technical and operational requirements designed to protect payment account data." Compliance scope depends on how a merchant handles cardholder data: an app that routes all payments through a tokenising third party (Stripe, Adyen, App Store, Google Play) keeps the cardholder data environment outside its own perimeter and qualifies for the smallest assessment scope. The PCI SSC does not enforce compliance itself; payment brands do, through their respective compliance programmes.
⚑Where mobile analytics typically creates exposure for telehealth apps
The simplest PCI DSS rule for mobile analytics is PAN (Primary Account Number) must never enter the analytics pipeline. A developer who logs purchase with parameter card_number: '4111…' has pulled the analytics SDK into the cardholder data environment, dramatically expanding the assessment scope. The same applies to track-2 data, CVV, and PINs (which fall under sensitive authentication data and must not be stored after authorisation at all).
Telehealth apps routinely process appointment metadata, symptom descriptions, diagnosis codes, medication names, vitals (heart rate, blood pressure, glucose), and prescription details. Each of these is individually identifying when combined with a user identifier in an analytics event.
Health-related data is treated as a special category under most privacy regimes — GDPR Art. 9, CPRA sensitive personal information, and PHI under HIPAA. A single event like appointment_booked with parameters { specialty: 'oncology', user_id: '...' } is structurally health data tied to an identifier.
▸What Respectlytics's design does (technical facts)
Respectlytics's API stores exactly five fields per event: event_name, session_id (rotates every two hours, RAM-only), timestamp, platform, and country. Health-category fields are rejected at the API with a 400. A telehealth app can use Respectlytics to track product signals (appointment_booked_paid, prescription_renewal_attempted) at the session level — the actual clinical content stays in the EHR or telehealth platform where it belongs.
Reduces the surface. Removing the surface where the categories covered by PCI DSS could be collected in the first place narrows what a PCI DSS review needs to scope. Whether the resulting posture meets the regulation's requirements for your specific app is something to discuss with your legal team.
❓Frequently asked questions
Is PCI DSS a law?
No. PCI DSS is a contractual industry standard maintained by the PCI Security Standards Council. It becomes binding on a merchant or service provider through the contracts they have with card networks and acquirers. Some U.S. states have referenced PCI DSS in legislation, but the standard itself is not government-issued.
If we use Stripe / Apple IAP / Google Play, are we still in PCI scope?
Yes, but at the smallest scope — typically SAQ A for merchants that fully outsource cardholder-data handling. The cardholder data never touches your servers, but the obligations don't disappear: you must ensure your code does not see, log, or transmit the PAN, and that any redirect/iframe to the payment processor is itself well-protected.
Does using Respectlytics by itself resolve PCI DSS obligations for our telehealth apps app?
No — and no analytics SDK can credibly answer that question. Whether your product meets PCI DSS's requirements is a property of your whole product, contracts, and operational practice, evaluated by your legal team. Respectlytics's contribution is a smaller data surface: identifying fields and the regulation's special categories are rejected at the API. Whether that posture, combined with your other controls, satisfies PCI DSS for your specific app is a conversation for your counsel.
What if we already use a different analytics SDK today?
The starting point is an inventory of what your current SDK actually collects and where it sends it. Our privacy self-assessment worksheet walks through that in seven sections — it outputs an educational summary you can bring to your legal team.