For credit card handlers, cloud computing guidelines just got clearer

The fact that regulations evolve at a much slower pace than cloud computing technologies can lead to confusion regarding how to meet regulatory requirements in the cloud. If a client moves a regulated function to the cloud and later falls out of compliance due to a shortcoming on the cloud vendor's part, the client remains accountable. So it's essential to have as much clarity on these issues as possible.

Recognizing this challenge with regards to the handling of credit card data, the Payment Card Industry (PCI) Security Standards Council has recently issued guidance on how to apply PCI Data Security Standards (PCI DSS) in the cloud.

PCI DSS applies to all organizations that hold, process or exchange credit card information. It was created to help ensure that consumers are not exposed to potential financial or identity fraud and theft. To accomplish this, PCI DSS provides a payment card data security framework that organizations deploy to prevent, detect and respond to security incidents. PCI DSS is not a law, and the PCI Security Standards Council doesn't directly impose any consequences for non-compliance, but the negative repercussions of non-compliance can include lawsuits, insurance claims, canceled accounts, payment card issuer fines and government fines. To ensure none of this happens to you when processing credit cards in the cloud, it's important to understand this new PCI DSS guidance.

PCI DSS was initially released on Dec. 15, 2004. To put this in perspective, that was over a year before Amazon Web Services initially began offering IT infrastructure services to businesses. The current version of PCI DSS, 2.0, was released on Oct. 26, 2010, but it wasn't until Feb. 5 of this year that the Cloud Special Interest Group of the PCI Security Standards Council released the PCI DSS Cloud Computing Guidelines to provide specific guidance on the use of cloud computing and maintaining PCI controls in cloud environments.

The guidelines are intended for use by organizations investigating, adopting or using cloud computing services as part of a cardholder data environment. Many elements of the guidelines align with issues addressed in my past columns, but they are worth reinforcing here within the PCI context. Some key concepts contained in the guidelines include:

It is crucial that an organization clearly understands its own needs before transitioning payment card operations to the cloud. To achieve this, you should build a team of key stakeholders to define needs and determine the degree to which available cloud services meet those needs.

While responsibility for security of cardholder data in a cloud environment is shared between the customer and cloud vendor, the customer remains accountable for ensuring that its cardholder data is properly secured according to applicable PCI DSS requirements.

Accountability and responsibility for managing the various PCI DSS controls need to be clearly understood and agreed upon by both the customer and the cloud vendor. Specific roles may differ on a case-by-case basis depending upon a number of variables, including:

The cloud service models (IaaS, PaaS, SaaS) and deployment models (public, private, community, hybrid) selected by the customer

The reason the customer is using the cloud vendor and the range of PCI DSS requirements it is deploying in the cloud

The services and system components that the cloud vendor has validated within its own operations.

When payment card data is stored, processed or transmitted in the cloud, PCI DSS compliance will include validation of both the cloud vendor's infrastructure and the customer's use of it.

Before adopting a cloud service, customers should first verify that the cloud vendor has validated PCI DSS compliance, by asking questions such as:

When was the cloud vendor first validated for compliance? When was its most recent validation?

Which specific services provided by the cloud vendor were included in the validation, and which were not?

Which specific elements (facilities, components) of the cloud service were included in the validation, and which were not?

How does the cloud vendor ensure that customers cannot introduce non-compliant elements or bypass existing controls?

A cloud vendor claiming to have completed an independent PCI DSS assessment should be able to provide a customer an Attestation of Compliance and Report on Compliance that should include details regarding the specific services, components and facilities included in the assessment.

Just because the cloud service is PCI DSS-compliant doesn't automatically mean that the customer is compliant. The customer must still ensure that it's using the service in a compliant manner.

The final recommendations in the conclusion of the guidelines:

-DOCUMENT everything with your provider in written agreements - for example, SLAs/Terms of Service contracts, etc.

-REQUEST written assurances that security controls will be in place and maintained.

-REVIEW the service and written agreements periodically to identify if anything has changed.

Essentially say it all -- get it in writing, and continuously monitor compliance. For those who want to gain these skills, and learn more about cloud computing risk mitigation via contract negotiation and vendor management, the next session of my seminar Contracting for Cloud Computing Services will be held March 25-26, 2013, in Los Angeles. I look forward to seeing you there.

Thomas Trappler is director of software licensing at the University of California, Los Angeles, and a nationally recognized expert, consultant and published author in cloud computing risk mitigation via contract negotiation and vendor management. For more information, please visit

Join the CSO newsletter!

Error: Please check your email address.

Tags securitycloud computinginternet

More about Amazon Web Services

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Thomas J. Trappler

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place