What Happened at Marriott?

Beginning as early as 2014, Starwood hotels, now owned by Marriott, experienced a massive data security breach reportedly at the hands of Chinese hackers. The breach may have exposed the personal data of as many as 500 million guests of the hotel chain.

Once the news of this breach became public, the far-reaching costs began showing almost immediately. According to Forbes, “The company now faces a class-action suit and shares have subsequently fallen 5.6%. On top of this, Marriott says for about 327 million victims, compromised data may include names, addresses and passport numbers — prompting Senator Chuck Schumer to demand that it “foot the bill” for new passports.”

Not all costs of such a breach translate directly to a dollar amount. NBC News illustrates some of the other struggles companies face after their systems have been invaded. “Aside from expensive technical investigations and regulatory filings, a breach also includes hidden costs such as lost business, negative impact on reputation, and employee time spent on recovery, according to a new report by the Ponemon Institute.”

The reputation hit is already being felt in this example. Marriott didn’t acquire Starwood until 2016, in the midst of the breach. But in the eyes of the public, this fact doesn’t excuse Marriott from fault. “In news reports, this is not Starwood’s data breach, but Marriott International’s,” says an article on the Internet Society website. “Like any data breach, this incident will harm trust between the company and its customers.”

The same article explains why this happening on Starwood’s watch doesn’t matter. “When Marriott International acquired Starwood and its data, they also acquired the risk associated with storing and handling that data. Digital security is a crucial part of a corporation’s bottom line, and security incidents can quickly become disastrous for a business.”

What Should Merchants Know About Data Security?

At Marriott’s size, the company will likely bounce back from this breach. Smaller businesses may not be so lucky. That’s why Payment Card Industry Data Security Standards (PCI DSS) exist. These PCI rules are intended to protect the sensitive card data that is used in processing a payment. Depending upon a company’s size, they must adhere to one of four PCI compliance levels. 

The more transactions a company processes each year, the more stringent their PCI burden becomes. This is good for smaller companies that don’t have the means to achieve Level 1 compliance. However, if their company is subject to a data breach, they may not be able to withstand the reputational losses companies like Marriott have experienced. This is especially true if the business in question relies on other businesses as clients. No management team will feel comfortable entering into a contract with a company that isn’t adequately protecting sensitive consumer card data. 



Information sourced from Visa.com

Though scans are listed for every level of compliance, they are not required depending upon the Self-Assessment Questionnaire (SAQ) each business must complete. According to complianceguide.org, regular scans are required only for SAQ A-EP, SAQ B-IP, SAQ C, SAQ D-Merchant and SAQ D-Service Provider.

There are two instances where merchants are eligible for the simple SAQ A: 

  • “Merchant website provides an inline frame (iframe) to a PCI DSS compliant third-party processor facilitating the payment process.”
  • ”Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.”

How to Manage Your Sensitive Data?

Along with the PCI requirements, there are more actions companies can take to keep sensitive data safe (minimizing the risks involved with processing a card payment). 


Ensure the policies you have in place for your business are sufficient to keep data safe and are in line with PCI standards. The policies and procedures should be kept as part of the company’s larger compliance management system. They can be updated after issues by conducting a root cause analysis, or can be audited and updated in larger segments as needed.   

Many merchant service providers also host a PCI certification program for their merchants with national vendors like Trustwave and Security Metrics. These programs provide all the policy and procedure templates your business needs to pass compliance. 


Of course, setting policies within your company is necessary. But policies won’t be helpful if they aren’t being followed. Providing initial education and ongoing training opportunities to staff helps you to prepare your staff for properly handling sensitive card data, including:

  • Cardholder names
  • Credit card numbers
  • CVV


Merchants need to understand the burden their core collection software holds in regard to data security. Collection software should be PCI-PA (payment application) compliant. If they are, credit card numbers can pass through their system to the processor. If their software isn’t compliant, then the merchants that use it aren’t compliant either.

As a business owner using third party vendors for services, consider what your clients might ask about your credit card payment compliance. Also note that if your vendors use an iframe linked to a payment processor, the software is compliant–but may be infringing on a patent. This will most certainly hurt your chance of gaining new business.

Finally, ask third party providers what happens to credit card numbers once service is established. Merchants who only have access to a token (the placeholder created for each credit card number for additional safety) will lose all recurring payment schedules created through that processor if they wish to leave. If you want the freedom to switch without disrupting your day-to-day business, find a provider that maintains both credit card numbers and tokens. 

How PDCflow Protects Its Partners and Clients

PDCflow is serious about security. We offer the highest level of PCI compliance possible, which results in minimal hands-on work for PDCflow partners and clients. Here are the ways we take on most of the PCI burden, making businesses and consumer data safe and secure.


PDCflow supports your PCI compliance by using a patented technology that protects both our clients and our software integration partners. This Secure Entry Overlay technology eliminates merchant and software partner need for contact, transmission or processing of a credit card number.

PDCflow’s protected process provides a small data entry window that is directly connected to our PCI certified environment. This window is where credit card number is entered. The ability to input card numbers directly into our PCI certified environment reduces the client’s PCI requirements to the 15-minute Self-Assessment Questionnaire A.

Without this process, clients must spend considerable time and money filling out SAQ C and providing quarterly scans of their network. Our software integration partners are probably the most fortunate. With Secure Entry Overlay, their software is completely eliminated from the scope of PCI compliance because it never touches a credit card number.


The highest level of PCI compliance is a costly and labor-intensive investment. PDCflow has taken on this burden so that taking credit card payments becomes safer for our customers. We use a third-party audit of our facilities, programming and infrastructure performed by a professional certification auditor. By maintaining Level 1 PCI compliance, we ensure an extra level of protection for our clients and their consumers.


A self-assessment questionnaire is unavoidable if your business accepts credit cards. However, our Customer Success staff is readily available to help clients answer any questions they may have about filling out the yearly questionnaire.  

PCI compliance is a dense subject with many angles to consider. To start with a quick overview of PCI compliance basics, download our PCI compliance guide.

Next Article: DAKCS Software Systems, Inc. Achieves SSAE18 SOC ...

For more from PDCflow, visit their blog