Best Practices for Implementing PCI DSS into Business-as-Usual Processes

 

To ensure security controls continue to be properly implemented, PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy. This enables an entity to monitor the effectiveness of their security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments. Examples of how to incorporate PCI DSS into BAU activities include but are not limited to:

  1. Monitoring of security controls—such as firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), file-integrity monitoring (FIM), anti-virus, access controls, etc.—to ensure they are operating effectively and as intended.

  2. Ensuring that all failures in security controls are detected and responded to in a timely manner. Processes to respond to security control failures should include:

    • Restoring the security control
    • Identifying the cause of failure
    • Identifying and addressing any security issues that arose during the failure of the security control
    • Implementing mitigation (such as process or technical controls) to prevent the cause of the failure recurring
    • Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively

  3. Reviewing changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to completion of the change, and perform the following:

    • Determine the potential impact to PCI DSS scope (for example, a new firewall rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS).
    • Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including FIM, AV, patches, audit logging, etc., and would need to be added to the quarterly vulnerability scan schedule).
    • Update PCI DSS scope and implement security controls as appropriate.

  4. Changes to organizational structure (for example, a company merger or acquisition) resulting in formal review of the impact to PCI DSS scope and requirements.

  5. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes. These periodic reviews should cover all facilities and locations, including retail outlets, data centers, etc., and include reviewing system components (or samples of system components), to verify that PCI DSS requirements continue to be in place—for example, configuration standards have been applied, patches and AV are up to date, audit logs are being reviewed, and so on. The frequency of periodic reviews should be determined by the entity as appropriate for the size and complexity of their environment.

    These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, firewall reviews, etc.—to assist the entity’s preparation for their next compliance assessment.

  6. Reviewing hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS. If it is discovered that technologies are no longer supported by the vendor or cannot meet the entity’s security needs, the entity should prepare a remediation plan, up to and including replacement of the technology, as necessary.


In addition to the above practices, organizations may also wish to consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions. In environments where one individual performs multiple roles (for example, administration and security operations), duties may be assigned such that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.

Note: These best practices for implementing PCI DSS into business-as-usual processes are provided as recommendations and guidance only, and they do not replace or extend any PCI DSS requirement.