Archive for PCI Compliance

New changes are coming to the SAQs!

Self-Assessment Questionnaires (SAQ) are forms used by eligible organizations to report the results of a PCI Data Security Standard (PCI DSS) self-assessment. On 30 January, the PCI Security Standards Council (PCI SSC) issued revised SAQs for use with PCI DSS version 3.2. In this Q&A with PCI SSC Senior Director of Data Security Standards Emma Sutcliffe, we look at what merchants need to know about new updates to the SAQs .

SAQs were updated with the publication of PCI DSS 3.2 in April 2016, so why is the PCI Council making changes to the SAQs now?

Emma Sutcliffe: The changes clarify points of confusion PCI SSC has heard from industry stakeholders since the SAQs were updated to align with PCI DSS version 3.2 in April 2016. This type of update is what we call an “errata”, which is a way for us to correct language that wasn’t clear enough and to fix typos and grammatical errors.

This is not a major update, but the changes do include the addition of guidance and may impact how SAQs are filled out. Additionally, some merchants may need to start validating to additional requirements, so it’s important for merchants to review their applicable SAQ and work with their merchant (acquiring) banks to understand any implications for them.

Are there any new SAQs?

Emma Sutcliffe: No, there are no new SAQs. Currently there are nine SAQs, each one intended to meet a different scenario based on how an organization stores, processes, or transmits cardholder data. The errata introduces minor updates to several of the existing SAQs.

Which SAQs are affected?

Emma Sutcliffe: The updated SAQs are SAQ A: Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced; SAQ B-IP: Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage; SAQ-C: Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage; and SAQ-C-VT: Merchants with Web-Based Virtual Payment Terminals – No Electronic Cardholder Data Storage.

What are the key changes merchants should be aware of?

Emma Sutcliffe: The updates include the addition of two requirements to SAQs B-IP and C-VT.  The first is Requirement 8.3.1 (use multi-factor authentication for all non-console administrative access into the cardholder data environment). Merchants that perform administrative access via non-console connections are already required to secure these connections with strong cryptography (Requirement 2.3), and the addition of Requirement 8.3.1 provides consistency for how these connections are secured.

The second requirement added to these SAQs is Requirement 11.3.4 (verify segmentation controls, if segmentation is used). SAQs B-IP and C-VT both require that specific device types be used, and that the defined devices are not connected to other systems. The addition of Requirement 8.3.1 in SAQs B-IP and C-VT is consistent with requirements in other SAQs for merchants using segmentation.

Details of the changes for each SAQ can be found in the “Document Changes” table near the top of each SAQ.

When do merchants need to begin using the updated SAQs?

Emma Sutcliffe: There is a transition period to allow merchants time to review changes to applicable SAQs and prepare to adopt them.  Merchants may continue to use the SAQs published in April 2016 (Rev. 1.0) until 30 September, 2017.  Starting on 1 October 2017, merchants will need to use the updated SAQs (Rev. 1.1, published on 30 January 2017).  Prior to 1 October 2017, merchants can use either the April 2016 or the January 2017 version of the SAQs.

How do merchants determine which SAQs they are eligible to use?

Emma Sutcliffe: Merchants should contact their acquirer or the applicable payment brand(s) to understand if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment. The SAQ Instructions and Guidelines document also provides additional guidance about the PCI DSS self-assessment process and the different SAQs.

PHPMailer Security Advisory (PCI Compliance & Standard Accounts Effected)

Exploit type: Remote Code Execution in third-party PHPMailer library
CVE Numbers: CVE-2016-10033 and CVE-2016-10045

All versions of the third-party PHPMailer library distributed are vulnerable to a remote code execution vulnerability.

We have listed a few applications effected. Immediate upgrade is required to avoid interruptions to the PHP mailer system built within your application. To protect our servers and networks this required action is not exceptional and must be repaired to avoid such actions and interruptions.

Software Known To the Advisory and thousands of others:

1. WordPress
2. Zen-Cart – 15.4 Versions & below. 1.5.5 claims to fix this issue.
2. OpenCart
3. CubeCart

All the listed above are known as well as many others. This critical PHPMailer flaw is to be taken seriously and leaves millions of websites vulnerable. Please update all applications that use this open-source software. Updating to the latest version should take care of the issue and will avoid interruptions of email services.

If you have any questions regarding this announcement or regarding how to get your website updated please contact our development & security team by opening a support request at

PCI 3.0 Now In Full Effect

PCI 3.0 has been applied to all PCI servers, PCI 3.0 requirements are now in full effect. Regarding PCI 3.0 with questions. Host 99 will now fully enforce PCI 3.0 for all PCI Shared, VPS and Dedicated Servers. We will monitor for any non compliance and reports will be made regarding logs and findings. Please contact your ASV for more information.

Based on feedback from the industry, in 2010 the Council moved from a two-year to a three-year standards development life cycle.The additional year provides a longer period to gather feedback and more time for organizations to implement changes before a new version is released.

Version 3.0 will introduce more changes than Version 2.0. The core 12 security areas remain the same, but the updates will include several new sub-requirements that did not exist previously. Recognizing that additional time may be necessary to implement some of these sub-requirements, the Council will introduce future implementation dates accordingly. This means until 1 July 2015 some of these sub-requirements will be best practices only, to allow organizations more flexibility in planning for and adapting to these changes. Additionally, while entities are encouraged to begin implementation of the new version of the Standards as soon as possible, to ensure adequate time for the transition, Version 2.0 will remain active until 31 December 2014. The nature of the changes reflects the growing maturity of the payment security industry since the Council’s formation in 2006, and the strength of the PCI Standards as a framework for protecting cardholder data.

Cardholder data continues to be a target for criminals. Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards leads to many of the security breaches happening today. The updates address these challenges by building in additional guidance and clarification on the intent of the requirements and ways to meet them. Additionally, the changes in PCI DSS and PA-DSS 3.0 focus on some of the most frequently seen threats and risks that precipitate incidents of cardholder-data compromise.

The updated standards will help organization s not by making the requirements more prescriptive, but by adding more flexibility and guidance for integrating card security into their business-as-usual activities. At the same time, the changes will provide increased stringency for validating that these controls have been implemented properly, with more rigorous and specific testing procedures that clarify the level of validation the assessor is expected to perform. Overall, the changes are designed to give organizations a strong but flexible security architecture with principles that can be applied to their unique technology, payment, and business environments.The updated versions of PCI DSS and PA-DSS will:

  • Provide stronger focus on some of the greater risk areas in the threat environment
  • Provide in creased clarity on PCI DSS & PA-DSS requirements
  • Build greater understanding on the intent of the requirements and how to apply them
  • Improve flexibility for all entities implementing, assessing, and building to the Standards
  • Drive more consistency among assessors
  • Help manage evolving risks / threats Align with changes in industry best practices Clarify scoping and reporting Eliminate redundant sub-requirements and consolidate documentation

Payment Card Industry (PCI) Version 3.0 Changes

PCI 3.0: What You Need to Know
What requirements changed from PCI 2.0, and why?

The PCI DSS was updated for the fourth time (1.0, 1.2, 2.0, 3.0) in November 2013. As always, the changes the PCI Council made address the latest vulnerabilities and include additional clarification and new guidance.

While we won’t cover every single nitty-gritty aspect that changed from 2.0 to 3.0 (like all the clarifications), we are covering the most important changes affecting the majority of merchants.

The newest Payment Card Industry Data Security Standard (PCI DSS) officially goes into effect on January 1, 2015. With the introduction of PCI DSS version 3.0, many merchants want to know how it will affect their business. Here are answers to a few commonly asked questions.

Requirement 0 – PCI Intro

The introduction section probably holds the biggest change for PCI 3.0. Web redirection systems are now defined as system components, which means they’re now part of scope for PCI DSS. PCI-Council-Releases-Security-Standards-3.0

The principal of redirection is when a website points users to a third party that collects and processes all card data. Another form of redirection is client side redirection, in which a customer types card data into a web form generated by the merchant, and is then sent directly to a third party. Either way, card data will not pass through the original website.

In the past, these forms of redirection were validated using SAQ A, but new emphasis in PCI DSS 3.0 changes that.

This new direction will affect many merchants who were previously completing an SAQ A and now must move to an SAQ A-EP, which is significantly longer and includes things such as external vulnerability scans and penetration testing. The reason behind this requirement change? If a hacker is able to manipulate redirection code, he could direct your customers to a fake payments page that looks identical to the one you had originally outsourced.

Network diagram_flat icons-03

Attacker directing customers to a fake payments page (i.e., man-in-the-middle attack)

Requirement 1.1.3

A cardholder data flow diagram should show how cardholder data enters your network, the systems it touches as it flows through your network, and any point it may leave your network (e.g., sent to a payment processor). You’ll want to maintain a diagram for each card flow that exists. Most businesses will have just one flow, but you might also have an additional flow if your website processes payment cards.

Network diagram_flat icons-02




















Physically creating a document that explains the processes will help you better understand where card data lives on your network.

Requirement 2.4

This requirement involves a document that lists all in scope device types and their function (e.g., POS systems, computers). This inventory list is also a great place to document software/firmware versions. If you’re feeling a little daunted by this task, interviewing department heads is a great place to start.

Requirement 4.1

In addition to GSM (cellular) connections and wireless Internet, it is now required that any communication that includes cardholder data sent over satellite should be encrypted. Depending on your business, this may not have much impact.

There is many large retail chain clients (e.g., gas stations, hospitality, restaurant chains). Many of these chains use satellite communications between chains and even as a backup connection. According to the PCI Council, it’s no longer good enough to rely on the link provider’s system security. It’s your responsibility to keep this data secure.

Requirement 5.1.2

For systems not commonly affected by viruses and don’t have anti-virus software installed, you are required to implement and document a new process that shows you periodically evaluate these systems against emerging threats. Assurance_PANscan icon

The point of Requirement 5.1.2 is to acknowledge hackers invent new ways to hack into systems every day. It requires merchants to research and pay attention to security notices from PCI vendors. If a new attack method is deemed a threat to your system, evaluate if the threat requires anti-virus.

Requirement 5.3

This requirement states that anti-virus can’t be altered without managerial approval. Often, anti-virus needs to be turned off to do system maintenance. During maintenance, who knows what could slip past your unguarded system.

Our advice is, if you are updating an application that requires disabling an anti-virus, don’t. Instead, take that system off the network or cut off its Internet connectivity for that period. As a side note, it’s not OK for system admins to just give all users admin access to get around the requirement. That’s missing the point entirely.

Requirement 6.3

Any custom software application for a cardholder environment (whether in-house or commissioned by a third party developer) is under your jurisdiction. It’s ok to outsource your software development, but it’s not OK to outsource your responsibility to ensure secure development practices are followed. If you’re planning to use the application, remember that it’ll be part of your PCI assessment…not your third party’s.

Requirement 6.5.10

This requirement to protect against broken authentication was added to fix common application vulnerabilities. You should create/add/adjust your application code to mitigate any exposure to vulnerabilities. This can be done through not exposing session IDs in URLs, using secure cookies, and enforcing appropriate session timeouts.

Requirement 7.1.1

You’re required to have a role-based access control system. That means access to card data and systems should only be granted on a need-to-know basis. PCI 3.0 requires a defined list of the roles that have access to the card data environment.

On this list, you should include each role, definition of each role, access to data resources, privilege level, and what privilege level is necessary for each person to perform normal business responsibilities. Users must fit into one of the roles you outline.

Requirement 8.4

Organizations are now required to not just document, but also train their users on how to implement password policies. This training should include guidance on how to select a strong password, how to secure it, and instructions not to reuse it.

It’s also crucial that you communicate password policy to your users. This will help them understand how to change their passwords and also not to use the same password between work and home.

Requirement 8.5.1

This new requirement is targeted specifically towards service providers who have remote access into a customer environment. This is common practice with vendors who do remote support or software training.

Any service provider with access to multiple customer systems is now required to maintain unique credentials for each customer environment. The PCI Council knows this requirement in particular will take some time to change, so they’ve given until July 2015 before this is officially required.

Requirement 8.6

The use of alternative authentication mechanisms (e.g., logical tokens, smart cards, certificates) must be tied to an individual user account and not shared among user accounts. To ensure this is met, every merchant must implement a control to enforce those authentication methods can only be used by the intended user (e.g., requiring a PIN, password, or biometric scan in addition to the token to validate the person is authorized).

Requirement 9.3

This requirement is all about controlling employee access to sensitive areas, which must be related to an individual’s job function. To meet this requirement, I suggest documenting exactly who has access to these environments and their business need. Access must be kept up to date, especially when individuals are terminated or their job role changes.

Requirement 9.9

This is a huge addition to the PCI standards. Organizations that use point of sale systems,PIN pads, mobile devices etc., are required to do three new things: chart_rust


  1. Maintain an up-to-date list of all devices (9.9.1) including physical location, serial numbers, make/model.
  2. Periodically inspect devices (9.9.2). That means looking at device surfaces to make sure they haven’t been tampered with, making sure the serial numbers match, checking that seals haven’t been broken, etc. This could be a very large task depending on the size of your organization. Whether you inspect devices every day or month is based on how at risk you are of tampering (e.g., publically accessible 24/7 gas station terminals vs. a behind-the-counter card swipe device). Make sure you document what you find.
  3. Provide staff awareness training (9.9.3) for staff that interact with card present devices on a day to day basis (e.g., cashiers), and record the who, what, and when for future reference. Ideally, the training will help staff detect any suspicious activity around a payment device. Training should include how to report suspicious behavior and what to do when third parties claim they need to work on the system. For example, rather than assuming IT came in last night to install a new device on the side of her terminal, an employee should question if its supposed to be there and notify appropriate persons.

Requirement 10.6.2

Depending on its size and complexity, this requirement could have a large impact on your environment. In addition to the logging requirements in 10.6.1, you’re now required to review logs of all other system components periodically, based on your policies and risk management strategy. computer hacker

Lots of different systems in your environment may impact your payment security. As part of your annual risk assessment, you need to identify systems that pose risk and define a process to periodically look at their logs to determine suspicious activity.





Requirement 11.1.1

Maintaining a complete list of authorized wireless access points will require extra documentation, especially in large environments. This list should include a documented business justification for each wireless access point.

It’s difficult to determine which wireless devices to remove if you don’t have an accurate list of them to begin with. That’s why the PCI Council requires you create a total list. If you’re a small ecommerce provider and all your systems fit into a single rack in your data center, this requirement should be pretty easy. If you’re a widespread organization, it will take a bit more time.

Requirement 11.3

The rewrite of section 11.3 is intended to provide additional guidance to both merchants and penetration testing organizations on penetration testing’s intended coverage.

The rewrite of section 11.3 is intended to provide additional guidance to both merchants and penetration testing organizations on penetration testing’s intended coverage. folder_yellow

Penetration testing organizations are now required to have documented and standardized testing methodologies that meet industry accepted standards, such as NIST 800.115. In addition, guidance is provided on how best to scope the penetration test and identify critical systems.


A penetration test Special Interest Group has been organized by the PCI Council to help merchants and penetration test organizations best interpret this new set of requirements. Results from this SIG group are expected near the end of 2014.

The PCI Council knows this requirement in particular will take some time to change, so they’ve given until July 2015 before the changes in the penetration testing requirement become official. However, this doesn’t mean you can wait to receive a penetration test until July 2015. The guidance provided in PCI DSS 2.0 for penetration testing is still valid until then.

Requirement 12.8.5

Not only should merchants maintain a list of a third party service providers, but now they must maintain a list of all PCI requirements their service provider meets, and a list of PCI requirements they’re required to meet.

Requirement 12.9

In conjunction with Requirement 12.8.5, service providers are now required to provide written documentation to all customers stating which PCI requirements they cover on their behalf. These two requirements attempt to avoid past miscommunication problems between service providers and merchants.contract_pen


Overall, PCI DSS 3.0 focuses on detecting, rather than reacting to, security vulnerabilities. With improved aspects like documentation and system monitoring, 3.0 will increase proficiency among merchants, service providers, and PCI vendors alike.

10 Commonly Asked Questions

The new SAQ-A EP form is designed for eCommerce merchants using client side redirection.

1. Why is there a new standard?

As always, new security guidance addresses the latest vulnerabilities affecting today’s merchants and also includes additional clarification. Three main reasons contributed to this updated security standard:

  • Additional guidance: New guidance sections provide layman’s explanations of why standards are important and how noncompliance may put your business at increased risk.
  • Evolving requirements: As technology, threats, and security risks change, the PCI DSS must adapt to the changing environment. PCI DSS 3.0 has evolved to not only address emerging threats, but also new technology like EMV, P2PE, and mobile payments.

2. Who does this affect?

The transition from PCI 2.0 to PCI 3.0 will affect everyone governed by PCI. If you store, process, or transmit payment card information, this change affects you.

3. When is the PCI DSS 3.0 deadline?

January 1, 2014 was PCI 3.0’s effective date. However, PCI DSS 2.0 compliant merchants have until January 1, 2015 to transition to the new standard. Some changes will continue to be best practices until June 1, 2015 (see question 8).

This means merchants do not need to revalidate until their compliance expires. For example, if your annual validation occurs in November 2014, you technically don’t need to validate compliance to 3.0 until November 2015. However, you are required to be compliant with the new standard starting January 1, 2015.

4. What does PCI DSS 3.0 mean for my business?

If you follow PCI 3.0 requirements, you will eliminate the majority of your business risk to compromise. PCI DSS 3.0 focuses on detecting, rather than reacting to, security vulnerabilities. But the standard only works if merchants comply. The best thing merchants can do now is review their compliance status. If you have a passing grade, great! Now it’s time to review PCI 3.0 requirements to make sure you will be in compliance once January 1, 2015 hits. If you have a failing grade, PCI 3.0 is a great time to reevaluate your security and begin securing your business.

5. What will happen on January 1, 2015?

If you haven’t complied with PCI 3.0 by January 1, 2015, you will technically be in violation of PCI DSS. If you are compromised, you may face heavy fines due to your noncompliance.

6. What is the biggest change for ecommerce merchants?

If you are an ecommerce merchant, the biggest change for you will be the new SAQ A-EP. Originally, ecommerce merchants were validated using SAQ A but many of those merchants must now move to a SAQ A-EP, which includes more requirements. Learn which ecommerce methods qualify for SAQ A-EP.

7. What new documentation does PCI DSS 3.0 require?

Documentation is a key theme of PCI 3.0. For example:

  • 1.1.3 requires a cardholder data flow diagram that shows how cardholder data enters your network.
    2.4 involves the creation of an inventory list of all your in-scope device types and their function (e.g.,
  • POS systems, computers).
  • 9.9.1 requires an up-to-date list of all devices, including physical location, serial numbers and make/model.
  • 11.1.1 involves maintaining a complete list of authorized wireless access points and the justification for each.
  • 12.8.5 requires a list of all third party service providers in use, a list of all PCI requirements the service providers meet, and a list of PCI requirements the merchant is required to meet

8. What are the new ‘best practice’ requirements?

The PCI Council knows some requirements will take more time for merchants to apply. There are six requirements considered ‘best practice’ until they are officially required on June 2015. They are:

  • 6.5.6: Insecure handling of PAN and SAD in memory
  • 6.5.11: Broken authentication and session management
  • 8.5.1: Unique authentication credentials for service providers with access to customer environments
  • 9.9: Protecting of point-of-sale devices from tampering
  • 11.3: Developing and implementing a methodology for penetration testing
  • 12.9: Additional requirement for service providers on data security

9. How can I ensure compliance with PCI DSS 3.0?

The only way to ensure lasting compliance with the PCI DSS 3.0 is to make data security part of your company culture. According to Bob Russo, GM of the PCI Security Standards Council, PCI 3.0 is “about making PCI compliance part of your business, not a once-a-year, study-for-the-test kind of thing.” The new standard helps you implement security controls without disrupting your day-to-day processes—allowing you to focus on your business while maintaining appropriate data protection.

10. What is ASV’s are doing to help me with PCI DSS 3.0?

To simplify the transition, Your ASV will update its SAQs, customer interface, and PCI scoping wizard on January 1, 2015. As part of the PCI 3.0 SAQ, select standards will be written in easy-to-understand language for the ease of the user. Because PCI 3.0 introduces more SAQs, your ASV will offer combination SAQs when more than one SAQ applies.

PCI Compliance: Time to Take Control

Visa, Mastercard, American Express, and other payment card companies currently require all merchants who accept credit card payments to comply with the Payment Card Industry Data Security Standard (PCI DSS).

PCI Data Security Standard: An insider’s look

Payment Card Industry (PCI) compliance is a complex and ever evolving subject affecting millions of businesses – acquiring banks, Independent Sales Organizations (ISOs), processors, hosts, shopping carts, e-commerce and retail merchants as well as other merchant services providers.

PCI applies to ALL organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data.

How Host 99 can help:

Our solutions provide comprehensive data protection ensuring PCI compliance

  • Host 99’s Security and Data Protection provides integrated anti-malware, data loss prevention (DLP) and simplified data encryption
  • Host 99’s EncryptGuard for centralized data encryption and protection of PCs and removable media
  • Email Security and Data Protection for integrated anti-malware, anti-spam and email encryption
  • Host 99 SafeGuard LAN Crypt for encrypting and securing network file shares
  • NAC permits network access to the users who need it and enables companies to create comprehensive security policies

Host 99 Professional Services

Host 99 Professional Services has extensive experience assisting retailers, and our offerings can be customized to meet your needs either it be web hosting, web development, merchant processing even security consulting.

4 Online Security Reminders for Small-Business Owners

1. The target can be (very) small. One of the prevailing and more damaging security myths is that small businesses are too insignificant for online crooks to bother with. “Who’d waste their time on little old me?” you ask. You might be surprised. First off, just about every legitimate business has a bank account, if not several of them. Banking and other financial accounts are obvious bull’s-eyes for bad guys. Customer databases and HR files — which often include social security numbers, credit card numbers, and other sensitive info — are also attractive to thieves. Honan’s experience shows that a target doesn’t even need to have any monetary value. His attackers didn’t empty out his bank account or run up his credit card bill: They hijacked his Twitter handle.

2. Apple is not a safe haven. Apple’s operating systems (the software that makes Macs, iPads, and iPhones work) have a reputation for being very secure and relatively free of the malware and other harmful junk that Windows PC users contend with. Honan’s case is a harsh reminder that security is much more than Trojan horses, keyloggers, and other online plagues. By gaining access to Honan’s Apple ID, the attackers were able to take control of — and effectively ruin — his MacBook, iPad, and iPhone. That little bit of information led to breaches of his Gmail and Twitter accounts, too. “You honestly can get into any email associated with Apple,” one of Honan’s attackers later told him. No hardware or software is fail-safe. Don’t assume you’re secure simply because you use Apple’s or any other company’s products. It’s just not true.

3. Don’t link online accounts. The bad guys were able to run roughshod over Honan’s digital life in large part because he linked, or “daisy-chained,” various accounts together. “My Twitter account linked to my personal website, where they found my Gmail address,” he writes. And that was just part of a snowballing sequence. This practice can be especially risky for small-business owners and self-employed professionals who mix and match technology for work and personal uses. Mobile devices, email accounts, and social media are common culprits.

4. Back your data up. Honan acknowledges that he bears part of the responsibility for his data loss, because he failed to back up his files, particularly those on his MacBook. As a result, he lost everything saved on his laptop. He later recovered much of it, but data-recovery services like the one Honan used are expensive — he shelled out nearly $1,700 — and far from guaranteed to work. Honan called the recovery of his files a “miracle.” The bottom line: Back up your information. There are myriad options for doing so, online and off. Several online platforms, including Google Drive and Microsoft’s SkyDrive, offer a decent amount of starter space — 5GB or more — for free. If you’re uneasy about storing sensitive business information online, do so on an external hard drive or other physical storage media. Just don’t keep it in the same place as your primary copies. Otherwise, you’re not protected from other kinds of disasters, such as a fire or flood.

What else can you do to protect yourself and your business? In the wake of Honan’s story, Google recommends enabling two-factor authentication on your accounts. Use strong passwords and change them regularly — and avoid using the same username and password combinations across accounts, which makes attacks like this even easier.

Remember: This type of digital disaster can happen to anyone. The worst mistake is to assume it can’t happen to you.

What is PCI?

 The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment.  Essentially any merchant that has a Merchant ID (MID).

The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with focus on improving payment account security throughout the transaction process.

The PCI DSS is administered and managed by the PCI SSC (, an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB.).

It is important to note, the payment brands and acquirers are responsible for enforcing compliance, not the PCI council.

A copy of the PCI DSS is available here.

Customers worry about theft of their data.

You should worry about business fallout.

More than 340 million computer records containing sensitive personal information have been involved in security breaches in the U.S. since 2005.1 Now criminals are shifting sights to small merchants because many have lax security for cardholder data. More than 80% of attacks target small merchants. If you are at fault for a security breach, business fallout can be severe:

•Fines and penalties
•Termination of ability to accept payment cards
•Lost confidence, so customers go to other merchants
•Lost sales
•Cost of reissuing new payment cards
•Legal costs, settlements and judgments
•Fraud losses
•Higher subsequent costs of compliance
•Going out of business

What data thieves are after

The object of desire is cardholder data. By obtaining the Primary Account Number (PAN) and sensitive authentication data, a thief can impersonate the cardholder, use the card, and steal the cardholder’s identity.

Sensitive cardholder data can be stolen from many places:
•Compromised card reader
•Paper stored in a filing cabinet
•Data in a payment system database
•Hidden camera recording entry of authentication data
•Secret tap into your store’s wireless or wired network

Defining “sensitive cardholder data”

Everything at the end of a red arrow is sensitive cardholder data. Anything on the back side and CID must never be stored. Everything else you store must be for a good business reason, and that data must be protected. PCI DSS explains how.

Credit Cards

Small Merchants

Small merchants are prime targets for data thieves. It’s your job to protect cardholder data at the point-of-sale.

If cardholder data is stolen – and it’s your fault – you could incur fines, penalties, even termination of the right to accept payment cards!

Let Host 99 help you become PCI Compliant and stay secured from hackers. Contact Us for more details.

Protecting cardholder data is good for your business

PCI security prevents stolen customer data, and:

  • Prevents lawsuits
  • Can save you money
  • Helps you to stay in business

You are responsible for preventing theft of cardholder data

Follow these steps:

  • Don’t store ANY sensitive cardholder data!
  • Secure card readers, point-of-sale, and payment systems
  • Use basic security techniques

Learn how

Details are in the PCI DSS.
It’s a strong, systematic way to secure cardholder data.

How to Be Compliant

Getting Started with PCI Data Security Standard Compliance

PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The Council is responsible for managing the security standards, while compliance with the PCI Security Standards is enforced by the payment card brands. The standards apply to all organizations that store, process or transmit cardholder data – with guidance for software developers and manufacturers of applications and devices used in those transactions.

If you are a merchant that accepts payment cards, you are required to be compliant with the PCI Data Security Standard. You can find out your exact compliance requirements only from your payment brand or acquirer. However, before you take action, you may want to obtain background information and a general understanding of what you will need to do from the information and links here.

The PCI DSS follows common-sense steps that mirror security best practices. There are three steps for adhering to the PCI DSS – which is not a single event, but a continuous, ongoing process. First, Assess — identify cardholder data, take an inventory of your IT assets and business processes for payment card processing, and analyze them for vulnerabilities that could expose cardholder data. Second, Remediate — fix vulnerabilities and do not store cardholder data unless you need it. Third, Report — compile and submit required remediation validation records (if applicable), and submit compliance reports to the acquiring bank and card brands you do business with.

For more information, download our Getting Started Guide and/or our Quick Reference Guide.

To learn what your specific compliance requirements are, check with your card brand compliance program:
• American Express:
• Discover Financial Services:
• JCB International:
• MasterCard Worldwide:
• Visa Inc:
• Visa Europe:

PCI DSS 2.0 Compliance

On Jan. 1, 2011, the latest version of the PCI DSS 2.0 went into effect. The revisions, which modify the Self-Assessment Questionnaires (SAQs), call for discontinuance of the existing PCI DSS version and SAQ forms by Dec. 31, 2011.

The PCI DSS 2.0 is another opportunity for you to engage merchants in active PCI education, provide valuable security information that strengthens the relationship and increase compliance rates throughout the portfolio. Use this information and leverage your PCI compliance solutions provider to build a strong and consistent communication and compliance plan.

PCI Merchant Requirements

For the PCI DSS Requirements and Security Assessment Procedures, the following defines the table column headings:

PCI DSS Requirements – This column defines the Data Security Standard and lists requirements to achieve PCI DSS compliance; compliance will be validated against these requirements.

Testing Procedures – This column shows processes to be followed by the assessor to validate that PCI DSS requirements are “in place.”
In Place – This column must be used by the assessor to provide a brief description of
the controls which were validated as “in place” for each requirement, including
descriptions of controls found to be in place as a result of compensating controls, or as a
result of a requirement being “Not Applicable.”

Not in Place – This column must be used by the assessor to provide a brief description of controls that are not in place. Note that a noncompliant
report should not be submitted to a payment brand or acquirer unless specifically requested.For further instructions on noncompliant reports, please refer to the Attestations of Compliance, available on the PCI SSC website (

Target Date/Comments – For those controls “Not in Place” the assessor may include a target date that the merchant or service provider expects to have controls “In Place.” Any additional notes or comments may be included here as well.

Similar to other industries, a secure state could be more costly to some organizations than accepting and managing the risk of confidentiality breaches. however, many studies have shown that this cost is justifiable.

If you are looking for a PCI Compliance Scanning Vendor or Host contact us we  can assist you becoming PCI Compliant within 72 Hours guaranteed, we have partnering services for PCI Compliance starting at only $112.00 a year unlimited scans and support included provided by Security Metrics.