Showing results for 
Search instead for 
Did you mean: 

PCI Compliance in Cloud setup?

I'm helping a client evaluate a different architecture for their site. At the moment they have a managed dedicated server hosting a site that accepts credit cards for certain transactions. I'm wondering if it's possible to store CIM in a cloud-hosted database or whether this is not PCI-compliant.

Having recently experienced a catastrophic loss of all data, the client learned that their contingency plans were too slow -- they lost 24 hours of data because of the slow data restore procedures. We have started to discuss the possibility of using Rackspace's cloud products to host the site.  E.g.:
option 1
* application (the php website) runs on a Cloud Server (
* database hosted by Cloud Database instance.
* another Cloud Server performs image import routines with partner sites (must talk to database and deliver resized images to a content delivery network)

The problems with this option are that:
1) rackspace says that Cloud Servers are not PCI compliant, presumably because they run on shared hardware. I've been told that these cloud servers are therefore "not auditable" or something.
2) while we do not store any credit card numbers in our database, we do store tokenized references to this information.  That is to say we store a customer profile id (customer id) and a customer profile payment id (customer credit card id) that correspond to data stored by our transaction gateway provider.  These tokenized references are meaningless integers unless you also have the account id and api transaction key we use to interact with our transaction gateway.  If you have both the api credentials (stored in a php file on our application server) and the tokenized account references, then you can actually take people's money.

Because Rackspace says the cloud servers are not PCI-compliant, this suggests we can't use option 1 because we would be using a Cloud Server to terminate our HTTPS connections and collect credit card data.

option 2
* dedicated managed server hosts application server
* database either Cloud Database service as above OR we host mysql on the dedicated server with a Cloud Server replicating the live data as a slave
* Cloud Server performs image import routines blah blah blah

In this situation, we'd still have dedicated/managed hardware aso our HTTPS endpoint and would therefore be pci-compliant in that respect, but we are still storing this tokenized customer payment data in cloud (i.e. shared-hardware) environments.  Is that acceptable? Is this tokenized data considered "sensitive" ?

Any thoughts on PCI compliance are welcome. Any thoughts on the data pathways in the above architecture are also welcome.


Nobody has thoughts on this?


The tokenized information is not considered sensitive, since credit card data can not be retrieved even if someone somehow gets their hands on the primary account login. Your best bet if you really care about PCI compliance is to put your payment pages on on PCI-compliant hosting, then the rest of your site can be on whatever you feel like. Or you can just pay the penalty fees, if they're less than the cost of a separate hosting account and/or additional development time.


Don't think any of the sites I've implemented for, to this date, have been on PCI-compliant hosting.


Thanks for your response! You must answer every question anyone asks here, TJP. What "penalty fees" are you referring to? That sounds scary.


I agree that the CIM tokens do not seem especially sensitive, but would appreciate some kind of authoritative absolution here -- either a written statement from or some other legally-sound indication that this is in fact no "cardholder data" or "sensitive authentication data" according to the PCI definition.


It was pointed out today that even if all of our customer's CIM profile id's and payment profile ids and our login and transaction key were compromised, the worse that could be done would be to take money from our customers and put it in our account.  Is there a possibility someone might grant a colossal refund to some credit card number and steal money that way? Or must a refund always be less than or equal to the amount collected in a prior transaction?


Your suggestion to "put your payment pages on on PCI-compliant hosting" does not necessarily solve our problem because, although we are using PCI-compliant hosting for our web server (to host HTTPS, collect credit card data, etc.) we would expect to use NON-PCI virtual machines to host our database and/or replicate the database for backup purposes.  Even if the CIM tokenized info is not "cardholder data" we still might have to adhere to SAQ D standards because of this requirement for SAQ C:


The payment application system/Internet device is not connected to any other systems within
your environment (this can be achieved via network segmentation to isolate payment application
system/Internet device from all other systems);


Ultimately, it sounds like we are at best stuck with adherence to the standards of SAQ D if we want to claim PCI compliance. At worst, the cloud setup isn't auditable because of unknown aspects of traffic flow in the cloud network.


Given your statement that nobody seems to bother with PCI-compliant hosting, it sort of makes me wonder what PCI compliance is for.

You get charged something like $15-$25 per month (not sure exact amount, haven't checked recently) and could theoretically end up with slightly higher credit card rates and so on if you don't perform a PCI security scan and pass it. Of course, that might vary according to your merchant account provider.


For PCI security purposes, sensitive data includes credit card data, bank account data, SSN, driver's license, state ID, passport ID, etc. As long as you're not storing that stuff, or any way to access it, you should be able to get away with SAQ C, assuming the other requirements are fulfilled. CIM profile ID's do not give you access to that data, therefore they won't push you into SAQ D.


There is, incidently, a difference between having your payment site and main site actively networked, and just redirecting users from one site to the other with a guid and basic payment info appended. The new SAQ C makes it more clear that it's the former that pushes you into SAQ D, not the latter.