And, of course, there's no way to know. Ironically, in many cases it would be far better for a site to outsource cc processing... unless they are just "cheating" at compliance. (The rules of compliance apply to everyone regardless of tier; it's only the assessment that varies.) Compliance is a costly process that requires either a great deal of knowledge and effort if done in-house. And yet, Tier 2-3 merchants may not want to outsource because they don't want to look like a small company that "can't" do it internally. So for the appearance of being bigger, they may go it alone, but not have the expertise and so put end users at risk.
I used to do development at a Tier 2 merchant, and I lost a little sleep over credit cards. I was fully compliant (without gaming the system), and even implemented systems that go way beyond what PCI requires (for example, my first rev of cc processing included tokenization). And still, I was scared of persistent threats. Even though credit card processing was isolated, data transiently passed through main web servers (over ssl, of course) on the way to be tokenized. Which would mean that it would be possible to gain access to those servers, and graft something onto that channel.
If I had to do it over again, I'd recommend at least a 3-tier system with main web processing, a secure super-stripped, super-minimalized set of web services where consumers would add card data on a DMZ, and then a dropbox server that would give out tokens. I'd build the 2 tier cc-processing servers as vms and probably destroy them once a week and do rolling redeployments off a patched gold master.
I think that'd probably start to let me sleep a little better.
Truth is, I'm way more concerned with identity security than credit cards. It's pretty trivial to get fraudulent charges reversed and get new credit cards. Try getting your credit history fixed and get a new SSN/taxpayer id. And there's no PCI handling for SSNs.