You will fall into one of those levels if your organisation processes fewer than six million card transactions per year.
There are several types of questionnaire, and in this blog we help you understand which one is right for you.
What is a PCI SAQ?
Organisations that are subject to the PCI DSS must demonstrate that they have taken appropriate steps to secure the payment card data that they hold.
There are two ways to do this: with a PCI SAQ or an RoC (report on compliance). Each payment brand (American Express, Discover, JCB, MasterCard and Visa) has its own requirements, so they establish the eligibility criteria for SAQ or RoC.
The PCI SAQ is the less rigorous method and is typically used for organisations that process fewer than six million transactions annually.
Once itâs completed, the PCI SAQ is signed off by an officer of the merchant or service provider, validating the organisationâs compliance practices.
PCI SAQ types
There are several types of PCI SAQ that apply in certain circumstances. Itâs essential that organisations choose the correct assessment. They are as follows:
SAQ A
For merchants that outsource their entire card data processing to validated third parties. This includes e-commerce merchants and mail/telephone order merchants.
It applies where:
The merchantâs website is hosted and managed by a PCI-compliant third-party payment processor; or
The merchantâs website provides an iframe (inline frame) or URL that redirects customers to a PCI-compliant third-party payment processor.
Nearly all online merchants aim for SAQ A, because it is the simplest, least time-consuming assessment.
SAQ A-EP
For e-commerce merchants that donât receive cardholder data but do control the method through which data is redirected to a third-party payment processor.
It applies where:
The merchantâs website creates a payment form and âdirect postsâ payment data to a PCI-compliant third-party payment processor; or
The merchantâs website provides an iframe or URL that redirects a consumer to a PCI-compliant third-party payment processor, but some elements of the payment page originate from the merchant website.
SAQ B
For merchants that only process credit card data via imprint machines or via a standalone dial-out terminal.
Card imprint machines are non-electronic machines that make an imprint of the payment card, transferring the imprint onto a carbon paper receipt, which is then stored by the merchant.
Dial-out terminals are electronic machines that use chip and PIN and swipe cards, or require users to manually key in information. To be eligible for SAQ B, a merchantâs standalone dial-out terminal must be connected to a phone line and nothing else.
SAQ B-IP
For merchants that donât store card data in electronic format but use IP-connected POI (point-of-interaction) devices. These merchants may handle either card-present or card-not-present transactions.
SAQ C-VT
For merchants that process cardholder data via a virtual payment terminal rather than a computer system. A virtual terminal provides web-based access to a third party that hosts the virtual terminal payment-processing function.
SAQ C
For merchants that process cardholder data via POS (point-of-sale) systems or other payment application systems connected to the Internet.
To be eligible for SAQ C, a merchant must operate isolated payment application systems that are connected to the Internet and donât store electronic cardholder data.
SAQ D
For those that donât fit into any of the above categories. It is often referred to as âReport on Compliance Lightâ, because it requires organisations to go through all 12 PCI DSS requirements, albeit on a reduced scale.
There are separate forms for merchants and service providers.
SAQ P2PE-HW
For merchants that use card-present transactions, meaning it is not applicable to organisations that deal in e-commerce.
Merchants that use a PCI-validated P2PE (point-to-point encryption) solution and have implemented it successfully are eligible for SAQ P2PE-HW.
Identify the right SAQ with IT Governance
Hopefully youâve now identified which SAQ applies to you, but how do you go about completing the form?
Thatâs where our PCI DSS Documentation Toolkit can help. It contains all the template documents you need to ensure complete coverage of your PCI DSS requirements.
All you need do is fill in the sections that are relevant to your organisation.
The toolkit also contains a document checker to help you select and edit the appropriate policy, so that you can create and amend documents as needs arise.
The toolkit supports all self-assessment questionnaires, regardless of your specific payment scenario.
Itâs fully aligned with the PCI DSS, so you can be sure that your policies are accurate and compliant with the Standard.
Much attention and excitement within the security world has recently been focused on the lucrative surge in crypto-mining malware and hacks involving or targeting cryptocurrency implementations themselves. Yet the volume of âreal worldâ transactions for tangible goods and services currently paid for with cryptocurrency is still relatively niche in comparison to those that are being paid for every minute of the day with the pieces of plastic we know as payment cards.
According to the British Retail Consortium, in the UK, card payments overtook cash for the first time ever last year. An upward trend assisted no doubt by the increasingly ubiquitous convenience of contactless micropayments. No coincidence either perhaps that contactless related card fraud in the UK also overtook cheque-based fraud in the first half of 2017.
For the foreseeable future, card payment channels are likely to present a continued risk to both businesses and individuals for the exact same reason that bank robber Willie Hutton gave us in the last century for his chosen means of income. In todayâs digital economy, however, agile cyber criminals will not only âgoâ as Mr. Hutton suggested âwhere the money isâ but will swiftly adapt and evolve their tactics to âgo where the insecurity is.â Hence, whilst according to a range of sources EMV chip cards have cut counterfeit fraud at âpoint of saleâ (POS) in the UK by approximately a third since the technology was introduced and similar improvements are now being cited for its more recent adoption in the US, a marked and plausibly corresponding uptake in online âcard not presentâ (CNP) fraud continues to rise.
The Payment Card Industry Data Security Standard (PCI-DSS) has formally existed since 2004 to help reduce the risk of card fraud through the adoption and continued application of a recognized set of base level security measures. Whilst many people have heard of and will often reference PCI-DSS, the standard isnât always as well understood, interpreted, or even applied as best it could be. A situation not entirely helped by the amount of myths, half-truths, and outright FUD surrounding it.
The PCI Security Standards Council website holds a wealth of definitive and authoritative documentation. I would advise anyone seeking either basic or detailed information regarding PCI-DSS to start by looking to that as their first port of call. In this blog, however, I would simply like to call out and discuss a few common misconceptions.
MYTH 1: âPCI JUST DOESNâT APPLY TO OUR BUSINESS/ ORGANIZATION/VERTICAL/SECTOR.â
It doesnât matter if you donât consider yourself a fully-fledged business, if itâs not your primary activity, or if card payments are an insignificant part of your overall revenue. PCI-DSS applies in some form to all entities that process, store, or transmit cardholder data without exception. Nothing more to say about this one.
MYTH 2: âPCI APPLIES TO OUR WHOLE ENVIRONMENT, EVERYWHERE, AND WE SIMPLY CANâT APPLY SUCH AN OBDURATE STANDARD TO IT ALL.â
Like many good myths, this one at least has some origin in truth.
Certainly, if you use your own IT network and computing or even telephony resources to store, process or transmit cardholder data without any adequate means of network separation, then yes, it is fact. It could also rightly be stated that most of the PCI-DSS measures are simply good practice which organizations should be adhering to anyway. The level of rigor to which certain controls need to be applied may not always be practical or appropriate for areas of the environment who have nothing to do with card payments, however. A sensible approach is to, therefore, reduce the scope of the cardholder data environment (CDE) by segmenting elements of network where payment related activity occurs. Do remember though, that wherever network segmentation is being used to reduce scope it must be verified at least annually as being truly effective and robust by your PCI assessor.
Whilst scoping of the CDE is the first essential step for all merchants on their road to compliance, for large and diverse environments with a range of payment channels, such an exercise in itself is rarely a straightforward task. Itâs advisable for that reason to initially consult with a qualified PCI assessor as well as your acquirer who will ultimately have to agree on the scope. They may also advise on other ways of reducing risk and therefore compliance scope such as through the use of certified point-to-point encryption solutions or the transfer of payment activities away from your network altogether. Which takes us directly on to discussing another area of confusion.
MYTH 3: âOUTSOURCING TRANSFERS OUR PCI RISK.â
Again, there is a grain of truth here but one that is all too frequently misconstrued.
Outsourcing your payment activity to an already compliant payments service provider (PSP) may well relieve you of the costs and associated âheavy liftingâ of applying and maintaining all of the necessary technical controls yourself. Particularly where such activity is far-removed from your core business and staff skill sets. As per Requirement 12.8 in the standard, however, due diligence needs to be conducted before any such engagement, and it still remains the merchantâs responsibility to appropriately manage their providers. At the very least via written agreements, policies and procedures. The service providerâs own compliance scope must, therefore, be fully understood and its status continually monitored.
It is important to consider that this doesnât just apply to external entities directly processing payments on your behalf but also to any service provider who can control or impact the security of cardholder data. Itâs therefore likely to include any outsourced IT service providers you may have. This will require a decent understanding of the suppliers Report or Attestation of Compliance (ROC or AOC), and where this is not sufficient to meet your own activity, they may even need to be included within your own PCI scope. Depending on the supplier or, service this may, of course, be a complex arrangement to manage.
MYTH 4: âCOMPENSATORY MEANS WE CAN HAVE SOME COMPLACENCY.â
PCI is indeed pragmatic enough to permit the use of compensatory controls. But only where there is either a legitimate technical constraint or documented business constraint that genuinely precludes implementing a control in its original stated form. This is certainly not to be misjudged as a âsoft option,â however, nor a way of âgetting aroundâ controls which are just difficult or unpopular to implement.
In fact, the criteria for an assessor accepting a compensatory control (or whole range of controls to compensate a single one in some cases) means that that the alternative proposition must fully meet the intent and rigor of the original requirement. Compensatory controls are also expected to go âabove and beyondâ any other PCI controls in place and must demonstrate that they will provide a similar level of defense. They will also need to be thoroughly revaluated after any related change in addition to the overall annual assessment. In many cases and especially over the longer term, this may result in maintaining something that is a harder and costlier overhead to efficiently manage than the original control itself. Wherever possible, compensatory controls should only be considered as temporary measure whilst addressing the technical or business constraint itself.
MYTH 5: âWE BOUGHT A PCI SOLUTION SO WE MUST BE COMPLIANT, RIGHT?â
The Payment Application Data Security Standard (PA-DSS) is another PCI Security Standards Council controlled standard that exists to help software vendors and others develop secure payment applications. It categorically does not, however, follow that purchasing a PA-DSS solution will in itself ensure that a merchant has satisfactorily met the PCI-DSS. Whilst the correct implementation or integration of a PA-DSS verified application will surely assist a merchant in achieving compliance, once again it is only a part of the overall status and set of responsibilities.
IT security vendors of all varieties may also claim to have solutions or modules that although they may have nothing directly to do with payments themselves have been specifically developed with PCI-DSS compliance in mind. They are often sold as PCI-related solutions. If deployed, used and configured correctly, many of these solutions will no doubt support the merchant with their compliance activity whilst tangibly reducing cardholder data risk and hopefully providing wider security benefits. No one technology or solution in itself will make you PCI compliant, however, and anyone telling you (or your board) that it does either does not understand the standard or is peddling âsnake oil.â Or both.
MYTH 6: âWEâRE PCI-DSS COMPLIANT SO THAT MEANS WE MUST BE âSECURE,â RIGHT?â
PCI-DSS should certainly align and play a key part within a wider security program. It should and cannot be an organizations only security focus, however. Nor should being compliant with any standard be confused with some unfeasible nirvana of being completely âsecureâ whatever that may mean at any given point in time. There have, after all, been plenty examples of PCI-compliant organizations who have still been harshly and significantly breached. Some reports of high profile incidents have voiced scathing comments about the potentially ostensible nature of the breached organizationâs PCI compliance status, even questioning validity of the standard itself. Such derision misses some key points. In the same way that passing a driving test does not guarantee you will never be involved in an accident, reasonably speaking, it will certainly decrease those chances. Far more so than if nobody was ever required to take such a test. PCI or any other security compliance exercise should be viewed with a similar sense of realism and perspective.
Applying PCI-DSS controls correctly, with integrity and unlike a driving test re-assessing them annually, must surely help to reduce the risk of card payment fraud and breaches. More so than if you werenât. Something that is to everyoneâs benefit. It cannot possibly, however, protect against all attacks or take into account every risk scenario. That is for your own wider security risk assessment and security program to deal with. Maybe yes, itâs all far from perfect, but in the sage fictional words of Marvelâs Nick Fury, âSHIELD takes the world as it is, not as weâd like it to be. Itâs getting damn near past time for you to get with that program.â
About the Author:Angus Macrae is a CISSP (Certified Information Systems Security Professional) in good standing, a CCP (NCSC Certified Professional for the IT Security Officer role at Senior Practitioner level) and PCIP (PCI SSC Payment Card Industry Professional.) He is currently the IT security lead for Kingâs Service Centre supporting the services of Kingâs College London, one of the worldsâ top 20 universities
Itâs an information security framework designed to reduce payment card fraud by requiring organisations to implement technical and organisational defence measures.
We explain everything you need to know about the PCI DSS in this blog, including who it applies to, the benefits of compliance and what happens if you fail to meet its requirements.
Who needs PCI DSS compliance?
Any merchant or service provider that processes, transmits or stores cardholder state is subject to the PCI DSS.
Merchants are organisations that accept debit or credit card payments for goods or services.
Service providers are businesses that are directly involved in processing, storing or transmitting cardholder data on behalf of another entity.
Some organisations can be both a merchant and a service provider. For instance, an organisation that provides data processing services for other merchants will also be a merchant itself if it accepts card payments from them.
Benefits of PCI DSS compliance
The most obvious benefit of PCI DSS compliance is to reduce the risk of security incidents. When organisations implement its requirements, they shore up the most common weaknesses that attackers exploit.
According to the 2020 Trustwave Global Security Report, the majority of data breaches involving cardholder data were CNP (card-not-present) attacks. This indicates that e-commerce platforms are the most vulnerable, but this is only half the picture.
Data protection isnât just about preventing cyber attacks; information can also be exposed by mistakes the organization makes. Such errors can also result in violations of the GDPR (General Data Protection Regulation) and other data protection laws.
PCI DSS compliance can help organisations prevent regulatory errors and the effects associated with it.
Is PCI DSS compliance mandatory?
The PCI DSS is a standard not a law, and is enforced through contracts between merchants, acquiring banks that process payment card transactions and the payment brands.
Compliance is mandatory for all organisations that process, store or transmit cardholder data. Covered organisations that fail to meet their requirements could face strict penalties.
Notably, the Standard doesnât simply levy a one-off fine for non-compliance. Instead, organisations can be penalised between $5,000 (about âŹ4,300) and $100,000 (about âŹ86,000) a month until they achieve compliance.
Organisations can also face other punitive measures from their acquiring bank. For example, the bank might increase its transaction fees or terminate the relationship with the merchant altogether.
How do I achieve PCI DSS compliance?
The PCI DSS contains 12 requirements that organisations must meet if they are to achieve compliance.
They are combination of technical solutions, such as data encryption and network monitoring, alongside processes and policies to ensure that employees manage sensitive data effectively.
Those processes include steps such as changing default passwords, restricting physical access to locations where cardholder data is stored and creating an information security policy.
How do you know if you are PCI compliant?
To demonstrate that your organisation is PCI DSS compliant, organisations must audit their CDE (cardholder data environment).
There are three types of audit:
An RoC (Report on Compliance), which must be completed by a PCI QSA (qualified security assessor) organization such as IT Governance, or by an ISA (internal security assessor).
An SAQ (self-assessment questionnaire) signed off by a company officer. There are nine types of SAQ and it is essential that you choose the correct one.
The type of audit you must conduct, and your exact PCI DSS compliance requirements, will vary depending on your merchant or service provider level. This information is based on the number of card transactions processed per year.
Level 1 merchants are those process more than 6 million transactions per year, or those whose data has previously been compromised. They must complete the following each year:
RoC conducted by a QSA or ISA.
Quarterly scan by an ASV.
Level 2 merchants are those that process 1 million to 6 million transactions per year. They must complete the following each year:
RoC conducted by a QSA or ISA, or an SAQ (SAQ D) signed by a company officer (dependent on payment brand).
Quarterly scan by an ASV
Level 3 merchants are those that process 20,000 to 1 million transactions per year. They must complete the following each year:
SAQ signed by a company officer.
Quarterly scan by an ASV (dependent on SAQ completed).
Level 4 merchants are those that process fewer than 20,000 transactions per year. They must complete the following each year:
SAQ signed by a company officer.
Quarterly scan by an ASV (dependent on SAQ completed).
The audit requirements for service providers are more straightforward. Level 1 encompasses any organisation that process and/or store more than 300,000 transactions per year. They are required to conduct a RoC by a QSA or ISA and have an ASV conduct quarterly scans.
Service providers that transmit and/or store fewer than 300,000 transactions per year must complete either an RoC conducted by a QSA or an ISA, or an SAQ D signed by a company officer. They must also have an ASV conduct quarterly scans.
Get started with the PCI DSS
As a QSA company, IT Governance provides services to support organisations at each stage of each organisationâs PCI DSS compliance project. You can find out complete list of PCI DSS services and solutions on our website.
It contains everything you need to implement the Standardâs requirements, including template documents and a document checker to ensure you select and amend the appropriate records.
The toolkit supports all self-assessment questionnaires, regardless of your specific payment scenario.
Itâs fully aligned with the PCI DSS, so you can be sure that your policies are accurate and compliant. All you have to do is fill in the sections that are relevant to your organization.
Now Rodriguez has built an Android app that allows his smartphone to mimic those credit card radio communications and exploit flaws in the NFC systemsâ firmware. With a wave of his phone, he can exploit a variety of bugs to crash point-of-sale devices, hack them to collect and transmit credit card data, invisibly change the value of transactions, and even lock the devices while displaying a ransomware message. Rodriguez says he can even force at least one brand of ATMs to dispense cash though that âjackpottingâ hack only works in combination with additional bugs he says heâs found in the ATMsâ software. He declined to specify or disclose those flaws publicly due to nondisclosure agreements with the ATM vendors.
A credit card, the biggest beneficiary of the Marquette Bank decision (Photo credit: Wikipedia)
Council Issues Guidelines to Address Security Shortcomings
In its just-released guidelines for ongoing risk assessments, the Payment Card Industry Security Standards Council notes three specific areas for improvement.
The guidelines, which are intended for any organization that handles credit or debit card data, offer specific recommendations for risk assessments, such as how to create an internal risk-assessment team and address risk reporting.
But Bob Russo, general manager of the PCI Council, points out that card data is only as secure as the weakest link in the payments chain. Compliance with PCI-DSS is the responsibility of all organizations and businesses that handle card data, he stresses. They must ensure that all links in the payments chain keep card-data protections up-to-date.
“The standard requires an annual risk assessment, because the DSS validation is only a snapshot of your compliance at a particular point in time,” Russo says.
Requirement 12.1.2 of the PCI-DSS states that any organization that processes or handles payment cards must perform a risk assessment at least annually. The PCI Council’s new recommendations include the need for:
A continuous risk assessment process that addresses emerging threats and vulnerabilities;
An approach that uses risk assessments to complement, not replace, ongoing PCI Data Security Standard compliance.
While the PCI Council does not enforce compliance, merchants, processors and others found to be out of PCI compliance after a breach or some other event will likely face steep fines from the card networks.
“Performing a risk assessment at least annually will help you identify the security gaps and address them,” Russo says. “The council received a lot of requests for clarity here. We hope the guidelines help them in their efforts to establish an annual process.”
There is a big misconception out there that PCI DSS compliance does not apply to us, because we are relatively a small company
The fact is PCI DSS must be met by all organizations that transmit, process or store payment card data. Also business owner want to know what is ROI on PCI compliance. It is the total cost of ownership which ensures that you keep earning big money. DISC
Thanks to federal law and standard practice by the financial industry, the maximum cash liability of a consumer whose cardholder data is stolen is only $50; the remaining losses are paid by the card companies. If the weak security controls allows a criminal to access other accounts or steal a consumerâs identity, financial fallout could be severe for that individual. Resolving just one incident of a stolen identity may take months if not years of effort.
Merchants face their own form of fallout. When a breach occurs, there are investigation and containment of the breach costs for the incident, remediation expenses, and attorney and legal fees. But this is just for starters. Strategic and long-term fallout for all Merchants may include but not limited to the followings:
âą _ Loss of customer confidence.
âą _ Lost sales and revenue.
âą _ Lower use of online stores due to fear of breaches.
âą _ Brand degradation or drop in public stock value.
âą _ Employee turnover.
âą _ Fines and penalties for non-compliance with PCI and
other regulations.
âą _ Higher costs for PCI assessments when merchants with a
breach must subsequently comply with the penalty of
more stringent requirements.
âą _ Termination of the ability to accept payment cards.
âą _ Fraud losses.
âą _ Cost of reissuing new payment cards.
âą _ Dispute resolution costs.
âą _ Cost of legal settlements or judgments.
The potential fallout for larger merchants can be huge, Smaller merchants, however, may have significant trouble weathering a cardholder data breach. Think about your companyâs cash flow and whether it could cover potential damage from a breach. The risk of going out of business perhaps should be a motivation enough to follow PCI and protect the credit and debit card data.
45 States followed California when they introduced “SB1386”, the Security Breach Information Act, which has specific and restrictive privacy breach reporting requirements.
Similarly to the SB1386 Law, California, Massachusetts & Texas are already looking at making PCI DSS Law and history tells us that when California moves, everyone else follows!
From the 1st January 2010, ALL businesses that collect or transmit payment card information, will be legally obliged, by Navada Law, to comply with PCI DSS.
Not only does this effect Navada-based organisations, it affects EVERY organisation that collect or transmit payment card information about any person who lives in Nevada.
Usually security breach occurs due to lack of basic security controls or lack of effective control which is not relevant over the time. Security controls also disintegrate over the time due to lack of maintenance and monitoring.
According to Privacy Rights Clearinghouse survey, the top three breaches resulted from laptop theft, software or human error, and hackers. Most of these breaches could have been prevented by procedural, management and technical security controls. Most of the security breaches happen during the state of non-compliance. The most famous TJX security breach happens in 2007, at the time of the breach TJX complied with only 3 out of 12 PCI-DSS requirements.
Small organizations sometimes donât have enough resources to comply with all the requirements of regulations and standards like HIPAA and PCI. But that is not an excuse of not understanding the relevant regulations and standards requirements to your business and having a clear security strategy which explains how to achieve the compliance down the road. Also your security strategy will be an evidence of your due diligence to secure your critical assets. On the other hand big organizations have enough resources to implement security controls, but for whatever reason they often do not have clear strategy how to establish security controls.
Information security is not a onetime static process but an ongoing assessment of risks in your business, where you need to understand the your critical assets, classification of those assets based on CIA, sensitive data and its access, policies, standards, procedures , training, security reviews and continuous monitoring.
One of the most popular baseline for security controls is the international standard ISO 27002 â Code of Practice for Information Security management. ISO 27002 have 11 security clauses and 133 security controls are high level which provides a reasonable guidance for implementing an Information Security Management System (ISMS). Due to ISO 27002 broad scope, itâs relevant to every industry and size of business.
Organization should have a baseline of security controls before barging onto complying with PCI or HIPAA regulation. ISO assessment will help you to understand what controls are in place and assist you with security strategy and later will become a measuring stick for your ISMS.
Ongoing compliance is achieved by monitoring the relevant controls. Ongoing compliance will depend on the quality of your information security management system (ISMS). ISMS would include thorough monitoring, logging and reviewing controls to maintain and improve system security over time. You can develop an automated monitoring process to achieve consistent results and sustain compliance by continuously monitoring your system. ISMS (based on ISO 27001) certainly can be a great value to manage ongoing monitoring, maintenance and improvement cycle.
During this down turn economy organized cyber crime is a booming underground business these days. Most of the security expert and FBI agree that cybercrimes are on the rise and pose a biggest threat to US vital infrastructure. Cybercriminals are thieves in cyberspace who will swipe the sensitive data and sell to other criminals in their community, who might turn around and ask for ransom to keep the data private or perhaps resell to the highest bidder again in the black market. The risk of getting caught is minimized by legal jurisdiction and neglected by huge monetary gains. Motivated by potential gains, cybercriminals are determined to exploit the vulnerabilities of the target rich environment. Another issue to this problem is that our personal and private information has potential to be exploited at various locations such as banks, credit card companies, credit debit card processor, credit report companies and merchants etc…
Level 1, 2 and 3 merchants usually follow security best practice, allocate enough resources and try to maintain PCI compliance. On the other hand level 4 merchant are usually not compliant and have security vulnerabilities which are easy picking for cybercriminals, which is a primary reason why more security breaches happens to level 4 merchants. PCI was apparently created to safeguard the credit card and debit card data. PCI DSS standard are managed by PCI Security Standard Council.
The most significant reason to comply with PCI is because you have to.
Â
PCI DSS address the baseline security for payment card infrastructure and ROI is a total cost of ownership. PCI DSS cannot guarantee absolute security but making organization to adhere to due care security justify its cost and use. As far as liability goes the security breach will be very detrimental in the state of non compliance which will include fines, legal fee and possibly lose the credit card processing ability. To motivate themselves, merchants should also remember that their customerâs data is worth a lot of money to cyber criminals.
The trick is keeping the state of compliance â true security of credit card holder data requires nonstop assessment and remediation to ensure that likelihood and impact of the security breach is kept as low as possible. PCI compliance is not a project; itâs an ongoing process of assessment. PCI assessor utilized defined set of controls objectives to assess the state of compliance. PCI provides an option of doing internal assessment with an officer sign off. Merchants should monitor and assess to keep compliance on ongoing basis. Implement defense in depth mechanism and apply security control at every layer (network, application, operating system, and data). The idea is to make their job hard enough so the attacker moves on to easier target.
M1 – We are relatively small company so we donât have to worry about PCI compliance
F1 â The PCI DSS must be met by all organizations that transmit, process or store payment card data
M2 â PCI DSS is either a regulation or a standard
F2 â Itâs a neither a standard nor a regulation. It is a contractual agreement between card associations, the merchant banks and merchants
M3 â We neither understand PCI and nor have in house expertise to address compliance
F3 â PCI document clarify most of the questions in business terms but get help to interpret technical questions. Due care imply to understand your requirements to comply and protect your data
M4 â PCI has no ROI and simply too much for a small business
F4 â PCI address a baseline security for payment card infrastructure and its ROI is a total cost of ownership
M5 â Why bother when some companies get breached even though they were compliant
F5 â PCI DSS compliance is not a onetime process it is an ongoing process to maintain it
M6 â PCI compliance cannot be that hard, all we have to do is fill out the questionnaires
F6 – Yes, on the questionnaires has to be validated through scan. Vulnerabilities need to be resolved before submitting the report to merchant bank
M7 â My application and POS equipment are PCI compliant
F7 â PCI DSS compliance apply to an organization neither to an application nor an equipment
M8 â PCI compliance addresses the security of the whole organization
F8 â PCI DSS does not addresses the CIA for the whole organization but only card holder data security
M9 â Data breach will not affect the business revenue
F9 â Become level 1 (cost of monitoring), lose card acquiring ability, forensic charges and fines
M10 â We donât need to scan PCI assets
F10 â Quarterly scanning is mandatory for all merchants (Level 1-4)
M11 â Merchants can use any application to transmit, process and store PCI data
F11 â Not really, beginning 2010, merchants can only use payment applications validated under the payment application data security standard (PA-DSS)
M12 â We have compensating control in place so we are covered
F12 â You still have to prove how well compensating control covers the PCI requirement. Compensating controls are harder to do and cost more money in the long run
The PCI DSS (Payment Card Industry & Data Security Standard) was established by credit card companies to create a unified security standard for handling credit card information.The retail service industry now understands the strategic significance of PCI DSS compliance, which was demonstrated when TJX announced that their system was compromised for more than 17 months, where well over 50 million customersâ credit and debit cards were breached. Retail business which fails to comply will be subject to penalties and fines, possibly lawsuits, and may lose their credit card processing capability. Non-compliance will not only expose businesses to fines and penalties but also make it vulnerable to many threats, which can exploit the vulnerabilities in the system and put your business to unnecessary risk. These risks could have been avoided with some due diligence. When business is non-compliant, any major breach will have a significant impact on business viability.
To start a process of PCI compliance, a merchant should determine if PCI DSS applies to their organization. PCI DSS is applicable if your customer PAN (Primary Account Numbers) is stored, processed or transmitted in your organization. After determining the applicability of the standard, the merchant needs to determine where their business falls in the categorization of businesses by their bank in terms of merchant level.
Before commencing the risk assessment the assessor will perform the system profile to determine the applicability of the scope and set the boundaries of the system covered under PCI-DSS assessment. Planning is the key to success of a project; this is the phase where all the planning and project preparation will take place. Now the key to the success of your on-going compliance is to simplify the scope of the project. The best way to achieve this to put all the PCI related assets in a precise segment to limit the merchant card holder environment.
Comprehensive risk assessment will be performed on the identified scope where risk analysis will identify the gaps based on PCI DSS standards and risk rating will prioritize the gaps for risk management. Thorough risk analysis will generate a quality technical and process gap analysis, where you decide the mitigation/compensating controls to comply with PCI DSS.After completion of the risk assessment the task of the risk management begins, to eliminate the gaps in your environment and to comply with the standard. Depending on the numbers of gaps the risk management team should set realistic goals to complete the tasks in hand.Best practices recommendations suggest that the organization should eliminate/mitigate the high risks (high impact & probability) gaps to the organization, but sometime organizations decide to go after the low hanging fruits to start with their risk management process.
When the risk management process gets close to finishing and you are well on your way to comply with PCI DSS, you might think that perhaps your job is done. Well in a way, itâs just a beginning of a process where your organization is supposed to maintain the compliance with PCI DSS.Based on expert opinion, PCI DSS is a process not a project. What you have done so far, is baseline your environment. Ongoing compliance is achieved by monitoring the relevant PCI DSS controls. Ongoing compliance will depend on the quality of the merchantâs information security management system (ISMS). A strong ISMS would include thorough monitoring, logging and reviewing controls to maintain and improve system security over time.You can develop an automated PCI monitoring process to achieve consistent results and sustain compliance by continuously monitoring your system. ISMS (based on ISO 27001) certainly can be a great value to manage ongoing monitoring, maintenance and improvement cycle.
In a sense,PCI is neither a regulation nor a standard but a contractual agreement between the merchant and their acquirer bank, when merchants start transmitting PAN data that makes them contractually obligated to comply with PCI DSS. To understand their obligations, the merchant should make a proactive effort to understand their acquirerâs particular interpretation of PCI DSS requirements to get compliant. Ongoing compliance will require adequate resources and automated controls in place to routinely monitor, maintain, review and improve the required systems. Ultimately, ongoing PCI compliance will enhance business efficiency and reduce the potential impact of adverse publicity on your business image.
![Reblog this post [with Zemanta]](https://img.zemanta.com/reblog_e.png?x-id=e4df808e-97bc-4fa0-a3a0-4ff663bf0824)
Usually security breach occurs due to lack of basic security controls or lack of effective control which is not relevant over the time. Security controls also disintegrate over the time due to lack of maintenance and monitoring.![Reblog this post [with Zemanta]](https://img.zemanta.com/reblog_e.png?x-id=4734aa88-27e0-45d9-a802-a6d2377faf3b)
![Reblog this post [with Zemanta]](https://img.zemanta.com/reblog_e.png?x-id=895f8198-7497-4c41-9dc5-c391622d8afe)
