Talk:Payment Card Industry Data Security Standard
|WikiProject Business||(Rated C-class)|
|WikiProject Computer Security / Computing||(Rated Start-class)|
- 1 Link "PCIDSS"
- 2 Oversimplified and inaccurate
- 3 Best Practices
- 4 PCI DSS for Enterprise Software Users
- 5 Cleaning up links
- 6 3 Programs controlled by PCI SSC
- 7 Is this a worldwide standard?
- 8 Verifying PCI compliance claims
- 9 Move back to PCI DSS
- 10 Add merchant qualification levels?
- 11 Terminology not clear for likely audience
- 12 Controversies and criticisms
- 13 Improvements
For someone who knows how. Searching PCIDSS does not currently direct here --K
- Done. --Clay Collier 07:12, 4 April 2007 (UTC)
This page should be merged with "Payment Card Industry" --Grvfuel 15:41, 17 October 2007 (UTC)
I'm not entirely convinced - the PCI page should really just talk about the PCI and link off to the various standards they provide IMO. Otherwise as the number of standards they issue or maintain grows, the PCI page will become rather bloated. Random name 10:57, 18 October 2007 (UTC)
Added links to sources regarding PCI compliance, the recent visa international payment mandates. ~~Classof96 20:52, 5 November 2007
- The problem with these links - there are millions of information sources like these. I've not been editing long enough to know how we're meant to decide which to use, and which to leave. Random name 21:52, 7 November 2007 (UTC)
Oversimplified and inaccurate
These two statements
A company processing, storing, or transmitting credit card numbers must be PCI DSS compliant or they risk losing the ability to process credit card payments. Merchants and service providers must validate compliance with an audit by a PCI DSS Qualified Security Assessor (QSA) Company.
are an oversimplification of the reality and not quite accurate. The truth is: an acquirer (say FirstUSA for the Visa credit card) might periodically ask a merchant (say Walmart) to answer (all/not all) questions within a number of questionnaires and execute a scanning test against vulnerabilities and threats on the merchant assets (computers, payment card readers, etc.) Then an auditor (internal or external) will review the answers and the results and solely decide whether the merchant is fully-partially-not compliant. It is not necessary that the auditor comes from a PCI DSS Qualified Security Assessor (QSA) Company.
The sentence The PCI DSS recognizes wireless LANs as public networks and automatically assumes they are a threat. is meaningless. The wireless LANs are not threats - rather they might be vulnerable and exposed to some threats.--Stagalj (talk) 18:45, 7 January 2008 (UTC)
PCI is regarded as being relatively more prescriptive than these other laws.
- You are right. I removed that sentence - a standard is not comparable to a law.--Stagalj (talk) 01:54, 2 February 2008 (UTC)
The "best practice" section has needed a cite for ages now, and it's now also being filled with random ERP suggestions. I'm deleting it soon unless someone can find a cite for it. Random name (talk) 16:38, 11 July 2008 (UTC)
PCI DSS for Enterprise Software Users
This section appears to be a somewhat random SAP section which provides no refs outside of commercial links to registration-protected commercial whitepapers. On top of that, it strikes me as excessive levels of information for one product - unless this article intends to discuss the particulars of security for all major software releases one might encounter in an enterprise environment, this section needs removing. Any comments? Random name (talk) 10:04, 19 July 2008 (UTC)
Folks, I've cleaned a number of links out of this page - if you're wondering why, please have a look at WP:EL. As it states, Wikipedia isn't meant to be a collection of links, useful or otherwise. As such, I've removed the blog that was linked, the conference page, and the link to the payment security certification. Random name (talk) 08:07, 22 August 2008 (UTC)
- Can anyone say why the http://selfservice.talisma.com link is still on here. It's a website that frames the actual https://www.pcisecuritystandards.org/ website. Absolutely nothing unique or different about it. I would classify it as blatant spam! It should be removed.
3 Programs controlled by PCI SSC
There are 3 programs controlled by PCI SSc, that is PCI PED, PCI PA-DSS and PCI DSS. PCI PIN is still controlled by Visa. —Preceding unsigned comment added by 22.214.171.124 (talk) 13:29, 22 September 2008 (UTC)
Is this a worldwide standard?
The article does not mention if PCI-DSS applies worldwide, or only within the US. I imagine it can be used worldwide by the major CC companies, but does that happen in practice? —Preceding unsigned comment added by 126.96.36.199 (talk) 15:22, 25 November 2008 (UTC)
Yes, it's a global standard, and was started by a council including a number of global card brands. Progress has been slower in some areas of the world, but it's being applied everywhere. Random name (talk) 13:17, 26 November 2008 (UTC)
Additionally, page 3 of the PCI DSS 1.2 (October 2008) clearly states the "global" applicability in the very first sentence. —Preceding unsigned comment added by Reconscout94 (talk • contribs) 01:43, 13 December 2008 (UTC)
Verifying PCI compliance claims
- Hmm no, it wasn't discussed, as I thought it was a non-contentious move. Given that other comparable items such as HIPAA and SOX go to their full names, rather than the associated acronyms, what is special about PCI DSS? Random name (talk) 08:48, 20 April 2009 (UTC)
Add merchant qualification levels?
Would it be worth including the relevant details from the card vendors (roughly the same across the payment brands) that show how to work out what level merchant you are? Monkey Web Daemon (talk) 09:38, 17 February 2010 (UTC)
Terminology not clear for likely audience
In the first two sentences of the third paragraph:
"Enforcement of compliance is done by the bodies holding relationships with the in-scope organizations. Thus, for organizations processing Visa or MasterCard transactions, compliance is enforced by the organization's acquirer, while organizations handling American Express transactions will deal directly with American Express for the purposes of compliance."
...the following three things are not clear to the likely audience:
1) What is an "in-scope" organization ?
2) What is an "organization's acquirer" ?
3) What are "bodies holding relationships with the in-scope organizations" ?
- "In-scope" system is "The boundaries and included area in which cardholder data resides." Probably what is meant here is a merchant or organization with an In Scope System, Cardholder Data Environment or PCI Scope Environment, all of which are the same.
- "Organization's acquirer" is likely the acquiring bank used by the merchant. "An acquiring bank is the bank or financial institution that provides accounts to merchants and processes credit and debit card transactions on their behalf. A merchant account allows an organization or company to accept credit cards. The bank or financial institution then deposits the funds into the merchant's checking account."
- Both definitions come from http://www.secureworks.com/compliance/pci/pci-compliance-glossary/
Controversies and criticisms
"It has been suggested by some IT security professionals that the PCI DSS does little more than provide a minimal baseline for security."
"...In contrast, others have suggested that PCI DSS is a step toward making all businesses pay more attention to IT security, even if minimum standards are not enough to completely eradicate security problems."
I don't see why "In contrast" is used. The two statements don't seem to disagree with each other. The two certainly indicate the importance of security, and also that these rules may not be enough to completely enforce and solve security problems. —Preceding unsigned comment added by Ibarrera (talk • contribs) 15:21, 20 August 2010 (UTC)
"132 changes": this is meaningless. What are all these changes? How significant are they? Changes since which version, perhaps 1.0? Why version 2.0, when the current version is version 3.0.
"two new or evolving requirements", is this a case of the editor not knowing or is one "new" and one "evolving"?
"differing points from version 1.2" Why version 1.2? It would be better to have a table of the current requirements. And the " 220 sub-requirements" referred to later on in the article.
Changes and differences should be in the History section.
How to get started:
This is like a user manual. Needs rewriting from "you".
This section should talk more about the enforcements and "fines and penalties" which are touched on in the controversies section.
Compliance and compromises:
This section slips into a long complicated legalese sentence. "Therefore…". It seems to be saying that passing the assessment is worthless; it doesn't provide any protection to the merchant.
"Level 1-3 merchants … Level 4" what are these levels?
Compliance as a snapshot:
"temporal persistence" = "permanence"
"the point in time when" = "when"? 188.8.131.52 (talk) 14:33, 13 February 2014 (UTC)
To extend the above, much of the article is written as a user guide rather than an encyclopedic article about the standard in question. I intend to remove the 'howto' tone entirely soon unless any objections are raised, as well as various sections that are outdated (referring to v1.x of the standard). Exponium (talk) 06:27, 3 April 2014 (UTC)