Tag Info

New answers tagged

4

Yes, PCI DSS requirement 4.2: Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.). Unless the email is somehow encrypted, you are not allowed to use it to send cardholder data.


1

In practice, it violates the DSS. In theory, it could possibly not, but that's pedantry rather than reality. DSS Requirements 3.4 ([Encrypt] PAN data in storage) and 4.1 (Encrypt PAN data across public networks) are generally violated by SMTP mail. Each mail hop is a store-and-forward gateway that writes mail to disk even if only temporarily; unless it's ...


1

"Secure Vault" is being used here in the context of tokenization, which almost always means "the Vault that someone else (e.g., your payment processor) keeps the cards in, and you only ever deal with the tokens that correspond to items in the vault." You can, of course, implement a "vault" yourself - that means a data store for PAN data which meets all the ...


3

Yes, it's in scope. There's actually a pretty thorough and explicit guide from the PCI Security Standards Council (the DSS people) to your exact question here: Information Supplement: Protecting Telephone-based Payment Card Data Which makes reasonably clear statements like this about card numbers: Call centers will need to ensure that PAN data is ...


0

If you outsource all cardholder data to a third party and you require compliance yourself, then the applicable requirements for SAQ A are applicable to you. While the PCI DSS consists of a large number of requirements (i.e. SAQ D), the vast majority of these will not be applicable to you if you do not handle cardholder data. Depending on volumes you may not ...


0

If the CC data never touched your servers, you wouldn't be a (PCI) service provider, so no - the same level of compliance requirements do not apply in both cases. (That said, SAQ D covers the majority of cases, so yeah, it covers a broad range of involvement). Yes, your clients will need to have some level of PCI compliance as they're collecting the data. ...


2

Let's try to tackle two problems at once. First of all yes you will take a performance hit, especially if you are logging onto the same machine. The idea is that you do not log everything locally but instead use an encrypted syslog connection (or similar) to log every request to a seperate logging server. This will relieve the webserver from being busy with ...


0

Let's break this down to a logical view of what you state you are doing without getting lost in the weeds on the definition of a service provider, hosting provider, Tier 1, Tier 2, etc.. You state: "We do not store or process card data, we only decrypt it, analyse it and then re encrypt it for transmission." While you may not be a PROCESSOR you are ...


0

I'm agreeing with AndyMac that you are in fact not a shared hosting provider, you are just offering a platform, so I think your QSA is wrong. So what do you do if you are not sure about his opinion? Then you get a second opinion where you explain your concerns! Ensure that you challenge your QSA first to explain why he believes you are a shared hosting ...


3

You have to report on PCI compliance if you are a level 4 merchant. You need to complete a self assessment (SAQ). So to become compliant you need to: Complete the Self-Assessment Questionnaire according to the instructions it contains. Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV). Note scanning ...


0

Well if your wholesaler does not offer an automated way to process data, you're going to have a hard time not storing the credit card info. This means that you probably will also have to get SAQ-D. Storing a token of a card is not the same as storing the card details. In your case you will have to store the PAN and Verification code for as long as the ...


3

If you are transmitting the credit card details to your payment gateway via HTTPS, you are not transmitting in plain text, you are using SSL/TLS cryptography. Once you don't store the details in your systems willingly (using databases, etc.), your only concern would be your system's logs, because they can store this informations without your knowledge, so ...


4

The best over all solution is to use a commercial payment handling service that deals with all of that for you. For that transaction volume, the danger of having card data stored on prem out weighs your need for the data. If this is a retail business, I would suggest something like square, which would essentially put the responsible handling of data in ...



Top 50 recent answers are included