Edit: I am glad I get to edit this to add to my answer a bit, because after happening to read it again a minute ago I realized how far from really answering your question in a direct, useful way I came. What I said below yesterday was not wrong, but let me add just a tad more upfront to actually start to answer the question/s you raised & tie in what I wrote yesterday. So:
First, a requisite disclaimer: From your standpoint you should not view me as you would a QSA or other compliance professional engaged by you in your paid employ and highly familiar with your specific circumstances. From your standpoint, you should treat me as some guy on the Internet who may or may not know what he's talking about, and who you probably should not rely upon your sole source of information and advice about any important point.
Okay, so...
Let's start with this: those five servers you noted? You very likely don't need any of them.
Why? Well, here's the thing: many of the PCI Requirements, as you may have intuited, aren't actually written with the small business owner's situation--especially the single-person small business owner's situation--in mind. Rather, many of them are really directed toward mid-sized and larger businesses. The complex thing, however, is that there's no actual, one single place in the Requirements that says which ones apply to everybody and which ones apply to only to larger entities with more complex operations to monitor. The reason behind that actually makes a little sense: some small businesses may actually use or run certain elements or capabilities that are typically found in larger firms and implicate some additional security considerations. But this not-really-clear approach can, in my experience, create some undue consternation among business owners when they start reading about how they need to take measures to protect equipment that they don't have.
Now, don't get me wrong: a small business, even a one-person small business, is not by any means exempt from the need or duty to comply with most specific Requirements. You don't get to store unencrypted card data, or run your PCs operating systems' unpatched, or anything like that. But there is at least a little bit of a "sanity test" element involved about whether a given Requirement applies to you. Lets go over one example: If you run a single-person business that you use a single Windows PC with a POS application on, what does Requirement 6.1 require of you? If you have Windows set up to automatically download and install patches, must you still "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”)..." Windows vulnerabilities? Even if you were super-motivated to read over Microsoft's vulnerability bulletins for each month's announced security updates by the time they are released and you've read them and rated them (somehow) your lone Windows PC has probably already installed the security updates that have fixed them? (Now, on the other hand, if you were a security team with a huge national retailer might find that a lot more relevant.) What about, say, Requirement 12.10.5? Do you need to develop a written response plan and then "[d]evelop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments." if you have a single-operator business?
Obviously not. If you look at your SAQ D self-questionnaire forms you'll see the "Not Applicable" column on there besides "Yes", "Yes, with Compensating Controls" and "No". Small businesses can expect to make good use of that column. In particular, a lot of Requirements that apply to the types of servers that you listed in your question simply do not apply to you, a business operator who neither has any of those servers nor any need for such servers. it is not the intent of the PCI Requirements, we must assume, to make you buy additional computers for your operations soley so you can put certain measures into effect to protect them and tick a "yes' box on the SAQ form.
But what about things that are less clear cut? Requirements that seem pretty oneous for (let's say) a one-person, one-computer small business but which sound like possibly relevant important controls? This is where a combination of being willing to rely on a common-sense understanding of what "Compensating Controls" you can rely on in real-world security and put on the SAQ with a straight-face can prevent you from needing to, for example, necessarily deploy a network-based Intrusion Detection System or dedicated file-modification monitoring software.
More about that in a bit. But first there's an important technical question to answer before almost any other: In your payment setup, is credit/debit card information first encrypted while it's still in the card reader or terminal itself, such that your attached PC with your Point-of-Sale software on it never even sees unencrypted vital card info at all? Or is that card information passed from your card reader/terminal to your attached POS machine "in the clear" where software on the PC first encrypts it before sending it out over the Internet? Because on the outcome of that question rests two things: the kind of PCI questionnaire you should be filling out (SaQ-P2PE vs. SAQ D) and the degree of measures you need to be implementing to provide a security environment that could legitimately PCI scrutiny. (As well as, you know, actually protect your customers' financial information.)
Let's start with your card reader or terminal. If you have the right one, it can make a huge, huge difference in the hassles you'll have to deal with in terms of PCI compliance. Why? Because of the existence of "on-swipe", card-reader-to payment-processor, end-to-end encryption. This is, by far, the single most important issue there is when it comes to both your PCI compliance and the actual quality of security with which you will safeguard your customer's card information.
Why is that so? Because with on-swipe encryption your customers' vital debit/credit card information is encrypted before it ever leaves the card reader and hits your systems. It is decrypted only when that bundle of information hits your payment processor's infrastructure after traveling over the Internet. In other words, whatever security weaknesses or flaws, even active malware installations on your Point-of-Sale systems (which is where payment information still gets first encrypted in most setups right now, unfortunately), become irrelevant.* The in-reader encryption means that you, your equipment, and any card-info stealing malware that may reside in your equipment, simply have no electronic access to the information a crook would need to counterfeit a customer's card or abuse a customer's card number. If Target, Kmart, Home Depot, et al. had had end-to-end encryption in place and properly configured exactly no cards could have had their info captured by Point-of-Sale malware in the breaches that have so rocked the American retail payment space. And--most directly applicable to your question-- the PCI requirements for a merchant who has o- swipe/end-to-end encryption setup are much, much shorter than the normal rules and entail vastly less expense and sophistication to comply with. (And those rules that exist focus entirely on whether you've got the encryption setup properly and on a few non-technological policy areas.)
How do you get on-swipe/on-reader encryption? Well, you will need to call your payment processor and talk with them about replacing your current card reader with an encrypting card reader. For the last very small business I did work for, less than a year ago, its payment processor had a Magtek reader (this payment processor just happened to partner with Magtek; there are other good makers out there also) available for about $90 per reader; setup entailed going over a configuration process over the phone with customer support for, oh, about 10 minutes. Before buying the new readers we also called the company that made the POS software on the standard Windows PCs we were using, just to be conservative about avoiding conflicts; no problems. Installation and activation went very well, and my client since has been running as reliably and with much better security than as before.
Alternatively, if you might be interested in switching over to new payment offerings from Square, Amazon, and Paypal all of their now-shipping readers come with on-swipe encryption built-in. And if you're looking at this October and thinking about getting an EMV/chip-card reader to meet the informal, not-a-deadline deadline for supporting that standard almost all of the dual EMV/magnetic stripe terminals you will see will come with baked-in encryption for magnetic swipe card transactions. (But check before you buy.)
So...yeah. That would be my guidance (as someone who, in a legal sense, you should not rely solely on for guidance. Just a reminder/disclaimer). But yeah, encrypt your card data at the reader.
*And yes, I suppose maybe I go a little close to saying on-swipe encryption is a magical cure-all of some kind. In information technology you should always, always do some defense-in-depth stuff (like making sure your OS & program security patches are routinely downloaded and applied, being cautious to some degree about the programs you install on your PCs, running with a decent anti-malware program on, etc.) But in-reader encryption is really a big, big deal.
tl;dr Get an encrypting card reader, set it up properly, and make compliance much easier and your customer's credit/debit card info safer.
