7 deadly PCI compliance mistakes you can't afford to commit:

  1. Not Managing User Permissions Properly
    All user roles must follow all rules – even ones of least privilege. All permissions must be appropriate for the applications and processes a certain user deals with. 

  2. Not Conducting a Readiness Assessment 
    This assessment should answer the questions “Who, what, when, where and why?” It’s a proactive, but necessary measure that keeps you in compliance so you don’t find yourself facing those huge fines we talked about earlier. 

  3. Not Enough Support from Executives and Senior Management
    Some tasks and processes you can do without the awareness or approval from leadership. PCI compliance isn’t one of them. If you don’t already have the support of organizational leaders, then it’s time to start conversations about PCI compliance. You must tell them the exact time and financial resources you need to make compliance a reality for your company. 

  4. Ignoring Virtualization Compliance
    Unfortunately, this often gets overlooked. If you have just a single virtual machine, your entire virtual infrastructure must comply with PCI standards. How they word this standard is somewhat vague. So, a large part of how the standard gets enforced is based on how auditors interpret it. 

  5. Not Changing Vendor Default Configurations
    If you leave default configurations in place, it’s easy to duplicate and deploy all your virtual machines. You can scan your IT infrastructure for new devices, but this doesn’t work very well in the case of virtual machines. 

  6. Not Monitoring Log Data
    Monitoring your log data is one of the key facets of PCI compliance. You also need to thoroughly protect it. 

  7. Storing Cardholder Data as Plain Text
    Less is more when it comes to cardholder data. Store as little of it as possible. If you absolutely have to store it, don’t keep the entire 16-digit card number. And of course, PIN and/or CVV data CAN'T and shouldn’t be in your log files either. All cardholder data should be encrypted, and encryption keys should be kept in as few locations as possible.

The AS/400, iSeries, System i that we run may be less susceptible to security breaches and have fewer vulnerabilities, but that is based on our operating and configuring them correctly in a secure manner.