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, risks and BAU reports.
8,9, 11 &12
New PCI scope
request register
To manage request for MIDs, new payment channels, new payment solutions, non-service catalogue projects.
1 – 12
Manage PCI scope:
PCI products
Manages the list of PCI approved products as part of the service catalogue.
12.3.7 - A list of company-approved products
Manage PCI scope:
Payment
processors
Reporting on compliance, ordering MIDs, report breaches.
1 – 12
Manage PCI scope:
PCI Locations
Manages your PCI location and the assets with them.
Manage PCI scope
Manages PCI payment channelsManage PCI scope:
Payment channels
Manages your PCI payments 1 – 12
Manage PCI scope:
reference systems
Manages all the systems associated with your PCI estate
1 - 12
PCI dashboard
Provides a dashboard revealing the key PCI measurable attributes across your estate1 -12
PCI policy register
Manages you PCI policy, associate them to your PCI estate andPCI Asset register
PCI Risk register
Manages PCI risks, incidents and discoveries by all your business units and 3rd parties.12.5.3 Creating and
distributing security incident response and escalation procedures are formally assigned.
12.9.1 – 12.9.6 Incident Response Plan
QSA register
QSA point of contact, review dates and access to provide remote support1 – 12
ASV register
ASV point of contact, review dates and access to provide remote access for Approved scanning11 Regularly test security
systems and processes
QSA/ASV review
and reports
Manages all the ASV/QSA reviews and reports
11 Regularly test security
systems and processes
PCI Audit and BAU
reports
Capturing all the PCI BAU audit reports required for PCI DSS
10 Track and monitor all
access to network resources and cardholder data
PCI projects for
assessment &
Escalated PCI
projects
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.
3
rdparty service
provider
The service catalogue of PCI approved service provider
2 - Do not use vendor-supplied
defaults for system passwords and other security parameters.
6 – Vendor-supplied security
patches.
3.4a - Obtain documentation
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
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
Firewalls
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
Our modules: PCI Asset register PCI Policy register PCI BAU reports
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.
PCI BAU reports PCI Asset register 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.
Each network asset can have its own network diagram, its location and the risk assessment document that is maintained periodically.
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
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.
Supplier systems & security
and passwords, to verify that default accounts and passwords have been changed. (Use vendor manuals and sources on the Internet to find
PCI Asset register PCI policy register PCI risk assessment
2.2.2 Obtain and inspect enabled
system services, daemons, and protocols from the sample of (insert number 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).
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.
Our modules include: PCI Systems register PCI Asset register
2.2.3.a 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.
All systems classed as Assets will have Asset owners that will have the obligation to provide necessary details for their assets.
2.2.3.b Verify that common security
parameter settings are included in the system configuration standards.
Minimum security standard per asset will set the baseline for all system configuration based on assets. Our modules include:
PCI Asset register
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.
Our modules include: PCI BAU Audit logs
2.2.4 Obtain and inspect system
files to determine that all
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 Web-based management and other non-console administrative access.
Our modules include: PCI BAU Audit logs
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.
Our modules include: PCI Policy register PCI 3rd party register
PCI Asset register
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).
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
3.2.2 Do not store the card
payment card [for example, CVV2 data, or CVC2 data]).
to Assets or PCI scopes and all changes to the PCI scope and its assets will inherit the policy and standard. Our modules include:
PCI Policy register
PCI Asset register (PED or PDQ) PCI BAU Audit reports
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: • One-way 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 custodians.
Our modules:
PCI BAU Audit reports PCI policy register
3.6 Fully document and
implement all key
management processes and procedures
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.
Our modules: PCI policy register PCI systems
PCI 3rd party service providers
4.2 Never send cardholder
information via unencrypted e-mail.
The PCI compliance policy will state the prohibition of unencrypted email and inherited by all changes to it.
Our modules: PCI policy register PCI systems
PCI 3rd party service providers
PCI risk assessment PCI project register PCI project escalation
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).
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 Asset register PCI BAU reports PCI policy register PCI policy register PCI 3rd party register
5.2 Ensure that all anti-virus
mechanisms current, and actively running, and capable of generating audit logs.
6 Develop and Maintain Secure Systems and Applications
6.1
Vendor-supplied 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 3rd party service providers to
their products and services and record the frequency of the updates per asset. Our modules:
current vendor patches are installed.
PCI policy register PCI 3rd party register
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.
The PCI compliance policy needs to cover each PCI software development cycle.
Our modules include: PCI change management PCI risk assessment PCI BAU reports PCI policy register PCI policy register PCI 3rd party register
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
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 author of the code
6.3.7.b 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.
Our modules include: PCI change management PCI risk assessment PCI Policy register
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
back-out 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
Ten Most Critical Web Application Security Vulnerabilities.” Cover prevention of common coding vulnerabilities in software development processes
6.5.a Obtain and examine
software development processes for any Web-based 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.
Our modules include: 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
Uniqueness of user identity
Identify all users with a unique username before allowing them to access system components or cardholder data.
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.
Our modules include:
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
8.3 Implement two-factor
Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access Control System (TACACS) with tokens, or VPN with individual certificates.
PCI change management PCI risk assessment PCI Policy register PCI BAU logs
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
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.
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.
Our modules include: PCI change management PCI risk assessment
PCI Policy register - physical security PCI BAU logs
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
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
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 Obtain and review the
media inventory log to verify that periodic media inventories are performed.
9.9.1.b Obtain and review
processes in place to verify that media is securely stored.
9.10.a Obtain the periodic media
destruction policy and verify it covers all media with cardholder data.
9.10.1.a Verify that hard-copy
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.
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.
Our modules include: PCI change management PCI products
PCI Asset register
PCI 3rd party service providers
PCI risk assessment
PCI Policy register - Network monitoring policy
PCI BAU logs
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
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
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
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.
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 non-delivery 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 PCI Asset register
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 attempts.
11.2.a Inspect output from the
most recent four quarters of network, host, and
until “clean” results are obtained.
PCI risk register PCI BAU reports
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
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:
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.
PCI policy register PCI Asset register
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
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
PCI Asset register PCI policy register
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
Manage PCI scope – PCI locations
12.3.7 A list of company-approved
products
Manage PCI scope – PCI products PCI 3rd Party service providers
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.
PCI Asset register PCI policy register PCI 3rd party register
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.
PCI policy register
12.5 Verify the formal
assignment of information security to a Chief Security Officer or other security-knowledgeable member of management. Obtain information security policies and procedures to verify that the following information security responsibilities are specifically and formally assigned:
12.5.1 Creating and distributing security policies and procedures is formally assigned.
PCI Policy register
12.5.2 Monitoring and analyzing
security alerts, and
distributing information to appropriate information security and business unit management personnel, is formally assigned.
PCI project risk assessments PCI risk register
PCI projects
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.
PCI access management policy
12.5.5 Monitoring and controlling
all access to data is formally assigned
PCI Asset register
12.6 Obtain security awareness
program documentation, and verify that it contains the following components:
PCI training and awareness policy
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
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:
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 3rd party suppliers.
Our modules include: PCI Policy register PCI Asset register PCI 3rd party register
PCI risk register PCI project register
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 Visa-approved entities in the event of a cardholder data compromise.
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.
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
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).
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 policy register PCI risk register PCI business units PCI asset register
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.
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 policy register 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.
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.
