Skip to main content
added 79 characters in body
Source Link
Lucas Kauffman
  • 54.7k
  • 17
  • 117
  • 197

Here are the basic do's and dont's for PCI-DSSbasic do's and dont's for PCI-DSS: enter image description here

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants. Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).

Here are the basic do's and dont's for PCI-DSS: enter image description here

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants. Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).

Here are the basic do's and dont's for PCI-DSS: enter image description here

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants. Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).

Source Link
Lucas Kauffman
  • 54.7k
  • 17
  • 117
  • 197

Here are the basic do's and dont's for PCI-DSS: enter image description here

Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions.

Now you have an argument, but consider there is a breach in your company and the CVV numbers are obtained and used together with card numbers collected in a breach from company B, then guess who will be held accountable as they did not adhere to the PCI-DSS standard.

The rules for PCI-DSS are not only there to give you guidance on how to store information but also serve as a way of off-loading risk from the card acquirers to the merchants. Maybe you might think that it's not fair, but in case of PCI-DSS: "The rules are the rules". The only way you would be able to avoid this risk is by having a QSA sign off on your implementation and explicitly have your architecture where you store the CVV as part of the audit report (to be fair I highly doubt any QSA will sign off on that).