3 ms·

Wise words. Information should be treated as toxic effluvia and HIPAA compliance (as well as GDPR and related laws) should be considered as superfund cleanup pr

by rsj_hn 6y ago

Wise words. Information should be treated as toxic effluvia and HIPAA compliance (as well as GDPR and related laws) should be considered as superfund cleanup procedures. They are expensive, complex, and fraught with legal risk. Don't collect information, don't store it, unless absolutely necessary and you can't find an expert certified third party to handle it for you.

sokoloff 6y ago
We had a PCI QSA who argued that pages that linked out to payment processors were in full scope for PCI, because if compromised, they could be changed to point to a compromised payment entry site. Which logically means that pages which point to those pages are also in scope, all the way up the stack and suddenly everything is in full PCI scope. Absolutely use a PSP to minimize your wasted effort on compliance activities, but also choose a sane QSA.
- hn_throwaway_99 6y ago
  Note this is explicitly covered in the PCI self-assessment questionnaire levels. SAQ A-EP is specifically for websites where you own the website, but link out to something like Stripe for the payment processing. Here's a good overview I found googling for "SAQ A-EP vs SAQ A": https://epayments-support.ingenico.com/en/direct/faq/comparison-of-the-saq-a-vs-saq-a-ep https://epayments-support.ingenico.com/en/direct/faq/compari...
  - sokoloff 6y ago
    It's been over a decade now, but I seem to recall the debate was not about "what needs to happen if this page is a payment page?" but rather was around "what makes a page in-scope for that requirement to apply?" and the QSA initially held/expressed an entirely illogical position on the matter.
    - URSpider94 6y ago
      That’s what I call the “divide by zero quality system”. If you don’t ship, then there’s no risk of leaking customer data. Likewise, if you just assume that every screen in your app is in-scope for PCI, then the consultant has a very easy job.

by rsj_hn 6y ago

sokoloff 6y ago

We had a PCI QSA who argued that pages that linked out to payment processors were in full scope for PCI, because if compromised, they could be changed to point to a compromised payment entry site. Which logically means that pages which point to those pages are also in scope, all the way up the stack and suddenly everything is in full PCI scope. Absolutely use a PSP to minimize your wasted effort on compliance activities, but also choose a sane QSA.

hn_throwaway_99 6y ago
Note this is explicitly covered in the PCI self-assessment questionnaire levels. SAQ A-EP is specifically for websites where you own the website, but link out to something like Stripe for the payment processing. Here's a good overview I found googling for "SAQ A-EP vs SAQ A": https://epayments-support.ingenico.com/en/direct/faq/comparison-of-the-saq-a-vs-saq-a-ep https://epayments-support.ingenico.com/en/direct/faq/compari...
- sokoloff 6y ago
  It's been over a decade now, but I seem to recall the debate was not about "what needs to happen if this page is a payment page?" but rather was around "what makes a page in-scope for that requirement to apply?" and the QSA initially held/expressed an entirely illogical position on the matter.
  - URSpider94 6y ago
    That’s what I call the “divide by zero quality system”. If you don’t ship, then there’s no risk of leaking customer data. Likewise, if you just assume that every screen in your app is in-scope for PCI, then the consultant has a very easy job.