The one truism of PCI-DSS compliance is this:

You are PCI-DSS compliant if your QSA says you are PSI-DSS compliant.

I'm of the opinion that the PCI council did a pretty stinking good job of giving us a very clear and to the point standard to follow, at least as far as standards go. That being said, this is one of those interesting cases where the requirement seems to be slightly out of whack with the intent.

Take the literal text from the requirement:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

That right there says, primary function which could open you up to some disagreements. One could say the primary purpose of a given server is to store the database for the processor, whereas it is also configured to run the reporting engine as a secondary function.

The Council also produces another document called "Navigating the PCI DSS v2.0", available for download at the same location as the standard itself. This document goes into much greater detail bout each requirement and attempts to explain the intent behind them.

This is intended to ensure your organization's system configuration standards and related processes address server functions that need to have different security levels, or that may introduce security weaknesses to other functions on the same server.

Ok, cool, I like that. It tells us that they're trying to segregate based on the security level of the data in question. So, in theory, if you have a web application that allows direct access to the database containing card holder data, and the only people that have access to that highest sensitivity of data have access to the webapp, one might be able to host them both on the same system while maintaining compliance. However, if there exists a reporting tool that provides statistical data about transactions, but not the cardholder data itself, and a different set of people have access to it? Yeah, you're going to want to split that off.

Very likely the last thing you want to be doing, however, is slicing hairs into smaller and smaller slivers with your QSA. So the typically held opinion is:

The information provided above is in no way intended to be taken as official advice and is provided without warrant, guarantee, good faith, or adequate morning coffee intake. The statements provided to not represent the views of the PCI council, any QSA/ASV, my employer, your employer, this site, any other site, nor the ISP on which you are viewing this message.

The one truism of PCI-DSS compliance is this:

You are PCI-DSS compliant if your QSA says you are PSI-DSS compliant.

I'm of the opinion that the PCI council did a pretty stinking good job of giving us a very clear and to the point standard to follow, at least as far as standards go. That being said, this is one of those interesting cases where the requirement seems to be slightly out of whack with the intent.

Take the literal text from the requirement:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

That right there says, primary function which could open you up to some disagreements. One could say the primary purpose of a given server is to store the database for the processor, whereas it is also configured to run the reporting engine as a secondary function.

The Council also produces another document called "Navigating the PCI DSS v2.0", available for download at the same location as the standard itself. This document goes into much greater detail bout each requirement and attempts to explain the intent behind them.

This is intended to ensure your organization's system configuration standards and related processes address server functions that need to have different security levels, or that may introduce security weaknesses to other functions on the same server.

Ok, cool, I like that. It tells us that they're trying to segregate based on the security level of the data in question. So, in theory, if you have a web application that allows direct access to the database containing card holder data, and the only people that have access to that highest sensitivity of data have access to the webapp, one might be able to host them both on the same system while maintaining compliance. However, if there exists a reporting tool that provides statistical data about transactions, but not the cardholder data itself, and a different set of people have access to it? Yeah, you're going to want to split that off.

Very likely the last thing you want to be doing, however, is slicing hairs into smaller and smaller slivers with your QSA. So the typically held opinion is:

The information provided above is in no way intended to be taken as official advice and is provided without warrant, guarantee, good faith, or adequate morning coffee intake. The statements provided do not represent the views of the PCI council, any QSA/ASV, my employer, your employer, this site, any other site, nor the ISP on which you are viewing this message.