PCI DSS requirements solution mapping

PCI DSS requirements solution mapping The main reason for developing our PCI GRC (Governance, Risk and Compliance) tool is to provide a central repository and baseline for reporting PCI compliance across your estate to your Acquiring Bank, QSA or External Auditors, with a direct link to the evidence required by the PCI Data Security standards requirements (PCI DSS). We provide a complete system of record for PCI DSS that consolidates all of the output from the network layer security service provider and monitoring solutions that have been implemented. Our solution records their deliverables onto a platform that allows a single view into all of your PCI DSS requirements, which enables our clients to ensure PCI DSS Governance and Compliance against all identified Risks at any stage during the year. Merchants, who have multiple PCI locations and Assets, benefit the most from our PCI GRC solution as it is easier to maintain consistency of data for all of their compliance and reporting requirements. This in turn enables them to directly link the relevant Risks and Policies to the PCI DSS compliance framework as defined by the PCI Council. Our modules as they relate to the PCI DSS 3.1 requirements Module Description PCI requirement compliance PCI: Manage Departments For managing your PCI locations including their MIDs, Assets, projects, 8,9, 11 &12 New PCI scope request register Manage PCI scope: PCI products Manage PCI scope: Payment processors Manage PCI scope: PCI Locations risks and BAU reports. To manage request for MIDs, new payment channels, new payment solutions, non-service catalogue projects. Manages the list of PCI approved products as part of the service catalogue. Reporting on compliance, ordering MIDs, report breaches. Manages your PCI location and the assets with them. 1 12 12.3.7 - A list of companyapproved products 1 12 Acceptable network locations for the technology

Manage PCI scope Manages PCI payment channels Manage PCI scope: Manages your PCI payments 1 12 Payment channels Manage PCI scope: Manages all the systems associated 1-12 reference systems with your PCI estate PCI dashboard Provides a dashboard revealing the key 1-12 PCI measurable attributes across your estate Manages you PCI policy, associate them to your PCI estate and PCI Risk register Manages PCI risks, incidents and discoveries by all your business units and 3 rd parties. QSA register QSA point of contact, review dates and access to provide remote support ASV register ASV point of contact, review dates and access to provide remote access for QSA/ASV review and reports PCI Audit and BAU reports Approved scanning Manages all the ASV/QSA reviews and reports Capturing all the PCI BAU audit reports required for PCI DSS 12.5.3 Creating and distributing security incident response and escalation procedures are formally assigned. 12.9.1 12.9.6 Incident Response Plan 1 12 11 Regularly test security systems and processes 11 Regularly test security systems and processes 10 Track and monitor all access to network resources and cardholder data PCI projects for assessment & Escalated PCI projects 3 rd party service provider The service catalogue of PCI approved service provider 1.1.1 Obtain and examine the firewall configuration standards and verify a formal process is in place for all changes, including management approval and testing for all changes to external network connections and the firewall configuration. 6.3.1 All changes (including patches) are tested before being deployed into production. 2 - Do not use vendor-supplied defaults for system passwords and other security parameters. 6 Vendor-supplied security patches. 3.4a - Obtain documentation about the cryptographic

system used to protect stored data, including the vendor, type of cryptographic system, and the encryption algorithms. Enable accounts used by vendors for remote maintenance only during the time needed. 12.3.9 - Activation of modems used by vendors only when needed by vendors, with immediate deactivation after use. 12.1 - Read the information security policy, and verify the policy is published and disseminated to all relevant system users (including vendors, contractors, and business partners). 11.1.c - For Service Providers only, examine relevant code, documentation, and processes to verify that velocity checks and other transaction trend data are monitored in realtime and collected to detect fraudulent transaction attempts. 12.8 - Obtain contracts between the organization and any third-parties that handle cardholder data (for example, backup tape storage facilities, managed service providers such as Web hosting companies or security service providers, or those that receive data for fraud modelling purposes). Prioritized approach 1 12

The PCI DSS reporting requirements and our solution PCI reqs Focus Evidence PCI-selfassessment.com solution & compliance approach 1 Install and maintain a firewall configuration to protect data 1.1 Obtain and inspect the firewall configuration standards and other documentation specified below to obtain evidence the standards are complete Each firewall Asset is supported by a firewall baseline policy, a configuration that all new firewalls will adhere to. Integration with network security device logs and reports 1.1.1 Obtain and examine the firewall configuration standards and verify a formal process is in place for all changes, including Firewalls management approval and testing for all changes to external network connections and the firewall configuration. Our modules: PCI Policy register PCI BAU reports PCI BAU reports PCI Project register PCI risk assessment PCI risk register 1.1.2 Obtain and examine a current network diagram, and verify that it documents all connections to cardholder data, including any wireless networks, and that the diagram is kept current. 1.1.3 1.1.4 1.1.5 1.1.6 Verify that firewall configuration standards include a description of groups, roles, and responsibilities for logical management of network components Each network asset can have its own network diagram, its location and the risk assessment document that is maintained periodically. Covered by Firewall configuration Firewall policy & standards associated with the firewall asset. 2 Do not use vendor-supplied defaults for system passwords and other security parameters 2.1 2.1.1 2.2 2.2.1 Use the sample of system components, and attempt to logon (with system administrator help) to the devices using default vendor-supplied accounts Each PCI Asset will have an accompanying PCI policy & baseline that will reinforce the requirements are inherited by each asset and associated projects that use the asset.

and passwords, to verify that default accounts and passwords have been changed. (Use vendor manuals and sources on the Internet to find 2.2.2 Obtain and inspect enabled system services, daemons, Supplier and protocols from the systems & sample of (insert number security and/or description of sample). Verify that unnecessary or insecure services or protocols are not enabled, and that any potentially dangerous ones are justified and documented as to appropriate use of the service (for example FTP is not used, or is encrypted via SSH or other technology). PCI risk assessment ALL PCI systems are listed in the PCI Asset register, with asset details included in each one. System services and protocols are included in the PCI baseline for each system. All new assets, projects and services that use it will adhered to the standard. PCI Systems register 2.2.3.a 2.2.3.b Inquire of system administrators and/or security managers to determine that they have knowledge of common security parameter settings for their operating systems, database servers, Web servers, and wireless systems. Verify that common security parameter settings are included in the system configuration standards. All systems classed as Assets will have Asset owners that will have the obligation to provide necessary details for their assets. Minimum security standard per asset will set the baseline for all system configuration based on assets. 2.2.3.c Select a sample of (insert number and/or description of sample) from all system components the samples of databases and critical servers (including wireless), and verify that common security parameters are set appropriately. 2.2.4 Obtain and inspect system files to determine that all PCI BAU Audit logs PCI BAU Audit logs

unnecessary functionality (for example, drivers, features, subsystems, and file systems) is removed. Also, verify enabled functions are documented, support secure configuration, and are the only ones present on the sampled machines. 2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/Transport Layer Security (TLS) for Webbased management and other non-console administrative access. 3 Protect Stored Data 3.1 Card holder data protection Keep cardholder information storage to a minimum. Develop a data retention and disposal policy. Limit your storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy. A programmatic (automatic) process to remove, at least on a quarterly basis, stored cardholder data that exceeds business retention requirements. Alternatively, performance of an audit, at least on a quarterly basis, to verify that stored cardholder data does not exceed business retention requirements. 3.2.1 Do not store the full contents of any track from the magnetic stripe (on the back of the card, or in a chip). 3.2.2 Do not store the card validation code (three-digit or four-digit value printed on the front or back of a PCI BAU Audit logs PCI Policy register PCI 3 rd party register The PCI compliance policy will be designed to ensure you set out the Dos and Donts of PCI in operation. This policy will be used as a baseline, apply

payment card [for example, CVV2 data, or CVC2 data]). 3.2.3 Examine the following from the sample selected, and obtain evidence that the PVV data is not stored under any circumstance: Incoming transaction data Transaction logs History files Several database schemas 3.3 Obtain and review written policies and review online displays of credit card data to determine that the credit card numbers are masked when displaying cardholder data, except for those with a specific need to see full credit card numbers. 3.4.a Obtain documentation about the cryptographic system used to protect stored data, including the vendor, type of cryptographic system, and the encryption algorithms. Verify that data is rendered unreadable using one of the following algorithms: Oneway hashes (hashed indexes) such as SHA-1 Truncation or masking Index tokens and PADs, with the PADs being securely stored Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures 3.5.1 Examine user access lists to determine that access to cryptographic keys is restricted to very few to Assets or PCI scopes and all changes to the PCI scope and its assets will inherit the policy and standard. PCI Policy register (PED or PDQ) PCI BAU Audit reports Our modules: PCI BAU Audit reports custodians. 3.6 Fully document and implement all key management processes and procedures 4 Encrypt transmission of cardholder and sensitive information across public networks

4.1 Cardholder and sensitive information in transit Use strong cryptography and encryption techniques (at least 128 bit) such as SSL, Point-to-Point Tunneling Protocol (PPTP), and Internet Protocol Security (IPSEC) to safeguard sensitive cardholder data during transmission over public networks. 4.2 Never send cardholder information via unencrypted e-mail. 5 Use and regularly update anti-virus software 5.1 Up to date Antivirus software Deploy anti-virus mechanisms on all systems commonly affected by viruses (for example, PCs, and servers). 5.2 Ensure that all anti-virus mechanisms current, and actively running, and capable of generating audit logs. Our modules: PCI systems PCI 3 rd party service providers The PCI compliance policy will state the prohibition of unencrypted email and inherited by all changes to it. Our modules: PCI systems PCI 3 rd party service providers PCI risk assessment PCI project register PCI project escalation Antivirus update relate to Assets that are capable of having Anti-virus and obviously need to be updated. Each Asset has to be registered and the evidence of the update maintained periodically by the Asset owner. Logs of such updates need to be stored giving the QSA a suite of choice to pick from Our modules: PCI BAU reports PCI 3 rd party register 6 Develop and Maintain Secure Systems and Applications 6.1 Vendorsupplied security patches. Using the sample of (insert either number or description of sample) system components and software, compare the list of security patches installed on each system to the most recent vendor security patch list, to determine that We link 3 rd party service providers to their products and services and record the frequency of the updates per asset. Our modules: PCI products PCI BAU reports

current vendor patches are installed. 6.2 Inquire of those responsible for processes in place to identify new security vulnerabilities, and verify that the process includes using outside sources for security vulnerability information and updating the system configuration standards reviewed in Requirement 2 as new vulnerability issues are found. 6.3 Obtain and review written software development processes to confirm they are based on industry standards and that security is included throughout the life cycle. 6.3.1 All changes (including patches) are tested before being deployed into production. 6.3.2 The test/development environments are separate from the production environment, with access control in place to enforce the separation. 6.3.3 There is a separation of duties between those personnel assigned to the development/test environments, and those assigned to the production environment. 6.3.4 Examine data used in the testing and development environments, and verify that production data (real credit card numbers) is not used for testing and development purposes, or is sanitized before use. 6.3.5 Test data and accounts are removed before a production system becomes active. PCI 3 rd party register The PCI compliance policy needs to cover each PCI software development cycle. PCI change management PCI risk assessment PCI BAU reports PCI 3 rd party register

6.3.6 Custom application accounts, usernames, and/or passwords are removed before system goes into production or is released to customers 6.3.7.a Obtain and review written policies to confirm they dictate that code reviews are required, and must be performed by individuals other than the originating 6.3.7.b author of the code Confirm that code reviews are occurring for new code as well as after code changes. 6.4 Follow change control procedures for system and software configuration changes. 6.4.1.a Obtain evidence that documentation of customer impact in included in the change control documentation for each sampled change. 6.4.2 Obtain evidence that management sign-off by appropriate parties is present for each sampled change. 6.4.3 Obtain evidence that testing that verifies operational functionality was performed for each sampled change 6.4.4 Obtain evidence that backout procedures are prepared for each sampled change. 6.5 Develop Web software and applications based on secure coding guidelines such as the Open Web Application Security Project (OWASP) guidelines. Review custom application code to identify coding vulnerabilities. From the following Web site, www.owasp.org, see The PCI change management PCI risk assessment PCI Policy register

6.5.a Ten Most Critical Web Application Security Vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes Obtain and examine software development processes for any Webbased applications. Confirm the process requires training in secure coding techniques for developers, and is based on guidance such as the OWASP guidelines. 7 Restrict access to data by business need-to-know 7.1 User access control to systems Limit access to computing resources and cardholder information to only those individuals whose job requires such access. The PCI policy defines the requirement, all changes inherit the policy, risk assessment ensures that all risk assessments enforce the policy and BAU logs confirm the policy is in operation. PCI change management PCI risk assessment PCI Policy register PCI BAU logs 8 Assign a unique ID to each person with computer access 8.1 Identify all users with a unique username before allowing them to access Uniqueness of user identity system components or cardholder data. 8.2 Employ at least one of the methods below, in addition to unique identification, to authenticate all users: Password Token devices (for example, SecurID, certificates, or public key) Biometrics The PCI policy defines the requirement, all changes inherit the policy, risk 8.3 Implement two-factor authentication for remote access to the network by employees, administrators, and third parties. Use technologies such as assessment ensures that all risk assessments enforce the policy and BAU logs confirm the policy is in operation.

Remote Authentication Dial- In User Service (RADIUS) or Terminal Access Controller Access Control System (TACACS) with tokens, or VPN with individual certificates. 8.4 Encrypt all passwords during transmission and storage, on all system components. 8.5 Ensure proper user authentication and password management for non-consumer users and administrators, for all system components. 8.5.1 Control the addition, deletion, and modification of user IDs, credentials, and other identifier objects. 8.5.2 Verify user identity before performing password resets. 8.5.3 Set first-time passwords to a unique value per user and change immediately after first use. 8.5.4 Immediately revoke accesses of terminated users. 8.5.5 Remove inactive user accounts at least every 90 days. 8.5.6 Enable accounts used by vendors for remote maintenance only during the time needed. 8.5.7 Distribute password procedures and policies to all users who have access to cardholder information. 8.5.8 Do not permit group, shared, or generic accounts/ passwords. 8.5.9 Change user passwords at least every 90 days. 8.5.10 Require a minimum password length of at least seven characters. PCI change management PCI risk assessment PCI Policy register PCI BAU logs

8.5.11 Use passwords containing both numeric and alphabetic characters. 8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords used. 8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts. 8.5.14 Set the lockout duration to thirty minutes or until administrator enables the user ID. 8.5.15 If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal. 8.5.16 Authenticate all access to any database containing cardholder information. This includes access by applications, administrators, and all other users. 9 Restrict physical access to cardholder data 9.1 Physical security requirements Use appropriate facility entry controls to limit and monitor physical access to systems that store, process, or transmit cardholder data. 9.1.1 Use cameras to monitor sensitive areas. Audit this data and correlate with other entries. Store for at least three months unless otherwise restricted by law 9.1.2 Restrict physical access to publicly accessible network jacks 9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder information is accessible. Employee refers to full and part time employees, temporary The PCI policy defines the requirement, all changes inherit the policy, risk assessment ensures that all risk assessments enforce the policy and BAU logs confirm the policy is in operation. PCI change management PCI risk assessment PCI Policy register - physical security PCI BAU logs

employees/personnel, and consultants who are resident on the entity s site. Visitor refers to a vendor, guest of an employee, service personnel, or anyone who enters the facility for a short duration, usually not more than one day. 9.3.1 Observe visitors to verify the use of ID badges. Attempt to gain access to the data center to verify that a visitor ID badge does not permit unescorted access to physical areas that store cardholder data. 9.3.2 Observe employee and visitor badges to verify that ID badges clearly distinguish employees from visitors/outsiders and that visitor badges expire. 9.3.3 9.3.3 Observe visitors leaving the facility to verify visitors are asked to surrender their ID badge upon departure or expiration date. 9.4 Use a visitor log to retain a physical audit trail of visitor activity. Retain this log for a minimum of three months, unless otherwise restricted by law. 9.5 Review policies and procedures for backups and visit the offsite storage facility to determine that backup media are stored in a physically secure, fireproof, offsite location. 9.6 Obtain the policies and procedures for protecting all paper and electronic media that contains cardholder data. Verify that the process includes controls for paper and electronic media in

computer rooms and data centers, as well as paper receipts, paper reports, faxes, CDs and disks in employee desks and open workspaces, and PC hard drives. 9.7 Verify that a policy exists to control distribution of cardholder information, covers all distributed media including that distributed to individuals 9.7.1 All media should be labelled so that it can be identified as confidential. 9.7.2 All media sent outside the facility is logged and authorized by management, and sent via secured courier or other delivery mechanism that can be tracked. 9.8 Select a recent sample of several days of offsite media tracking logs, and verify the presence in the logs of tracking details and proper management authorization. 9.9 Obtain the policy for controlling storage and maintenance of hardcopy and electronic media, and verify this policy requires periodic media inventories. 9.9.1.a 9.9.1.b 9.10.a 9.10.1.a Obtain and review the media inventory log to verify that periodic media inventories are performed. Obtain and review processes in place to verify that media is securely stored. Obtain the periodic media destruction policy and verify it covers all media with cardholder data. Verify that hard-copy materials are cross cut shredded, incinerated, or

pulped, in accordance with ISO 9564-1 or ISO 11568-3. 9.10.1.b Observe storage containers for information to be destroyed to verify that containers are secured. For example, verify that a to be shredded container has a lock preventing access to the contents. 9.10.2 Verify that electronic media is destroyed beyond recovery by using a military wipe program to delete files, or via degaussing or otherwise physically destroying the media. 10 Track and monitor all access to network resources and cardholder data 10.1 Network monitoring Verify, via observation and inquiry of the system administrator, that audit trails are enabled and active, including for any connected wireless networks. 10.2 Confirm though inquiry, review of audit logs, and review of audit log settings for (insert as-of dates) for the samples of (insert number and/or description of sample) system components, 10.2.1 Logging of access to cardholder data 10.2.2 Logging of actions taken by any individual with root or administrative privileges 10.2.3 Logging of access to all audit trails 10.2.4 Logging of invalid logical access attempts 10.2.5 Logging of use of identification and authentication mechanisms 10.2.6 Logging of initialization of audit logs 10.2.7 Logging of creation and deletion of system level objects Working in collaboration with your networking monitoring providers, and system owners, ensure all the relevant PCI assets are captured and audit requirements defined with reports generated to assist reviews. The PCI policy defines the requirement, all changes inherit the policy, risk assessment ensures that all risk assessments enforce the policy and BAU logs confirm the policy is in operation. PCI change management PCI products PCI 3 rd party service providers PCI risk assessment PCI Policy register - Network monitoring policy PCI BAU logs

10.3 Confirm through inquiry and observation, for each auditable event mentioned at 10.2 above, that the audit trail captures the following information: 10.3.1 User identification 10.3.2 Type of event 10.3.3 Date and time stamp 10.3.4 Success or failure indication, including those for wireless connections 10.3.5 Origination of event 10.3.6 Identity or name of affected data, system component, or resources 10.4 Obtain and review the process for getting and distributing the correct time within the organization. Also obtain and review related system parameter settings for the sample of (insert number and/or description of sample) system components. Verify the following is included in the process and implemented: NTP or similar technology is used for time synchronization Two or three central time servers within the organization receive external time signals (directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC [formerly GMT]), peer with each other to keep accurate time, and share the time with other internal servers (for example, internal servers should not be all be receiving time signals from external sources). NTP is running the most recent version Specific external hosts are designated from

which the time servers will accept NTP time updates (to prevent an attacker from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the NTP service (to prevent unauthorized use of internal time servers). 10.5 Verify the following via inquiry of the system administrator and review of file permissions: 10.5.1 Only individuals who have a jobrelated need can view audit trail files. 10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation. 10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter. 10.5.4 Offload or copy logs for wireless networks onto a centralized internal log server or media that is difficult to alter. 10.5.5 Verify the use of file integrity monitoring or change detection software for logs by observing system settings and monitored files, as well as results from monitoring activities. 10.6.a Obtain security policies and procedures and determine that they include procedures to review security logs at least daily,

and that follow-up to exceptions is required. 10.6.b Through observation and interviews, determine that regular log reviews are performed for all system components 10.7.a Obtain security policies and procedures and determine that they include audit log retention policies and require audit log retention for at least one year. 10.7.b For the sample of (insert number and/or description of sample) system components, verify that audit logs are available online or on tape for at least one year. 11 Regularly test security systems and processes 11.1.a System testing Confirm through inquiry of security personnel that periodic security testing of the devices within the cardholder environment occurs. 11.1.b Verify that a wireless analyzer is used periodically to identify all wireless devices in use. 11.1.c For Service Providers only, examine relevant code, documentation, and processes to verify that velocity checks and other transaction trend data are monitored in realtime and collected to detect fraudulent transaction 11.2.a attempts. Inspect output from the most recent four quarters of network, host, and application vulnerability scans to verify that periodic security testing of the devices within the cardholder environment occurs. Confirm the scan process includes rescans We have an integrated ASV module that allows organisations to link into your PCI estate, review your PCI scope and in collaboration determine the assets that fall into the PCI periodic testing scope as well as scheduling the testing and reporting dates for the whole year. Non-compliance or nondelivery are automatically alerted on the risk register. This framework allows you to identify an ASV provider, present your list of PCI asset that fall into requirement 11 scope, agree test scope and dates, generate reports and store them in relation to each asset. Where risks emerge out of the tests, these will be lodged directly onto the risk register against the relevant assets. Our modules: ASV register QSA register QSA/ASV Audits

until clean results are obtained. 11.2.b To verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, inspect output from the four most recent quarters of external vulnerability scans to verify the following: Four quarterly scans occurred in the most recent 12-month period. The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities. The scans were completed by a vendor approved to perform the PCI security scanning procedures. 11.3 Obtain results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment. Confirm that any noted vulnerabilities were corrected. 11.4 Observe the use of network intrusion detection and/or prevention software on the network. Confirm IDS and/or IPS is in place to monitor and alert personnel of suspected compromises. Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection. 11.5 Verify the use of file integrity monitoring products by observing system settings and PCI risk register PCI BAU reports

monitored files, as well as reviewing results from monitoring activities. 12 Maintain a policy that addresses information security for employees and contractors 12.1 PCI policies Read the information security policy, and verify the policy is published and disseminated to all relevant system users (including vendors, contractors, and business partners). Also verify that: 12.1.1 The policy addresses all requirements in this specification. 12.1.2 The information security policy includes an annual risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment 12.1.3 The information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment. 12.2 Develop daily operational security procedures that are consistent with the requirements in this specification (for example, user account maintenance procedures, and log review procedures). 12.2.a Review the daily operational security procedures. Verify they are consistent with this specification, and include administrative and technical procedures for each of the requirements. 12.3 Obtain and examine the modem usage policy and verify that it specifies and/or requires: 12.3.1 Explicit management approval to use the device(s) 12.3.2 All device use is authenticated with The PCI compliance strategy in collaboration with the PCI policies and procedures can be set centrally and disseminated across every PCI location, asset and scope.

username and password or other authentication item (for example, token). 12.3.3 A list of all devices and personnel authorized to used the devices 12.3.4 Labeling of devices with owner, contact information, and purpose 12.3.5 Acceptable uses for the technology 12.3.6 Acceptable network locations for the technology 12.3.7 A list of company-approved products 12.3.8 Automatic disconnect of modem sessions after a specific period of inactivity 12.3.9 Activation of modems used by vendors only when needed by vendors, with immediate deactivation after use. 12.3.10 Disabling storage of cardholder data onto local hard drives, floppy disks or other external media when accessing such data remotely via modem. Also disabling of cut-and-paste, and print functions during remote access. 12.4 Verify that information security policies clearly define information security responsibilities for both employees and contractors. 12.5 Verify the formal assignment of information security to a Chief Security Officer or other securityknowledgeable member of management. Obtain information security policies and procedures to verify that the following information security responsibilities are specifically and formally assigned: Manage PCI scope PCI locations Manage PCI scope PCI products PCI 3 rd Party service providers PCI 3 rd party register

12.5.1 Creating and distributing security policies and procedures is formally assigned. 12.5.2 Monitoring and analyzing security alerts, and distributing information to appropriate information security and business unit management personnel, is formally assigned. 12.5.3 Creating and distributing security incident response and escalation procedures are formally assigned. 12.5.4 Administering user account and authentication management is formally assigned. 12.5.5 Monitoring and controlling all access to data is formally assigned 12.6 Obtain security awareness program documentation, and verify that it contains the following components: 12.6.1 Multiple methods of communicating awareness and educating employees (for example, posters, letters, or meetings). 12.6.2 Requirement for employees to acknowledge in writing that they have read and understood the company s information security policy. 12.7 Inquire of Human Resource department management and determine that there is a process in place to perform background checks on potential employees who will have access to systems, networks, or cardholder data. These background checks should include pre-employment, criminal, credit history, and reference checks. 12.8 Obtain contracts between the organization and any PCI Policy register PCI project risk assessments PCI risk register PCI projects PCI access management policy PCI training and awareness policy

third-parties that handle cardholder data (for example, backup tape storage facilities, managed service providers such as Web hosting companies or security service providers, or those that receive data for fraud modeling purposes). Verify that the PCI Data Security Standard requirements relevant to the business relationship between the organization and the third-party are included in the contract. Specifically verify the following information is included in the contract: 12.8.1 Contract provisions include acknowledgement by the third-party of their responsibility for securing cardholder data. 12.8.2 Contract provisions include ownership and acceptable uses of cardholder data. 12.8.3 Contract provisions include appropriate business continuity provided by the third-party such that the third-party s services will be available in the event of a major disruption or failure. 12.8.4 Contract provisions allow for audits by Visa or Visaapproved entities in the event of a cardholder data compromise. 12.8.5 Contract provisions require continued security of cardholder data during and after contract terminations. 12.9.1 Verify that the Incident Response Plan and related procedures includes: Roles, responsibilities, and communication strategies in the event of a compromise Coverage and responses for all critical system PCI compliance strategy will include contractual provisions in the PCI policies to identify ownership and acceptable of card data. This policy will be applicable to internal users as well as 3 rd party suppliers. PCI Policy register PCI 3 rd party register PCI risk register PCI project register PCI compliance strategy will indicate the contractual provisions required on all contracts and applicable to all PCI payment channels. All new entries into the channel automatically inherit the PCI contract policy. The incident response policy is linked to the risk register which captures

components Notification, at a minimum, of credit card associations and Acquirers Strategy for business continuity post compromise Reference or inclusion of incident response procedures from card associations Analysis of legal requirements for reporting compromises (for example, per California bill 1386, notification of affected consumers is a requirement in the event of an actual or suspected compromise, for any business with California residents in their database). 12.9.2 Testing of the plan at least annually. 12.9.3 Verify via observation and review of policies, that there is 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, critical IDS alerts, and/or reports of unauthorized critical system or content file changes. 12.9.4 Verify via observation and review of policies, that staff with security breach responsibilities are periodically trained. incidents as risks from the business units and ensures the incident response plans implemented to address the risks. Lessons from the risks are reviewed and use to update the incident response plan whose review frequency can be set automatically. Our modules: PCI risk register PCI business units PCI asset register PCI compliance strategy will include PCI training policy and procedures. The PCI risk register will be made available to staff to enter risks associated with their areas. Our modules: PCI risk register PCI business units PCI asset register 12.9.5 Verify via observation and review of processes, that monitoring and responding to alerts from security systems is included in the Incident Response Plan. The incident response policy is linked to the risk register which captures incidents as risks from the business units and ensures the incident response plans implemented to address the risks. Lessons from the

12.9.6 Verify via observation and review of policies that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. risks are reviewed and use to update the incident response plan whose review frequency can be set automatically. Our modules: PCI risk register PCI business units PCI asset register